Archive

Innovation

Wants, Needs

My previous post seems to have struck a chord, judging by the number of retweets on Twitter. It also presents an opportunity to explore a perennial challenge of building things for other people: teasing out real needs from expressed wants.

Have you ever worked with business folks who articulate their wants in the form of solutions, rather than as solution-free “requirements”? As means rather than ends?

Let’s take another look at the list of desired outcomes (wants) appearing in the aforementioned post:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement

Business Analysis for the Way the Work Works

From my days as a Business Analyst, I’ve learned that uncovering needs means having an ongoing dialogue with the people that matter. A dialogue in which we dig down, together, into the things they say they want, so as to uncover their real needs. Once we’ve teased apart the wants from the needs, we’re in a better place to choose effective strategies (solutions) for addressing those needs. Going with the superficial wants tends to box us in to the strategies (means) they provide. Strategies which often fall short of being effective.

I suspect what I’m talking about will become clearer as we examine in turn each item from the above list…

Item: A more coherent, disciplined approach to software development

This looks to me like a solution masquerading as a need. That’s to say “a more coherent, disciplined approach” seems like more like means to other ends, than and end in itself. What might those ends be? What might be the underlying needs driving this proposed solution? A dialogue with the people that matter seems in order here. A dialogue that could prove challenging, absent a degree of trust and willing collaboration. And even assuming we are all able to dig down towards the underlying needs, just as in building software there’s no guarantee we’ve identified those needs accurately, until we’ve built and delivered something and seen it “in production” long enough to gather some feedback. Active feedback, which also implies iteration and evolution: “Is this really meeting the needs of everyone that matters? Is it good enough yet? What else do we need to do to improve it further?” etc..

For illustration, I’ll take a stab at the needs which might underlie this want. Maybe some folks suppose that “a more coherent, disciplined approach” will bring order to the present chaos (a need for order). Maybe some folks suppose that “a more coherent, disciplined approach” will make delivery of e.g. features or product increments more predictable (a need for predictability).

Maybe productive and effective dialogue will uncover other latent needs implicit in this want.

Item: Improved governance and oversight

This also looks to me like a solution masquerading as a need.

Maybe some folks choose “Improved governance and oversight” as their automatic, default solution (strategy) for bring order to the present chaos (a need for order).

Item: Improved estimates

This again looks to me like a solution masquerading as a need.The No Estimates movement and debate has just about done this one to death. What might the supposed need for “improved estimates” imply. What’s really need here?

Item: Better due-date performance (reliable on-time delivery)

Whilst we could imagine this as yet another solution masquerading as a need, in this case I find this want more interesting, maybe closer to a real need than the previous two items.

I suspect some folks that matter may suppose that “better due date performance” is the obvious means to improve (external) customer satisfaction, and thereby revenue, repeat business, profit, market demand, market share, and other business metrics. Maybe those involved in the way the work works, armed with an explicit, agreed need to satisfy one or more specific business metrics, would be able to come up with ways of working which effectively address those metrics. In other words, valuable innovations.

Item: More visibility into project roadmaps

This again looks to me like a solution masquerading as a need. What might be the underlying need here? Maybe it’s something born of a feeling of powerlessness in the absence of information about what’s happening. Maybe it comes from a sense of frustration or embarrassment when having to face customers and investors expecting information about product release schedules, feature sets, and road maps. Whatever the case, an effective, productive dialogue may flush out some of those underlying feelings, and thereby lead to a better understanding of the needs we’re all trying to address.

Item: Common standards

Yet again this looks to me like a solution masquerading as a need. I’ve heard this want many times in numerous companies. This looks to me like an implicit solution to the question “how do we become more flexible, how can we cost-effectively deploy and redeploy our developers between projects and project teams as business priorities change?” I guess the people that matter suppose that “common standards” is the obvious answer. But it’s our job to understand the underlying need and come up with the most effective solution (strategy) for addressing it, not just the most common solution.

