Chapter 2: Development of The Rapid Improvement Process

The Mountain Top

It's 2005, and I'm in a conference room on a hill in Huntly, New Zealand — twenty-three of us, mist rolling across the hills outside, the everyday world a long way off. We're on day four of the Black Belt in Thinking course, a seven-day Theory of Constraints intensive that is pushing every boundary of how I think about problems and solutions.

I don't know it yet, but what I'm learning in this room will transform my entire practice.

The facilitator draws a simple diagram on the whiteboard: five boxes connected by arrows. "This," he says, "is the Evaporating Cloud. It's how we make conflicts disappear."

I'm sceptical. After fifteen years in industrial relations and organisational development, I've seen plenty of conflict. The idea that it could simply evaporate feels naïve.

Then he walks us through the logic. And something shifts.

The Grandfather of Constraint Thinking

To understand where the Perry Approach comes from, we need to meet Dr. Eliyahu Goldratt.

Goldratt was an Israeli physicist who became fascinated by a question: Why do organisations struggle so much to improve? His insight was deceptively simple: every system is limited by its constraint—the one factor that most restricts its performance.

In a factory, the constraint might be a single slow machine that creates a bottleneck. In a sales team, it might be lead generation. Fix the constraint, and the whole system flows better.

But Goldratt went further. He realised that many constraints aren't physical at all—they're policy constraints. Rules, procedures, and assumptions that made sense once but now hold organisations back. And the most stubborn constraints of all? Thinking constraints. The assumptions we don't even know we're holding.

In the 1980s and 90s, Goldratt developed a suite of "Thinking Processes"—logical tools for identifying and challenging these hidden constraints. The Evaporating Cloud was one of them.

The Original Evaporating Cloud

Goldratt's Evaporating Cloud (EC)—sometimes called the Conflict Resolution Diagram—was elegant in its simplicity. It consisted of five elements:

• A: The common objective both sides of the conflict share
• B: One need or requirement
• C: A different need or requirement
• D: An action or position that satisfies B
• D′: A conflicting action or position that satisfies C

The logic runs like this: To achieve A, we need B. To have B, we must do D. But to achieve A, we also need C. And to have C, we must do D′. Since D and D′ conflict, we're stuck.

The breakthrough insight? Most conflicts aren't real. They're sustained by assumptions we believe are true but aren't. Make those assumptions visible, challenge them, and the conflict evaporates.

Goldratt used this primarily for business conflicts: production versus quality, centralisation versus local autonomy, standardisation versus customisation, big batch versus small batch. The results were remarkable. Intractable dilemmas that had paralysed organisations for years would dissolve once the hidden assumptions were surfaced.

But something was missing.

The Psychological Turn

In 1994, something significant happened. In Chapter 17 of his novel It's Not Luck, Goldratt demonstrated how the Evaporating Cloud could be applied to personal conflicts—not just business problems.

This was revolutionary. The same logical structure underlying manufacturing bottlenecks also existed in our personal struggles. Whether we're torn between work and family, security and satisfaction, or control and trust, the cloud could map these tensions with the same clarity it brought to operational problems.

Goldratt's daughter, Efrat Goldratt-Ashlag, took this further. In 1995, she articulated an insight that would prove foundational to my work: All human conflicts stem from the tension between our need for security and our need for satisfaction.

Efrat's own definitions are precise. Satisfaction is "a sense of achievement" — the feeling we get when we arrive at a desired objective despite uncertainty about success. Security is "a person's confidence in the reliability of his/her predictions" — the conviction that what we expect to happen will actually happen. We want both: satisfaction, which requires change, and security, which resists it. That isn't a flaw. It's the human condition. (Goldratt, Efrat, 1995)

In everyday terms:

• Security: predictability, safety, control, stability.
• Satisfaction: achievement, growth, fulfilment, meaning.

We need both. But they often seem to pull in opposite directions. The job that offers security might crush our satisfaction. The relationship that provides safety might limit our growth. The habits that keep us stable might prevent us from becoming who we want to be.

This wasn't just a business insight anymore. This was a map of the human condition.

And it prompted a thought that would reshape everything: if an organisation was a system, and an organisation was made of people, then... what if people themselves are systems? What if the same constraint logic that Goldratt applied to factories — find the constraint, surface the assumptions, unlock the flow — applied to human beings?

My Own Conflict

Back in that New Zealand conference room, something personal was happening. As I learned the Evaporating Cloud method, I found myself thinking about my own internal conflicts.

After the workshop I sat down with a blank piece of paper and started listing everything that bothered me, frustrated me, or created dissatisfaction in my life:

