Archive

Ex-Amplify.com

The Rightshifting Ethos

March 20, 2011
Archive, Ex-Amplify.com, Rightshifting
Leave a comment

The Rightshifting Ethos

[From the Archive: Originally posted at Amplify.com Mar 20, 2011]

I tweeted this morning:

“Say what you believe – and see who follows” ~ Seth Godin | +1

followed by:

“I believe that a Rightshift of knowledge-work businesses will bring improved health, wealth and wisdom for [both] individuals and society at large”

Given the chord I know this strikes with some folks, I thought I’d explain this belief in just a little more detail…

Health

Many researchers have written of the correlation between meaningless work, lack of job satisfaction, etc and personal health issues brought on by e.g. stress. Marcus Buckingham in First Break All the Rules summarises 25 years of Gallup research into what makes for a satisfying job. And recent research points to the deleterious effects of job-related stress on individuals’ health and well-being.

So, I believe that an improvement in job satisfaction brings about a reduction in job-related health issues. Happier people are indeed healthier people. And given the long hours almost all of us spend working, a happier work experience can contribute markedly to a happier life.

Rightshifting an organisation means “making it more effective at achieving its intent, or business objectives” (see chart):

(For the purposes of this post, we can use the green productivity line as a proxy for job satisfaction).

In practice, significant improvements in organisational effectiveness can only come about through the organisation transitioning to a different mindset. The Marshall Model explains this in more detail (see the Marshall Model White Paper, and diagram, below):

I don’t think it’s any coincidence that as we move to the right on this diagram, we find organisations where job satisfaction is much higher than in those organisations to the left. So, Rightshifting any given organisation means that folks in that organisation will find greater job satisfaction, engagement, etc. And this means, I believe, that they will also have less (negative) stress and therefore improved health. And if people are less stressed and happier at work, I also believe that will contribute, indirectly, to a more healthy society for all of us.

Wealth

As organisations shift to the right (become more effective), that implicitly means that they will be more successful commercially. Margins should improve, as should revenue and market share. Couple this with a more enlightened and “fairer” attitude towards sharing success with all stakeholder (including employees), and I believe that those who work in rightshifted organisations will benefit by earning more than their counterparts in those organisations to the left. And as organisations earn more, and move to a perspective of e.g. greater corporate social responsibility, I believe the commercial successes of these organisations will trickle-down directly and indirectly into the greater prosperity of their host societies.

Wisdom

Organisations have been locked, seemingly irrevocably, in the Taylorist, Theory-X, command-and-control approach to management for more than a century now. Rightshifted organisations have learned that this perspective on the management of organisations (specifically, of knowledge-work organisations) has outlived its usefulness, and other, more effective, and moreover, more humane means to managing work now exist. This seems like wisdom to me.

Conclusion

This is what I believe. If you believe in the same interpretation of cause and effect, and share my hope for a better, more humane world of work, civil society, and world in general, I invite you to join with us in the Rightshifting movement. Thank you for reading.

– Bob

Rightshifting Transitions (Part 2)

March 6, 2011
Archive, Ex-Amplify.com, Organisational effectiveness, Rightshifting
1 Comment

Rightshifting Transitions (Part 2)

[From the Archive: Originally posted at Amplify.com Mar 6, 2011]

The Essence of the Three Rightshifting Transitions

Part 2 – Analytic to Synergistic

The Marshall Model proposes that there are three fundamental transitions that any business will encounter on its rightshifting journey (i.e. the journey to significantly improved organisational effectiveness).

Encountering these transitions is inevitable, although businesses generally do not recognise a transition when they (most often, unwittingly) bump into it. And given the low probability of making a successful transition, any one business may repeatedly bump into the same transition some number of times.

The second transition, and the one we’ll discuss here today, is from the Analytic mindset to the Synergistic.

Analytic to Synergistic

Most businesses that discover the value of discipline settle comfortably into the Analytic (aka mechanistic) mindset for the long haul. Most such businesses do not survive long enough to progress past this Analytic mindset and experience the more effective Synergistic and even Chaordic approaches. (Hence, btw, most executives, managers and employees never get to experience working under anything other than Ad-hoc and Analytic mindsets.)

Setting aside the reasons for this (a hot topic for a future post), those few businesses that continue to strive for futher improvements to their effectiveness will, sooner or later, encounter the transition to the Synergistic mindset. Again, this encounter is generally unexpected and unrecognised, even when the business is mired in the day-to-day practicalities of the transition.

Successfully accomplishing this transition involves abandoning common notions of discipline, such as hierchical management, extrinsic motivation, functional decomposition of the organisation into silos, local optimisations, targets, projects, conformance, appraisals, coercion, etc. Note: This does NOT imply abandoning an appreciation of the value of discipline itself, just its traditional manifestations.

For those people within the business used to a structured, command-driven environment where e.g. managers make the decisions and workers do the work, these changes can be just as traumatic as those associated with the Ad-hoc to Analytic transition (see previous post). And again; some people may embrace the changes, some may adapt, others may leave, and some may be required to leave (i.e. fired).

If the transition is successful (and most are not, especially when people fail to recognise what’s happening), the business finds itself with a markedly new and different view of the world of work. A world where decisions are made collaboratively, most often by the people doing the work; horizontal value streams replace hierarchical management as the prevailing structural paradigm; stakeholders (especially customers) and their needs drive business decisions; and everyone in the extended value streams (or value networks) are bound together in, and energised by, a sense of common purpose. Discipline is no longer pursued for its own sake, but harnessed in service of that shared purpose. All stakeholders are much happier; growing the business seems like a breeze; and everything is achieved much more easily and effectively.

The successful Analytic to Synergistic transition educates a business (retrospectively) as to the value of (shared) purpose. Note: Simon Sinek with his “Golden Circle” model explains well the value of a (shared) sense of purpose.

Next time we’ll take a look at the third (and rarest of all) transition: from the Synergistic mindset to the Chaordic.

– Bob

Rightshifting Transitions (Part 3)

March 3, 2011
Archive, Ex-Amplify.com, Rightshifting
Leave a comment

Rightshifting Transitions (Part 3)

[From the Archive: Originally posted at Amplify.com Mar 3, 2011]

The Essence of the Three Rightshifting Transitions

Part 3 – Synergistic to Chaordic

The Marshall Model proposes that there are three fundamental transitions that any business will encounter on its rightshifting journey (i.e. the journey to significantly improved organisational effectiveness).

Encountering these transitions is inevitable, although businesses generally do not recognise a transition when they (most often, unwittingly) bump into it. And given the low probability of making a successful transition, any one business may repeatedly bump into the same transition some number of times.

The third transition, and the one we’ll discuss here today, is from the Synergistic mindset to the Chaordic. I.E. The Transition to the most effective organisation mindset of the model.

Synergistic to Chaordic

In this instalment, we’ll take a look as the third and final transition postulated by the Marshall Model: the Synergistic to Chaordic transition. (Note: the word Chaordic was first coined by Dee Hock during his evolution of the Visa organisation.)

Those (few) businesses that discover the value of Purpose – and the other aspects of the Synergistic mindset – find themselves also hooked on the beauty and power of continuous improvement. Once well-established in the new synergistic ways of doing things, these businesses find that their customers, staff and shareholders are all happily engaged in productively and jointly pursuing the organisation’s purpose.