But I could be barking up the wrong tree about the presumed underlying need here, so I’d want to have conversations with the people that matter so as to really understand what they might be trying to achieve through addressing this want.

Item: Better project organisation

Another solution masquerading as a need. What might “better project organisation” bring us? Better due date performance? More visibility into project roadmaps and current status? See explanations, above, for the needs which might underlie *those* wants.

Item: People working “in sync”

Solution masquerading as a need. What might “people working in sync” bring us? Reduction in friction and waste? Improved flow (of products and features into the market)? Better due date performance? By digging down, though dialogue, we may uncover candidates for the underlying needs, which we can proceed to validate through delivering a way the work works, and getting feedback on the degree to which that way of working effectively addresses folks’ real needs.

Item: Senior management confidence (in e.g. the teams’ ability to deliver)

This is probably the one item in our list of sought outcomes that’s closest to a real need. We can intuit the scale of the problem (shortfall in senior management confidence) by looking at all the solutions they’re helpfully trying to provide us with, via the other items here. Solutions (masquerading as needs) that they believe will improve things and thereby deliver the boost in confidence they seek (and need). Ironically, the solutions they provide – being very much less effective solutions than those we can come up with for them, as experts – often undermine the very outcomes they seek.

Item: Higher staff motivation and engagement

Very laudable. But let’s not let the humanity of this want blind us to its nature as (yet another) solution masquerading as a need. What’s the end in mind? Why might the people that matter seek “higher staff motivation and engagement”?

So they can feel better about the culture for which they they feel responsible? As a means to increased throughput and thus improved revenues and profits? Again, until we know what they really need, any solutions we provide will likely fall well short of the mark. In other words, wasted effort.

Summary

So, we can see that taking “sought outcomes” at face value can lead us into sleepwalking into addressing superficial wants, and adopting other people’s (non-expert, relatively ineffective) solutions. Solutions which rate poorly on the effectiveness scale, and which in any case may well be addreessin the wrong needs. I find it ironic just how much non-expert interference and micromanagement goes unnoticed, unchallenged and unlamented. Plenty of time for lamentation a year or two later.

Bottom line: When building software, the biggest risk lies in building the wrong thing (getting the requirements wrong), and it’s not any less of a risk when “building” – we might choose to call it “evolving” or even “engineering” – the way the work works.

– Bob

Do Nothing That Is Not Play

If we think about it calmly for but a moment, one logical outcome of nonviolence is folks not working for a living, but playing for a living.

Innovation

Many companies seem desperate for “innovation”. Is innovation more like to come about through folks doing what they’re told (“working”) or through playing with things, as they see fit? I posit the latter is far more likely.

And no, this is not some flight of fancy. Do we really embrace wholehearted the set of assumptions labelled by Douglas McGregor as Theory-Y?

Theory-Y assumptions are: (1) physical and mental effort are natural and most people (depending on the work environment) find work to be a source of satisfaction, (2) they generally, on their own motivation, exercise self-control, self-direction, creativity, and ingenuity in pursuit of individual and collective (company) goals, (3) they either seek responsibility or learn to accept it willingly, and that (4) their full potential is not tapped in most organisations.

Could it be that folks’ “full potential is not tapped in most organisations” because they are obliged to “work” rather than play?

Could it be that engagement (and productivity) would take an amazing leap forwards if we invited folks to “play” rather than “work”?

Could you have the courage to experiment to find out for yourself?

Or are we all so in thrall to what Walter Wink calls The Domination System that play as an alternative to work is undiscussable?

– Bob

Further Reading

Serious Play ~ Michael Schrage
The Importance of Play (A Valentine for Marshall Rosenberg, part 2) ~ John Kinyon
What If #7 – No Work ~ Think Different
The Human Side of Enterprise ~ Douglas McGregor
Theories of Motivation ~ Think Different

Holistic Solutions for Product Development Businesses

Several people have been in contact this week to say “It’s all very well talking about holistic solutions for software development, but who really has any notion of what that might even look like?”