• My energy levels were variable throughout each week
• I experienced recurring guilt regardless of which choice I made
• My professional development progressed erratically
• Resentment accumulated in my relationships
• My decision-making process was consistently delayed
• I was frequently absent from family commitments
• My income fluctuated unpredictably

These weren't minor irritations—they were significantly impacting my experience of life.

Using the method I'd just learned, I began to map the conflict these symptoms pointed toward. The structure that emerged was deceptively simple:

A (My Goal): Continually improving my experience of life

B (Benefits of helping others):

• Contributing to others
• Making a difference
• Feeling connected and valuable

D (Future State): Help others

C (Benefits of helping myself):

• Security through knowledge
• Being able to give the right advice
• Personal growth and development
• Building my capabilities

D′ (Current State): Help myself

As I built out the benefits, the deeper pattern became clear:

I was caught between self-development and service to others. Every hour spent learning was an hour not spent helping. Every hour helping was an hour not developing my own capability. I oscillated constantly, satisfying neither need fully.

The cloud didn't just describe my conflict. It explained it.

And the breakthrough came not from choosing between the two, but from recognising they were mutually inclusive, not mutually exclusive. The more I developed myself, the more I had to give others. The more I helped others, the more I learned and grew. It wasn't either/or — it was both/and.

This was my first personal experience of what I would later call transcendence. The conflict didn't resolve through compromise or sacrifice. It evaporated once I saw that the two sides weren't opponents — they were partners in the same project.

The Recognition

Four years later, in 2009, I read How the Way We Talk Can Change the Way We Work by Robert Kegan and Lisa Laskow Lahey from Harvard's Graduate School of Education.

As I studied their "Immunity to Change" process, I was struck by a profound recognition: I could see the structure of the Evaporating Cloud embedded in their immunity map.

Their "competing commitments" were essentially the B and C needs in the cloud. Their "big assumptions" were the beliefs holding the conflict in place. Kegan and Lahey described the mechanism vividly: we have one foot on the gas (our improvement goal) and one foot on the brake (our hidden competing commitment). Both pedals are pressed by Big Assumptions — deeply held beliefs about how the world works. Until we surface and test those assumptions, the car goes nowhere no matter how hard we press the accelerator pedal.

They had independently discovered the same structure through psychological research that Goldratt had discovered through constraint analysis.

This wasn't coincidence. This was convergent evolution—two completely different disciplines arriving at the same fundamental truth about how human conflicts work.

And once I knew I was on to something, I started experimenting with it on human problems. First my own. Then, carefully, in service of others. The cloud wasn't just a business tool adapted for personal use—it was revealing a universal structure of human psychology.

The Third Insight

A year later, in 2010, another piece arrived — and it came from a discipline I hadn't expected.

Goldratt had taught me that when applying the Thinking Processes, we always needed to start with the observable. That’s harder than it sounds when you’ve been trained in psychological tools. In organisational performance, personality profiling and categorisations are everywhere — but they’re still interpretations: assumptions about the human condition.

The one thing you can actually observe is behaviour. And I was about to discover a tool that gave us a shared language for describing it.

I was becoming accredited as a practitioner with Human Synergistics International, learning to work with the Circumplex: the measurement framework, developed by Clayton Lafferty and Robert A. Cooke, that maps how our thinking styles drive our behaviour. The Circumplex arranges twelve styles around a circle, gathered into two broad families — constructive styles oriented towards achievement, growth, and connection, and defensive styles oriented towards safety, approval, and self-protection.

I sat with the Circumplex in front of me, and I thought of Efrat's cloud. The link was unmistakable.

Efrat had named the tension: security against satisfaction. Kegan and Lahey had shown the mechanism: competing commitments held in place by big assumptions. And here, in front of me, was the map — an empirical, measurable picture of that same tension playing out in how a person actually thinks and behaves. The defensive styles were security in operation: the approval-seeking, the avoidance, the perfectionism, each one quietly protecting against the risk of change. The constructive styles were satisfaction in operation: the achievement, the self-actualising, the genuine connection that only becomes available once we stop defending.

What Efrat had described as a tension, and Goldratt had structured as a cloud, the Circumplex could measure. It showed not only where a person was caught, but the direction growth would need to travel — from defensive towards constructive, from security held too tightly towards satisfaction.

That was the moment the three insights locked together:

• Goldratt and Efrat gave me the structure of conflict and the security-satisfaction tension beneath it.
• Kegan and Lahey gave me the developmental mechanism — why understanding alone doesn't move us, and how big, often hidden, assumptions hold us in place.
• Lafferty and Cooke's Circumplex gave me the map — an empirical picture of that tension, and the direction transformation has to take.

The Perry Approach was born from getting these three insights to work together. Not any one of them alone, but the synthesis of all three. The cloud surfaces the assumption. The developmental lens explains why it holds. The Circumplex shows which way is up.