For most such businesses, this is often more than enough, and the will to continuously improve is channelled into conducting their core business ever more effectively. But for the few, the lure of another significant uplift in the effectiveness of the whole organisation beckons: the Chaordic mindset.

Most synergistic businesses remain tied, more or less, to the apron strings of their effective application of (self) discipline and purpose. The Chaordic business seeks something more. It seeks the effectiveness that comes with being able to leverage its command of discipline and purpose in the pursuit of fleeting, ever-changing market “sweet-spots”. Like the quantum foam of the Cosmos, commercial opportunities are forever winking into and out of existence. Rare indeed are the businesses that can respond fast enough to *systematically* seize on these fleeting opportunities and turn them, time and again, into profitable, albeit most likely short-lived, commercial successes.

Successfully accomplishing the transition from Synergistic to Chaordic involves becoming intimately familiar and comfortable with the business reconfiguring itself on an almost daily basis. The certainties of established ways of doing things, with stable roles and responsibilities, and an established set of things to do – however Lean, Agile, holistic, collaborative, and so on – have to give way to a much more fluid and unpredictable reality.

Everyone in a Chaordic organisation is constantly aware that things can change fundamentally at any time, even with just a few minutes’ or hours’ notice.

The Primary Lesson of Each Transition

To recap, having successfully made one of the above transitions, a business can reflect (with the benefit of hindsight) and see that each transition provides a different lesson in improving organisational effectiveness:

  • Ad-hoc to Analytic – The value of discipline
  • Analytic to Synergistic – The value of (shared) purpose
  • Synergistic to Chaordic – The value of positive opportunism

As ever, I welcome your comments, observations and questions.

– Bob

Rightshifting Transitions (Part 1)

March 2, 2011
Archive, Ex-Amplify.com, Organisational effectiveness, Rightshifting
2 Comments

Rightshifting Transitions (Part 1)

[From the Archive: Originally posted at Amplify.com Mar 2, 2011]

The Essence of the Three Rightshifting Transitions

Part 1 – Ad-hoc to Analytic

The Marshall Model proposes that there are three fundamental transitions that any business will encounter on its rightshifting journey (i.e. the journey to significantly improved organisational effectiveness).

Encountering these transitions is inevitable, although businesses generally do not recognise a transition when they (most often, unwittingly) bump into it. And given the low probability of making a successful transition, any one business may repeatedly bump into the same transition some number of times.

The first transition, and the one we’ll discuss here today, is that from the Ad-hoc mindset to the Analytic mindset.

Ad-hoc to Analytic

Few businesses, when starting out, recognise the need for – and value of – discipline. And even those that do recognise this need will, at their outset, likely have few disciplines in place. New and successful ad-hoc businesses can grow for some months or even years before they get to the point where the folks in charge decide that “things just can’t go on any more being as disorganised as they have been”.

At this point the business begins to tinker with introducing some management structure, methods, controls, policies, procedures, oversight, etc, and thus begins the transition towards the Analytic mindset.

For those people in the business who have been used to making things up as they go along – and equally, not used to being held accountable, nor to following processes, conforming to standards, and so on – these changes can be very traumatic. Some of these folks may grudgingly adapt, others may quit, and some may even be required to leave (i.e. fired).

If the transition is successful (and many are not), the business finds itself with a markedly different view of the world of work, where management hierarchy, budgets, meetings, lines of reporting and so on replace the previous free-for-all. It’s almost always less fun, but at least it’s generally a little more effective than continuing in the the near-chaos of the Ad-hoc mindset. Customers are probably a little happier, and growing the business becomes a little more tolerable and predictable once more.

Thus the successful Ad-hoc to Analytic transition educates a business (retrospectively, for the most part) as to the value of discipline. Of course, some things are also lost along the way, most notably in my view, any kind of humanity and respect for the individual.

Next time we’ll take a look at the second transition: from the Analytic mindset to the Synergistic mindset.

– Bob

The Many Roles in Software Projects

February 25, 2011
Archive, Ex-Amplify.com, Software development
3 Comments

The Many Roles in Software Projects

[From the Archive: Originally posted at Amplify.com Feb 25, 2011]

I recently re-quoted (on Twitter) something Capers Jones has said recently in a LinkedIn Forum. His quote (about many software projects having more than 50 distinct roles) reminded me I had some years ago made a list of the many and varied roles found involved in software development project teams. (The list originally sparked by a Chapter from “XP Explained” by Kent Beck).

I thought I’d share that list here. Please feel free to suggest and share further additions or changes.

General Team Roles and Responsibilities

Any software-intensive product- or service- development project has at its core a team of people aiming to meet the collective needs of the project’s diaspora of stakeholders. This core team in turn relies on an extended team of other folks to provide it with the essential context in which it operates. Both groups need to do a great job to be sure of a great result.

N.B. Typically, each project should keep track of its own community of stakeholders and their respective needs.

The following tables describe the many and varied roles that need to be fulfilled in a successful project (n.b. in no particular order). Note that we’re generally talking about relative small teams, as small as just five to seven people. So we’re assuming that each team member will have to play a number of these roles, either at the same time or in frequent alternation.

The Core Development Team

Interaction Designer

  • Ensuring the “interaction goals” of the system are clearly articulated and agreed by all stakeholders.
  • Developing user personas.
  • Co-defining and blue-printing the overall behaviour of the product and its value proposition.
  • Choosing the overall system interaction metaphor.

Chief Engineer

  • Determines the (stakeholders) needs that the product must meet and continually oversees the development of the product to ensure that it’s on target to meeting those needs.
  • Listens to the stakeholders and then negotiates with the project team to address the stakeholders’ needs (and desires).
  • c.f. “The Surgeon” in Fred Brooks’ “Surgical Team” model (The Mythical Man Month)

Architect

  • Ensuring the product or service under development achieves its performance and other qualitative requirements.
  • Guiding the interfacing and Integration of the solution components of this project into the existing architectural landscape.

GUI Designer

  • Guiding look-and-feel decisions.
  • Helping write and clarify user stories and personas.
  • Elaborating user interaction guidelines and standards.
  • Analysing the system-in-use so as to continually refine usability and the user interface.

Requirements Analyst

  • Solicitation and elaboration of stakeholder needs and requirements.

Storyboard Artist

  • Illustrating user stories (e.g. graphically) during planning sessions, workshops, etc.

Content Artist

  • Creating, enhancing and modifying e.g. graphical content to suit its presentation context.

Technical Writer

  • Providing early feedback to the core and extended teams about e.g. desirable features.
  • Creating closer and more productive relationships with the various stakeholder communities (through e.g. creating tutorials, reference manuals, technical overviews, brochures, video, audio, etc.)

Internal Marketeer

  • Generating leads for additional features (a.k.a. value-add) amongst e.g. the stakeholder community.

Project Public Relations

  • Promoting the system and its features amongst the stakeholders – to maximise feedback, their participation in the development, and the visibility of the team and its outputs.
  • Generating interest in the product both amongst the stakeholders and the widest potential user community.

Internal Communications

  • Anticipating the general information needs of the projects stakeholder communities (re: e.g. schedules, budgets, timescales, progress, status, morale, events, etc.).
  • Ensuring those needs are met.