Which is a fair question.

Aside: Let’s note that the phrase “holistic solution for software development” is an oxymoron of the first order. By definition, software development is but part (and generally a small part) of any solution that addresses customer or market needs. Even software “pure plays” have a lot of non-software components.

So, I thought I’d describe just one holistic solution for whole organisations that develop new products containing some software. For want of a better name, I’ll call it this example “Flow•gnosis”. With this example, I hope that maybe one or two readers might find a spark of insight or inspiration to broach the question of a True Consensus in their own organisation.

I’ll try to keep this post brief. I’d be happy to come talk with you about holistic product development solutions for organisations, in person, if you have any real interest.

Flow•gnosis?

Flow•gnosis is a hybrid born of FlowChain and Prod•gnosis. FlowChain is not specifically a holistic solution, focussing as it does on improving the flow of knowledge work through a development group or department whilst moving continuous improvement “in-band”. Prod•gnosis is specifically a holistic solution for effective, organisation-wide product development, but says little about how to organise the work for e.g. improved flow or continuous improvement.

Together, they serve as an exemplar of a holistic solution for knowledge-work organisations, such as software product companies, software houses, tech product companies, and organisations of every stripe with in-house product development needs.

Let’s also note that Flow•gnosis is just an example, to illuminate just a few aspects of a holistic solution. Do not under any circumstances consider copying it or cloning it. Aside from the lack of detail presented here, you’d be missing the whole point of the challenge: building a True Consensus, as a group, with your people, in your context.

What’s the Problem?

Before talking more about a solution, what’s the problem we’re trying to solve?

I’ll work through an almost universal problem facing organisations that “do” software development. A problem that some enterprising supplier or management team might choose to address with an “innovative” solution.

Understanding the Problem

Here are some typical Undesirable Effects (UDEs) I hear from many companies involved in software and product development:

UDE: Delivery is not fast enough (long time-to-market)

UDE: New products cost too much to develop (high cost to bring to market)

UDE: We struggle to keep our products at the cutting edge

UDE: We always drop balls in hand-offs of tasks (i.e. between specialists, or business functions)

UDE: Continual contention for in-demand specialists

(For the sake of brevity, I’ll skip the building and analysis of the cause and effect graph. Your analysis will be different, in any case).

Root cause: Developing new software, products and services through a byzantine labyrinth of tasks and hand-offs, between and across dozens of specialisms within the company and its network of suppliers and distributors. This approach causes many delays (waste of time), mistakes (waste of effort, money), contention of resources, etc.

Conflict: A) Specialists must work together in their own specialist groups or silos to maintain their cutting-edge skills and know-how. B) Specialists from across all specialisms must work together as a group else handoffs and queues will cause many delays and mistakes.

Conflict arrow: Specialists cannot work in their own groups advancing their specialist knowledge at the same time as they work together with other kinds of specialist on new product ideas.

Flawed assumption at the root of the conflict: Specialists must work together. What makes this so? Only the old rules of the organisation. That silos (a.k.a. business functions) “own” their clutch of specialists. What if we changed that rule? (Note: this change is one key element of Toyota’s TPDS). And if we changed that rule, what other rules would we need to change too?

A Bird’s Eye View of Flow•gnosis

Prod•gnosis looks at an organisation as a collection of parallel Operational Value Streams, each dedicated to the selling and support of one of the organisations’ (whole) product or service lines. And each with its own team or collection of people doing the daily work of that operational value stream. Further, Prod•gnosis asks “How do these operational value streams come into being?” And answers with “They are made/created/developed by a dedicated Product Development Value Stream.”

FlowChain describes a way of working where a pool of self-organising specialists draws priority work from a backlog, executes the work, and delivers both the requested work item, and posting new work items (for improving the ways the work works) into the backlog. In this way, FlowChain both improves flow of work through the system, and brings continuous improvement “in-band”

By merging Prod•gnosis and FlowChain together into Flow•gnosis, we have an organisation-wide, holistic example which improves organisational effectiveness, reifies Continuous Improvement, speeds flow of new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