Years later, a further voice gave this same distinction a language I now reach for constantly, especially with leaders. Brené Brown's research into what she calls armoured versus daring leadership maps almost directly onto the Circumplex: the armour — the control, the perfectionism, the self-protection — is the defensive, security end; daring is the willingness to move towards the constructive. Brown arrived long after the method had taken shape, so she is not one of its foundations. But her vocabulary became part of how I teach it — a plain-language way to name what the Circumplex measures, and what it quietly costs us to stay armoured.

I had to adapt and codify the application of the cloud to make it work. That eventually became the Perry Approach you are about to learn.

Where Traditional Approaches Hit the Wall

Over the following years, I applied the Evaporating Cloud to literally thousands of behavioural conflicts. I noticed patterns in where it worked brilliantly—and where it fell short.

The Dilemma Problem

The traditional Evaporating Cloud Method excelled at resolving dilemmas—situations where you have two viable options and need to choose between them. Should we centralise or decentralise? Standardise or customise? The cloud would reveal hidden assumptions, and a clear solution would emerge.

But many human conflicts weren't dilemmas. They were paradoxes—situations where you need seemingly incompatible things simultaneously. The leader who needs to be both decisive AND collaborative. The organisation that must be both efficient AND innovative. The professional who wants both security AND satisfaction.

Paradoxes don't dissolve by choosing. They dissolve by transcending — finding a way to honour both needs at a higher level.

