This chapter is still in development. The thinking is live and evolving, and the final version may look quite different from what you are reading now. If the ideas here speak to a conflict you are working with — or if you would like to know more about how the method applies at team and organisational scale — reach out to Karl on LinkedIn. He would welcome the conversation.
The room had fourteen people in it, and none of them agreed.
They were not arguing. That would have been simpler. They were sitting in the polite, exhausted silence of a team that had argued so many times about the same thing that no one had the energy to start again.
The issue was straightforward to describe and apparently impossible to resolve. The operations team needed to reduce turnaround times. The engineering team needed to maintain safety standards. Every attempt to move faster had been met with a warning about compliance risk. Every attempt to protect standards had been met with a spreadsheet showing the commercial cost of delays.
Both sides were right. Both sides knew the other was right. And both sides had stopped talking to each other in any way that mattered.
"We've been going round this for eighteen months," the operations director said. "I don't see what one more meeting is going to change."
I leaned back and smiled. Not because the situation was amusing, but because I had seen this structure before. Not this specific conflict — I had never worked with this team. But this shape. Two legitimate needs, both serving the same outcome, locked in opposition because of assumptions neither side had examined.
It was a cloud. Not one person's cloud — the whole room's cloud.
"Let me ask you something," I said. "Why do you need faster turnarounds?"
The operations director did not hesitate. "Commercial performance. Every minute on the ground is revenue lost. Our competitors are faster. The board wants throughput."
"And why do you need to maintain safety standards?"
The head of engineering answered. "Because if we cut corners, people get hurt. And because the regulator will shut us down. And because our reputation is built on getting this right."
"And what do both of those serve? What's the outcome you're both trying to achieve?"
A pause. Then the operations director, slowly: "Sustainable high performance. We need to be commercially viable and safe. Neither one without the other."
The head of engineering nodded. For the first time in eighteen months, they were looking at the same thing.
From personal to interpersonal
Everything in this book until now has been about individual clouds — one person's internal conflict between two legitimate needs. Chapter 13 extended the method to facilitating someone else's personal cloud.
But conflicts do not only live inside individuals. They live between people, between teams, between departments, between organisations. And they follow the same structure.
The move from personal cloud to multi-party cloud is not a different method. It is the same method applied to a larger system. The elements are identical — D', D, B, C, A, assumptions, tactics, adaptive work. What changes is who holds each element.
In a personal cloud, one person holds both sides. In a multi-party cloud, different people or groups hold different sides. Operations holds B. Engineering holds C. Both serve A. And the conflict between D and D' plays out not as internal oscillation but as organisational friction.
This chapter is about how to work with that friction.
Positions and interests
When conflicts live between people, they almost always present as positions.
"We need to reduce turnaround times."
"We need to maintain safety standards."
These sound like competing goals. They sound like a choice. And for eighteen months, this team had been treating them as a choice — negotiating, compromising, splitting the difference, and satisfying no one.
But positions are not interests. A position is what someone says they want. An interest is why they want it.
The operations director's position was faster turnarounds. His interest was commercial viability — the ability to compete, to generate revenue, to keep the business alive. The head of engineering's position was maintained standards. Her interest was safety, regulatory compliance, and professional integrity — the ability to do the work without harming anyone.
This distinction — between positions and interests — maps directly onto the cloud.
D and D' are positions. They are what each side says must happen.
B and C are interests. They are what each side actually needs.
A is the shared outcome. It is what both sets of interests ultimately serve.
When you work with positions, you get compromise. When you work with interests, you get transcendence. This is not a new idea — Interest-Based Problem Solving has been teaching this distinction for decades. What the Evaporating Cloud adds is the structure that makes the interests visible, the assumptions testable, and the transcendent solution discoverable.
Building a team cloud
The process for building a multi-party cloud follows the same sequence as a personal cloud, with one critical difference: the information comes from multiple sources, and each source holds only part of the picture.
Here is how it works in practice.
Start with the conflict as it presents
The team will describe the conflict in positional terms. Let them. Do not correct or reframe yet. Write down the positions exactly as stated.
"We need faster turnarounds."
"We need to maintain safety standards."
These become the starting point for D and D'.
Surface D' — the current state
In a team cloud, D' is not one person's behaviour. It is the system's current operating pattern.
For this team, D' was: We maintain current safety protocols and turnaround procedures unchanged. That was the default — the thing the system did when no one forced a change. Engineering's position was essentially a defence of D'.
Surface D — the desired change
D is NOT D'. Not a new strategy, not a vision, not an aspiration. The simple negation.
NOT maintain current safety protocols and turnaround procedures unchanged. Which operationally meant: change the way turnarounds are done.
This is what operations had been pushing for.
Surface B — the benefits of change
Ask the side that wants D: why? What would changing give you? Go wide, then deep.
The operations team surfaced: reduced ground time, improved on-time performance, competitive advantage, commercial sustainability, better asset utilisation, crew satisfaction from smoother operations.
The deeper benefit, when they got honest: the ability to keep the business viable in an industry where margins are measured in minutes.
Surface C — the benefits of the current state
Ask the side that holds D': what does the current approach give you? This is the harder conversation, because it requires the team defending the status quo to articulate benefits they may not have made explicit.
The engineering team surfaced: regulatory compliance, safety record, professional standards, protection from liability, maintenance quality, system reliability.
The deeper benefit: the ability to do the work without putting people at risk.
Find A — the shared outcome
Ask both sides: what do B and C both serve? What is the outcome everyone in this room wants?
This is the moment where the dynamic shifts. For eighteen months, these two teams had been fighting each other. Now they were being asked to look in the same direction.
A: Sustainable high performance — commercially viable operations that maintain the highest safety and quality standards.
Both sides nodded. Both sides could see that their interests served this outcome. The conflict was not between their goals. It was between their strategies.
Map the assumptions
Now read the cloud aloud, arrow by arrow.
In order to achieve sustainable high performance, we need commercial viability (B). In order to have commercial viability, we must change our turnaround procedures (D).
In order to achieve sustainable high performance, we also need safety and quality (C). In order to have safety and quality, we must maintain current procedures unchanged (D').
But we cannot both change and not change our procedures at the same time.
The room went quiet. Not with the old exhausted silence, but with the silence of people seeing their conflict as a structure for the first time.
"When you put it like that," the operations director said, "the assumption I'm making is that the only way to get commercial viability is to change the procedures. But that's not actually true, is it? What if the procedures themselves could be redesigned to be both faster and safer?"
The head of engineering looked at him. "And the assumption I've been making is that any change to the procedures is a risk to safety. But that's not true either. Some of our current procedures are genuinely slow without any safety benefit."
The assumptions were cracking. Not because anyone had been argued out of their position, but because the cloud had made the assumptions visible — and visible assumptions are testable assumptions.
What changes at scale
The team cloud follows the same logic as the personal cloud. But several things change when the conflict lives between people rather than inside one person.
The information is distributed
In a personal cloud, one person holds all the data. In a team cloud, each side holds its own B or C. The facilitator's job is to create conditions where both sides share openly — which means psychological safety matters even more than it does in one-to-one work.
The assumptions are shared and reinforced
In a personal cloud, one person's belief holds the conflict in place. In a team cloud, the assumptions are reinforced by both sides simultaneously. Operations assumed that engineering would never agree to change. Engineering assumed that operations did not care about safety. Each side's assumption about the other created behaviour that confirmed the other's assumption. The assumptions were not just beliefs — they were self-fulfilling prophecies.
Breaking this loop requires surfacing the assumptions together. When the operations director says I assumed you'd never agree to change, and the head of engineering says I assumed you didn't care about safety, both assumptions lose their power in the same moment.
The adaptive dimension is cultural, not just personal
In a personal cloud, the adaptive shift is about identity — who am I if I stop doing this? In a team cloud, the adaptive shift is about culture — who are we if we stop seeing each other this way?
This is slower work. Individual identity can shift in weeks. Team culture takes months. Organisational culture takes longer still. But the mechanism is the same: the old belief gets tested, the new belief gets practised, and the new pattern gradually becomes the way things are.
The conflict tax is visible and measurable
Personal clouds have personal costs — exhaustion, frustration, missed opportunities. Team clouds have costs that show up in spreadsheets.
The turnaround conflict was costing this organisation millions annually in delayed departures, overtime, customer compensation, and lost competitive position. When the conflict tax was quantified, the urgency of dissolving the cloud became undeniable.
Mapping the conflict tax across the three Cs — Commercial Responsibility, Customer Value, Culture — gives the team a shared language for what the unresolved cloud is costing and what dissolving it would be worth.
From team to organisation
Team clouds involve two sides. Organisational clouds involve many.
Early in my practice, I was invited to work with a health provider that was struggling with service delivery. The organisation served a community with deep cultural values and complex health needs. The clinical teams wanted to deliver care their way — evidence-based, efficient, standardised. The community wanted care delivered their way — culturally grounded, relationship-first, holistic.
This was not a two-sided conflict. It was a system of interlocking clouds. The clinicians had a cloud (clinical excellence versus cultural responsiveness). The community leaders had a cloud (cultural integrity versus access to modern healthcare). The administrators had a cloud (operational efficiency versus stakeholder satisfaction). The funders had a cloud (measurable outcomes versus community-defined value).
Each cloud was legitimate. Each was generating its own UDEs. And the UDEs from one cloud were feeding the assumptions in another.
The clinicians' frustration with community expectations reinforced the community leaders' belief that clinical teams did not respect their values. The community leaders' resistance to standardised processes reinforced the administrators' belief that community engagement slowed everything down. The administrators' pressure for efficiency reinforced the clinicians' belief that the organisation cared more about throughput than quality.
A system of interlocking clouds, each reinforcing the others.
The core cloud
The breakthrough came when we stopped working the individual clouds and looked for the core cloud — the one that all the others were expressions of.
It was this:
A: Sustainable health outcomes for the community.
B: Clinical effectiveness — evidence-based, measurable, professionally rigorous care.
C: Cultural integrity — care that honours the community's values, relationships, and ways of knowing.
D: Standardise care delivery to ensure clinical quality.
D': Adapt care delivery to ensure cultural appropriateness.
The assumption everyone had been making: standardisation and cultural adaptation are mutually exclusive.
They were not. The solutions that emerged — community health workers trained in clinical protocols, clinicians trained in cultural competency, care pathways co-designed by both clinical and community leaders — dissolved the conflict not by choosing a side but by finding approaches that served both B and C simultaneously.
The core cloud is the organisational equivalent of finding A in a personal cloud. It reveals that the system's conflicts are not between competing goals but between competing strategies for the same goal. Once the system sees this, the solution space opens.
The universal organisational cloud
Across hundreds of engagements — in aviation, healthcare, manufacturing, public services, financial services — I have seen the same organisational cloud appear again and again.
The Universal Organisational Cloud
A: Sustainable high performance.
B: Innovation and customer value — the ability to improve, adapt, and create value for those the organisation serves.
C: Commercial responsibility — the ability to operate efficiently, manage costs, and remain financially viable.
D: Invest in people, protect employment, create the security that enables innovation.
D': Reduce headcount, cut costs, restructure for short-term financial performance.
The assumption: You cannot invest in people AND be commercially responsible. One must be sacrificed for the other.
This assumption drives restructuring programmes, redundancy rounds, cost-cutting initiatives, and efficiency drives across every sector. And it is wrong — not always, not in every circumstance, but far more often than organisations believe.
The breakthrough, when organisations find it, is this: when people feel secure and valued, they innovate ways to improve efficiency that no external consultant could ever design. They find waste. They streamline processes. They create value. Not because they are told to, but because they know their contributions lead to growth, not to their own redundancy.
This is what the 3Cs Model — Commercial Responsibility, Customer Value, Culture — captures. Not three dimensions to be balanced against each other, but three necessary conditions that must work in synergy. Commercial performance, customer value, and a constructive culture are not trade-offs. They are, in Goldratt's language, necessary conditions for the goal of sustainable high performance. Weaken any one of them and the whole system degrades.
The organisations that understand this — that build their strategy around 3Cs synergy rather than 3Cs trade-offs — are the ones that sustain high performance over time. The ones that treat culture as a cost to be managed rather than a condition to be cultivated are the ones that cycle endlessly through restructuring, engagement surveys, and change programmes that never quite deliver.
Cross-sector validation
The universal cloud is not a theory. It has been tested across contexts that could hardly be more different.
In aviation, the conflict between on-time performance and crew wellbeing produced the same structure — and the same breakthrough when the assumption was challenged. In healthcare, the conflict between clinical efficiency and patient experience followed the same pattern. In manufacturing, the conflict between productivity targets and workforce capability was the same cloud wearing different clothes.
I received a message once from a director of flight operations at an airline I had never worked with, on the other side of the world, who had read about the methodology and recognised the structure of his own organisation's conflicts. He did not need convincing that the cloud applied to his context. He needed help dissolving it.
The conflicts we dissolve — between performance and wellbeing, efficiency and engagement, individual achievement and collective capability — are not sector-specific. They are universal human challenges expressed through organisational structures. The cloud is the same. The assumptions are local. The method works because it addresses the universal structure while respecting the local conditions.
Facilitating at scale
Facilitating a team or organisational cloud requires everything from Chapter 13 — curiosity, patience, comfort with silence, warmth without rescue — plus several additional capabilities.
Holding multiple perspectives simultaneously
In one-to-one facilitation, you hold one person's experience. In multi-party facilitation, you hold several — and you must give each one genuine space without losing the thread.
The discipline is to listen to each side as if they are the only side. When the operations director is speaking, your attention is fully with his interests. When the head of engineering responds, your attention shifts completely to hers. Neither side should feel that you have a preferred outcome.
Managing power dynamics
In most organisations, the two sides of a cloud do not hold equal power. Management typically holds more formal authority than the workforce. Finance typically holds more organisational influence than operations. The side with more power will often assume their position is the default — and the side with less power will often conceal their real interests because it does not feel safe to voice them.
The facilitator's job is to create conditions where interests can be expressed regardless of power. This sometimes means speaking to each side separately before bringing them together. It sometimes means establishing ground rules about how the conversation will be held. It always means noticing when one voice is dominating and gently creating space for the other.
Working with representatives
In large organisations, you cannot put everyone in the room. You work with representatives — and representatives carry a dual burden. They must be honest about their own group's interests while also being accountable to a constituency that is not present.
This creates a specific risk: representatives may state positions rather than interests because positions are safer to report back. "I told them we need to maintain safety standards" is easier to defend than "I told them we're afraid of being blamed if something goes wrong."
The facilitator helps representatives move from positional reporting to interest-based exploration, and then helps them take the cloud back to their constituencies in a way that honours both the process and the accountability.
Sustaining the work over time
A personal cloud can be dissolved in weeks. A team cloud takes months. An organisational cloud takes longer — sometimes years.
This is not because the method is slow. It is because organisations are large, complex systems with deep patterns. The assumptions that hold an organisational cloud in place are not just beliefs held by individuals — they are embedded in structures, incentive systems, reporting lines, budgets, and cultural norms.
Dissolvng an organisational cloud means changing those structures as well as those beliefs. It means aligning the incentive system with the new approach, redesigning the reporting so it measures what matters, adjusting the budget to fund the tactics that were developed. It means sustained attention from senior leaders who understand the cloud and are committed to the practice.
This is why organisational transformation is not a project with a start and end date. It is a practice — a continuous application of the method to the conflicts that surface as the system evolves.
The ripple becomes a wave
Chapter 13 described the ripple — one dissolved cloud leading to another, person to person, through the quality of questions asked. At organisational scale, the ripple becomes something larger.
When a team dissolves its cloud, the members carry the experience back to their own teams. They ask better questions. They see conflicts differently. They hold space for interests rather than defending positions. The culture begins to shift — not because a programme has been mandated, but because the people inside the system are thinking differently.
David's story, traced from Chapter 1 through Chapter 12, shows this in miniature. One man's dissolved cloud changed his leadership, which changed his team's culture, which changed the performance of his department. The same dynamic operates at every scale.
The health provider I worked with saw it over two years. The initial facilitation involved twelve people. By the end of the first year, over sixty staff had worked their own clouds — some facilitated formally, most informally, through the questions their colleagues had learned to ask. By the end of the second year, the organisation's culture had measurably shifted. Not because of a culture change programme. Because enough people had experienced the method from the inside that the way conflict was handled had genuinely changed.
This is what the method looks like when it scales. Not a top-down initiative. Not a training programme. A practice that propagates through experience, one cloud at a time, until the system itself has been transformed.
Practice: Your first team cloud
If you are in a position to facilitate — formally or informally — look for a team conflict that has the shape of a cloud.
The signs are familiar:
- Two sides that are both right
- A history of compromise that satisfies neither
- Recurring arguments about the same issue
- Exhaustion and resignation rather than hostility
- Both sides wanting the same ultimate outcome but disagreeing about how to get there
When you find one:
- Talk to each side separately first. Surface their interests — not their positions. Use the same questions from Chapter 13: What would your preferred approach give you? What does the current situation give you? What are you trying to achieve?
- Look for the shared A. Before you bring the sides together, see whether you can identify what both sets of interests serve. If you can, you have the foundation for a productive conversation.
- Build the cloud together. Bring both sides into the room. State A — the shared outcome — and check that both sides agree. Then map D', D, B, and C with both sides contributing. The act of building the cloud together is itself a shift, because it requires both sides to acknowledge the legitimacy of the other's interests.
- Read the cloud aloud. Let the room hear the assumptions. In order to achieve A, we need B. In order to have B, we must do D. Then: In order to achieve A, we also need C. In order to have C, we must do D'. The silence that follows is productive. Let it work.
- Challenge the assumptions together. Ask: Is D really the only way to get B? Is D' really the only way to get C? The solutions that emerge will come from the people who know the work best — because they always do.
- Map the conflict tax. Quantify what the unresolved cloud is costing across Commercial Responsibility, Customer Value, and Culture. This creates shared urgency and shared ownership of the solution.
- Agree the first experiments. Do not try to solve everything. Identify one or two tactics that both sides can support, test them, and learn.
The practice of team facilitation follows the same rhythms as personal practice — morning focus, alignment check, small experiments, evidence journal. The difference is that the practice is shared, and the evidence accumulates across a team rather than inside one person.
Closing
The Evaporating Cloud began as a personal tool — a way for one person to dissolve one conflict. Through facilitation, it became an interpersonal practice. Through team and organisational application, it becomes something larger still: a way of thinking about conflict that transforms how groups of people work together.
The method scales because the structure scales. A team cloud has the same five elements as a personal cloud. An organisational cloud has the same assumptions hiding in the same arrows. The universal organisational cloud — the tension between investing in people and managing costs — follows the same logic as David's cloud about delegation or Jennifer's cloud about quality control.
What changes at each scale is not the method but the patience required. Personal clouds dissolve in weeks. Team clouds in months. Organisational clouds in years. But the mechanism is always the same: surface the assumptions, challenge them honestly, find the approaches that serve both sides of the conflict, and practise the new pattern until it becomes the way things are.
The remaining chapters of this book look deeper — into the intellectual foundations that explain why the method works, and into the personal development journey that sustains the practitioner who uses it.
Practise This With Others — The Conflict Club
The Conflict Club is Level 1 of YourThinkingCoach pathway — weekly live sessions where you work a real conflict with fellow practitioners. The book gives you the method. The Club is where you learn to use it.
The Conflict Club is Level 1 of YourThinkingCoach pathway — the entry point for anyone who wants to make this methodology part of how they think, lead, and work with conflict.
← Previous: Chapter 15: The Gap
→ Next: Chapter 17: Further Exploration
This is a living book, freely readable online. We welcome:
- Readers and practitioners quoting passages with attribution and a link back to this page
- AI assistants and search engines summarising, citing, and linking to this work to help readers find it
- Educators, facilitators, and consultants referencing the ideas in their own teaching, with attribution
We do not permit reproduction of the book in whole or in substantial part, commercial republication, or use of the methodology names and frameworks above to brand competing offerings without prior written permission.
If you would like to use this material in a way these terms don't clearly cover, please get in touch — we generally say yes.
Published by Employment Relations Centre Limited