The latter point is perhaps the most significant aspect of Flow•gnosis. Having customer, supplier, marketing, sales, finance, logistics, service, billing, support and technical (e.g. software, usability, emotioneering, techops, etc.) specialists all working together (cf. Toyota’s Obeya or “Big Room” concept) enables the evolution of “Mafia Products” and “Mafia Offers” which the more traditional silo-based models of business organisation just can’t address effectively.

Out With the Old Rules, In with the New

Flow•gnosis is an innovation. Irrespective of the promised benefits of Flow•gnosis, we have learnt in recent posts that adopting an innovation ONLY brings benefits when we change the rules.

Let’s apply the four questions to our Flow•gnosis innovation and see what rule changes will be necessary to truly reap the benefits.

Q1: What is the POWER of Flow•gnosis?
A1: Flow•gnosis makes it commercially feasible for a company to repeatably come to market with new “Mafia Products”.

Mafia Product: “A product (or service) so compelling that your customers can’t refuse it and your competition can’t or won’t offer the same.”

Q2: What limitation does Flow•gnosis diminish?
A2:  Serialisation of specialist work (passing things back and forth between various specialist and business functions).

Q3: What existing rules served to help us accommodate that limitation?
A3: Handoffs. Queues. Batches. Separation of command and control from the work. Process. Process conformance. Local measures. Constant expediting. Critical path planning (Gannt charts, WBS). Local optima. Functional management (discrete management of each separate business function).

Q4: What (new) rules must we use now?
A4: Flow. Value streams. SBCE. Holistic measures. Ubiquitous information radiators. Cost Of Delay prioritisation. Buffer management. Constant collaboration. Dedicated teams of generalising specialists. Self-organisation. In-band continuous improvement. Resource levelling. Limits on WIP.

Summary

This post has been a – necessarily brief – look at one holistic solution to (software) product development. Crucially, we have seen how old rules have to be replaced, and what many of the replacement new rules might look like.

I invite you to remember that Flow•gnosis is just an broad-brush example of a holistic solution. Please don’t consider copying it or cloning it. And remember the real challenge: building, as a management group, a True Consensus.

– Bob

Further Reading

Meeting Folks’ Needs At Scale – Think Different blog post

Obstacles to True Consensus – Summary

[Tl;Dr: Major improvements in the effectiveness of any organisation go begging, because the skills and experience for reaching the necessary True Consensus are almost always absent.]

This is the final post in my recent mini-series about obstacles to True Consensus.

The Big Picture

Let’s step back and try to take in the big picture for a moment.

I most often label this big picture “Organisational Effectiveness”. You might prefer to call it “improving the bottom-line”, “productivity”, or simply “success”.

Why does this big picture matter to me? Because of the impact ineffective organisations have on the people who work in them, on the people who depend on their products and services, and on society as a whole.

Employees

I’m a software engineer at heart. I have so many times worked with software engineers and other folks wanting to make a difference in the world, and being unable to do so because of the ineffectiveness of the organisations within which they work. Sooner or later, these folks simply give up on their dreams and “check out” (remaining employed but disengaged) or quit. Having been in the same boat myself on any number of occasions, I feel like I can relate. And, BTW, that’s why I now serve organisations in the role of Organisational Psychotherapist, actually doing things – albeit non-software engineering things – to “make a difference”.

Customers

I’m a customer of these organisations, too. We all are. Not out of choice, let me add. I have in mind the various organs of state, in which we have no say regarding the shoddy services and lame products they foist on us. Not that most private corporations are much better.

Society

How do ineffective organisations impact society? Apart from the waste of public money (many are in the public sector) that could be put to better use elsewhere, the sheer number of ineffective organisations lead us all to believe that ineffectiveness is normal and unavoidable. We seem to have lost the belief that we can ever expect to see things become better.

The Key to Improved Effectiveness