Cybrarian

  • Anticipating the technical information needs of the team (and, ideally, stakeholders too) and fulfilling these needs.
  • Maintaining the content of the project’s technical (internally-facing) wikis, etc.

Amanuensis

  • Ensuring that each and every relevant conversation, decision etc. within the project gets recorded and published to all the team and beyond.

Content Maven

  • Ensuring the timely availability of all necessary content in the appropriate format(s).
  • Separating content from presentation.

Technology Maven

  • Ensuring the team uses its available technologies to the best possible effect.

Methods and Practices Maven

  • Advising the team such tat everyone chooses and then uses relevant development methods and practices to the best possible effect.

Metricant

  • Advising on suitable approaches to making things visible, collecting metrics, and the metrics that might best serve the team.
  • Collecting metrics (measurements) according to the prevailing metrics plan.

Operations Maven

  • Ensuring the continuous availability of all the project development infrastructure – development servers, repositories, tools, workstations, printers, scanners, network connectivity.

Production Operations Maven

  • Ensuring the team has all necessary information regarding the prospective production (live) environment(s).

Site Reliability (SRE) Maven

  • Single point of responsibility and arbiter between the Dev and Ops teams. Ensures the product’s reliability and low latency. “Site Reliability Engineering is concerned with on the reliability and maintainability of large systems”.

Development Assets Security Maven

  • Ensuring only duly authorised people have access to the information, work-in-progress, codebase, etc. within the development infrastructure.

Release Coordinator

  • Ensuring the optimal transition of product releases into the production environment(s).

Stakeholder Security and Privacy Maven

  • Ensuring the product or service under development safeguards stakeholders’ security and privacy.

Toolsmith

  • Ensuring the continuous availability of all the projects tools – incl. compilers, editors, IDEs, source code repositories, etc.
  • Ensuring the project has the tools it needs to be optimally productive.

Test and Integration Maven

  • Ensuring the continuous availability of the current status of all candidate releases.
  • Ensuring the continuous availability of the continuous integration environment.
  • Continually co-ordinating, communicating and championing the project’s test strategy, principles and practices.
  • Creating or assisting in the creation of test scripts, test data and harnesses.
  • Monitoring results from automated tests.

Designer

  • Finding solutions to known requirements.
  • Exploring the requirement space.

Coder

  • Advising on economic feasibility of implementing designs / requirements in available programming languages.
  • Implementing i.e. user stories – in whatever language is most suited to the problem at hand (c.f. Polyglot Programming).

Risk Maven

  • Reducing or eliminating waste and rework.
  • Enhancing the chances of successful delivery of the system across all requirement dimensions.

Full-time Stakeholders

  • Representing the perspectives of themselves and /or their nominated stakeholder communities.

Feedback Maven

  • Ensuring that feedback from e.g. usability sessions, early-access programmes and live operations get incorporated into subsequent product releases.

Team Psychotherapist

  • Helping improve the well-being and mental functioning of the team.
  • Monitoring and helping improve individual and team motivation and morale.

Project Facilitator

  • Facilitating the interactions of the members of the core team
  • Facilitating the interactions of the members of the extended team
  • Facilitating the interactions between the core team and the extended team.
  • Continually reminding people of the big picture.
  • Maintaining synchronisation between the team’s plans and reality.

Coach

  • Maintaining alignment of purpose between all the various participating groups.
  • Helping people discover solutions to their challenges.

Process Champion

  • Driving continual process improvement.
  • Driving the continual identification and remediation of ineffective working practices – a.k.a. ScrumMaster.

Administrator

  • Ensuring all the little odds and ends get tied up.

Production Database Designer

  • Ensuring the product meets production DBA requirements.
  • Planning product features to support e.g. data schema migration.

Issues Maven

  • Ensuring that issues get recorded, tracked and closed.

Standards Maven

  • Ensuring all in-house and e.g. regulatory standards and constraints are understood by the team and adhered-to by the product.

Style Maven

  • Maintain the project’s Style Guide for e.g. document and other publication media styles.
  • Ensuring the continuous conformance of project styles to broader programme and corporate house style(s).
  • Monitoring the conformance to prevailing style guidelines of all project publications.
  • Encouraging awareness of and conformance to project style guidelines across all publishers within the project.

Budgeteer / Scrounger

  • Ensuring the project has the resources it needs to progress effectively, and the continued support of its resource (budget) holders.

Accessibility Maven

  • Ensuring the product supports access by people with disabilities.

Subcontracts Maven

  • Ensuring the optimal use of any contracted (third-party) suppliers and sub-contractors to the project.

The Extended Team

The Extended Team includes all those people not part of the Core Team that nevertheless have critical roles to play in the successful development and launch of the new product or service.

Product/Service Manager/Owner

  • Ensuring that the evolving product or service continually best meets stakeholders’ needs.
  • Resolving prioritisation conflicts regarding e.g. implementation of features (could be a Core Team role on occasion).

Executive

  • Providing resources, accountability.
  • Articulating big-picture goals.
  • Demanding continual improvement in the way things get done.
  • Presenting the team, its methods and achievements, positively to the rest of the organisation.
  • Protecting the team from the consequences of its success.
  • Resolving inter-project conflicts.

Other Stakeholders

  • Presenting their own views, perspectives and needs.
  • Reviewing plans, priorities, risks and deliverables.

Stakeholder Proxy

  • Representing the views, perspectives and needs of their potential stakeholder communities.
  • Reviewing plans, priorities, risks and deliverables.

Human Resources

  • Assisting in hiring, motivating and aligning the members of the core team.
  • Advising of Employment Law and company employment policies and procedures.

Domain Expert

  • Advising and guiding the team on domain-related issues (better as a Core Team role whenever possible).

Value Chain Maven

  • Ensuring the product works well w.r.t. inter-company (extended / integrated value chain) contexts

Content Provider

  • Providing the content, etc. for the product or service.

Development Process Advisor / Champion / Steward

  • Helping the project maintain a continual-process-improvement process awareness (Kaizen)
  • Helping with the selection and adoption of a suitable baseline process.
  • Anticipating the needs of each new project team w.r.t. suitable candidate baseline processes (Kaikaku).

Product Liability / IP Lawyer

  • Ensuring the product minimises exposure to product liability law suits.
  • Preventing patent and other IPR infringements.

Contracts Lawyer

  • Oversight of the contractual framework of the project.
  • Interpreting the legal, contractual requirements for the project to the core team.

Concierge

  • Relieving team members of personal administrivia and allowing them more time to focus on their own specialist contributions.
– Bob

Contextualising FlowChain

January 22, 2011
Agile, Archive, Ex-Amplify.com, Flowchain, Organisational effectiveness, Snippet, Software development
Leave a comment

Contextualising FlowChain

[From the Archive: Originally posted at Amplify.com Jan 22, 2011]

[Update: Grant is sadly no longer with us.]

My colleague and co-conspirator Grant Rule writes this piece, with which I concur on just about every point. Some “traditionalist” have already had some trouble seeing past their existing assumptions and approaching the ideas herein with an open mind. Maybe you can suspend disbelief for a few minutes while reading the full post?

