Example Conflict Resolution with TOC Evaporating Clouds (Part II)



In Part I we explored the nature of conflict and how Theory of Constraints Evaporating Clouds work.

Now we’ll bring the technique more to life with a concrete example using Acme Insurance, an online insurance provider whose CTO and COO are in conflict.


This kind of situation that is far more common that you might suppose and one which arises in part because of the different focus of different roles and the silos that can result by splitting work along functional lines.

The COO and CTO Fight


At Acme Insurance, whose primary business is now online, there’s a long-running conflict between the COO and CTO. Despite everyone’s best efforts they just cannot agree.

The CTO has been trying to get the organisation onto a new technical platform for years. The existing systems are prehistoric and becoming increasingly difficult to maintain and support. It is no longer possible to get external support and maintenance for key hardware and software systems, which mean that the technical team depend on their own wits and experience to keep things running.

Implementing new features on such an old platform is very challenging and lack of progress also puts the CTO regularly in conflict with the CMO who is desperate to deliver new services. Rising transaction levels put the existing architecture under ever increasing strain. The CTO has sleepless nights worrying about an unrecoverable systems failure that will kill the business.

The COO is opposed to a new platform. The existing system functions well and more importantly the entire service delivery organisation knows how it works, all its foibles and is skilled at getting the best from it.

The COO doesn’t trust the ability of the CTO to deliver (given past aborted initiatives) and believes that a wholly new solution would be hugely expensive to implement and so disruptive that service delivery could collapse, risking business reputation. The CTO has been complaining for years and disaster has never come. The COO also believes that the operational team would take the blame for any service failure during the migration.

After a series of unsuccessful meetings, the CEO decides to use Evaporating Clouds to help resolve the disagreement.

Drawing the Evaporating Cloud for the CTO and COO


The Wants-Needs-Shared Goals cloud for the CTO and COO

The CEO, CTO and COO get together to draw the Evaporating Cloud on the wall.

First they draw the conflicting positions of “New Technology” and “No System Changes”.

Next, the CEO probes the CTO and COO to understand the need behind each of their positions. After some back-and-forth exchanges they discover that the CTO’s primary need is to avoid systems failure and the COO’s primary need is to avoid service disruption.

Looking for common ground behind each need, the three of them soon work out that in fact both the CTO and COO are aiming to reduce risk. This is their shared goal. They disagree on what the biggest risks are (as we’ll see) and the best way to avoid them, but they are trying to accomplish the same beneficial outcome for the business.

(Note that the CMO who isn’t shown in this simplified picture is also trying to avoid risk – market risk that Acme Insurance will lose business to competitors).

Digging deeper and starting with the shared goal of reducing risk, the CEO next draws out the assumptions behind the different needs.

The full Evaporating Cloud with left-to-right assumptions for the CTO and COO

Behind the CTO’s insistence that avoiding systems failure is the assumption that this is the biggest risk to the business.

Behind the COO’s insistence that avoiding disruption to service is the assumption that this is the biggest risk to the business.

The three of them discuss the merits and the CEO states his perception that the biggest risk to the organisation is failing to move forward. The CEO highlights the CMO’s view of risk as justification for this view.

After lengthly discussion, the COO and CTO agree that they must find a way to move forward and that avoiding systems failure and service disruption are equally important.

Turning from the needs to the specific wants, the three of them look at the different assumptions.

It soon becomes clear that the CTO believes the current technology is so poor that a blank canvas solution is the only possibility. Starting again will allow them to build new systems from scratch that are fit-for-purpose and far more capable. This will also enable many new features and the CTO and their team are very excited about the possibilities for completely new interfaces and technologies.

At this point the COO identifies their key assumptions. They fear that a new solution would be so different that thousands of staff would need complete re-training and with current delivery pressures this would be simply impossible.

Resolving the Conflict


Having brought out all the wants, needs, shared goals and assumptions, the CEO, CTO and COO now explore new alternatives.

They very quickly come up with a new list of possibilities:


What if we develop new technology but with a similar/same front-end to minimise change?

What if we deliver new technology incrementally, starting with a single small-scale insurance product to reduce the risk and prove the technology?

What if we form a joint team of technical and operations staff to explore the best way to design a new interface that is intuitive and minimising re-training costs?

What if we targeted the highest volume products that represent the biggest risk and left other systems alone?

What if incrementally deliver and time new releases of systems to avoid service peaks?

By the end of the meeting, the CTO and COO are both keen on a route forward based on these ideas and they agree to work together to create a common proposal that satisfies everyone’s needs.

Concluding Remarks


It is one thing to be able bring people together using their boss. But sometimes that’s difficult. We can imagine that either the CTO or COO might not be willing to have this conversation.

It is still possible and useful to use Evaporating Clouds with only one party. With this you need to really focus on figuring out the other party’s wants, needs, and assumptions. You may then perceive a better solution that satisfies both and convinces others, though the other party may still object to it if they have not been involved.

You might be thinking this technique is interesting and useful, but fun, really?, come on! Well, YMMV but this can become fun if an organisation practices it widely and people grow to learn how much insight it brings. It is a lot more fun to work alongside other people and create solutions that meet everyone’s needs.

Nothing should now stand in the way of you trying this in your organisation. So – off you go.

Good luck implementing Evaporation Clouds in your organisation and if you need any help, you know where I am.

Posted in Decision-Making, Theory of Constraints.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>