It’s pretty much accepted that the ability to transcend paradigms (an organisation’s beliefs, assumptions and rules about work) is the greatest lever to improve effectiveness. And by effectiveness, I mean reducing or eliminating things that should not have been done but nevertheless were done. See my recent post: Reliability and Effectiveness for details and objective measures of this.

In other words, the prevailing paradigm, or mindset or memeplex governing an organisation determines its effectiveness. And so, it’s obvious that to improve effectiveness, we must “shift” this paradigm. This is where most organisations falter and fail. They have no experience or capability in achieving a True Consensus. Such a thing looks like an impossibility.

Aside: Agile

In case you’re wondering if there’s any relevance to tech companies and their employees and customers: All flavours of Agile are essentially forms of local optima. Local optima, in that Agile initiatives are almost always limited to one silo (the “development” or “IT” silo) in the organisation. Most people in organisations doing software development are obliged to place their faith in systems of local optima. This is because the prospect of building a True Consensus across the whole organisation seems so daunting, so impossible, so contrary to prevailing behaviours, as to never receive serious consideration or discussion. And so, systemic ineffectiveness is locked in.

True Consensus

A “True Consensus” is when ALL top managers agree on the exact SAME action plan, with each and every top manager regarding his or her components of the joint action plan as his or her own baby.

Whether in a single organisation, or society as a whole, True Consensus is a prerequisite for concerted action to make things better, to make things more effective. On the path towards effective organisations, progress will only come about if the top teams, and eventually their whole organisations, can agree on their core problems and find coherent, holistic ways forward, together. True Consensus is the necessary prerequisite for Rightshifting any organisation.

This mini-series and its precursors has described one path to arrive at such a True Consensus, including describing the obstacles we can expect to encounter along the way, and ways of overcoming those obstacles.

In brief, the described path consists of repeatedly practicing, as a group and emergent leadership team, these steps:

  • understanding the core conflict in a problem by discovering the inherent flawed assumption
  • agreeing on a direction for a solution
  • elaborating that direction into a full (holistic, company-wide) solution or plan of action
  • agreeing on how to implement that full solution
  • enacting the implementation

You can find more details in the posts of this mini-series:

Obstacles to True Consensus – The Dominant Impatient Visionary

Obstacles to True Consensus – The Smart Conservative

Obstacles to True Consensus – Extrapolating From the Past

Obstacles to True Consensus – Solutioneering

Obstacles to True Consensus – Summary (this post)

and in the four posts prior to the mini-series itself:

Organisational Psychotherapy and the Bottom Line

Pillars

Innovation ALWAYS Demands We Change the Rules

Reliability and Effectiveness

And you can find even more in-depth elaboration of these ideas in e.g. Goldratt’s audiobook “Beyond The Goal”.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)
Leverage Points: Places to Intervene in a System ~ Donella Meadows
The Asch Conformity Experiment (Video)

Obstacles to True Consensus – Solutioneering

Following on from the third post in this mini-series, today I’ll describe another obstacle to True Consensus. Again, it’s about the behaviour of certain key people. And again, in line with our belief that “People are Good”, the behaviours we’re discussing are not dysfunctional behaviours, but the outstanding, positive behaviours that have brought the company to its present success.

The term “solutioneering” describes our natural tendency to jump to a solution, and elaborating that solution, even implementing something, before we fully understand the problem at hand.

Obstacle: Solutioneering

If we think about solutions while we are analysing a core problem, we will distort reality to fit the solution we have in our mind.

And at the time we’re creating the solution, any time we spend on thinking about how we’ll implement it will distort the solution, too.

In other words, we’ll come up with better solutions, and implement them better, when we tackle any candidate idea in clearly delineated and separated steps:

  1. Analyse the core problem. Simply understand the problem, and the underlying core conflict.
  2. Find the solution
  3. Decide how to implement the solution

You may recognise this approach as the Three Fundamental Questions of Theory of Constraints.

1. What to change?
2. What to change to?
3. How to effect the change?