Amplify’d from smsexemplar.com

Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create & throw away know-how, at – it seems – every opportunity. And crucially, they allow the C-suite and ‘business-side’ managers to ignore their responsibilities for the system of work and for the desired outcome.

Read more at smsexemplar.com

– Bob

A Great Example of the Synergistic Mindset

January 22, 2011
Archive, Ex-Amplify.com, Organisational effectiveness, Snippet
1 Comment

A Great Example of the Synergistic Mindset

[From the Archive: Originally posted at Amplify.com Jan 22, 2011]

Another great example of the Synergistic mindset in practice. If you’ve ever wondered what a business with a collective Synergistic mindset looks like in reality, this is a great description. And yes, this describes only the early days of a synergistic organisation – there’s so much more scope for improvement yet to come.

P.S. I’d love to hear how things have been going since the transition – if you have any info please let me know!

Amplify ’d from www.managementexchange.com:

Once I started reading it I could not put it down and read it cover to cover. I immediately knew that this was not only what this business unit needed to do, but that it also made the reasons behind the problems I had seen and experienced in hierarchical organizations crystal clear. Most striking to me was the sheer level of disengagement and dissatisfaction present in most workforces. If this didn’t scream out the fact that businesses were in dire need of a change, I really wasn’t sure what would.

Read more at www.managementexchange.com 

– Bob

There’s a Lot of it About (Bullshit)

January 20, 2011
Archive, Ex-Amplify.com, General, Snippet
Leave a comment

There’s a Lot of it About (Bullshit)

[From the Archive: Originally posted at Amplify.com Jan 20, 2011]

[Update: The original source article is no longer available. This post now links to a Wayback Machine archived copy]

A key observation, and very germane to the worlds of IT, software development, product development and consulting:

Amplify’d from www.regrettheerror.com

Battling Bullshit 

One challenge is that “digital and media literacy” is a very broad area. Allow me to focus one small but essential sliver of the new, urgent literacy: bullshit detection.

Bullshit, you see, is everywhere. It is being produced, perfected, pontificated and pushed out at astounding rates by all manner of people and organizations. It spreads and multiplies. It morphs and mutates. People spew it, broadcast it, print it, tweet it, like it, blog it.

The bad news is there is too much bullshit. The good news — cue the theme to The Six Million Dollar Man — is we have the technology to defeat it. The strange news is that very same technology is also helping spread bullshit. Let me put it this way:

The Internet is the single greatest disseminator of bullshit ever created.

The Internet is also the single greatest destroyer of bullshit.

In between is a confusing world that is far less binary than the above construction. As that Concordia student put it, it’s a world that sometimes seems characterized by “too much.”

Which means all of us need to develop what Ernest Hemingway called a “a built-in bullshit detector.“ Universities need to teach the new literacy, to give people the tools to sniff out bullshit and practice the art of verification.

Read more at www.regrettheerror.com

 – Bob

Employees’ Self-confidence – A Cinderella of Organisational Effectiveness

January 19, 2011
Archive, Ex-Amplify.com, Organisational effectiveness, Snippet
Leave a comment

Employees’ Self-confidence – A Cinderella of Organisational Effectiveness

[From the Archive: Originally posted at Amplify.com Jan 19, 2011]

Penned in 1994, and still an alien or ignored idea in most Analytic-minded organisations even today:

Note to self: applies to peers as much as to “subordinates” (ugly term).

Amplify’d from www.winstonbrill.com

One of a manager’s most important responsibilities is increasing subordinates’ self-confidence; employees then have a more optimistic—but realistic—view of their skills and talents. 

Increasing self-confidence offers more than psychic rewards.  If employees feel good about themselves, chances are you will notice that productivity and morale both improve.  Why?  First, self-confident people are decisive rather than tentative.  They can focus on their work responsibilities instead of worrying about the reactions of others, and they are optimistic about reaching their objectives.

Second, self-confident people are risk-takers, and taking risks is crucial in technical organizations.  These people are expressive; they forge ahead instead of waiting for someone else to show the way.  People who lack self-confidence, on the other hard, tend to play “catch up” rather than focus on progress.

Third, people who feel good about themselves are likely to increase the self-confidence of those around them.  Self-confident people are respected by colleagues and management, and they return that respect.

Once we decide that improving self-confidence among the staff is a vital responsibility for a manager, how do we go about it?  By accepting, praising, appreciating, encouraging, and reassuring.  Let’s examine these actions.

Read more at www.winstonbrill.com

– Bob

Traditional vs “New” Management Thinking

January 15, 2011
Archive, Ex-Amplify.com, Leadership, Organisational effectiveness, Snippet
Leave a comment

Traditional vs “New” Management Thinking

[From the Archive: Originally posted at Amplify.com Jan 15, 2011]

This post from the Deming Learning Network has many similarities with what I call the Analytic vs Synergistic thinking transition. See also the table, comparing the two mindsets.

Amplify’d from www.dln.org.uk [Note 23-Jan-2021: Original page long gone. Wayback Machine version is available here.]

Based on underlying perceptions we develop a management culture, with its methods, to address the challenges within our organisations. Our traditional culture was designed to maximise the return from capital and to control Labour. It was very successful. But the situation has changed or evolved. The challenge of the future is to recognise and then utilise the knowledge, creativity and spirit of staff. The traditional culture, as represented by the blue line, was not designed for this task. To maximise the potential of people requires new thinking; and from this new thinking will evolve new methods (red line).

A comparison between the management language of our traditional management culture with what is evolving with the new concepts:

Traditional LanguageLanguage of the Future
  • Hierarchical organisation chart
  • Supervision
  • Analytical Thinking – seeing the parts
  • Budgets and Targets
  • The Performance of the Individual
  • Job Specifications
  • Accountability (and Blame)
  • Staff Appraisal
  • Training on Individual
  • Standards
  • Auditing and Compliance
  • Performance Related Pay
  • Holistic Thinking – seeing the whole
  • Systems Thinking
  • Capability of the System
  • Interdependence
  • The Performance of the Team
  • Variation
  • Statistical Process Control
  • Stable and Unstable Systems
  • Self Organising Systems
  • Intrinsic Motivation
  • Our Needs as People
  • Theories as the Basis of Knowledge
  • Organisational Learning

Read more at http://www.dln.org.uk [Note 23-Jan-2021: Original page long gone. Wayback Machine version is available here.]

– Bob

The Constant Tension Between Rightshift and Left-drift

January 7, 2011
Archive, Ex-Amplify.com, Rightshifting, Snippet
Leave a comment

The Constant Tension Between Rightshift and Left-drift

[From the Archive: Originally posted at Amplify.com Jan 7, 2011]

To “Rightshift” simply means “to improve the effectiveness of an organisation by some amount”. Jamie Flinchbaugh reminds us in his recent blog post that efforts at Rightshifting are ALWAYS swimming against the tide of entropy – i.e. changes within and without the organisation that conspire to continually erode its effectiveness.

Most organisations, even those who invest much time and effort in improvement programmes, rarely manage to do much more than tread water in terms of a net Rightshift. Given the pace of technological change, technology businesses often feel this issue particularly acutely.

Is this a widely recognised phenomenon, or one of which most organisations remain unaware?

Amplify’d from jflinchbaugh.com