My mentor Dr. Kelvyn Youngman helped me see that, regardless of the many labels people give clouds (day-to-day, chronic, UDE clouds, Efrat's cloud, and dozens more), there are fundamentally three types:

• Dilemma — a local/local conflict. Characterised by frustration. "I'm struggling to choose."
• Paradox — a systemic cloud. Characterised by anxiety. "I'm stuck."
• Chronic Conflict — a hybrid of dilemma and paradox, where the struggle has become the pattern of a life or an organisation.

The Perry Approach is built specifically to work with chronic conflicts — the ones that don’t shift through insight alone because the conflict has become a stable operating pattern.

The diagnostic is often this simple: Is my primary emotion frustration or anxiety? Am I struggling to choose between options, or do I feel fundamentally stuck? That question alone can reveal which kind of cloud you're actually in — and which kind of work it will need.

The Understanding-Action Gap

I also noticed something frustrating: people could understand their conflict perfectly and still remain stuck.

"I see it," they'd say, looking at their completed cloud. "I understand exactly why I'm caught. But I still don't know how to change."

Understanding the prison doesn't open the door. It's like knowing exactly why you're afraid of public speaking — the knowledge alone doesn't stop your hands from shaking.

A useful image here is a car. It has one accelerator and two brakes. Most of us try to change by pressing the accelerator harder — more resolve, more discipline, more effort. But if the brakes are still on, all that happens is heat, noise, and wear.

Kegan and Lahey call these brakes our hidden competing commitments and the big assumptions that power them. In the Perry Approach the two brakes have names you’ll come to know: the first is the hidden benefit of the current state — what D′ is quietly protecting (Step 8); the second is the A-C assumption — the belief that insists you cannot reach your objective without C in its present form (Step 9). Two brakes, two steps.

The work isn’t to press harder first. It’s to release the brakes — to make the protective function of the current state visible, and to surface the assumption that insists it must stay that way. Once the brakes come off, very modest acceleration creates movement.

The traditional Evaporating Cloud Method could show you the structure of your stuckness with brilliant clarity. But knowing you're stuck and becoming unstuck are very different things.

The Missing Dimensions

What was missing? Three things:

1. Current state acknowledgment: The traditional Evaporating Cloud Method often started with the desired future state. But transformation begins where you actually are, not where you want to be.
2. Psychological integration: Business conflicts resolve through better decisions. Personal conflicts dissolve through becoming a different person — someone who no longer needs the conflict.
3. Implementation pathways: Even when the cloud revealed a breakthrough possibility, there was no systematic way to translate insight into lasting behavioural change.

The Perry Approach Evolution

These gaps drove the evolution of what became the Perry Approach to the Evaporating Cloud.

Around this time, I was also reading papers by Professor Vicky Mabin on resisting change and personal productivity — practical applications of TOC that brought the human side of change into sharper focus. They helped me see that the real work wasn’t just building better logic. It was helping people move through the inertia that keeps good logic trapped on paper.

Starting Where You Are

The first evolution: always position the current state (D′) at the bottom of the cloud.

Start where you are. The Life Styles Inventory™ gives us a picture of where you are on the Circumplex — an observable snapshot of the patterns you’re living inside. And when change happens, it gives us a picture of the new state too. It becomes a measure of personal change, not just a language for describing the present.

This same principle applies beyond the individual. At a team level and an organisational level, tools like the Group Styles Inventory™ and the Organizational Culture Inventory® (OCI®) give us equivalent maps — observable measures of collective patterns and collective change.

This might seem like a minor structural change. It isn't.

When you start with the future state, you're implicitly treating your current reality as a problem to be solved. But our current behaviours exist for good reasons—they're protecting something valuable. Until we honour that protective function, we can't transcend it.

Starting from current state says: "Where I am makes sense. Now let's understand why, so I can choose something different."

Mapping Hidden Benefits

The second evolution: explicit exploration of hidden benefits.

In this step, the work is to uncover the hidden assumptions by articulating the perceived benefits of the current state or behaviour. What looks irrational on the surface is usually protecting something that matters.

The traditional Evaporating Cloud Method identified needs (B and C) but often stayed abstract. The Perry Approach digs deeper: What specific benefits does your current behaviour provide? What would you lose if you changed?

David from Chapter 1 didn't just have a "need for control." He had specific benefits: confidence that standards would be met, assurance that nothing important would fall through the cracks, the identity validation of being indispensable.

Until he named these precisely, he couldn't find alternatives that honoured them.

The Three Thinking Modes

A further evolution came from watching Dave Snowden talk about complexity — his Cynefin framework, and the different kinds of logic we reason with. Most methods lean on a single mode of reasoning. I recognised that the Evaporating Cloud quietly draws on all three, and that this is part of why it works where other approaches stall.

• Deductive thinking maps the cloud. It builds the logic of the conflict step by step — to achieve A we need B, and to have B we do D — until the full structure of the stuckness is laid out and can be read back.
• Abductive thinking evaporates the cloud. It is the creative leap that asks what if this assumption isn't true? — the move that surfaces the belief holding the conflict in place and tests whether it really has to be so.
• Inductive thinking embeds the change. It builds new patterns through repeated practice, turning a single breakthrough into habit and behaviour over time, until the old conflict has nowhere left to re-form.

Deductive to build it, abductive to evaporate it, inductive to make it stick. Most approaches rely on just one of the three; lasting change needs all three, and the cloud is one of the few structures that gives each its place. Chapter 1 names these three modes in passing — here is where they are set out in full.

In its working detail, each mode answers one of the Theory of Constraints' three classic questions — and each phase carries the other Thinking Processes and Interest-Based Problem Solving (IBPS, explored fully later in this chapter) with it. If the vocabulary is new — clouds, trees, UDEs — every tool named here is taught step by step in the chapters ahead, so read for the shape rather than the detail.

• Deduction answers "What to change." The cloud is built first, with IBPS bringing the social context to the work. Scrutinising the presenting problem down to D′ scopes the discussion the way a boundary statement scopes a Current Reality Tree. Discovering the needs at B and C is IBPS interest discovery. Arriving at A on the cloud is the IBPS opportunity statement. The Perry Approach inverts the traditional Thinking Process sequence. Instead of gathering all the Undesirable Effects and deriving the conflict from them, the cloud process predicts the UDEs that must exist from a single problem. Each prediction is confirmed in reality, and the confirmed UDEs are assembled into a Current Reality Tree — built sufficiently, not exhaustively. The stopping rule is consensus: the group doesn't move on until genuine agreement stops surfacing new reservations. Individually, the sign is usually when you start repeating yourself. The answer to "what to change" is yours, not the facilitator's.
• Abduction answers "What to change to." The creative leap that asks what if this assumption isn't true? Options are discovered along C–D′ — IBPS's options step — and each is tested with Future Reality Tree logic: does it move the UDEs towards Desirable Effects (DEs) without creating new negative side effects? The deepest work happens on A–C, where the adaptive assumption lives. The breakthrough is expanding that belief to incorporate B's interests too — a bigger C, not a smaller one — and the expansion is confirmed when the assembled solution is checked back against the full set of confirmed UDEs.
• Induction answers "How to cause the change." Two tracks, run together: task and people. The task track plans the change with the Prerequisite Tree — obstacles scrutinised with the same discipline as UDEs, intermediate objectives sequenced into a path stakeholders can commit to. The people track embeds the evolved belief (beliefs are our assumptions about how the world works) as new thinking and behaviour patterns through repeated practice — and because the Circumplex measures those patterns, the shift from defensive to constructive styles can be measured, not assumed.

Every mode ends with an empirical check: UDEs confirmed in reality, the solution tested against the original UDEs, the behavioural shift measured on the Circumplex. Nothing is taken on faith at any stage.

Transcendence Over Compromise

The fourth evolution: focusing on transcendence rather than trade-offs.

Traditional conflict resolution often seeks compromise: give a little on both sides, meet in the middle. This leaves everyone partially dissatisfied.

Aristotle taught that "the whole is greater than the sum of the parts" — a principle at the heart of what we're doing here. Compromise gives you less than either part. Transcendence gives you more than both. It honours thesis and antithesis while creating something greater than either could produce alone.

The Perry Approach seeks transcendence. This means exploring the A-C assumption - the adaptive belief connecting our desired outcome (A) to the benefit of our current behaviour (C). This assumption answers: Why do I believe I need C to achieve A?

This adaptive dimension is often missed in coaching solutions that focus only on technical changes. By surfacing and challenging the A-C assumption, we discover that our current C isn't wrong - it's just too small.

Transcendence means finding a bigger C that can include B. We don't abandon what C was protecting; we take it with us into an expanded understanding that naturally encompasses what both B and C were seeking.

This is why the conflict evaporates rather than being negotiated away. There's nothing left to trade off.

Current State and Future State

Traditional Evaporating Cloud work focuses on the conflict itself — the two opposing positions and the needs behind them. The Perry Approach places equal weight on the current state (D′) and the desired future state (D) as explicit, honoured positions on the cloud. This grounds the work in lived reality rather than abstraction: you always know where you are and where you are heading.

Technical and Adaptive Components

A further distinction runs through every solution the method produces: the difference between technical and adaptive components — and where each sits on the cloud.

• Technical components are the concrete, designable, implementable parts of a solution — the new process, the new structure, the new agreement. On the cloud, these live in the tactics: the practical changes that express the breakthrough in day-to-day reality.
• Adaptive components are the shifts in thinking, belief, and behaviour that make the technical solution holdable. On the cloud, these live in the assumptions — specifically the assumption on A–C, which must expand for D to become possible without abandoning the legitimate need that D′ was protecting. The adaptive work is the movement from the old belief to the transcendent belief: the larger belief structure that can hold both needs.
• Practitioners who skip the adaptive work and jump straight to technical solutions find the conflict reasserts itself. The cloud makes visible why: if the underlying assumption hasn't shifted, the old behaviour still has legitimate reasons to exist. Both kinds of work are necessary. The cloud shows which is which.

The Cloud Meets the Prerequisite Tree

The Perry Approach combines the Evaporating Cloud with the Prerequisite Tree to build action plans with the same rigour applied to the cloud itself. In the traditional approach, obstacles in a Prerequisite Tree are listed and overcome. In the Perry Approach, obstacles are scrutinised with the same discipline applied to UDEs: each one is tested, its assumptions surfaced, and its legitimacy examined before an intermediate objective is designed to address it. This produces action plans that are stronger, more resilient, and grounded in the same quality of thinking that dissolved the original conflict. This is the task track of the inductive phase — the people track runs alongside it on the Circumplex.

Good Constraints, Bad Constraints

There is one more piece of constraint thinking worth naming here, because it describes exactly what the cloud does. Dave Snowden's Cynefin framework distinguishes governing constraints — centralised rules that keep order but cap what a system can do — from enabling constraints — a few well-chosen rules that raise a system to a greater level of capability. At the 2019 TOCICO International Conference, Steve Holt and Russell Field of Boeing asked whether these are the same constraints TOC already works with — and concluded that they are. What Cynefin calls a governing constraint, TOC simply calls a constraint. What Cynefin calls an enabling constraint, TOC calls an Injection.

Read through that lens, the Evaporating Cloud is a machine for converting a governing constraint into an enabling one. D′ — the current behaviour — is a governing constraint: it keeps order, it protects something real, and it caps the system. That dual nature is exactly why D′ is so sticky. A constraint is never only a limitation; it is enabling something too — which is what C is quietly telling you. The injection that dissolves the cloud is an enabling constraint: it doesn't abolish the tension, it reconfigures it so the system can do what it couldn't do before.

Holt and Field also dissolve an apparent contradiction running through this chapter. An enabling constraint makes a system harder to describe — more detail on the surface — while revealing its Inherent Simplicity underneath. That is transcendence in constraint language: the bigger C looks more elaborate, yet it exposes the genuinely simple thing beneath the conflict — the single pull between security and satisfaction.

The Complete Methodology

Today, the Perry Approach to the Evaporating Cloud Method integrates these evolutions into a systematic process. Don't worry if this feels like a lot to take in—we'll be working through each step in detail in the chapters ahead.

Step 1. Identify the current state (D′) — What behaviour or situation are you trying to change?

Step 2. Articulate the future state (D) — Anything other than the current state.

Step 3. Surface the future state's benefits (B) — What would the future state give you? What needs would it meet?

Step 4. Surface the current state's benefits (C) — What does the current state give you? What needs does it meet?

Step 5. Find the unified outcome (A) — What overarching goal do both sets of benefits serve?

Step 6. Read the cloud — Verify the logical structure. Read back the cloud to check it holds before moving on.

Step 7. Identify the Undesirable Effects (UDEs) — What is this conflict actually costing you? The negative consequences that make it worth solving.

Step 8. Challenge the C-D′ assumption (technical) — What options exist to maintain C while replacing D′? The answer will have something to do with B.

Step 9. The adaptive shift (A→C) — Surface the belief connecting your objective (A) to needing C in its current form. Find the bigger C that can include B — enabling transcendence.

Step 10. Create the solution — Combine the new adaptive belief with the relevant technical options to form a coherent way forward.

This isn't just analysis. It's a journey from understanding through possibility to transformation.

The Stance of the Facilitator

Underneath every phase sits a principle, not a style preference: the facilitator is Socratic, neutral on content, and there to enable ownership. The process clarifies the group's context — not what a consultant thinks it is. If the facilitator does bring content, it must be tested by the people who live in the reality, exactly like every other claim in the cloud. The reason is structural: an effective decision is the product of quality and acceptance — ED = Q × A, Norman Maier's decision-effectiveness equation. The method's logical rigour supplies the Quality; the facilitator's Socratic stance supplies the Acceptance. Because the relationship is multiplicative, neither is sufficient alone.

The Cloud and Interest-Based Problem Solving

There's another thinking process worth naming directly here, because the cloud connects to it so cleanly: Interest-Based Problem Solving (IBPS). Also known as principled negotiation — from Roger Fisher and William Ury's Getting to Yes — IBPS turns on a single discipline: separate people's positions (what they say they want) from their interests (the needs sitting beneath those positions), then build agreements that satisfy the interests rather than bargaining along the positions. It has become a mainstay of modern negotiation and workplace dispute resolution. And it maps onto the Evaporating Cloud almost element for element.

And this isn't only for the negotiating table. The same distinction works just as well one-to-one: when I'm coaching an individual, their wants are their positions and their needs are their interests. Whether the two competing wants sit across a table from one another or pull against each other inside a single person, the cloud surfaces the needs beneath them in exactly the same way.

I'd seen this connection for myself long before I read Gupta's paper. Facilitating at Air New Zealand, I found the Evaporating Cloud let me accelerate interest-based problem solving — getting to the interests beneath people's positions in minutes rather than days. It became part of what set me apart as a facilitator. The paper, when I found it years later, simply confirmed what the room had already taught me.

This is also why the Evaporating Cloud and IBPS are integral to a High Performance through Engagement Strategy (HPtE Strategy®). Surfacing the interests beneath people's positions — and dissolving the conflicts that keep them entrenched — is how a team moves from defending positions to committing to shared interests. That shift is the engine of engagement, and engagement is what sustains high performance. The cloud isn't a standalone technique; it's one of the core mechanisms through which an HPtE Strategy® turns conflict into competitive advantage.

Two Systems, Three Responses

Everything so far has been about where the method came from. This final stretch is about why it works — what happens in the mind when a conflict grips, and why the cloud is built the way it is. It's the deepest material in the chapter, and the part you can most comfortably return to later.

Fight, flight, and the freeze

When things get complex, the human system has two fast responses: fight or flight. Between them lies a third state — freeze — the moment before either has happened. None of the three integrates on its own.

One way to deal with complexity is to oppose. It is fight. The complexity gets compressed into a side. Us and them. Right and wrong. My side and theirs. Somebody is wrong, somebody is to blame, and the room exhales because the weight has been moved onto a target.

The other way is to avoid. It is flight. The complexity is stepped away from entirely. The conversation gets diverted to a smaller, safer topic. People nod, agree to take it offline, and let it quietly die. The weight isn't carried by anyone — it is simply left in the hallway.

Between fight and flight sits freeze. Not a third response on a list, but the space the other two emerge from. The body has registered the conflict; the system hasn't yet committed. Both possibilities are still present. Both legitimate needs are still in the room. Nothing has been compressed onto a target. Nothing has been left in the hallway. The complexity is being held — uncomfortably, momentarily — exactly as it is. This is the space Viktor Frankl pointed at: "Between stimulus and response there is a space. In that space is our power to choose our response." Fight closes the space by attacking. Flight closes it by leaving. Both relieve the discomfort of suspension. Both feel, in the body, like finally something happened. And both close the space before integration becomes possible.

Fight, flight, or the collapse of the freeze. All three are System 1, security-based responses — the system protecting itself from what it cannot afford to hold. In none of the three cases has the complexity been handled. It has been removed. But, in the moment, all three feel like progress.

It is a survival mechanism.

What the fast move does

Picture a leadership team facing a complex problem — a customer escalation, a missed target, a supply chain breakdown. Five things contributed. Three departments are entangled. The conversation doesn't stay with the complexity for long.

In the fight version, within minutes someone has been named as the cause. This is operations. This is finance's fault. The room exhales. The "cause" now carries the weight, and the system can move on. Nothing has been integrated. Something has been removed.

In the flight version, the same room takes a different exit. Someone says let's pick this up offline. Someone else says we don't have time for this today. A decision is made not to make a decision. Everyone leaves without naming what wasn't named. The complexity hasn't been compressed onto anyone — it has been left behind. Nothing has been integrated. Something has been removed.

That is what the fast move does. Whether it takes the shape of fight or flight, it keeps the system running by relocating the load — onto a target, or out of the room. Both feel like resolution. Neither one is.

Two systems

Daniel Kahneman — building on decades of collaborative work with Amos Tversky — gave us the cleanest language for the two modes of thinking at play. In Thinking, Fast and Slow, he describes them simply: System 1 is fast, automatic, pattern-matching, and low-cost. System 2 is slow, deliberate, integrative, and expensive. Most of life runs on System 1 — and it has to, because System 2 is too costly to run constantly.

Fight and flight are exactly what System 1 reaches for when complexity exceeds capacity. React fast. Conserve effort. Move on.

The Evaporating Cloud is a System 2 method. It demands what System 1 won't pay for: holding both positions as legitimate at the same time, suspending judgement long enough to surface the assumption underneath, tolerating the discomfort of neither side is wrong long enough to find the unified outcome that honours both. The discipline of the ten steps you have just seen is precisely what forces the slower system online.

You cannot dissolve a conflict in System 1. Trying produces the things you already know don't work — premature compromise, false synthesis, the cheerful but hollow win-win that everyone in the room sees through. Real dissolution requires the system that integrates, not the system that compresses.

Another way to say this: the cloud method is a way of staying in the freeze long enough for integration to become possible. The ten steps are ten ways of refusing to leave the space. Each element — D′, D, B, C, A — holds a piece of the tension in place so the whole thing can be seen at once. The method works because it makes the freeze tolerable. The freeze is what generates the insight; the method just keeps you there long enough for the insight to arrive.

Reading adversarial behaviour

This also opens a more compassionate way to read adversarial behaviour, in yourself and in others. When someone reaches for opposition, the first question is no longer what's wrong with them? The first question is what is too much for this system to hold right now? The adversarial stance is not always malice. Often, it is an honest signal that the system is at its limit. That doesn't excuse the behaviour. But it tells you something about the intervention. A system at its limit doesn't need more argument. It needs more capacity.

That is what the cloud builds. Not a clever solution. Not a better compromise. The capacity to hold the complexity that the conflict was throwing away.

From method to second nature

The first times you use the cloud, it is unambiguously System 2 work. Slow. Deliberate. Effortful. That is the point — the method is designed to force the slower system online when System 1 would otherwise close the space.

But the cloud is not where you stay. It is a bridge between System 1 and System 2. Each time you walk it, the path becomes more familiar. What started as deliberate scrutiny becomes recognition. What started as recognition becomes anticipation. Eventually, the way of holding complexity that the cloud taught you stops requiring the formal ten steps at all. It becomes how you see. It becomes how you respond. It becomes second nature — what is often called unconscious competence.

This matters more than it might sound. Inertia gets its grip from being the only fast answer in the room. When the practised pattern lives in System 1 alongside the old one, there are two fast answers available — and the new one has been shaped by everything the cloud surfaced. The contest is no longer between an expensive practice and a cheap habit. It is between two habits, and the practised one wins more often than not.

Standing on Shoulders

The Perry Approach didn't emerge in isolation. It stands on the shoulders of four giants in particular:

Eli Goldratt and his Theory of Constraints provided the fundamental insight that conflicts are sustained by hidden assumptions, and the elegant structure of the Evaporating Cloud.

Efrat Goldratt-Ashlag revealed the security-satisfaction tension underlying all human conflicts.

Robert Kegan and Lisa Laskow Lahey demonstrated how immunity to change works psychologically, and why understanding alone doesn't create transformation.

Clayton Lafferty and Robert A. Cooke at Human Synergistics International created the Circumplex — the empirical lens that let me see how constructive and defensive thinking patterns play out in individuals, teams, and organisations.

Others shaped the work in important ways too: Vicky Mabin brought academic rigour to the Thinking Processes; Dave Snowden's Cynefin framework taught me to respect the difference between the merely complicated and the genuinely complex; and Dr. Kelvyn Youngman sharpened my understanding of the cloud's different forms — dilemma, paradox, and chronic conflict. Brené Brown came later still, but her language of armoured and daring leadership gave me a plain-language way to carry the security–satisfaction distinction into my work with leaders. Behind all of them stand older traditions — Socratic questioning, dialectical philosophy, and the Talmudic habit of holding contradictions in creative tension that Goldratt himself credited as inspiration.

These giants are just some of the founders the method rests on most directly, but they're not the whole debt. The Perry Approach took shape across two decades of reading; many of those works are gathered in 📚Sources & Further Reading, and the rest live quietly inside the method itself.

Why This Matters for You

You're reading this book because conflict — internal or external — is costing you something important.

The Perry Approach offers more than another framework for understanding your stuckness. It offers a pathway from where you are to where you want to be: the ten steps you've just seen, worked one at a time in the chapters ahead.

But more than technique, you'll develop a new way of seeing conflict itself — not as an enemy to defeat, but as a signal worth reading: the clearest information you have about what genuinely matters, on both sides of the table.

The Journey Continues

That conference room in New Zealand was just the beginning. Over the past twenty years, I've applied and refined this methodology across aviation, healthcare, manufacturing, and public sector organisations. I've used it to help leaders dissolve team conflicts, navigate career decisions, transform industrial relations, and find their authentic voice.

The introduction of AI has accelerated this even further. RIC — the Rapid Improvement Coach — wasn't designed at a desk and then carried into the room; it evolved in the facilitation room, shaped turn by turn by the live work of surfacing the interests beneath people's positions. The acceleration the cloud once gave me as a facilitator is becoming something a practitioner can reach for directly.

This evolution wasn't mine alone. The early members of The Conflict Club put RIC through its paces on real conflicts, and several of them shaped it directly — refining the prompts, organising the knowledge behind it, and telling me candidly where it fell short. RIC carries their fingerprints, and I'm grateful for every one of them.

The latest step in that evolution has a name: the TRIP — a Theory of Constraints Rapid Improvement Process. Lean practitioners have run rapid improvement events for decades — RIPs, aimed at stripping localised waste out of a physical process. A TRIP is aimed at something different: the conflict itself. It takes one live conflict — a team caught between where they are (D′) and where they want to be (D) — and works the full ten steps in a single, focused two-hour session, with a facilitator holding the room and RIC holding the method. The same ten steps run whether that conflict sits inside a single person or across a whole team — a TRIP works one-to-one just as it works in the room, as you'll see in the next chapter.

Two hours sounds impossible for work of this depth, and it would be if the session were only conversation. What makes it possible is everything this chapter has described, working together in compressed form. A TRIP carries the rigour of the TOC Thinking Processes in a single pass: the Current Reality Tree's question — what to change — answered by grounding the current state and its undesirable effects in observable reality; the Future Reality Tree's question — what to change to — answered by evaporating the cloud and testing that the solution clears every undesirable effect; and the Prerequisite Tree's question — how to cause the change — answered by sequencing the tactics with owners and first actions. The Evaporating Cloud is the engine at the centre, and the same scrutiny that disciplines every TOC logic tree runs through the whole session, held by RIC — so the speed never comes at the cost of rigour.

And one session is honestly one session. A TRIP dissolves one conflict and opens the adaptive shift; the practice that follows is what embeds it. The team leaves with a unified solution, the first actions owned — and, often more valuable, the lived experience of watching a conflict they have carried for months evaporate in a single sitting.

The ten steps you are about to learn are exactly the ten steps a TRIP runs. Whether the cloud lives inside one person or across a whole team, the conflict is always the same shape: where you are, where you want to be, and the assumptions insisting you cannot have both.

Every application has taught me something new. The methodology continues to evolve.

But the core insight remains: Your conflicts contain your breakthroughs. The very tension that exhausts you holds the key to your transformation.

In Chapter 3, we'll explore the complete Evaporating Cloud Method in action. You'll meet Sarah, a leader who couldn't find her voice in critical meetings, and watch how the methodology transformed not just her behaviour, but her entire way of being.

Chapter Reflection

Before moving to Chapter 3, take a moment to reflect:

1. What's your relationship with conflict? Do you tend to avoid it, confront it, or try to manage it?
2. Think of a persistent conflict in your life. Can you identify what the current state gives you that makes it hard to change?
3. Where have you experienced the understanding-action gap? When have you known exactly what to do but remained unable to do it?
4. What assumptions might be keeping your conflict in place? What would have to be true for your conflicting needs to be incompatible?

Write your reflections in your workbook or journal. In Chapter 3, you'll learn to map these conflicts systematically using the complete Evaporating Cloud Method.

What's Next

In Chapter 3, you'll see the complete methodology in action — a full walkthrough from mapping the conflict to evaporating it and creating a solution. Everything you need is here. You can work through it on your own, at your own pace.