At each step, we forbid ourselves from considerations better reserved to the other steps. Given the risk of confusion, delusion, distortion, and ineffective conversations, we must maintain the separation between these steps. Absent such separation, the risks of conflating these concerns means we will be that much less likely to achieve our essential True Consensus.

Next time: Summary – Summarising this mini-series.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)
Theory of Constraints: What to Change ~ Dave Lane (blog post)

Obstacles to True Consensus – Extrapolating From the Past

Following on from the second post in this mini-series, today I’ll describe another obstacle to True Consensus. Again, it’s about the behaviour of certain key people. And again, in line with our belief that “People are Good”, the behaviours we’re discussing are not dysfunctional behaviours, but the outstanding, positive behaviours that have brought the company to its present success.

Extrapolating from the past is not something negative, it’s something positive. If we don’t extrapolate from the past, if we start every time from a clean slate, what are the chances we’ll do anything sensible? Pretty close to zero. Experienced people are, by definition, people that extrapolate from the past. Otherwise we have no intuition, no insights into a subject.

Here, we’re going to look at two different aspects of this obstacle.

Obstacle: Extrapolating From the Past Into What We Might Do In the Future

This is the first aspect of extrapolating from the past. Extrapolating from the past works in our favour. So what’s the problem with it? When we come to build the change, to build the new strategy based on our new rules, to really embrace the power of the synergistic approach, our past contains what? Yup. The old rules. And if we extrapolate from the old rules, what do we get? We get the same strategy we already have – maybe in slightly different words only – and nothing happens.

Remediation: Exclude the old rules

So, how can we make sure we extrapolate from the past, building everything on past experience, except for the old rules. How can we exclude these old rules? By examining each conflict, by identifying our flawed assumptions- rooted in the old rules – and removing these flawed assumption. In this way, we make our past experience more homogeneous, and everything makes much more sense. We’re not abandoning the past. We’re not erasing our past experience. Exactly the opposite. We’ve removed the one thing that causes our experience to be inconsistent. And we’re reshaping our past experience. Making it much clearer and more palatable. Folks love this.

So what we have to do is take a number of key ideas in turn, and apply the same process:

  • Do the analysis
  • Discover the conflict via the flawed assumption
  • Remove the conflict

By doing this, we reshape our past experience. And the minute we do this, we still extrapolate from our past experience, but based on the new rules, rather than the old rules.

And by the way, did you notice how, for this aspect of the obstacle, remediation is much the same approach as we take with the Dominant Impatient Visionary and the Smart Conservative obstacles?

Obstacle: Extrapolating From Past Experience of Each Other

This is the second aspect of extrapolating from the past. Given our experience of the folks we work with, will they collaborate now? Do they really mean yes when they say yes? Can we rely on them? In most companies, extrapolating from the past in this context leads to less than positive feelings, because what we extrapolate from the past is not exactly flattering.

Remediation: Explore, Reflect and Change as a Group

How to remediate? We have to ensure that we reflect on the past, on our past interactions, on our extrapolations of folks’ behaviours, as a group, rather than in one-to-one conversations. In this way, each person will see how everyone else is also going through the same kind of change. This means, by the way, that all the previous remediations we have mentioned in this series also have to be done in a group, not one-to-one.

Aside: This excludes people learning this stuff from books. People have lost the art of reading together in groups.

Next time: Solutioneering – the final obstacle to True Consensus, explored.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Obstacles to True Consensus – The Smart Conservative

Following on from the first post in this mini-series, today I’ll describe another obstacle to True Consensus. Again, it’s about the behaviour of certain key people.  And again, in line with our belief that “People are Good”, the behaviours we’re discussing are not dysfunctional behaviours, but the outstanding, positive behaviours, the virtues, that have taken the company to its present success.

Obstacle: The (Smart) Conservative

Usually, these are people with an enormous amount of experience, very well respected. But somehow, given any suggestion of what to improve, they immediately find ways to prove to you it should not be done. It’s as if they’re going out of their way to maintain the status quo. Do you know anyone like this? What can we do?