The simple reality is that our pace of improvement must move faster than the pace of entropy. You cannot escape the entropy. It might as well be the second wall of process improvement (not that there is a first).

Read more at jflinchbaugh.com

– Bob

The Term “Analytic Mindset” Defined

January 6, 2011
Archive, Ex-Amplify.com, Rightshifting
3 Comments

The Term “Analytic Mindset” Defined

[From the Archive: Originally posted at Amplify.com Jan 6, 2011]

Introduction

Given my frequent use of the terms “Analytic thinking”, Analytic Mindset” and so on – especially in the context of Rightshifting – you might find it useful to understand how I define the term “Analytic”.

Analytic Thinking, Mindset, Organisation

My choice of the designation (for the second of the four organisational mindsets in the Marshall Model) derives from the great Russell L Ackoff, who uses the term “Analytic” to label much the same thing.

This short video of Professor Ackoff talking about Systems Thinking explains more about the term “Analytic” in this context.

And for the record, here’s a short recap of my definition, as taken from my recent white paper “The Marshall Model of Organisational Evolution“:

Analytic organisations (e.g. those organisations with a prevailing, collective Analytic mindset) exemplify, to a large extent, the principles of Scientific Management a.k.a.Taylorism – as described by Frederick Winslow Taylor in the early twentieth century. Typical characteristics of Analytical organisation include:

  • A Theory-X posture toward staff.
  • Functional silos (e.g. Sales, Marketing, Finance, Operations, IT, HR, etc.).
  • Breaking things down into parts, and managing each part in isolation.
  • The belief that breaking the organisation into parts improves chances for business success.
  • Local optimisations
  • Personal accountability and the “single wringable neck”.
  • A management focus on e.g. costs and ‘efficiencies’, including Cost Accounting.

Middle-managers are seen as owners of the way the work works, channelling executive intent, allocating work and reporting on progress, within a command-and-control style regime. The Analytic mindset recognises that the way work is done has some (limited) bearing on costs and the quality of the results.

N.B. Some folks, including Tom Burns, have used the synonym “Mechanistic”.

– Bob

We’re All Human (Even CEOs)

January 4, 2011
Archive, Ex-Amplify.com, Leadership, Snippet
Leave a comment

We’re all human (even CEOs)

[From the Archive: Originally posted at Amplify.com Jan 4, 2011]

A great opinion-piece from Mike Myatt (@MikeMyatt) about the C-level perspective on responding to the need for business change.

#1 take-away for me: we’re all prone to the frailties of the human condition, even CEOs. And we can all help each other out too, to compensate.

Amplify’d from www.n2growth.com

So why is it that so many CEOs shirk their responsibility, stick their heads in the sand, and avoid making necessary changes? It is my experience that they either lack the personal skill sets, or haven’t built the right executive team to lead change, they just don’t recognize the need for change, or they just don’t care.

Read more at www.n2growth.com

– Bob

Does the Project Manager Have a Future in the World of Agile?

January 3, 2011
Agile, Archive, Ex-Amplify.com, Organisational effectiveness, Software development
Leave a comment

Does the Project Manager Have a Future in the World of Agile?

[From the Archive: Originally posted at Amplify.com Jan 3, 2011]

Introduction

What does the idea of “Project Manager” tell us about the prevailing mindset of the organisations who have such job titles?

Certainly it tells us that they like to do work in “projects” – itself a zero-sum game, at best (see what PG Rule had to say on this subject).

And it also tells us that they see value in having some ONE “manage” other people (the project team) and “manage” the relationships between the team and the wider organisation (sponsors, users, etc).

Note: I’m writing here about the job of “Project Manager”, not so much the role or task of project management. As long as there are projects, some “managing” of them will be necessary. I propose to leave until another day any discussion of just how this task might be divvied-up. And indeed, whether it’s time to say “goodbye” to the whole concept of projects.

What Might We Reasonably Infer About Mindset?

Most often, the very notion of “Project Manager” suggests a prevailing “Analytic” mindset, where the assumptions underpinning the way folks see the world of work include:

  • Command and Control (managers tell, workers do)
  • Failures result from individual’s flaws
  • Personal accountability and the “single wringable neck”
  • Extrinsic motivation
  • Functional (vertical) silos
  • Breaking things down into parts, and managing each part in isolation
  • Primary focus on costs
  • etc.

Agile principles point the way to a transition to a collective “Synergistic” mindset, where the underlying assumptions about the nature of the world of work differ markedly from those listed above, e.g.:

  • Self-organising teams
  • Failures result from systemic issues (collective responsibility)
  • Intrinsic motivation
  • End-to-end (horizontal) value streams
  • Looking at how the organisation works as a whole (as in Systems Thinking)
  • Primary focus on flow (of value)
  • etc.

What do these diametrically-opposed sets of assumptions say to us about the future of the “Project Manager” job in the Agile organisation?

– Bob

In-band vs Out-of-band Change in Technology Businesses

January 2, 2011
Agile, Archive, Ex-Amplify.com, Organisational effectiveness, Snippet
Leave a comment

In-band vs Out-of-band Change in Technology Businesses

[From the Archive: Originally posted at Amplify.com Jan 2, 2011]

If Change Is A Normal Condition, Why Do So Many Businesses So Often Regard It As Something Extraordinary?

@alshalloway‘s recent post (see below) on the problems with BCUF (big change up front) resonates with me on a number of levels.

Over the years, I’ve been involved with, or seen from “over the fence”, more change projects and programmes than I care to remember. And in line with the statistics, few of them have been truly successful.

One recurring theme has been that of the change initiative as a one-off event. Maybe that was an understandable viewpoint back in the day, when changes in the external business environment (technology, regulation, market demand, etc.) moved at a much slower pace.

But nowadays, the climate in which most (technology) businesses operate is much more volatile, demanding much more frequent change (and thus many more, and more frequent, change initiatives). Actually, it’s got to the point now where many organisations have so many change initiatives running concurrently they’ve lost all semblance of effective control over them.

In my public talks, presentations, workshops, etc. I use the term “out-of-band” (OOB) change initiatives to refer to these discrete, one-off change projects that happen outside of the normal running of the business (a.k.a. Business As Usual or BAU).

Out-of-band change is the norm in Analytic organisations (by which I mean organisations where the prevailing collective mindset – or perspective on the world of work – is Analytic in nature. See The Marshall Model and a number of other posts on this blog for a fuller explanation).

Synergistic organisations, on the other hand, have come to recognise the fact that change is a normal part of everyday business (BAU) and thus integrate change into their BAU. I refer to this as the “In-Band” change approach. One archetypal example of in-band change is Kaizen (as typically practised) within Lean organisations.

What are the advantages of In-band change over out-of-band change that makes the more effective Synergistic organisations prefer the former over the latter?

And which is more suited to addressing the current demands on businesses – and especially, tech businesses – for almost-constant change?

Amplify’d from www.netobjectives.com

The irony of Agile’s (currently) most popular method, Scrum, using something comparable to BDUF hit me this morning in responding to a discussion on a user group regarding Scrum roles. The challenge was that the roles of Scrum Master and Product Owner are pre-defined for Scrum teams. For those that don’t have either true teams or these roles, one has to make a Big Change Up Front (BCUF) to start Scrum.

Read more at www.netobjectives.com

As ever, dear readers, I invite your comments and questions.

– Bob

To Deliver the Project at Hand, or Improved Project-delivering Capability for the Future?

December 30, 2010
Archive, Ex-Amplify.com, Organisational effectiveness, Snippet, Software development
3 Comments

To Deliver the Project at Hand, or Improved Project-delivering Capability for the Future?

[From the Archive: Originally posted at Amplify.com Dec 30, 2010]

Dadi Ingolfsson (@blubberplinth) asks me to “please open” the “tricksy can of worms” (my comment) which his tweet (see below) raises.

Note: His tweet, amplified here, was in response to my own tweet:

“Should e.g. Scrum Masters, Agile coaches be more vested in success of “the project“, or in #agile adoption in the organisation?”

So, the core question – in my mind at least – is “Should folks focus on delivering the project at hand, or on delivering improved project-delivering capability for the organisation, for the future?”.

I can’t deny that to be an effective coach or Scrum Master within a specific project team, the coach must have the trust and confidence of that team. Such trust and confidence is rarely won easily, and this challenge is compounded when the coach has a different agenda (goals) from the team (irrespective of whether the team knows this explicitly).

Let’s remember that not every team is itself focussed on delivering the project as their highest priority. Setting aside the pathological cases – such as where the “team” is not actually a team (and therefore has no shared goal(s) as such), or where the team’s aspirations lie elsewhere than delivering the project (i.e. in CV enhancement, or in finding a new gig for the team) – the team may actually have valid priorities other than the delivery of the project itself. In particular, the team, directed by e.g. senior management, may already be working on improving their own – and the organisation’s – capabilities in the longer-term (i.e. post-project).

And of course, this is most often not an either/or situation (although rarely does capability improvement make it into the explicit objectives – a.k.a. requirements – of a project).

Capability improvement – i.e. getting better at delivering projects over the longer term – is central to some (but not many) agile adoptions. And most often in these cases, it’s the Agile coach or Scrum Master that is expected (e.g. by senior management) to be the locus of effort to this end. And they will be held accountable in such circumstances for any perceived shortfall in such improvement – whether agreed and articulated, or not.

Typically, then, when capability improvement in on the client’s agenda, the coach has little option but to include this within his or her remit. (Aside: I would suggest that it’s in everyone’s interest to make this agenda clear, unambiguous and explicit, with quantified (capability improvement) objectives as part of the project’s collection of non-functional requirements. Your project does have a set of actively-managed NFRs, doesn’t it?).

Asking a project team – who are likely already fully-committed to just delivering the project – to also deliver useful capability improvements back into the organisation (as an ‘extra’ or side-effect) is a recipe for grumbling and dissent, at best. Put another way, expecting a team to contribute capability improvements without allowing for the additional time and effort required is likely to cause friction, and if the coach or Scrum Master is seen as the person who is pushing the extra workload onto the team, all the worse. And we’ve all seen what happens to “lessons learned” exercises at the end of most projects, especially when the team is then disbanded (don’t get me started on those particular dysfunctions!).

My apologies if this post rambles rather more that usual, but I did start out by saying the subject was a “tricksy can of worms” :}

In summary, I agree that if a Scrum Master/Coach is to be a real, accepted, trusted member of a team, he/she needs to commit to that team more than to an agile adoption (a.k.a. improving capability). But actually, reality says that a delicate balancing act is the order of the day, because there are a number of stakeholding parties and constituencies involved, each possibly wearing several hats and having several (possibly conflicting) needs from the project, the team and the coach.

Amplify’d from twitter.com
  • blubberplinth @flowchainsensei I say, if a Scrum Master/Coach is part of a team he needs to commit to that team more than to an agile adoption

Read more at twitter.com

– Bob

Postscript

This situation (i.e. the existence of implicit and/or explicit requirements for improvements to organisational capability) is (yet) another reason why agile adoption is more tricky than it may superficially appear. And another reason why good/great coaches / Scrum Masters who understand this stuff can really earn their coin.

 

Agile/Lean Principles Simply Will Not Scale

December 29, 2010
Agile, Archive, Ex-Amplify.com, Organisational effectiveness, Snippet
Leave a comment

Agile/Lean Principles Simply Will Not Scale

[From the Archive: Originally posted at Amplify.com Dec 29, 2010]

A somewhat contentious title in this clipped post (intentionally on the part of the author) but a post congruent, in general terms, with my recent “State of Agile” piece.

Amplify ’d from www.linkedin.com:

Agile and Politics Like Oil and Water

Agile/Lean principles will simply not scale. Ah good now I have your attention. The truth is that Agile development can scale in small, medium, and large companies, but they typically won’t. Now I am not saying this to upset Agile and Scrum purists. I have had the opportunity to work in small development companies (i.e. iLinc Inc.), medium size companies (i.e. Syntellect, Inc.), and larger companies (i.e. US Airways, GoDaddy.com), and I can tell you that Agile, for the most part, is not working there. It has been over 9 years since Agile was first introduced as a development methodology. Agile was developed during a ‘pow wow’ in Utah in February 2001. For more details on this please check Wikipedia (http://en.wikipedia.org/wiki/Agile_software_development) or the Agile Alliance website (http://www.agilemanifesto.org). Today there are more and more software development companies adopting Agile, Lean, and more iterative development practices and methods. The idea being that they can increase the quality (or at least not lose any) while simultaneously speeding up the “Time to Live”. This is a great thing; however here is the problem.

Now how does this relate back to Agile? Well if Agile will expose waste, and your job is pointless, then guess what? You are out of a job.
Therefore when Agile is introduced into a large company with a lot of these unnecessary positions, those people are in big trouble. Of course, if these people can get management to somehow not by into the Lean/Agile approach to doing business, then they may keep their positions.

In an attempt to shed a little light on this topic I would like to offer an approach to this issue where those who are “hiding in the details” to find a place in the new methodology.

First: Be the scrum Master. Now this topic could be its own article and I may actually write one on it one day, but lucky for you today is not the day. Just know this a Scrum Master is the person with the least amount of control or influence. A big problem is that development managers freak out and jump on this role because they think it is the one with the most control over the team. Sadly it is not. The scrum master is more like a waiter in a big restaurant. They are the servers to the team. The reason
development managers take on the role of a scrum master is because they hear that the team is “self-organized” and therefore they are no longer needed. Again this is not the case. A Scrum Master, is the process cop. The scrum master is the organizer and assistant to the team. This would be a great role for someone that can make the move to learning how Scrum or XP SDLC should be done, and not have a vested interest in the success or failure of the project.

Second: Be a SME (Subject Matter Expert). As you have been in your role for a long time you surely have picked up a few details and tribal knowledge that needs to be shared. Take that information and offer it up as part of the team. Help with the requirements gathering and defining of acceptance criteria. This will be very important as the team needs to capture this information as early as possible in the process.
Read more at www.linkedin.com

– Bob

#lru2010 Conference Report

December 18, 2010
Archive, Ex-Amplify.com, Rightshifting
Leave a comment

#lru2010 Conference Report

[From the Archive: Originally posted at Amplify.com Dec 18, 2010]

The first London Rightshifting Unconference took place Friday December

17th from 12 Noon through to circa 6 PM, at London City University, EC1. This is my report of the event.

Sessions

As this was an unconference, our first order of business was to find
a structure for the day that suited all attendees. After a short
discussion, we settled on a kanban-like backlog of session headings, each of nominally twenty minutes (and open to revision throughout the day). At the end of each twenty-minute session “slot” we then chose the next most interesting / important item, by consensus, for the next session (given a ten-minute break). This seemed to work well (although time did not allow us to address every item in the backlog).

Backlog

  1. 30-Minute Run-through Of Rightshifting Basics
  2. Experience Reports (from the Field)
  3. Barriers to Introducting Rightshifting e.g. Fear, Uncertainty and Doub
  4. Alternative Views
  5. Introductions
  6. Desired Outcomes for the Day / Next Steps 7. Overcoming “Well-known” Myths
  7. Measurement
  8. Dreyfus Model

Sessions as they Happened

1) 30-Minute Run-through of Core Rightshifting Ideas

By popular demand, I myself (@flowchainsensei) hosted this first session, with the aim of refreshing folks’ acquaintance with the concepts of the Rightshifting idea, including the Marshall Model. Given the degree of conversation that ensured, the group decided to continue for more than the allotted thirty minutes. The session centred around a slide deck I had presented to the London Limited WIP Society earlier in the year (see: The Bigger Picture)

Key points emerging from this conversation

Rightshifting is an awareness campaign, founded on Sir John Whitmore’s ARC principle.

  • Not only do most executives not realise the massive scope for improved effectiveness within their organisations, but most people working in those (relatively ineffective) organisations will never have experienced life in more-effective organisations, nor even realise that these exist. Absent this fundamental awareness, Rightshifting suggests that few people will see any need to take responsibility for doing something about the relative ineffectiveness of their own organisations, let alone commit themselves to taking any action(s).
  • Rightshifting is not another method, or solution. It does not tell organisations WHAT to do to become more effective, only that significant gains are there for the taking. In my travels, seeing hundreds of tech businesses, the common theme has been the lack of engagement with the desire to do anything about the status quo (almost universally, a significant, unappreciated level of ineffectiveness as an tech organisation or tech business).
  • With the Marshall Model, Rightshifting describes the challenges facing tech organisations contemplating a journey towards significantly improving their effectiveness, and how that journey will be a series of punctuated equilibria.

2) Experience Reports

Some folks have already been using Rightshifting ideas and the Marshall Model in conversations with clients and customers. This session invited folks to share such experiences.

First up: Ant Clay (@soulsailor) of 21Apps related his very recent experience (this week!) of presenting the Rightshifting curve and the four mindsets to one of his current clients. I personally found it both interesting and gratifying to hear the extent to which his clients (senior managers) quickly embraced the Rightshifting idea, and in particular used the vocabulary themselves to better articulate and discuss their business strategy and aspirations for the business (along with the role of technology therein).

Ant also took this opportunity to address (in part) the backlog item “Alternative Views”. Given his company’s focus on Sharepoint as an Enterprise solution, he explained his view of how Rightshifting helped 21Apps articulate their USP (Unique Selling Proposition) and Positioning to their clients.

Following on from Ant was Grant Rule (@pg_rule) of SMS Exemplar, who related the tale of his company’s two-year association with a major European technology manufacturer in trying to help them get a major organisation-wide improvement programme off the ground. This engagement has been using Rightshifting throughout (and latterly the Marshall Model too) as the glue with which to build a consensus on change amongst all the many and varied stakeholding groups involved.

3) Introductions

In this session, the ten attendees took turns to introduce
themselves, explain their interest in, and use for, the Rightshifting concepts, and talk about what they’d like to take away from the event. In summary, most folks attending are “tech” people, including a couple of CTOs, some consultants, some coaches, and others, all with a common interest in understanding what makes for an effective technology business and a desire to help such organisations also understand the massive latent opportunities for improving effectiveness.

4) The Dreyfus Model of Skills Acquisition

Liz Keogh (@lunivore) presented this excellent session, relating her experiences of applying the Dreyfus Model with some number of her clients, most notably, at Screwfix Direct Ltd. After a short summary of the purpose and levels of the Dreyfus Model, Liz provided us all with some very useful hints and tips on applying the Dreyfus Model in the real world. Given that the Marshall Model is subtitled “Dreyfus for the Organisation”, the latter was of particular interest and value to me personally.

Note: The Dreyfus Model generally has five levels, whereas the Marshall Model has seven. This difference is intentional – can you think why this may be so?

5) Wrap-up

In the wrap-up session, we had a wide-ranging discussion wih the general aim of ensuring that everyone attending had got as much out of the day as possible, filling-in any remaining gaps or omissions.

This wrap-up session included a brief conversation around next steps for the Rightshifting movement, not least regarding the future of #rshiftchat, our regular weekly Thursday evening tweetchat (presently suspended until the New Year). NB If you have any ideas or preferences for building the Rightshifting community, and movement, including the future of #rshiftchat, please get in touch, or preferably, comment on this thread.

We also discussed the possibility of another unconference in London next Spring, as well as similar events in other geographies soon.

My thanks go to all who braved the nasty weather to attend and contribute, and my special thanks to Dr Andrew Tuson, David Chan, and City University for providing such a fine venue, and support.

As ever, I am happy to provide more information, explanation, etc, as well as welcoming your input and comments.

– Bob

References

This is just a short list of the references I heard mentioned during the event. If you’d like to understand why they were mentioned (e.g. context), please get in touch.

Note: there are many more (book) references on my website. (Attendees – please help me out by adding further references via comments on this thread).

“Dirty Little Secrets” ~ Sharon Drew Morgan
“Coaching for Performance” ~ Sir John Whitmore
“The Marshall Model of Organisational Evolution” ~ Bob Marshall
“Managing Transitions” ~ William Bridges
“The Satir Change Model” ~ Virginia Satir
“The Unfreeze/Change/Refreeze Model” ~ Kurt Lewin
“Great Boss, Dead Boss” ~ Ray Immelman

Would You Rather Not Know?

December 5, 2010
Archive, Ex-Amplify.com, Organisational effectiveness
Leave a comment

Would You Rather Not Know?

[From the Archive: Originally posted at Amplify.com Dec 5, 2010]

Would You Rather NOT Know About What Makes Organisations More or Less Effective?

I’ve had some folks ask me recently as to the point of knowing this information, given that many developers, staff in general and even middle-managers feel that they have little influence over wider business issues and how the work works, end-to-end, within their organisations.

Correlation or Causation?

Is there a correlation between organisat­ional mindset (how the people within an organisation perceive the world of work) and the effectiveness of that organisation? If so, is it a simple correlation or is mindset in fact a causation of (high, or low) effectiveness?

The Marshall Model

The Marshall Model proposes that this is a causative relation­ship. That is to say, that the prevailing mindset in an organi­sation directly dictates the effectiveness of that organi­sation. And moreover, to realise any significant improvement in effectiveness requires that the organisation changes the way it looks at the world of work (its prevailing mindset).

So, maybe learning what makes organisations effective only leads to distraction, frustration, unhappiness and a kind of learned helplessness?

I suggest this proposition is flawed. And only serves to disempower people and perpetuate organisational homeostasis (aka the status quo).

Further, I believe that developers – and others – that come to understand the cause of organisational effectiveness can do much to help break the log-jam of organisational homeostasis and contribute to “Rightshifting” their organisations.

The “collective mindset” of an organisation may seem like an abstract, nebulous and difficult-to-wrangle animal, but in fact, organisational mindset is little more than an amalgam of the mindsets of the individuals within the organisation, underscored by implicit and explicit policies, with a modicum of history thrown-in.

Collective Mindset is Key

So it seems to me that, with knowledge of the key role that mindset plays in organisational effectiveness – and assuming some degree of positive motivation to change things for the better – everyone within an organisation can help effect positive change. At its simplest, folks can simply begin talking about the subject, with their friends, colleagues, fellow team-members, peers and management.

The Japanese concept of ‘ba’ may have relevance here. Nonaka et al suggest that we take ‘ba’ to mean ‘place’. It is a here-and-now coming together of physical, virtual and mental spaces, which together constitute a shared “context in motion” for tacit knowledge to become explicit. In other words, a concept of a place ‘where shared meaning can emerge’.

This requires little in the way of sanction, support or coordination from the top. A crucible or place (“ba”) for regular dialogue can help, certainly – in due course.

Granted, active support and coordination from the CEO or MD is vital in transforming a vertically-organised, siloed organisation into one where horizontal value-streams are the preferred mode of operation.

But CEOs, MDs and such are more likely to act if they feel that people within their organisations already have a basic grasp of the issues, and a relatively positive disposition towards, and a sense of ownership in, potential changes.

– Bob

Rightshifting and the Senior Management Pitch

November 21, 2010
Agile, Archive, Coaching, Ex-Amplify.com, Rightshifting
Leave a comment

Rightshifting and the Senior Management Pitch

[From the Archive: Originally posted at Amplify.com Nov 21, 2010]

Introduction

A number of folks have said to me recently that although Rightshifting strikes a chord with them personally, it’s their senior management that really needs to hear the message.

Few indeed are the organisations where ideas from the rank-and-file are taken seriously by the senior management. It’s almost as if these senior people are conditioned to automatically discount anything said to them by their “minions”. Maybe that’s one reason why consultants seem to have more success in bringing ideas to the attention of decision-makers.

I’ve been using “Value Forward Selling” for some years now as a means to engage with decision-makers, and a key technique in Value Forward Selling is something the originator – Paul DiModica – calls “The Three Box Monty”.

Not that I’m suggesting technical folks start learning how to sell ideas to management – that could be a whole new career! And most software people I know prefer to get on with the job at hand, rather than spend time and effort on “politics” and the like. Whether that’s a productive perspective or not is a different question, and maybe one for a different post.

Aside: There are a number of people in the Rightshifting community, myself included, that can help practitioners build and present a *tailored* case for more effective software development to their decision-makers. Go ahead, don’t be shy, ask for help and advice – that’s one of the reasons the Rightshifting community is here!

So, let’s take a closer look at the Three Box Monty, and why approaching it from a Solutions Focus perspective makes it even more powerful than the original technique.

The Three Box Monty Explained

The justification for the Three Box Monty is the observation that executives relate best to people they trust, and an effective means to build mutual trust is to establish a peer-to-peer relationship. Simply put, people listen more to and are more open to advice from people like themselves (“Business Peers”).

The Three Box Monty helps build that kind of mutual trust and peer-respect in a quick and simple fashion (i.e. during a thirty-minute to one-hour presentation).

So what is a Three Box Monty?

A Three Box Monty is a presentation technique using three boxes drawn on a Whiteboard or Flip chart:

BoxA            Box B

BoxC

The Three Box Monty serves to position the presenter (typically, a sales person, coach, consultant, etc.) as a peer of the decision-makers in the audience. (An audience might generally consist of five to fifteen people, including decision-makers and members of their respective staffs).

The three boxes of the Three Box Monty are:

  • Box A: The general business issues (pain points and problems) that are addressed by the presenter’s idea, product, or service and faced by all organisations in the same line of business, or industry sector, as the organisation being presented-to.
  • Box B: The specific business issues currently faced by the people in the audience (and their organisation).
  • Box C: A short list of ways in which the presenter’s ideas, products or services will directly contribute to the reduction of the problems listed in boxes A and B – and thus to the organisation’s declared objectives.

The presenter starts a Three Box Monty by writing a list of known “industry-wide” issues or problems into box A. This helps establish “peer credentials”, credibility, a common frame of reference, early consensus, and a basis for tackling box B.

With some five to seven items in box A, the presenter then moves on to box B, listing two or three business issues or problems specific to and familiar to the audience. Most often, these will have been learned from earlier discussions with the organisation. After inviting the audience to validate and contribute more items to box B, the presenter moves on again to box C. In box C, the presenter lists key solutions to the issues already listed in boxes A and B. Box C both shows how those solutions will help the organisation reach its desired goals, and highlights the role of the presenter’s organisation in providing key elements of these solutions.

Note that there’s a lot more to an effective Three Box Monty presentation than this brief introduction covers. In particular, I have skipped some of its most powerful aspects, centred around the psychology and sociology of meetings. See the very excellent “Value Forward Selling” by Paul DiModica pp 190-220 for much more information and explanation.

So, the normal Three Box Monty as just described concentrates on *problems*. What is “Solutions Focus” and where does it come into the picture?

Solutions Focus and the Three Box Monty

Solutions Focus is an approach to coaching and positive change that’s finding increasing acceptance in the world of business. It’s based on the basic principle of “finding what works, and doing more of it”. Rather than spend time analysing the past and its problem, why not just head directly for a solution? I recommend reading the excellent book “The Solutions Focus” by Jackson andMcKergow if you want to find out why this is nowhere near as trite as it may at first sound.

I’m not going to go into the details of the effectiveness of a Solutions Focus approach, except to say that there are some number of case studies describing the remarkable results a Solutions Focus approach can deliver when applied to e.g. business change.

So, the three boxes for my modified “Solutions Focus Three Box Monty” looks like this:

  • Box A: What the leading businesses in the industry do (well)
  • Box B: Which of those things the audience’s business is also presently doing (well)
  • Box C: Which other things the audience would like their business to do (well) in the future

Note here that the key point is to change the focus of the Three Box Monty technique from problems to solutions, from the very outset. This is, of course, similar to the generally thrust of my “Perspectives on Rightshifting” presentation.

But wait! There’s another variant for us to consider:

The “Outcomes Focus” Three Box Monty

This variant adds to the Solutions Focus Three Box Monty by replacing the focus on solutions with a focus on outcomes:

  • Box A: What positive outcomes the leading businesses in the industry are seeing presently
  • Box B: Which of those outcomes the audience’s business is also presently seeing (and maybe one or two where they’re ahead of the competition)
  • Box C: Which other positive outcomes the audience would like their business to see in the future.

Note that here, in this alternate variant, which I’m calling “The Outcomes Focus Three Box Monty”, the key point is to focus on positive outcomes – both those already seen and those desired for the future – from the very outset.

I’d be happy to explain more, particularly about the psychology underpinning this approach, should anyone express an interest in this line of thought, or wish to begin using it to positive advantage in their own situation.

I’d also love to hear from anyone already doing stuff like this.

– Bob