As long as these people are in the crowd – and they’re always in the management crowd – what chance do we have of reaching a true consensus on some idea, or way forward, that is beyond the expectation of almost anyone in the group? It’s not that these conservative people are stupid. Definitely not. Do you think that they’re out of touch with reality? That they don’t know the situation of the company? Of course they know. And very well.

And now if we talk with them and ask them “What do you think? Do you think that if the company fails to embark on a process of ongoing improvement, it will survive in the future? What do you think their answer might be? They thoroughly believe that if we DON’T improve, we’re going to be out of business. So how come that these people – with so much experience, with such strong convictions that the company must improve – block any suggestion for improvement? What are they, imbeciles? How it is that this happens?

Here’s the explanation: These smart conservative people have the gift of being able to see both sides of a conflict. Very clearly. As a matter of fact, when we, through analysis, cause them at last to see the core problem, they will tell us “We already know that. We have already spoken out about it, more than once.” And they really believe the problem exists, and the analysis is correct. They have seen both sides of the conflict. They are keenly aware of both sides of the conflict. But do you see what’s happening? Most suggestions for improvement that they have seen in their careers, the vast majority, anyway, are not solutions or improvements that remove the conflict, they are solutions based on movement on the conflict arrow. To give an example of what we mean by “movement on the conflict arrow” consider the bin-annual flip-flop in many companies; from centralisation, to decentralisation, and back again to centralisation. Each time this movement was presented as “THE thing that will save the company” So many huge and expensive reorganisations. Each time, these smart conservative people oppose such initiatives.

Why? They’ve already seen solutions based on movement on the conflict arrow. They have learned from experience that the ONLY thing that will happen in such cases is the substituting one set of undesirable effects for another set of equally undesirable effects. And if that’s what people want to do, better not to do anything. ”Thank you – we have seen it before, we’ve been there already, why should we try the same thing again?”

Remediation: Block Movement on the Conflict Arrow, Identify and Remove the Flawed Assumption

How then do we cause these conservative folks to move towards our true consensus? Let’s present some new ideas, and for each one show the core problem, the conflict. To begin with they will not be surprised. They know the problems already. But then we show them that we have no intention whatsoever to move on the conflict arrow. More than that, we show that we propose blocking any movement on the conflict arrow, because it would be just substituting one set of undesirable effects with another.

Instead, we highlight the flawed assumption within the conflict. We don’t say ”we have a solution”, but rather “we have a direction for a solution”. In other words, our direction is based on the knowledge that we have found one (or more) flawed assumptions. So now we proceed to the next step: creating the full solution. In Theory of Constraints, the full solution emerges from the creation of a Future Reality Tree.

Yes, But

The Future Reality Tree leverages the remarkable ability of people, especial smart, conservative people, to say “Yes, but…”. Usually, a small yes, and a big BUT…

So, rather than attacking these “yes, but” reservations, we embrace the gift within every “yes, but”: “Yes, I understand the solution, yes, it will remove the conflict, BUT it will create another issue…”.

We help as much as we can to meticulously document the cause and effect of the “but”. We go out of our way to do this, to clarify their reservation. Once we have articulated really clearly what’s bothering someone, their reservation will augment our solution by removing the “but”. In this way we arrive at a full solution. With each reservation making that solution simpler, more powerful, and more intense.

And we ourselves learn the value of taking the time to listen to and clarify folks’ reservations.

Repeating this approach three or four time with a smart conservative person, they begin to realise that we are even more paranoid than they are. In a good way.

As soon as these folks understand our intentions, our rigour in dealing with risks, they become our champions and biggest supporters. In most cases the biggest supporter of True Consensus and all the changes it implies is the CFO.

This is how to remediate the obstacle of the smart conservative.

And by the way, did you notice how it’s much the same approach as we take with the Dominant Impatient Visionary?

Next time: Extrapolating From the Past – another obstacle to True Consensus explored.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

 

%d bloggers like this: