Here is what actually moves an organisation. An event throws the received wisdom about what is possible into question. In doing so it opens up a new language of possibility, a way of talking about what could now be done that could not be said before. People reach for that language and start to organise around it, proposing new ways of working that the old vocabulary gave them no way to imagine. Out of those new arrangements a new kind of agency emerges, one that sustains and extends the change without anyone having to drive it. And then the most important thing happens: the completed change enlarges what people can see, which lets them identify and create the next event. Positive change is generative. It does not just solve the problem in front of it; it builds the organisation’s capacity to generate the change after that. This is a flywheel, and understanding it is the difference between an organisation that has to be dragged through every change and one that produces its own.

ELSA names the four movements this process passes through, so you can see which one you are in, which one you are avoiding, and why a change that looked complete keeps coming undone. The four are Event, Language, Structure, and Agency. They are not values, not stages of a maturity model, and not a checklist. They are the actual movements a change passes through to take hold, and the order matters, because each one produces the raw material the next one needs. This article explains each movement in its own terms, shows why they run in the order they do, explains the one transition that breaks the pattern, and shows how that break is what makes change generative rather than a thing you survive.

1. The Four Movements, in One Picture

Before the detail, the shape. A change begins with an Event: something happens that the existing way of seeing cannot account for, and in failing to account for it, opens a question about what is now possible. Then comes Language: people find words for the new possibility, because until it can be spoken it cannot be worked on. Then Structure: the new language gets built into something solid, a process, a team, a system, a budget line, or it stays just talk. Then Agency: people take the new structure and make it theirs, act through it without being told to, until it stops being an imposition and becomes simply how things are done.

That is one full turn. The catch, and the reason this is a cycle rather than a ladder, is what happens after Agency. Once a change is fully owned, the organisation can see things it could not see before; the new way of working reveals new possibilities, new questions, new events that were invisible from where it used to stand. The turn does not return you to where you started, and it does not just leave you exposed to the next external shock. It leaves you standing somewhere new, where you can see further, which means you can find and create the next event yourself rather than waiting to be hit by one. Change is not a line and not even a closed loop; it is a loop with a break in it, and the break is the most important part, because the break is where one change becomes the seed of the next.

2. Event: What Breaks the Old Frame and Opens a New One

An Event is not just news, and not every problem is an Event. Organisations handle most of what happens to them without any change at all, by fitting it into categories they already have. A competitor cuts prices: you have a playbook. A system goes down: you have a runbook. A regulation changes: you have a compliance process. None of that is an Event in the sense that matters here, because none of it requires the organisation to see differently. It is absorbed by the way of seeing that already exists.

An Event is the thing that cannot be absorbed that way. It is the development that does not fit any existing category, that the current playbook has no move for, that exposes a gap the organisation did not know was there. The arrival of a technology that makes a core skill cheap. A failure that the existing safety story said was impossible. A shift in what customers want that the segmentation model cannot describe. What makes these Events is not their size but their fit: they reveal that the organisation’s way of seeing has a hole in it, and the hole was always there, waiting for something to fall through.

But exposing a hole is only half of what an Event does, and the lesser half. The more important thing is that by breaking the received wisdom about what is possible, an Event opens a space that was closed before. As long as the old way of seeing held, certain things were simply not thinkable; they were ruled out so completely that nobody even argued against them. When the Event breaks that frame, those things become thinkable for the first time. The technology that makes a core skill cheap does not only threaten the people who had that skill; it makes a whole class of work newly possible that nobody could justify proposing while the skill was expensive. This is why the Event, not the leader, is the true agent of change. A leader can argue all day for a possibility that the prevailing wisdom rules out, and get nowhere, because the organisation has no room to hear it. The Event creates the room. It is the thing that makes the previously unsayable sayable, and only once something can be said can anyone organise around it.

This is why Events are so often denied. The first response to a genuine Event is almost always to treat it as a non-Event, to force it into an existing category and absorb it after all. The technology gets filed under “tools we already use.” The failure gets filed under “one-off, won’t recur.” The customer shift gets filed under “noise in the data.” Forcing the Event into an old category is not stupidity; it is the path of least resistance, because the alternative is admitting the way of seeing is incomplete, and that admission is expensive. But it is also where the possibility is lost, because an Event that is denied opens nothing. An organisation that can recognise an Event as an Event, rather than flattening it into something familiar, has done the first hard thing, and has kept open the possibility the Event arrived carrying. Most of the failure to change happens right here, before any change has even been attempted, in the refusal to admit that something has happened at all.

3. Language: The Vocabulary of the Newly Possible

Suppose the Event is admitted, and the possibility it opened is still alive. The organisation accepts that something has happened its existing categories cannot hold, and that something is now thinkable that was not thinkable before. Now comes the second movement, harder than it looks: building a language for the new possibility. You cannot manage, plan, fund, or assign what you cannot name. Until the new possibility can be spoken, in words the organisation can actually use, it cannot be worked on at all. It sits there as a felt sense that something has opened up, with no purchase for action. The language is not decoration on the change; it is the thing that enables the change, because it is what lets people point at the new possibility together and start to act on it.

Language work is the work of building new vocabulary, and it is genuinely creative, not a matter of looking up the right term. The organisation has to develop ways of talking about the Event that let people point at it, argue about it, and coordinate around it. This is why the early phase of any real change feels like a period of bad meetings and circular conversation. People are reaching for words that do not exist yet, describing the new thing in terms of old things it only half resembles, contradicting each other because they have not yet agreed on what to call what they are all dimly seeing. That apparent confusion is the work. It is the organisation manufacturing the vocabulary it will need before it can do anything else.

The failure mode here is the opposite of the confusion, and more dangerous. An organisation can skip the language work by reaching for a ready-made vocabulary off the shelf, the consultant’s framework, the vendor’s terminology, the industry buzzword, and adopting it wholesale. This feels like progress, because suddenly everyone has words. But borrowed words describe someone else’s Event, not yours. The organisation ends up fluent in a language that does not quite fit its own situation, and the gap between the words and the reality becomes a permanent low-grade dishonesty that everyone learns to talk around. Real language work produces words that fit your Event, even if they are clumsy, even if they would mean nothing to an outsider. Honest and clumsy beats fluent and borrowed every time.

4. Structure: Making the Words Solid

Language alone changes nothing. An organisation can develop a perfectly good vocabulary for a new reality and still do exactly what it did before, because talk is cheap and reversible. The third movement is Structure: building the new language into something that persists whether or not anyone is talking about it. A process. A team with a remit. A system that enforces a rule. A budget line that funds a direction. A role that did not exist before. Structure is what turns a way of speaking into a fact of the environment, something people run into whether they believe in it or not.

The test of Structure is durability without attention. If the change depends on someone championing it in every meeting, it has not yet become Structure; it is still Language being kept alive by effort. When it has become Structure, you can stop talking about it and it persists, because it is now built into how the work flows. The reorganisation that creates a new team, the pipeline that will not let unreviewed code through, the funding model that pays for the new direction rather than the old one: these are Structure, because they shape what happens by default, without anyone having to argue for them each time.

The strongest Structure is not imposed from the top; it is proposed from inside. Once people have a language for the new possibility, they begin to organise around it on their own, suggesting new ways of working, forming the team that ought to exist, drafting the rule that should hold, building the small tool that makes the new way easier than the old. This is the quiet engine of the whole cycle, and it only runs when the language is genuinely shared, because people can only propose structures they have the words to describe. A leader’s real job at this movement is less to design the structures than to notice the ones people are already reaching for and give them room to harden, rather than overriding them with a structure designed elsewhere. Structures that people proposed for themselves arrive already half-owned; structures imposed on them start the next movement at a disadvantage.

Structure is the movement organisations are best at, and that is precisely the danger. Building structures is what management knows how to do, so the strong temptation is to jump straight to it, to skip the Event and the Language and just reorganise, just stand up the new team, just buy the platform. A structure built on skipped work is a structure built on sand. It encodes either a borrowed vocabulary that does not fit, or no clear vocabulary at all, and so it produces a process nobody understands the purpose of, a team whose remit is contested from the first day, a system that everyone games because the reason for it was never made real. The most common artefact of failed change is a structure that works perfectly and serves no purpose anyone can articulate, because the purpose was never built before the structure was.

5. Agency: The Self-Sustaining Ownership That Emerges

A structure can be in place and the change can still not have happened. People can comply with a new process while privately treating it as an obstacle, follow a new rule while waiting for it to be quietly dropped, work inside a new team while their loyalty and their habits still belong to the old arrangement. Compliance is not the end of change. The fourth movement, Agency, is the point at which people stop treating the structure as something imposed on them and start acting through it as their own, exercising judgement inside it, defending it, extending it, using it without being told to.

This is the difference between a rule that is followed and a rule that is owned. A followed rule needs enforcement; the moment the enforcement relaxes, the behaviour reverts. An owned rule needs no enforcement, because the people inside it would not now choose to act any other way; it has become part of how they understand their own work. Agency is the movement where a change finally stops being something the organisation is doing and becomes something the organisation is. You can see it in the small signs: people improving the new process without being asked, defending it to newcomers, treating a violation of it as a violation of something they care about rather than a technicality.

Agency cannot be installed, and that is what makes it the movement organisations find hardest to force. You can mandate a structure; you cannot mandate ownership of it. Ownership has to be taken, by people, from the inside, and it can only be taken if the three movements before it were done honestly. If the Event was denied, people know the change answers no real question. If the Language was borrowed, people know the words do not fit. If the Structure was imposed without either, people know it is arbitrary, and you cannot own what you know to be arbitrary. Agency is where the shortcuts taken earlier come due. An organisation that skipped the hard early work can get all the way to a fully built structure and then stall here, permanently, with a change that everyone complies with and nobody owns, which is to say a change that has not actually happened and never will.

6. One Change, All Four Movements

The abstraction becomes clearer with a single change walked the whole way through. Take a composite example, the kind of thing that recurs across many organisations: a firm whose product teams have always shipped on a fixed quarterly release, and which now has to move to releasing continuously, many times a day. Watch where the change actually lives at each stage, and watch where it usually breaks.

The Event is not the arrival of the tooling that makes continuous release possible. The tooling is just a capability; an organisation can buy it and change nothing. The Event is the moment it becomes undeniable that the quarterly rhythm is now a liability rather than a discipline, that competitors releasing daily are learning from real users at a rate the quarterly firm cannot match, and that the firm’s whole way of seeing release as a periodic, ceremonial, all-hands event has a hole in it. Most firms deny this Event for a long time. They file continuous release under “risky for a business like ours,” or “fine for consumer apps, not for us,” forcing the new reality into a category that lets them carry on. The denial is comfortable, because admitting the Event means admitting that a rhythm the whole organisation is built around is now wrong.

Suppose it is admitted. Now the Language work begins, and it is messier than anyone expects. The firm has no shared words for what it is trying to become. People say “continuous” and mean five different things: some mean deploying daily, some mean deploying on demand, some mean small batches, some mean removing the release-approval committee, some just mean faster. The meetings go in circles because the vocabulary does not exist yet. This is the dangerous moment when someone reaches for a borrowed language off the shelf, adopts a brand-name methodology wholesale, and everyone suddenly has fluent words for someone else’s version of the change. The firm that does the honest work instead builds its own clumsy vocabulary, words that fit its actual constraints, its actual risk appetite, its actual customers, even if those words would mean nothing at a conference.

Then Structure, the part the firm finds easiest and therefore the part it is most tempted to rush. Now the new language gets built into things that persist: a deployment pipeline that will not pass code without automated checks, a standing rule that batches stay small, the dissolution of the quarterly release committee and the funding of the capability that replaces it. If this Structure is built on honest Language, each piece has a purpose people can articulate. If it was built on a borrowed Language or no Language at all, the firm ends up with a pipeline nobody trusts, a small-batch rule everyone games by relabelling large batches as small, and a committee that was formally dissolved but reconstitutes itself informally because the reason for dissolving it was never made real.

And finally Agency, where the change either becomes the firm’s own or stalls forever. Agency has arrived when engineers release small changes daily without being told to, when they would now find the old quarterly ceremony absurd, when they improve the pipeline unasked and treat a skipped check as a violation of something they care about rather than a rule to be dodged. If the earlier work was honest, this ownership grows naturally, because the change answers a question people genuinely feel. If the Event was denied, the Language borrowed, or the Structure imposed, Agency never comes; the firm gets a fully built continuous-delivery apparatus that everyone operates joylessly and nobody owns, reverting to quarterly habits the moment attention moves elsewhere. The change is complete on every dashboard and has not actually happened.

7. Why the Order Cannot Be Rearranged

The four movements run Event, Language, Structure, Agency, and the order is not a preference. Each movement produces the exact raw material the next one needs, and none of them can run on material that has not been produced yet.

Language needs an Event to work on; you cannot find words for a new reality you have not admitted is there. Structure needs Language to build from; you cannot make solid a vocabulary you do not yet have, and if you try, you will build from a borrowed one instead. Agency needs Structure to act through; you cannot own a change that has not been made into anything yet. And the whole sequence needs to have been done honestly, because each movement carries forward the integrity or the dishonesty of the ones before it. A denied Event poisons the Language. A borrowed Language poisons the Structure. An imposed Structure poisons the Agency. The shortcuts do not disappear; they travel downstream and surface at the end as a change that will not take.

This is why so many changes that look complete on paper quietly fail in practice. The structure is built, the announcements are made, the training is delivered, and a year later nothing has really changed, because the work was done out of order or with steps skipped. The organisation jumped to Structure because Structure is visible and fundable and looks like progress, and skipped the Event and the Language because they are slow, confusing, and produce nothing you can put in a status report. Then it waited for Agency to arrive on its own, and it never came, because Agency cannot stand on an Event that was never admitted and a Language that was never built.

8. The Break in the Loop

The first three transitions are handoffs. Event hands its disruption to Language, which hands its vocabulary to Structure, which hands its solid form to Agency. Each is a translation: the disruption becomes words, the words become a built thing, the built thing becomes owned practice. The material changes form at each step, but it carries through. The line, despite the translations, is continuous.

The fourth transition is different, and getting it right is the whole point of treating change as a cycle rather than a line. Agency does not hand off to the next Event. There is no smooth translation from a fully owned change to the next disruption. The next Event, when it comes, comes from outside the entire settled situation that Agency produced. It is not the next logical step; it is the thing the new settled way of seeing also cannot absorb, the new hole in the new picture. The transition from Agency back to Event is not a handoff at all. It is a rupture.

This matters practically, and it cuts two ways. The uncomfortable half: arriving at full Agency, at a change completely owned and working, does not protect you from the next change. The very completeness of the settled state is what the next Event will throw into question, and a deeply owned way of seeing is a deeply invisible one, so the new settled state carries its own new blind spots. There is no final structure, no terminal state where change is complete and the cycle stops. But the generative half is the more important one, and it is what the next section is about: the same completeness that creates new blind spots also gives people a higher place to stand, and from that higher place they can see possibilities, and create Events, that were invisible from where they used to be. The break is not only how the next shock gets in. It is how the organisation reaches the vantage point from which it can author the next change itself.

9. The Flywheel: Why Change Generates More Change

Put the cycle together and a property emerges that no single movement shows on its own. A completed turn does not just leave a change in place; it leaves the organisation able to see and do things it could not see or do before. People who have lived through one full cycle have a new language, new structures, and the lived experience of having taken something unfamiliar and made it their own. That experience is itself a capability. It lowers the cost of the next cycle, because the organisation now knows, in its body rather than its slide decks, that change can be admitted, named, built, and owned. And it sharpens the organisation’s eyes: from the new vantage point, things that were unthinkable before become merely difficult, and people start to notice Events, and even create them, that the old position could never have surfaced.

This is the flywheel, and it is the most important claim in this whole account. Positive change is generative. It does not consume itself in solving one problem; it builds the capacity to find and make the next change. An organisation that has turned the cycle honestly a few times stops being something that has to be dragged through transformation by exhausted leaders and becomes something that produces its own transformation, because its people can now see possibility where they used to see only the way things are. The leader’s role shifts accordingly, from forcing change against the grain to keeping the flywheel turning: admitting the Events, protecting the messy language work, giving room to the structures people propose, and getting out of the way of the agency that sustains it.

And here is the part that surprises people. The organisation that becomes good at generating its own change, as a by-product, becomes far better at absorbing change that comes from outside. The capability is the same capability. An organisation fluent in admitting Events, building honest language, and turning that into owned practice does not freeze when an external shock arrives; it runs the cycle it already knows how to run. The same machinery that lets it author internal change lets it metabolise external change, and lets it hear its own internal feedback, the quiet signals from the edges that something is shifting, because a culture practised at recognising Events is a culture that listens for them. Resilience to the outside world is not a separate programme you bolt on. It is what you get for free once the flywheel is turning, because the flywheel is built out of exactly the habits that resilience requires.

10. Reading Your Own Change

The practical use of ELSA is diagnostic. Take any change your organisation is currently attempting, or failing to attempt, and locate which movement it is actually in, as opposed to which one the plan says it is in. The gap between those two is usually where the problem lives.

If the organisation is busy and frustrated and going in circles, with lots of talk and no settled direction, it may be in honest Language work, which looks like failure but is not, or it may be stuck because it never admitted the Event and is trying to find words for something it will not name. If it has reorganised and built and announced, and a year on nothing has changed, it almost certainly jumped to Structure over skipped Event and Language work, and is now waiting for an Agency that cannot come. If people are complying without owning, going through the motions of a change they do not believe in, the structure was probably imposed without the language work that would have made it make sense. And if a change feels genuinely complete, fully owned and working without effort, the useful question is not how to defend it but what it now lets you see: from this new vantage point, what was unthinkable before and is merely difficult now? That question is how you turn a finished change into the Event that starts the next one, which is how the flywheel keeps turning.

The four movements give you a vocabulary for change that does not flatter the straight-line story. They tell you that the confusing early work is real work, that the visible late work is worthless without it, that ownership cannot be commanded, and that arrival is temporary. None of that fits on a tidy slide. All of it is what actually happens when an organisation changes, or fails to.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Pick the most important change your organisation is currently trying to make. Do not ask how it is going. Ask which of the four movements it is actually in.

Be honest about the difference between the plan and the reality. The plan almost certainly says you are in Structure, building the new thing, because that is the movement that produces fundable, reportable progress. The reality may be that you skipped the Event, never admitting clearly what happened that made this change necessary, and skipped the Language, never building words that fit your own situation rather than words borrowed from a framework. If so, the structure you are building is standing on nothing, and no amount of building will fix that, because the problem is underneath it.

Then ask the harder question. For each movement you have genuinely completed, was it done honestly or was it faked? Was the Event admitted or flattened into something familiar? Was the Language yours or borrowed? Was the Structure built on real words or imposed over a gap? You will usually find one movement where the shortcut was taken. That movement is where your change will fail, no matter how well the others were done, because the dishonesty travels downstream and comes due at Agency, as a change everyone complies with and nobody owns.

Fix the earliest skipped movement first. If the Event was never admitted, no language work will land until it is. If the Language was borrowed, no structure will hold until you have built words that fit. Going back to the earliest broken movement feels like regression; it is the only thing that actually moves a stalled change forward.

Then, when that change is genuinely owned and running on its own, ask the question that keeps the flywheel turning. Now that your people can see and do what this change made possible, what was unthinkable here a year ago and is merely difficult now? Name it out loud. That naming is how you turn a finished change into the next Event, and an organisation that does this on purpose stops waiting to be disrupted from outside and starts generating its own change from within. That is the whole point: not to survive one change, but to become the kind of organisation that makes the next one.

Disclaimer

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

A specification is not a system. It is a precise account of a system that does not yet exist, and the distance between the two is the distance this article is about. The Deciding phase ended with an organisation that had, at last, converted its situation into something buildable: a bounded, described, owned account of what it had decided to make true. That account is real work, hard-won. It is also, on its own, inert. Nobody has built anything.

Every phase of this series ends by producing something the next phase cannot directly use. The gap is the point. Learning ended with a capacity, and a capacity is not a description, so Deciding had to begin by applying it to produce one. Deciding now ends with a specification, and a specification is not a system, so Building has to begin by constructing it into one. The handover is never a clean pass. It is a translation, and the thing being translated changes its kind in the crossing. This article is that translation: what the Deciding phase actually produced, why it cannot be handed straight to delivery, and where the Building phase has to start instead.

1. What Deciding Produced

The Deciding phase ran a particular path. It began with Language; the discipline of describing the domain precisely enough to decide within it at all, Ohno’s work and Evans’s. It moved to Structure; understanding how the parts of the organisation relate when a decision is made, Beer’s work and Conway’s and Ackoff’s. It moved to Agency; the capacity of the people in the room to commit, to exclude, to choose rather than default, Simon’s work and Boyd’s and Kegan’s. And it ended at an Event: not a disruption arriving from outside, but a specific, bounded, buildable thing produced from the inside. The decision, properly made, is the Event. It is the trigger.

This matters because of what kind of object the Event is. It is not a strategy, which is a direction. It is not an intention, which is a wish. It is a specification: precise enough that someone other than its author could build from it, bounded enough that its edges are known, owned by someone who will answer for it. The Deciding phase, at its honest end, does not produce a better opinion about what to do. It produces a thing with edges. And a thing with edges can be handed to someone else, which is exactly what makes the next phase possible and exactly what makes it dangerous.

2. Why the Specification Cannot Simply Be Executed

The intuitive model of what happens next is execution: the specification is correct, delivery is the faithful carrying-out of it, and the work is to manage that carrying-out efficiently. This model is wrong, and the whole of the Deciding phase has been quietly arguing against it.

A specification is a hypothesis. It is the organisation’s best current account of what should be built, and like every account it was assembled by people of bounded rationality, working from descriptions that were necessarily incomplete, inside a structure that shaped what they could consider. It will be partly wrong. This is not a failure of the deciding; it is the permanent condition of deciding, and the phase named it repeatedly. Schön called the alternative the swampy lowland, where real problems live and textbook procedures do not reach. Building is not the execution of a correct specification. It is the activity in which the specification meets reality and is corrected by it.

Which means the relationship between Deciding and Building is not sequential in the way a plan is sequential. The specification is the input to Building, and the operational knowledge Building generates is feedback that re-enters Deciding for the next pass. The handover is a translation precisely because a specification and a system are different kinds of thing, and the difference cannot be closed by careful project management. It can only be closed by building, and by treating what the building reveals as information rather than as deviation.

3. Why Building Starts at Structure

Each phase of the series enters its cycle at a different point, and the entry point is forced by what the previous phase handed over. Building begins at Structure, and the reason is exact: a specification has to be constructed before it can do anything else, and construction is, first, a structural act.

Structure here has the literal Conway meaning. The teams that will build the thing, and the components the thing is made of, are the same shape; the communication structure of the organisation is reproduced in the architecture of what it builds, and this is not a tendency to be managed but a law to be designed with. Building starts by deciding the structure twice over: how the work is divided into teams, and how the system is divided into components, knowing that those two divisions will mirror each other whether or not anyone intends it. The Deciding phase made structure visible as the thing that shapes decisions. The Building phase makes structure the first thing it constructs, because everything built afterwards inherits its shape.

This is the cleanest reason the bridge cannot be skipped. An organisation that takes a specification and moves straight to delivery, without first treating structure as the opening design decision, will get the architecture its existing org chart dictates, and discover the mismatch only when the system is built and rigid. Building starts at Structure so that the shape is chosen rather than inherited.

4. What the Building Phase Will Argue

The Building phase runs its own path; Structure, then Agency, then Event, then Language; and although its full architecture belongs to the articles ahead, the shape of its argument can be set out here, because it is what this bridge hands toward.

After Structure comes Agency, and Agency in Building has a dual meaning that the phase will treat as its central move. There is the autonomy of teams: whether the team that owns a component can make decisions about it without hierarchical mediation. And there is the agency of components themselves: in a system of services and software agents, each part makes promises about what it will do and what it will not do, and the coordination between autonomous parts is the promise, not the command. The Building phase takes Promise Theory as its anchor for exactly this reason; it is the account of how autonomous agents, human or software, coordinate without a controller. Then comes Event; what happens when the built thing meets reality, the continuous signal from a system in operation, where Beer’s POSIWID and Ohno’s jidoka return as the disciplines of evaluation. And then Language; what the organisation learns from what it built, operational knowledge becoming the description that feeds the next cycle.

Building is inherently iterative in a way the earlier phases are not. Its final position, Language, feeds straight back to its first, Structure, for the next pass. Continuous integration, continuous delivery, continuous feedback: these are not modern delivery fashions but the Building cycle running fast. The phase will also carry a warning the bridge should name now. A system of autonomous parts coordinating through promises still depends on something the structural account cannot supply: the energy that keeps autonomous teams moving rather than draining. The cadence of a building organisation; its standups, its demos, its retrospectives; is not administrative overhead. It is where that energy is generated or lost, and the Building phase will treat it as seriously as it treats architecture.

5. The Handover

So the bridge can be stated plainly. The Deciding phase produced a specification: a bounded, described, owned account of what to build, which is a hypothesis and not a certainty. The Building phase takes that specification and begins, at Structure, to construct it into a system; divides the work and the components together; gives the parts genuine autonomy and binds them by promises rather than commands; lets the built thing meet reality and treats what reality says as information; and turns that information into the language that starts the next cycle.

The gap between the two phases is real and it is not a defect. A specification handed straight to execution, treated as correct and carried out faithfully, produces a system that is an accurate construction of a misunderstanding. A specification handed to Building, treated as a hypothesis to be constructed and corrected, produces a system that gets better as it meets the world. The difference between those two outcomes is the entire reason this bridge exists, and the entire reason Building is a phase in its own right rather than a delivery function bolted to the end of Deciding.

The Deciding phase asked how an organisation gets clear on what to do. The Building phase asks the harder and more exposed question: how an organisation makes the thing real, and stays honest with itself while reality tells it what it got wrong. That is where the series goes next.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

The data platform was approved in under an hour. The business case was clean, the vendor credible, the numbers held, and the room agreed. Eighteen months later it was technically sound and strategically useless — built to answer questions the company had stopped asking. No one in that room chose badly. They optimised an answer to a question nobody had pinned down.

Most decision post-mortems look for the bad choice. They rarely find one. What they find instead is a decision taken without anyone having established two things: whether the organisation knew what it was deciding, and whether it had picked a sound way to decide it. A decision has two failure modes, and the visible one — the wrong call — is the rarer of them. The dangerous one is structural and almost invisible: a sound-looking choice produced by a process that was never fit for the decision in front of it.

This is the closing instalment of the Deciding phase, and its job is consolidation. The phase has moved through bounded rationality and satisficing, ubiquitous language and the discipline of going to see, viable systems and the purpose revealed by behaviour, heuristics and recognition and reflective practice, dissolution and incrementalism and orientation. Behind that variety is a single claim, the Deciding hypothesis: decisions are design challenges, and design is a sequence of decisions under constraint. If that is true, then a decision can be examined the way a design can be examined — not by whether you like the result, but by whether the process that produced it was sound. This article turns the phase into nine methods. Each one is a diagnostic, something you can observe, and a method, something you can do. They fall into three groups, the three levers that run through every phase of this series: Identity, Information, and Interaction. Used together, they answer the two questions a decision actually turns on. Do you know what you are deciding? And have you chosen a sound way to decide it?

The three levers are not a sequence. A decision is exposed to all three at once. Identity concerns who decides and what they are able to see; that is Simon’s territory. Information concerns how precisely the thing being decided can be described; that is Ohno’s. Interaction concerns how the parts of the organisation relate at the moment the decision is made; that is Beer’s. The nine methods are three to a lever. What follows is each of them, and then the consolidated diagnostic a practitioner can carry into the room.

Identity: Who Decides, and What They Can See

The Identity lever asks what constrains the decision-maker before the decision begins. Simon is its foundation thinker. Bounded rationality is not a flaw to be corrected by better training or more data; it is the permanent condition of every decider, human or organisational. No one sees the whole problem. The Identity methods do not remove the constraint. They make it visible, so that whatever is excluded is excluded on purpose rather than by accident.

1. Name what you will not do. Can the organisation state, for this decision, what it has ruled out? Simon’s satisficing carries an implication that is easy to miss: a decision is an act of exclusion. To decide is to close options, and if you cannot say which options you are closing, you have not decided. You have added a commitment alongside all the others and called it a choice. Drucker said the same thing in the language of boundary conditions — an effective decision specifies what it must accomplish, and by implication what it declines to attempt. Rumelt’s account of bad strategy is the diagnostic in negative form: bad strategy is the strategy that excludes nothing, the list of good things, the dog’s dinner of goals that reads as ambition and functions as evasion. The method is blunt. Require every proposal to carry an explicit statement of what it rules out. That statement is the decision. Everything else in the document is justification. And exclusion only counts as a decision if the thing excluded was genuinely on the table, which raises the next question: whether the decision was made at all, or merely inherited.

2. Tell choosing from defaulting. When was this decision last consciously taken? Bounded rationality has a second consequence. Most of what an organisation appears to decide, it does not decide. It defaults. The decision premise was set years ago, by someone who has since left, for conditions that have since changed, and it now runs unexamined because nothing has forced it back into view. March named the pattern: getting better at the wrong thing, the competency trap, in which the organisation refines an inherited answer with real discipline and never asks whether the answer still fits the question. Christensen’s incumbents did not choose to miss the disruption; they defaulted into the decision their existing customers and their existing margins had already made on their behalf. The default extends past answers to methods. An organisation inherits not only what it decides but how it decides — the committee, the business case, the steering group, applied to every decision regardless of type because they are simply what the structure produces. Schön named the underlying error, technical rationality: the assumption that every problem is a well-formed problem, to be solved by applying the standard procedure. Most real decisions are not in the textbook. They are in what he called the swampy lowland. The method: for any significant decision, ask when it was last consciously taken, and whether the method now being used was chosen for this decision or simply supplied by habit. If neither has an answer, you are not deciding. You are maintaining.

3. Hold competing designs without closing too early. Are there at least two structurally different options genuinely in play — and do they decide the question in different ways? Boyd’s OODA loop locates the advantage with whoever can hold a situation open longer and re-orient inside it faster, not with whoever commits first. Kegan’s self-transforming mind describes the developmental capacity this requires: the ability to hold a position and its opposite without needing the discomfort resolved before it has been understood. An organisation that collapses to consensus before its alternatives have been genuinely inhabited has not chosen between options. It has ratified the first one and staffed the rest. This is also the method where the way of deciding gets chosen. Two options that differ only in detail can be decided by the same procedure. Two options that are structurally different — build it versus dissolve the need for it, optimise the current system versus redesign it — cannot, and the gap between them forces the organisation to ask which way of deciding actually fits. Gigerenzer’s work belongs here: there is no single best method, only a method matched to its environment, and a fast heuristic will outperform an elaborate analysis in an uncertain world while the reverse holds in a stable one. Klein showed that experts under time pressure do not compare options at all; they recognise a workable one and simulate it forward. Kahneman completes the set with the necessary caution: know when the situation is benign enough to trust the fast judgement, and when it will punish you for trusting it. The method: require at least two structurally different options before any commitment, and make each option name the method by which it would be decided. Where the methods differ, you have found the real decision — which is not which option to take, but how to choose. Holding genuine alternatives, though, depends on being able to describe them precisely enough to tell them apart, and that is the work of the second lever.

Information: How Precisely You Can Describe What You Are Deciding

The Information lever asks whether the organisation can describe the thing it is deciding about with enough precision to decide within it. Ohno is its foundation thinker. Evans, whose ubiquitous language and bounded contexts run through the phase, is the software instantiation of an older and more general discipline, and that discipline is Ohno’s. Gemba is the instruction to go and see the actual place where the work happens, because the description that reaches the decision-maker has been smoothed, summarised, and quietly flattered at every level it climbed. Standard work is the current best description of how a thing is done, written down — not so that it can be obeyed, but so that it becomes the explicit hypothesis the next observation can falsify. The Information methods are the discipline of seeing precisely enough to decide.

4. Use one language for the domain. Do the people deciding, the people building, and the people operating use the same words for the same things? This is Evans’s ubiquitous language. Where a domain expert says one thing, a strategy deck says another, and the running system encodes a third, the organisation does not have a model of its domain. It has three, and the translation between them is exactly where meaning leaks out. Ohno would say the description has drifted from the gemba — that the account on the slide no longer matches the work on the floor. The test is auditory. Listen for translation. Where a meeting needs someone to explain what a term really means, the model is split, and every decision taken on top of it inherits the split without knowing it has. The method is not to mandate a glossary, which produces a document nobody consults. It is to put the people who decide, build, and operate in the same room using the same words until the words mean one thing.

5. Separate what you know from what you assume. For each load-bearing claim in the decision, is it marked as known, believed, or hoped? This is the method that most directly tells you what kind of decision you are in, and therefore how it should be decided. A decision rests on claims, and the claims are not all the same. Some are known. Some are believed on reasonable evidence. Some are hoped, and dressed as believed. Taleb’s distinction is the sharp edge here: a decision in a domain of thin, well-behaved uncertainty can be optimised, and a decision exposed to fat-tailed, consequential uncertainty cannot. In the second domain the only sound methods are the ones that cap the downside, preserve optionality, and proceed by via negativa — removing the fragilising error rather than predicting the unpredictable. An organisation that has not established which kind of uncertainty it faces will choose the wrong method with complete confidence. Parnas gives the constructive form of the same instruction from software: a design should hide the decisions most likely to change, and to hide them you must first know which they are — which assumptions are both load-bearing and volatile, and which are safe to build on. The method: mark every key assertion in a strategy or design as known, believed, or hoped, then check whether the volatile, consequential assumptions are the ones the decision is most exposed to. If they are, the method must change. Stop optimising and start limiting downside.

6. Make the model visible enough to be argued with. Is the model behind the decision explicit enough that a competent colleague could disagree with it on the substance? Evans treated the domain model as a designed artefact, not a diagram drawn after the fact to decorate a decision already taken. Ohno’s standard work is a hypothesis precisely because writing the current method down makes it challengeable — a thing the next observation at the gemba can prove wrong. Argyris named the failure mode with more force than anyone else in the phase: the model that cannot be challenged is the one held as a theory-in-use, never surfaced, never tested, and defended most strongly by the people who deny holding it at all. Senge’s mental models and Nonaka’s movement from tacit knowledge to explicit are the same instruction approached from different sides. A decision model that lives only inside someone’s head cannot be improved, because it cannot be attacked. The method: make every decision model explicit enough that someone could disagree with it specifically. If no one can locate the thing to disagree with, the model is not visible, and the decision is being taken on faith. A precise description, though, is always taken inside a structure, and the structure has already shaped what the decision is allowed to be. That is the third lever.

Interaction: How the Parts Relate When the Decision Is Made

The Interaction lever asks how the parts of the organisation relate at the moment a decision is made. Beer is its foundation thinker. His POSIWID — the purpose of a system is what it does — is the most unforgiving diagnostic in the series, because it refuses to let an organisation describe itself by its intentions. Ackoff supplies the constructive move: the distinction between solving a problem inside the existing system and dissolving it by redesigning the system so the problem no longer arises. Conway supplies the structural fact the whole lever rests on: an organisation’s communication structure is reproduced in everything it designs, and that includes its decisions.

7. See the decision the structure will allow. Before asking what we should decide, have we asked what decisions this structure can produce? Conway’s law, generalised from software to decisions, says that a structure built around three divisions will produce three-division decisions, and a structure with no forum where two functions meet cannot produce a decision that requires those functions to agree. Alexander made the same observation in architecture: form is shaped by the structure of the context that produces it, and a form imposed against that structure will not hold for long. The decision an organisation reaches is bounded by the conversations its structure permits before anyone enters the room. The method: before deliberating, map which decisions the current structure can and cannot produce. If the decision you need is not one the structure can produce, then the first decision is a structural one, and deliberating before you have made it is theatre.

8. Decide whether to redesign the system or optimise within it. When a problem recurs, is it being solved, or is the system that keeps generating it being redesigned? Ackoff distinguished resolving a problem, solving it, and dissolving it, and argued the highest move is dissolution — redesigning the system so the problem stops arising. Lindblom is the honest counterweight, and the phase needs both. Most organisations cannot redesign their systems at will, and should not pretend they can; they muddle through by small comparative steps, and incrementalism is a genuine method with real strengths in a world too complex to redesign with confidence. The point is not that redesign beats incrementalism. It is that they are different methods, and an organisation should know which one it is using and why it has chosen it. A recurring problem patched the same way every time is the signature of incrementalism applied where dissolution was needed — and applied not as a choice but as a reflex. The method: when a problem recurs, ask explicitly whether the problem lies in the decision or in the system that keeps generating the decision, and choose the method to match. Patch by intent, not by habit.

9. Check what the decision process actually produces. Does the way this organisation decides produce what it claims to produce? This is Beer’s POSIWID turned on the decision process itself. A process that reliably produces delay, or the diffusion of accountability until no one owns the outcome, or the protection of the largest existing budget, has those as its purpose, whatever its stated aim. The gap between what the process claims and what it does is the real strategy of the organisation, and it is observable, which is the standard this series sets for every probe. The military tradition examined earlier in the phase supplies the constructive form: a decision is not complete until accountability for it is unambiguous and the process that produced it can be examined honestly after the fact. The method: take the last several significant decisions, compare what the process actually produced with what it claimed it would produce, and decide on the basis of the gap rather than the claim.

Choosing How to Decide

The nine methods do two distinct jobs, and it is worth separating them. Methods four, six, and seven test whether the organisation knows what it is deciding — whether the thing on the table has been described in one language, modelled visibly enough to be argued with, and bounded by a structure the organisation has actually examined. Methods one, two, three, five, and eight test whether it has chosen a sound way to decide — whether it has excluded on purpose, chosen rather than defaulted, held genuine alternatives, typed its uncertainty correctly, and matched redesign or incrementalism deliberately to the problem. Method nine tests both at once, after the fact, by looking at what the process produces over time.

The phase has, in effect, been assembling a small library of deciding methods, and the consolidation worth stating plainly is that there is no best one. Optimisation suits a described, stable, thin-uncertainty decision. Satisficing suits a bounded decision where optimisation is not available at any reasonable cost. Recognition-primed judgement suits a time-pressed domain in the hands of a genuine expert. Heuristics suit an uncertain world. Dissolution suits a recurring structural problem. Incrementalism suits a world too complex to redesign with confidence. Via negativa suits a decision exposed to consequential tails. The error this phase has diagnosed, in one thinker after another, is almost never the wrong option. It is the organisation’s habitual method applied to a decision of a type that method cannot handle — and the misapplication going unnoticed, because the method itself was never chosen, only inherited.

AI sharpens this rather than changing it. As generation becomes cheap, the bottleneck in deciding moves decisively away from producing options and analysis and towards choosing well among them. A model will generate a credible business case, a plausible architecture, and a confident recommendation in the time it once took to schedule the meeting. None of that touches the two questions that actually matter. The organisation that treats AI as a way to produce more decisions faster will accelerate its existing pathologies. The organisation that treats it as a reason to get deliberate about what it is deciding, and how, will have used the tool for the one thing it cannot do itself.

The Consolidated Diagnostic

Nine questions. They are not a scoring rubric. They are the checks a practitioner runs before committing, and again afterwards, and the value is in the questions the organisation cannot answer, because each unanswerable question names a method it does not yet have.

Identity — who decides, and what they can see:

1. Can we state plainly what this decision rules out?

2. When was this decision last consciously taken, and was the method being used chosen for it or simply inherited?

3. Are there at least two structurally different options in play, and do they decide the question in different ways?

Information — how precisely the decision is described:

4. Do the people who decide, build, and operate use one language for the domain, with no translation in the room?

5. Is each load-bearing claim marked as known, believed, or hoped, and is the consequential uncertainty correctly typed?

6. Is the model behind the decision explicit enough that a competent colleague could disagree with it on the substance?

Interaction — how the parts relate when deciding:

7. Have we asked what decisions this structure is capable of producing before asking what we should decide?

8. When this problem recurs, are we solving it or redesigning the system that generates it — and is that a deliberate choice?

9. Does the decision process produce what it claims to produce, judged on the last several decisions rather than its stated aim?

If the organisation can answer the first six honestly, it knows what it is deciding and has chosen how. If it can answer the last three, the structure it decides inside is one it understands. If it cannot answer some of them, those are not gaps in the decision. They are gaps in the organisation’s capacity to decide at all, and they will recur under every future decision until they are closed.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

The methods are not the hard part. An organisation can run an exemplary process; two structurally different options on the table, every load-bearing assumption marked, the domain described in one language, the structure mapped before anyone deliberated; and still produce a decision that goes nowhere. The previous article set out nine methods for deciding well. This one asks the question those methods provoke and cannot themselves answer: why, given the methods, do organisations still fail to decide?

The answer is not that they lack discipline, or courage, or the right framework. The Deciding phase has moved through Simon and Ohno and Beer, through Drucker and Ackoff and Conway, through Boyd and Taleb and Klein and a dozen others, and the consistent finding is that the failure to decide is not an absence of something. It is the presence of something: a set of mechanisms, each one locally sensible, that combine to make genuine decision almost impossible. An organisation that cannot decide is not broken. It is working exactly as its structure, its language, and its inherited premises require it to work. That is the harder problem, and it is the one this phase closes on.

1. The Decision Was Already Made

Most of what an organisation treats as a live decision was settled long ago. Simon’s bounded rationality has a consequence that is easy to state and painful to absorb: no decision-maker reasons from a blank slate. Every choice is taken inside a frame of decision premises; assumptions about what the organisation is, who its customers are, what counts as success, which options are even admissible; and those premises were set by people who have since left, for conditions that have since changed. The meeting believes it is deciding. It is mostly ratifying.

This is why so many decision processes feel like theatre. They are theatre, in a precise sense: the performance of choosing, staged on top of a choice already made by the inherited frame. March named the deeper version of this. The competency trap is the organisation getting steadily better at the wrong thing, refining an inherited answer with real skill and never asking whether the answer still fits the question. The skill is genuine. The refinement is genuine. The trap is that both are aimed at a target the organisation defaulted into and never re-examined.

The first reason an organisation cannot decide, then, is that it does not know which of its decisions are still open. It treats settled premises as live questions and live questions as settled premises, and it has no routine for telling them apart. A decision it cannot see is a decision it cannot make.

2. The Description Never Arrived

Suppose the decision is genuinely open. It still has to be decided about something, and that something reaches the room as a description; a report, a deck, a summary, a model. Ohno’s discipline of seeing exists because that description is never the reality. It is an account, smoothed at every level it climbed, and the decision taken on top of it inherits every omission without knowing it.

The phase has named the ways this goes wrong. The language is split: the domain expert, the strategy deck, and the running system use three different vocabularies for the same thing, and the translation between them is where meaning leaks out. The uncertainty is mistyped: a decision exposed to consequential, fat-tailed risk is handled with the confident machinery built for thin, well-behaved risk, because no one established which kind they were in. The model behind the decision is invisible: it lives in someone’s head, unchallengeable because it was never made explicit enough to challenge. Each of these is a failure of description, and none of them announces itself. The room feels well-informed. It is well-supplied with confident accounts, which is a different thing.

The second reason an organisation cannot decide is that the thing it is deciding about never actually arrived in the room. A polished description of a misunderstood situation is worse than an honest gap, because the gap at least invites a question.

3. The Structure Already Chose

Even a genuinely open decision, precisely described, is decided inside a structure, and the structure has been quietly voting the whole time. Conway’s law, generalised past software, is blunt: an organisation can only produce the decisions its communication structure permits. A structure built around three divisions produces three-division decisions. A structure with no forum where two functions meet cannot produce a decision that requires those functions to agree. The deliberation in the room is real, but its range was fixed before anyone entered.

This is the mechanism behind a familiar and demoralising experience: the obviously correct decision that the organisation simply cannot reach. It is not that people are too stupid or too timid to reach it. It is that the decision requires a conversation the structure does not hold, an agreement between parties the structure keeps apart, an owner the structure never appointed. Beer’s POSIWID is the diagnostic that makes this visible without mercy: the purpose of a system is what it does. If the decision process reliably produces delay, or the diffusion of accountability until no one owns the outcome, or the protection of the largest existing budget, then those are its purpose, whatever the stated aim. Ackoff supplies the escape and also the catch. The recurring problem usually lives in the system, not in the decision, and the real move is to redesign the system; but most organisations cannot redesign at will, and so they patch the same problem the same way, and call the patching a decision.

The third reason an organisation cannot decide is that the structure has already narrowed the decision to the options it was built to produce, and the room mistakes that narrowing for the field of choice.

4. Why the Three Compound

Taken one at a time, each of these is manageable. The damage is in how they reinforce one another, and the direction of the reinforcement is not random.

Inherited premises determine what descriptions get commissioned: you do not gather information about a question you do not know is open, so the settled frame quietly decides what the organisation will trouble itself to see. The descriptions that do arrive are shaped by the structure that produced them: each function reports in its own vocabulary, optimised for its own position, and the structure that keeps the functions apart also keeps their accounts from reconciling. And the structure, in turn, is held in place by the inherited premises, because the current structure looks natural and inevitable to anyone whose decision frame was formed inside it. Identity constrains Information constrains Interaction, and Interaction loops back to confirm Identity.

This is why the failure to decide is so stable, and why effort alone does not shift it. An organisation that works harder inside this loop gets better descriptions of the wrong question, routed faster through a structure that was always going to produce the same answer, in service of a premise no one has examined. The loop does not resist effort. It absorbs it, and converts it into the appearance of progress. That is the honest and unwelcome finding of the Deciding phase: the organisation that cannot decide is not under-performing its design. It is performing its design exactly.

5. Where the Loop Breaks

If the three reinforce one another, the question is whether there is any point of entry, and there is. The loop is closed, but it is not equally strong at every point. It breaks at Interaction, because Interaction is where the other two become visible and changeable.

You cannot argue an organisation out of an inherited premise; the premise is not held as an argument, so argument does not reach it. You cannot, on its own, fix a description while the structure that distorted it stays intact; the next description will be distorted the same way. But you can change how the parts relate. You can create the forum the structure was missing, appoint the owner it never named, build the channel that lets a true signal travel. And when the interaction pattern changes, the descriptions change, because new information now flows; and when the descriptions change, the premises become visible, because the organisation is now looking at the question it had defaulted past. Causation runs one way for understanding: Identity, then Information, then Interaction. It runs the other way for intervention: change Interaction, and the rest becomes reachable.

This is the structural reason the Deciding phase ends where it does, and it is the hinge into what comes next. An organisation gets clear on what to do not by thinking harder but by changing how its parts relate; and changing how the parts relate is no longer a decision. It is a thing to be built.

6. The Deciding Phase Was Always Pointing Here

Step back and the shape of the phase resolves. Its hypothesis was that decisions are design challenges, and design is a sequence of decisions under constraint. Every thinker in the phase has been an instance of that single claim. Simon: deciding is satisficing under cognitive constraint. Ohno: deciding well requires seeing the constraint precisely, at its source. Beer: the structure is the constraint, and it must be designed, not merely inhabited. Ackoff: the highest decision is to redesign the system that generates the problem. Boyd: deciding is the continuous redesign of your own orientation. The phase did not assemble a toolkit of decision techniques. It made an argument, and the argument was that there is no clean separation between deciding and designing; that the moment a decision is taken seriously it becomes a question of design, and the moment a design is taken seriously it dissolves into a sequence of decisions.

Which means the honest end of the Deciding phase is not a better decision. It is a specification: a bounded, precise, buildable account of the thing the organisation has decided to make true. An organisation that cannot decide, in the end, is an organisation that cannot convert its situation into something buildable. It stays in deliberation because deliberation is safe and building is exposed. The capacity to decide and the capacity to build are closer than they look, and the gap between them is the subject of everything that follows.

You cannot decide your way out of the inability to decide. At some point the talking has to become a thing with edges, handed to people who will build it and find out, against reality, whether the decision was any good. That handover is the next phase, and the next problem.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

Two rooms can be built to the same specification and only one of them is alive. You know it on entering, before you could say why: one room is comfortable, settled, somewhere you would choose to sit; the other is correct and dead. The specifications match. The materials match. Something the specification did not capture is the whole difference, and an organisation that cannot name that something will keep producing the dead version and signing it off as done.

Christopher Alexander spent fifty years on that something. He was an architect and a mathematician, and he was after a single question: why are some places alive and most are not, and can the difference be made teachable. The answer he built is the most complete account in this series of what design actually is, which makes him, for the Deciding phase, an unavoidable thinker. The phase has argued throughout that decisions are design challenges and that design is a sequence of decisions under constraint. Alexander is where that argument was first worked out in full, by someone building real buildings and watching most of them fail to come alive.

1. A Pattern Is a Decision That Recurs

Alexander’s early work, Notes on the Synthesis of Form, treated design as the achievement of fit between a form and its context. A design problem is a knot of interacting requirements; the designer’s task is to find the places where the requirements cluster tightly and the places where they barely touch, and to cut the problem along the loose seams into sub-problems that can be solved nearly independently. This is the same insight Simon reached in the same decade about complex systems, and the two men were, without much contact, building one idea: a problem becomes tractable only when it is decomposed where its real seams are.

But decomposition was the analytical half. The generative half came later, and it is the pattern. A pattern, in Alexander’s mature definition, is a recurring problem in a context, stated together with the core of a solution that resolves the competing forces the problem creates. Light on two sides of a room. A place to wait that is also a place to be. The exact form is never specified, because it will be built a thousand times and never twice the same; what is specified is the conflict and its resolution.

The point worth holding for this phase is what a pattern actually is. It is not a template, and it is not a reusable component. It is a decision that recurs, captured. It is the distilled record of how a particular conflict of forces has been resolved well, written down so the next person faced with that conflict reuses the decision rather than the object. An organisation that builds a library of its patterns is not building a catalogue of solutions. It is building a memory of its good decisions, and that is a different and more valuable thing.

2. The Forces Are the Point

The centre of a pattern is the field of forces: the genuine, competing pressures the situation creates. A room needs daylight and needs shelter from glare. An entrance needs to welcome and needs to secure. The forces are real, they pull against each other, and a pattern earns its place only if its resolution actually holds both rather than sacrificing one.

This is the test Alexander cared about most, and it is the test most often skipped. A pattern used to decorate, lifted in because it is familiar or because it looks like the kind of thing one does, resolves nothing; it suppresses one force and calls the suppression a design. Alexander’s word for what results is dead structure. The building stands. It is also lifeless, because the conflicts it was supposed to resolve are still there, merely hidden under a form that ignored them.

The organisational translation is direct, and it sharpens a distinction this phase has returned to repeatedly: the difference between a decision made and a decision performed. A decision that names the competing forces honestly and resolves them is alive; it holds. A decision that picks the comfortable option and suppresses the inconvenient force is performed; it looks like a decision and will not hold, because the suppressed force is still pulling and will surface again, usually later and more expensively. Alexander gives the phase its cleanest tool for telling the two apart. Ask of any decision: which forces did this claim to resolve, and did it resolve them, or did it just quieten the one that was complaining loudest.

3. The Quality Without a Name

The companion volume, The Timeless Way of Building, names the thing the patterns serve, and then refuses to name it with a single word. Alexander calls it the quality without a name: the property of being alive, whole, comfortable, free, exact, that some places have and most do not. He refused a one-word label deliberately, because every available word; beauty, harmony, elegance; was too small and would be mistaken for a style.

The quality cannot be manufactured. This is the hard claim, and it is the one that matters here. You cannot specify wholeness in advance and then have it executed, the way you might specify a dimension. It can only be generated, grown by the honest application of a pattern language to the actual forces of an actual situation. A place comes alive when each decision in the sequence genuinely answered the conflict in front of it; it stays dead when the decisions were taken from habit, or from the catalogue, or to satisfy a sign-off.

For a series of senior technologists this lands as something other than a metaphor. Everyone has seen the system, the team structure, the operating model that is correct on every measurable axis and somehow inert; nobody wants to work in it, nothing moves easily through it, and no single defect explains the deadness. Alexander’s account says the deadness is real, diagnosable, and caused: it is what you get when a thing is assembled from decisions that did not resolve real forces. And it says the quality is observable rather than measurable, which is exactly the standard this series sets for everything it asks you to look for. You cannot put a number on whether a structure is alive. You can tell.

4. Wholeness Is Grown, Not Installed

If the quality can only be generated, then the method has to be generative, and Alexander’s later work is an attempt to say precisely how. Wholeness, he argued, is made of centres: local zones of coherence that strengthen one another, so that a thing is alive to the degree its centres intensify rather than compete. And it grows by structure-preserving transformation: each healthy change strengthens the centres already present instead of erasing them. Change unfolds what is there. It does not demolish and replace.

This is a direct rejection of the master plan, the big design fixed in advance and then executed whole, and it is a rejection with obvious force for anyone who has watched a three-year transformation programme arrive complete and lifeless. Alexander’s alternative is piecemeal growth: small increments, each one corrected against the actual state of the whole as it now stands, never a single grand design imposed at once. Stated in the vocabulary of modern delivery, this is iterative development, and Alexander reached it decades before the software industry did and for deeper reasons. Continuous, incremental, structure-preserving change is not a project-management preference. It is the only process that produces something alive, because wholeness cannot be specified ahead of the building; it can only accumulate, decision by decision, as each step answers what the last step revealed.

5. The Patterns Movement, and What It Missed

Alexander’s idea crossed into software. The design-patterns movement of the 1990s took the form of the pattern directly from him, and the influence runs through the catalogues of reusable solutions that a generation of engineers grew up on. In 1996 Alexander was invited to address that community, and he used the platform to tell them, with care, that they had taken his patterns and missed his point.

The patterns, he said, were never about reusable solutions. They were about generating life and wholeness, about making places and things that were morally good in the sense that they made the people who used and built them more alive. The software community, he observed, had adopted the mechanism and dropped the purpose: it had a method for cataloguing solutions and had not asked whether the systems it built were good to live inside.

The warning is this series’ warning, and it is why Alexander belongs in the Deciding phase rather than merely near it. A pattern detached from its forces becomes dead structure. A framework adopted as a catalogue, applied because it is the done thing rather than because it resolves a conflict that genuinely exists, becomes exactly the framework worship the series has rejected from the start. Alexander is the proof that a powerful idea about design survives only if it stays attached to the question of whether the result is alive. Drop that question and you keep the vocabulary and lose the thing the vocabulary was for.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Take a recurring problem your teams keep re-solving, and write it up as a pattern.

Pick something that comes round again and again; a kind of integration that is always painful, a review that always stalls, a handoff that always loses information. Write it as a pattern, in three parts.

First, the context: when and where does this problem arise.

Second, and this is the part that does the work, the forces: the genuine competing pressures the situation creates, named without flinching, including the inconvenient one.

Third, the resolution: the core of what actually resolves both forces, not the form, the decision. Now look at how your organisation currently handles it.

If the current handling suppresses one of the forces rather than holding both, you have found a decision that was performed rather than made, and you have found why the problem keeps coming back. The pattern is not paperwork. It is the captured decision, and writing it honestly is the first time the decision is genuinely taken.

Further Reading

Christopher Alexander: Notes on the Synthesis of Form (1964). Design as the achievement of fit, and the decomposition of a problem along its real seams.

Christopher Alexander, Sara Ishikawa and Murray Silverstein: A Pattern Language (1977). The 253 patterns, each a recurring problem and the core of its resolution, linked into a generative language.

Christopher Alexander: The Timeless Way of Building (1979). The philosophy the patterns serve: the quality without a name, and the generative process.

Christopher Alexander: “The Origins of Pattern Theory” (1996 OOPSLA keynote). His address to the software community on what the patterns movement took from him and what it missed.

The Hillside Group: https://hillside.net/patterns/ - a repository of early patterns from a stalwart of the patterns movement in software.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

In 1972 David Parnas asked a question that sounds trivial and is not: given a system to build, on what basis do you divide it into parts? The conventional answer was to follow the steps of the work; one module per stage of processing, the structure of the software mirroring the sequence in which it ran. Parnas built the same small system both that way and a second way, and showed that the two were identical in what they did and entirely different in what they cost to change. One could absorb a change in a single part. The other spread every change across the whole. Same behaviour, same output, opposite futures.

Parnas was a software engineer, and one of the first to insist that software should be a real engineering discipline rather than a craft. But the question he answered is not a software question, and it is why he belongs in the Deciding phase. He found the criterion for where to draw a boundary, and a boundary, as this phase has argued from several directions, is never neutral. It is a decision. Parnas tells you which decision it is.

1. Information Hiding Is Decision Hiding

Parnas’s answer to his own question was the principle he called information hiding. Each module should hide a design decision. The interface, the part other modules can see, exposes only what they need to know in order to use it. Everything else; how the work is actually done, what data structure holds it, what algorithm runs it; is secret, sealed inside the module where the rest of the system cannot reach it and, crucially, cannot come to depend on it.

The phrase is routinely misread as data hiding, the keeping-private of variables, and that misreading loses the whole idea. What a module hides is not data. It is a decision: a choice that could have gone otherwise and may one day have to be revisited. The interface is the part of the decision the rest of the system is allowed to rely on. The secret is the part the rest of the system is forbidden to rely on, so that it can change without anything else breaking.

This reframes what a system’s structure actually is. Two systems can do exactly the same thing and have completely different module boundaries, and the boundaries are the design. They determine what can change independently, what can be built in parallel, what can be understood without understanding everything else. The structure of a system is the set of decisions it has chosen to encapsulate. Build it well and each decision sits behind a boundary, changeable on its own. Build it badly and the decisions are smeared across everything, so that no decision can be revisited without revisiting all of them. Parnas made the structural fact unavoidable: every boundary hides a decision, and the quality of the system is the quality of that hiding.

2. Draw the Boundary Where the Change Will Be

If a boundary hides a decision, the obvious next question is which decisions deserve their own boundary, and Parnas’s answer is the sharp one. Draw the boundary around the decision most likely to change.

This sounds modest and is not. It means the structure of a system should be organised, not around what the system does, and not around the steps of its processing, but around a judgement about the future: which choices are volatile and which are stable. A decision that is likely to change should be sealed inside its own module, so that when the change arrives it is contained. A decision that will never change barely needs hiding at all. The whole architecture is therefore a set of bets about where change will strike, and the bets are made, consciously or not, the moment the boundaries are drawn.

This connects Parnas precisely to the rest of the phase. Simon established that complex systems must be decomposed to be tractable; Parnas supplies the criterion Simon’s account did not, the rule for where the decomposition should cut. Taleb and Christensen taught the phase to attend to volatility, to the consequential change the comfortable forecast leaves out; Parnas is the constructive answer to their warning, because designing for change means deciding, in advance, which assumptions are volatile enough to wall off. And it makes the boundary itself the thing to scrutinise. An organisation reviewing a design should not first ask what each part does. It should ask what decision each boundary is hiding, and whether that decision is one likely to change. A boundary drawn around a stable fact, or around a step of processing, is a boundary in the wrong place, and every future change will pay the bill for it.

3. The Honest Lie of the Rational Process

Parnas was too rigorous to pretend that real design proceeds cleanly. In a 1986 paper written with Paul Clements, he conceded the point most methodologies will not: no actual project ever follows a clean, rational, top-down design process. Requirements are not fully known at the start. People make mistakes. Priorities move. The real path of any design is a mess.

His response was not to abandon the rational process but to separate it from the record of the work. The documentation, he argued, should be written as if the process had been rational, even though it never was, because the person who later has to understand the system needs the rational structure, and does not need, and must not be given, a diary of the false starts. He called this faking it, and he meant the phrase without cynicism. Faking it is not dishonesty. It is the discipline of producing the clean account that makes a system comprehensible and maintainable, independently of the messy route by which it was actually reached.

There is a productive tension here with Schön, and the phase should hold both ends of it. Schön described how design really proceeds: as a reflective conversation with the situation, a thing of moves and surprises and reframings. Parnas does not deny that; he insists, on top of it, that the messy conversation must still resolve into a rational record, because the next person inherits the record, not the conversation. For an organisation deciding what to build, the lesson is exact. The deciding will be messy, and that is fine and normal. What is handed on must nonetheless be a clean, rational specification, because a specification is read by people who were not in the room, and a faithful transcript of the room’s confusion helps none of them.

4. Software Ages, and the Cause Is Ignorant Change

Parnas’s last great theme, set out in a 1994 paper, was software aging. Software, he observed, degrades over time; not through use, since it does not wear, but through change. Every modification made without regard to the system’s original structure erodes that structure a little further, and the erosion accumulates until the system can no longer be changed safely at all and must be replaced.

His name for the mechanism is exact and unkind: ignorant surgery. A change made by someone who does not understand the design, who cannot see which decision each boundary was built to hide, and who therefore cuts across the boundaries rather than respecting them. Each such change works, in the narrow sense that the system still runs. Each one also leaves the structure slightly less coherent than it found it, until the structure is gone and what remains is merely code that happens to function. The defence Parnas prescribed is documentation and discipline: keep the structure visible and intact, so that every change can be made knowingly.

This is the point at which Parnas speaks most directly to the present. AI now generates and modifies code at a scale and speed no human team can match, and by default that modification is ignorant surgery industrialised. An agent changing a system it does not understand, that cannot see which decision each boundary was protecting, will produce working code and accelerate aging at the same time. The faster the generation, the faster the structure erodes, unless the structure is deliberately documented and the boundaries deliberately enforced. AI does not change what Parnas said. It raises the cost of ignoring it, and it shortens the time you have before the bill arrives.

5. The Decision Comes First, and Always Did

Stand back and Parnas resolves into a single instruction for the Deciding phase. A module boundary is a decision. The decision is a bet about what will change. The structure of a system is the sum of those bets, and the system’s whole capacity to absorb the future is set by how well they were made. Information hiding, design for change, the faked rational record, the diagnosis of aging: four faces of one claim, that the durable value in any built thing is the quality of its decomposition, not the quantity of its code.

This is why AI, far from making design judgement less important, makes it the scarce thing. Generation is becoming nearly free; an implementation can be produced faster than it can be specified. What cannot be generated is the judgement about where the boundaries go, what each one should hide, which decisions are volatile enough to wall off. That judgement is the irreducible human contribution, and Parnas identified it half a century before the tools made it urgent. The organisation that treats AI as a way to produce more code faster will generate technical debt faster. The organisation that treats it as a reason to get deliberate about boundaries will build systems that endure. Either way the rule is the one Parnas stated in 1972: decide what to hide before you build what to show. The decision comes first. It always did.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Take one component your teams have recently built, and ask what decision each of its boundaries hides.

Choose a component, a service, or a module that was built or substantially changed in the last few months, ideally one with AI in the loop. For each boundary it has; each interface, each seam where it meets another part; ask two questions. What design decision does this boundary hide: what choice is sealed inside, free to change without breaking anything outside? And is that a decision likely to change, or is the boundary wrapped around something stable, or worse, around a step of processing? If your team can answer cleanly, the component was designed. If they cannot, it was implemented, not designed, and it is already aging. Then, before the next component is built, write down the three decisions it must encapsulate, and only then generate it. The decisions come first. That is the whole of the discipline.

Further Reading

David L. Parnas: “On the Criteria To Be Used in Decomposing Systems into Modules” (Communications of the ACM, 1972). The foundational paper on information hiding. Twelve pages that changed how software systems are structured.

David L. Parnas and Paul C. Clements: “A Rational Design Process: How and Why to Fake It” (IEEE Transactions on Software Engineering, 1986). Why the documentation should be written as if the process had been rational, even though it never is.

David L. Parnas: “Software Aging” (Proceedings of the 16th International Conference on Software Engineering, 1994). How software degrades through change, and why ignorant surgery is the mechanism.

Daniel M. Hoffman and David M. Weiss (eds.): Software Fundamentals: Collected Papers by David L. Parnas (2001). The collected papers, with commentary. The best single entry point to Parnas’s work.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

She was describing, without using the phrase, what Donald Schön called a reflective conversation with the situation. Schön died in 1997, before any of this was possible; his subject was architects, urban planners, psychotherapists, and engineers working at drawing boards and with paper. But the shape of what he described is the shape of AI-augmented work. Every move is provisional; every output is a response; every specification is a hypothesis the material will shortly refute or refine. The plan does not survive contact with the artefact. The question Schön asked, and that this phase of the series has to answer, is what kind of thinking survives the collision.

1. The Swamp and the Hilltop

Schön’s most enduring image appears in The Reflective Practitioner (1983). The professional landscape, he says, has a high hard ground on one side and a swampy lowland on the other. On the high ground, problems are well-defined; techniques apply cleanly; rigour is possible. In the swamp, problems are messy, confusing, embedded in values and context; rigour in the technical sense is not available and the problems that matter live there regardless.

The dominant epistemology of the professions, which Schön called technical rationality, trains people for the high ground and then sends them into the swamp. You learn a body of scientific theory and a set of techniques; you apply the theory to solve well-defined problems; rigour equals adherence to method. The difficulty, Schön noticed, is that almost nothing of significance in professional life looks like this. Architects do not derive buildings from theorems. Managers do not produce optimisation problems to decide who is promoted. Engineers do not generate systems by deduction. They make moves, watch what happens, reframe, and move again.

Technical rationality is not wrong; it is wrong about where the real work happens. Simon’s bounded rationality, covered earlier in this series, sits on the high ground: an analytic account of how decisions are made when the problem can be stated. Schön’s critique was that most decisions in practice cannot be stated cleanly, and that the act of reaching for method before the problem has revealed its shape is itself where competence fails.

2. Knowing-in-Action

What do practitioners know, then, if not theory? They know how to do things they cannot quite say how they do. A skilled manager reads a room; a surgeon’s hands find the tissue plane; a jazz pianist alters a chord before the ear has named it. Schön called this knowing-in-action: knowledge bound up in the doing, not prior to it.

This is the same terrain Bourdieu covered with habitus and Giddens with practical consciousness. Nonaka calls it tacit knowledge and describes the process (SECI) by which organisations try to convert it into explicit form. Gigerenzer’s adaptive toolbox, covered in the article just before this one, is its empirical cousin: a repertoire of fast and frugal rules that experienced practitioners select by feel. Klein’s recognition-primed decision is the same idea operationalised for fire-ground commanders. All of these thinkers describe expertise that is demonstrable, real, and resistant to articulation.

The implication for AI adoption is uncomfortable. The most valuable thing inside your organisation, the thing that makes experienced people better than new hires with the same credentials, is the part your specifications cannot capture. This is why “document the process and automate it” keeps producing automations that work on paper and fail in the building. The process was never the work. The work was the judgement running over the process.

3. Reflection-in-Action

Knowing-in-action is enough when the situation is familiar. The interesting question is what happens when it is not. When the ground shifts, when the artefact surprises, when the result is not what was expected, what does the practitioner do?

Schön’s answer is reflection-in-action: thinking on one’s feet. The practitioner does not stop to consult a theory. She reflects on the tacit understanding implicit in her action while continuing to act. She asks, silently and quickly: what assumption did I just make; what does the situation seem to be telling me; what would happen if I saw it differently. Then she makes a new move. The situation talks back again. She adjusts.

This is not iteration in the modern software sense, though the two are related. Iteration is repeating a process with refinement. Reflection-in-action is conducting a conversation in which both parties may change. The practitioner learns from the situation; the situation, in responding, takes new shape. Schön proposed five questions to judge whether a reframing is worth keeping: can the problem be solved as now framed; do I like what I get; is the new framing coherent; is it congruent with my fundamental beliefs; and has inquiry been kept moving. These are not metrics. They are the conscience of a practitioner who is still in the work.

4. Virtual Worlds

The reflective conversation needs a place in which to happen. Schön called these places virtual worlds: sketchpads, models, physical prototypes, simulations, any representation that lets the practitioner try a move and see its consequences without bearing the full weight of commitment. The drawing does not have to be right to be useful; it has to be wrong in an informative way.

This is perhaps the most exact anticipation of AI-augmented work in twentieth-century management thought. An AI coding assistant is a virtual world. A generated prototype is a virtual world. A simulation of a process before it is rolled out is a virtual world. The purpose of these artefacts is not to produce the right answer on the first attempt. Their purpose is to let the material talk back, early and cheaply, so that the practitioner can reframe.

The organisations that will get most from AI are not the ones with the best prompts. They are the ones whose people treat AI outputs as moves in a conversation, not as finished products. Whether they develop that capacity is not a tooling question; it is a cultural one, which returns us to Argyris and the defensive routines that close reflection down long before the tools arrive.

5. The Specification Delusion

A large part of enterprise technology practice has assumed, for forty years, that the main difficulty is getting requirements right at the front. Waterfall projects institutionalised this. Agile reacted against it but retained the assumption that, given the right techniques, intent could be captured upstream of the build. The Deciding phase of this series has been quietly dismantling that assumption from several directions. Evans showed that a domain model is not discovered before the code; it emerges through the code. Taleb showed that planning under deep uncertainty is a category error. The object-oriented design tradition, profiled in an earlier article, showed that every interface is a decision about what to hide. Schön is the philosophical floor beneath these arguments.

The belief that you can specify what AI should build before building it is, in Schön’s vocabulary, a pure expression of technical rationality. In practice, specification is a reflective conversation. You specify; the model generates; the output talks back; you respecify. Specification is not upstream of the build. Specification is the build, conducted in words rather than keystrokes. Organisations that still treat specification as a one-time activity at the front of a programme are preparing to deliver systems that met the early description and missed the later reality. Organisations that treat specification as a live conversation will produce systems that surprise them, sometimes for the better.

6. Repertoire and the Problem of the New Practitioner

There is a hard edge to this argument that deserves acknowledgement. Reflection-in-action depends on repertoire: the accumulated stock of examples, patterns, and half-remembered analogues the practitioner draws on to see a new case as like some older one. “Seeing as,” Schön called it, borrowing from Wittgenstein. Without repertoire, there is nothing to reflect with.

This is where the AI adoption argument gets awkward. The practitioners best positioned to work well with AI are experienced people whose repertoires are deep. The practitioners most threatened by AI are junior ones who have not yet built those repertoires, and whose traditional training pathway (doing simple work under supervision) is the same work AI is now doing. The industry has not yet produced an honest answer to how the next generation acquires repertoire when the apprenticeship work has been automated. “They will learn by reviewing AI output” is the current answer, and it may turn out to be right; it has not been shown to be. Leaders planning AI adoption who ignore this question are accepting an unfunded liability on their organisation’s future capability.

7. Beyond the Stable State

Schön’s earlier and less-read book, Beyond the Stable State (1973), argued that there is no stable state to defend; institutions and the societies that contain them are in continuous transformation; belief in a fixed state to which things can return is itself the obstacle to learning. This is the premise of the series. It is also the premise that makes reflection-in-action a permanent requirement rather than a crisis response.

If the ground moves constantly, then every artefact in the organisation is provisional; every specification is a draft; every structure is a hypothesis about a world already different from the one it was designed for. The practitioner who treats this as catastrophic will suffer. The practitioner who treats it as the normal condition of professional life, which Schön argued it always was, will find the work richer and less anxious. The swamp is not a failure mode. It is where the work happens.

(An Organisational Prompt is something you can do now to test the ideas of this article in your own organisation.)

Organisational Prompt

Name your reframings.

In the next project review, do not ask what went wrong or what went well. Ask three things:

(1) what the team was trying to do when the work began;

(2) what the material told them that changed their framing;

(3) and what they are trying to do now.

If nobody can answer the second question, the team is either working on a problem too simple to reward reflection or is pretending they never changed their minds. Both are warning signs. A team that can name its reframings is learning in action. A team that cannot is running a script.

Further Reading

Donald Schön, The Reflective Practitioner: How Professionals Think in Action (1983). Demanding but every page rewards patience.

Donald Schön, Beyond the Stable State (1973). The earlier, broader statement of the social theory behind the practice idea.

Chris Argyris and Donald Schön, Organizational Learning II: Theory, Method, and Practice (1996). Where Schön’s epistemology meets Argyris’s diagnostic framework.

Mark K. Smith, “Donald Schön: learning, reflection and change,” infed.org: https://infed.org/mobi/donald-schon-learning-reflection-change/. The most thorough free overview.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

The weekly report showed the production line running at target. Throughput was within range, defects sat inside tolerance, the summary was green. On the floor, the same line was stopping every few minutes; the operators had learned to absorb the interruptions into the rhythm of the shift, and the numbers still came out flat. The report was not lying. It was doing what reports do: it had averaged, summarised and rounded until the thing that mattered had disappeared.

Every organisation decides on the strength of descriptions like that report. The description is never the reality; it is an account of the reality, assembled by people, each of whom had a reason to smooth it. By the time a description has climbed three levels of an organisation it has been attenuated at every step, and the decision taken on top of it inherits every omission silently. This is not a failure of honesty. It is the ordinary physics of information moving through a hierarchy, and it is the problem the second lever of the Deciding phase exists to address.

That lever is Information: whether an organisation can describe the thing it is deciding about with enough precision to decide within it at all. The Learning phase placed Bateson at this lever, and he gave it an epistemology; information is a difference that makes a difference, and the double bind is the pathology that corrupts the signal and keeps it circulating. Bateson tells you what meaningful information is and how it is degraded. He does not tell you what to do on a Tuesday. Taiichi Ohno does, and that is why the Deciding phase needs him here.

Ohno built the Toyota Production System over roughly three decades, and although it is remembered as a manufacturing method it is more accurately a theory of how an organisation sees. Gemba, standard work, jidoka, the five whys: each is a mechanism for closing the gap between the account and the actual. Several articles in this phase have already leaned on him without naming the debt. The treatment of domain-driven design described Evans’s ubiquitous language and bounded contexts as a decision discipline, and they are one; but they are a software instance of an older and more general idea, and the idea is Ohno’s. This article makes the debt explicit and sets out the discipline on which the rest of the Information lever rests.

1. Gemba: Go and See

Gemba is a Japanese word meaning the actual place: the spot where the work is done and where value is, or is not, being created. Ohno’s instruction was uncompromising. The truth about the work is held only at the gemba, and a manager who manages from a conference room is managing an artefact. The report on the screen is not the work; it is a representation of the work, and a representation made by someone who had to decide what to leave out.

The practice Ohno is most associated with makes the point physical. He would chalk a circle on the factory floor and require a manager to stand inside it, sometimes for the better part of a day, with a single instruction: watch the work, and tell me what you see. Most could not, at first. They saw what they expected to see, which is not the same as seeing. Ohno’s circle was a training device for a capacity that does not arrive by default. Looking is automatic; seeing is a discipline, and the discipline has to be built.

Gemba is the corrective to the problem Bateson named. Bateson showed that the signal degrades as it travels; Ohno’s answer is not a better reporting template but a change of physical location. Go to where the signal originates, before it has been averaged, summarised and rounded by everyone whose job depended on its shape. A report is a description of the work written by someone who needed it to look a particular way, and no amount of refinement to the document removes that fact. Only standing at the source does.

For software, this is not a metaphor that needs stretching. Evans’s knowledge crunching, the long sessions with domain experts that produce a model, is gemba. You do not learn a domain from a requirements document, because the document is already an attenuated account; you go to where the domain knowledge actually lives, which is the practitioner doing the work, and you watch and ask until the model matches what they do rather than what they wrote down. Going to see is the first move of the Information lever. But it is only useful if you have something to see against.

2. Standard Work as Hypothesis

Standard work is the current best-known way to perform a task, documented precisely: the sequence of steps, their timing, the small inventory of materials the task requires. It is the most misread idea in Ohno’s system. Read carelessly, it looks like the bureaucratic enemy of improvement, the laminated procedure that punishes initiative. It is the exact opposite, and the misreading matters because it inverts the purpose.

Ohno’s own formulation closes the question: where there is no standard, there can be no kaizen. The standard is not a cage; it is a baseline. Without a written standard, every observation of the work is merely an anecdote, one person’s impression set against another’s. With a standard, an observation becomes a measured difference: the work either matched the standard or it did not, and the deviation is now a fact rather than an opinion. The standard is what makes a difference visible, which is Bateson’s definition of information made into a shop-floor object.

The deeper move is to see what kind of claim a standard is. It is an explicit, falsifiable statement about the best way currently known to do the work. It invites refutation. The next person to perform the task, or to stand in the circle and watch it, can demonstrate that the standard is wrong, and when they do, the standard changes that day. This is the series’ Popperian thread rendered as practice: the standard is a conjecture, kaizen is the refutation, and the improved standard is the next conjecture. A standard held as a hypothesis improves continuously. A standard held as a rule ossifies, and then deserves the bad reputation the misreading gives it.

This is why an organisation with no standards is not free but blind. It has nothing to notice change against. It cannot tell improvement from drift, or a real problem from a bad day, because every state of the work looks much like every other. Standard work is the instrument that lets an organisation see precisely, and seeing precisely is the whole task of the Information lever. The standard tells you, reliably, when something has gone wrong. It does not tell you why.

3. The Five Whys: Description Before Decision

The why is answered by asking it again. Ohno’s discipline for reaching a cause was to ask why repeatedly, conventionally five times, refusing to stop at the first answer that sounded sufficient. His own example runs from a stopped machine to a blown fuse to a seized bearing to inadequate lubrication to a worn pump shaft. Stop at the fuse and you replace the fuse, and the line stops again next week. Reach the shaft and the problem is gone.

The five whys is not a root-cause ritual to be performed in a workshop and forgotten. It is a discipline of description, and its target is the most common failure in organisational decision-making: acting on a symptom because the symptom is what the report described. A decision taken at the first why is a decision about a surface, and it will be re-taken, again and again, because the cause underneath it was never touched. The organisation experiences this as a recurring problem and treats the recurrence as bad luck. It is not bad luck. It is a description that stopped too early.

This connects directly to the hypothesis the whole Deciding phase rests on: decisions are design challenges, and design is a sequence of decisions under constraint. You cannot design a remedy for a problem you have described only at its surface, any more than you can design a bridge from a photograph of a river. The five whys is how an organisation earns a description precise enough to design against. The recently published methods for deciding asked whether the model behind a decision is visible and challengeable; the five whys is one of the plainest ways to build such a model, because each why forces a claim into the open where it can be examined. Seeing precisely, and describing to the root, still leaves one question: what should happen the instant a defect appears.

4. Jidoka: Build Quality In

Jidoka is usually translated as autonomation, or automation with a human mind. A machine equipped with jidoka detects its own defect and stops itself, rather than continuing to produce flawed parts at speed. The principle extends past machines through the andon cord: a line, a signal, or a button by which any worker who sees a problem can halt the entire production line.

The radicalism of this is easy to understate. A single worker, at any moment, can stop the whole system. Most organisations would regard that as an invitation to chaos. Ohno regarded the alternative as the chaos: a known defect, undetected or detected and ignored, travelling downstream where it is built into larger assemblies, multiplied, and buried so deep that by the time it surfaces it has cost a hundred times what it would have cost at source. Stopping the line is not the expensive option. It is the cheap one, paid early.

Jidoka is, at its core, an information principle. A defect is information; it is a difference that very much makes a difference. Jidoka makes that information impossible to ignore by giving it the authority to stop production. Quality is built in at the source rather than inspected in at the end, and the reason is precisely about description. By the time a defect reaches final inspection it has been described as a finished unit, wrapped in all the work performed on top of it, and the original signal is almost impossible to recover. Where Bateson’s double bind corrupts a signal and keeps it quietly circulating, jidoka is the mechanism that stops the corrupted signal dead. It is the Information lever’s refusal to let a bad description pass downstream and become someone else’s foundation.

5. The Seven Wastes: Seeing What Is Not There

Ohno catalogued seven forms of waste, or muda: overproduction, waiting, transport, over-processing, inventory, motion, and defects. The list is useful, but the insight beneath it is the part worth keeping. Waste is invisible until you have a language that makes it visible. A team can work hard for an entire day, produce mostly waste, and go home feeling productive, because without the categories there is simply nothing to see. Effort is felt; waste is not, until it is named.

Naming creates perception. This is the quiet link back to the rest of the series: a vocabulary is not a description of a world already seen, it is the instrument that lets the world be seen at all. Give a team the seven categories and they begin, within days, to notice things that were always there and always invisible. Ohno held that overproduction was the worst of the seven, and the reasoning is instructive: overproduction manufactures the appearance of progress, the full shelves and the busy line, and that appearance hides the other six wastes behind it. The most dangerous waste is the one that looks like success.

For the Deciding phase this is direct. An organisation that cannot see its waste cannot decide what to stop, and stopping is half of deciding. The probes that run through this phase asked exactly that question: can the organisation halt what no longer works, or does everything it has ever started simply continue. The honest answer is usually that the organisation cannot see clearly enough to know what to stop, because it has no shared language for waste and so experiences its waste as ordinary work. These are not five or seven separate techniques. Gemba, standard work, the five whys, jidoka and the wastes are one discipline seen from different angles, and naming the discipline lets us settle a question this phase has been carrying.

6. Why Evans Is Ohno in Software

Earlier in this phase, domain-driven design was treated as a foundational decision discipline, and on its own terms it is. But it is not foundational in itself, and the distinction matters for how the architecture of this series holds together. Evans’s ubiquitous language is standard work for a domain: a shared, written, precise description of how the domain is talked about, maintained as the baseline that the next conversation can correct. Bounded contexts are value-stream boundaries. Ohno drew the edges of a work cell where the flow of value naturally divided; Evans drew the edges of a model where the language naturally divided; it is the same act of seeing a seam and cutting along it rather than across it.

The parallels continue once you look for them. Knowledge crunching is gemba: the modeller does not build from a document but goes to where the domain knowledge actually lives. The anti-corruption layer is jidoka installed at a boundary: it exists to stop a corrupted model from one context passing into a clean model in another, halting the bad signal exactly as the andon cord halts the line. None of this diminishes Evans. It locates him. He is the shaping thinker who showed an entire profession what Ohno’s discipline looks like rendered in their own medium, and that translation was indispensable; most software practitioners would never have reached Ohno directly.

But Ohno is the foundation thinker for the Information lever because the discipline is general. It governs a factory, a hospital ward, a domain model and a fleet of software agents with equal force, because in every case the task is the same: see the work precisely, at its source, and hold the description as a claim that reality can correct. Evans is Ohno for software. That framing is not a demotion of Evans; it is a promotion of the principle, and it is exactly the principle that now faces its hardest test, because the newest medium of work is one in which the worker is a model.

7. The Agentic Turn

Software agents generate work at a scale and speed that makes the gemba problem acute rather than incidental. Two descriptions are now suspect at once. There is the description the agent is given to act on, and there is the description the agent produces of what it did, and both are smoothed accounts. An AI-generated status summary is attenuation performed instantly, fluently and with great confidence; it is the green weekly report, written in a second, for a thousand lines at once.

Standard work as hypothesis becomes the governance mechanism here, and it is hard to see what replaces it. An agent’s method has to be an explicit, written, falsifiable standard, because if there is no standard you cannot tell when the agent has drifted. You can only tell when it has failed visibly, and most drift does not fail visibly; it produces plausible output that is quietly wrong. Jidoka becomes the second requirement. An agent has to be built so that it stops when it cannot meet the standard, rather than producing confident, defective output at volume. An agent that never stops the line is not an efficient worker; it is an overproduction machine, and overproduction was the waste Ohno feared most because it looks like success. The andon cord has to be wired into the system deliberately, because the agent will not reach for it on its own.

This argument is structural, not normative. AI does not change what good description requires; the requirement was always to see the work at its source and hold the account as a correctable claim. What AI removes is the time you used to have. An organisation with weak gemba discipline survived for decades because work moved at human speed, and a wrong description could be caught before it had done much damage. At machine speed there is no such grace period. The organisation that never learned to see precisely will not be punished more harshly by AI; it will simply be punished faster, and with less warning, than it was before.

Ohno equips the Information lever fully: a description seen at its source, held as a falsifiable standard, with a mechanism that stops the corrupted signal before it travels. But a precisely seen reality is not yet a good decision. The signal, however clear, has to move; it has to reach the part of the organisation that holds the authority and the variety to act on it, and whether it can is a question of structure, not of seeing. That is the Interaction lever, and it is where the Deciding phase turns next, to Stafford Beer and the Viable System Model. Beer would recognise Ohno’s andon cord at once: it is an algedonic signal, the alert that bypasses the hierarchy because the news is too important to be attenuated on the way up. He would recognise the gemba as the audit channel, the direct and unfiltered contact with operations that no viable system can do without. Ohno built the practices. Beer built the architecture that determines where those practices must sit for the signal to survive the journey. Seeing clearly is the beginning of deciding. Whether what you see can move is the next problem.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Go to the gemba for one decision you are about to take on the strength of a report.

Pick a decision currently circulating in your organisation on the basis of a dashboard, a status deck or a written summary. Before the next meeting about it, go to the place where the work that report describes actually happens, and watch it for an hour. Do not interview anyone, and do not ask the team to present to you; if you ask, you will get another report. Just watch. Then write down, in one column, what the report told you, and in another, what you saw. The gap between the two columns is the information your decision was about to be missing. If there is no gap, you have a rare and genuinely well-run process. If there is a gap, you have just discovered that you were about to decide on a description rather than a reality, and you now have the one hour of seeing that changes the decision.

Further Reading

Taiichi Ohno: Toyota Production System: Beyond Large-Scale Production (1978; English translation 1988). The foundational text. Just-in-time, autonomation, the seven wastes, and the discipline of asking why five times.

Taiichi Ohno: Workplace Management (1982; English translation 2013). Short, aphoristic reflections on gemba, standard work, and the manager’s task of seeing reality precisely.

Jeffrey Liker: The Toyota Way (2004; 2nd edition 2021). The most widely read synthesis of Ohno’s system, with worked detail on standard work and jidoka.

Lean Enterprise Institute. Overviews of the Toyota Production System, jidoka, standard work and gemba, with links to primary sources.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

Six months in, decisions are slower. The platform generates so much information that committees spend their time debating the inputs rather than making the call. The people who used to decide well — the ones with twenty years of domain knowledge and a reliable instinct for what matters — now defer to the dashboard. When the dashboard is ambiguous, which it often is, nobody decides at all.

This is not a technology failure. It is an epistemological one.

The Bias Industry

Earlier in this series, we examined Kahneman’s work on the two cognitive systems — the fast, associative System 1 and the slow, deliberative System 2 — and the catalogue of biases that arise when System 1 handles problems that properly belong to System 2. The implications for organisations were clear: human judgment is unreliable, systematically distorted by anchoring, availability, overconfidence, and a dozen other heuristic shortcuts. The corrective seemed obvious. Slow down. Gather more data. Build decision frameworks that force deliberation and override intuition.

An entire industry has grown from this logic. Behavioural economics consulting. Debiasing workshops. Nudge units. And now, AI-powered decision platforms that promise to do what humans apparently cannot: weigh all the evidence without cognitive distortion.

Gerd Gigerenzer, director of the Harding Center for Risk Literacy and for decades the most formidable intellectual opponent of the Kahneman-Tversky programme, argues that this corrective is built on a misunderstanding. Not a small one. A foundational one.

The error is this: the assumption that heuristics are cognitive failures to be corrected, rather than cognitive tools to be understood.

Simon’s Scissors

To see what Gigerenzer is doing, we need to return briefly to Herbert Simon, whose concept of bounded rationality has already appeared in this series. Simon argued that humans cannot optimise; they lack the computational capacity, the time, and the information. Instead, they satisfice — they search until they find an option that meets their threshold, then stop. This was a descriptive claim about cognitive limits.

But Simon said something else, less often quoted, that Gigerenzer takes as his starting point. Human rationality, Simon wrote, operates like a pair of scissors: one blade is the cognitive capacity of the decision-maker, the other is the structure of the environment. You cannot understand how a pair of scissors cuts by looking at only one blade.

The Kahneman-Tversky research programme looks almost exclusively at the cognitive blade. It examines how people deviate from optimal statistical reasoning — from Bayesian updating, from expected utility maximisation — and catalogues the deviations as biases. The implicit benchmark is a decision-maker with unlimited information and unlimited computational capacity. Against that benchmark, of course, human judgment looks deficient.

Gigerenzer’s argument is that the benchmark is wrong. Not just impractical, but wrong as a description of what good decision-making looks like under the conditions in which real decisions actually occur.

Ecological Rationality

The core of Gigerenzer’s programme is the concept of ecological rationality. A heuristic is not rational or irrational in the abstract; it is rational to the degree that it fits the structure of the environment in which it is deployed. A simple rule that ignores most available information can outperform a complex model that uses all of it — not despite its simplicity, but because of it.

This is the less-is-more effect, and it is not a curiosity. It is a robust empirical finding across domains from medical diagnosis to investment to personnel selection.

Consider: emergency physicians at a Michigan hospital needed to decide quickly whether patients presenting with chest pain should be sent to the coronary care unit or a regular bed. The standard protocol used a complex logistic regression model incorporating dozens of variables. A fast-and-frugal decision tree — asking at most three yes-or-no questions — matched or outperformed the complex model. It asked whether the ECG showed ST-segment changes, whether chest pain was the chief complaint, and whether any of five other factors were present. Three questions. Better outcomes.

Why? Because the environment had a specific structure: a few cues were highly diagnostic while the rest added noise. Under those conditions — which, Gigerenzer argues, characterise most real-world decision environments — the complex model overfits. It captures not only the signal but the noise in the historical data, and the noise does not generalise. The simple heuristic, by ignoring most of the information, is more robust. It travels better from the past to the future.

The Adaptive Toolbox

Gigerenzer does not argue that one heuristic fits all situations. His model of the mind is not a single algorithm but what he calls the adaptive toolbox: a repertoire of heuristics, each adapted to a particular class of environment. The recognition heuristic — when in doubt, choose what you recognise — works when recognition correlates with the criterion of interest, as it does in many consumer and investment decisions. The take-the-best heuristic — search cues in order of validity, stop at the first one that discriminates — works when cue validities are skewed and information is redundant. The 1/N rule — divide resources equally among options — outperforms mean-variance portfolio optimisation when the number of options is large relative to the available data.

The art of good decision-making, on this account, is not the elimination of heuristics but the selection of the right heuristic for the right environment. This is what Gigerenzer means by risk literacy: not the ability to calculate probabilities (though that helps), but the ability to match a decision strategy to the structure of the problem.

The Kahneman-Gigerenzer Debate

It would flatten the intellectual landscape to pretend this is a settled question. The disagreement between Kahneman and Gigerenzer is genuine, substantive, and unresolved.

Kahneman’s position, put simply, is that heuristics produce systematic errors in a wide range of conditions, and that awareness of these errors — combined with structured decision processes — can improve outcomes. The evidence for specific biases (anchoring, framing effects, base-rate neglect) is extensive and replicable. Gigerenzer does not deny that these effects occur in laboratory settings; he argues that they occur primarily in environments that have been specifically designed to make heuristics fail — narrow experimental conditions that strip away the environmental structure on which heuristics depend. Transpose the same decision-maker into a natural environment with ecological validity, and the ‘bias’ often disappears or reverses.

Klein, whose work on recognition-primed decision-making we have already discussed, sits closer to Gigerenzer on this question. Kahneman himself acknowledged the convergence in his later work with Klein, conceding that expert intuition is reliable when the environment is regular enough to be learned and when the decision-maker has had adequate opportunity to learn it. The disagreement is about how often those conditions obtain — and about what to do when they do not.

For the purposes of this series, the productive tension matters more than the resolution. Kahneman tells us where human judgment fails. Gigerenzer tells us where it succeeds and why. An organisation that heeds only Kahneman builds systems designed to override human judgment. An organisation that heeds only Gigerenzer trusts domain expertise without examining the conditions under which it was formed. The intelligent position is to hold both: to know when the environment supports heuristic reasoning and when it does not, and to design accordingly.

What This Means for Organisations Adopting AI

The relevance to AI adoption is immediate and largely ignored.

The prevailing assumption in enterprise AI is that more data produces better decisions. This is true in stable, data-rich environments with well-defined outcome variables — the complicated domain, in Snowden’s terms. It is not true in the environments where most consequential organisational decisions actually occur: volatile, ambiguous, and poorly structured, where the relevant variables are not yet identified and the future will not resemble the training data.

In those environments — which is to say, in most of the decisions that actually matter to a technology leader — Gigerenzer’s research suggests that organisations should be investing not in more comprehensive models but in better heuristics. Simple decision rules, transparent and debuggable, that capture the structure of the specific environment and ignore everything else.

This runs directly counter to the AI sales pitch, which is precisely why it deserves attention. The vendor tells you that the model considers thousands of variables. Gigerenzer asks: in an uncertain environment, is that a feature or a liability?

The Decision Hygiene Question

There is, however, a place where Gigerenzer and the debiasing tradition converge, and it matters for practice. Gigerenzer’s work on risk literacy demonstrates that many decision failures are not failures of heuristic reasoning but failures of representation. Doctors misinterpret screening results not because they use bad heuristics but because the results are presented in conditional probabilities rather than natural frequencies. The heuristic is fine; the information format is hostile to it.

This connects to what Kahneman, Sibony, and Sunstein have called decision hygiene — the structural conditions under which decisions are made. The question is not only ‘which heuristic?’ but ‘has the environment been structured to support good heuristic use?’ For organisations, this reframes the AI question entirely: the goal is not to replace human judgment with algorithmic judgment, but to structure the information environment so that the adaptive toolbox works well.

The Organisational Prompt

Identify one recurring decision in your organisation that is currently supported by a complex scoring model, a multi-criteria framework, or an AI recommendation engine. Now ask:

What simple rule would your most experienced domain expert use if forced to decide in sixty seconds with no dashboard?

Articulate that rule explicitly. It will likely use one, two, or at most three cues. Test it against the complex model’s track record. If the simple rule performs comparably — and Gigerenzer’s research suggests it often will — then the complexity of the model is not adding predictive value. It is adding cost, latency, and opacity.

The point is not that you should replace every model with a heuristic. The point is that you should know, empirically, whether the complexity is earning its keep. Most organisations have never asked.

Further Reading

Gerd Gigerenzer, Peter M. Todd, and the ABC Research Group, Simple Heuristics That Make Us Smart (Oxford University Press, 1999). The foundational text. Available as a précis: Behavioral and Brain Sciences, 23, 727–780.

Gerd Gigerenzer, Gut Feelings: The Intelligence of the Unconscious (Viking, 2007). The accessible introduction; starts from the gaze heuristic and builds outward.

Gerd Gigerenzer, Risk Savvy: How to Make Good Decisions (Viking, 2014). Risk literacy in practice — medicine, finance, everyday life.

Gerd Gigerenzer, “Why Heuristics Work,” Perspectives on Psychological Science 3, no. 1 (2008): 20–29. The clearest short statement of the less-is-more argument. Freely available PDF.

Gerd Gigerenzer and Wolfgang Gaissmaier, “Heuristic Decision Making,” Annual Review of Psychology 62 (2011): 451–482. The comprehensive review. Freely available PDF.

Daniel Kahneman and Gary Klein, “Conditions for Intuitive Expertise: A Failure to Disagree,” American Psychologist 64, no. 6 (2009): 515–526. The remarkable partial convergence between the two programmes.

Victor DeMiguel, Lorenzo Garlappi, and Raman Uppal, “Optimal Versus Naive Diversification: How Inefficient Is the 1/N Portfolio Strategy?” The Review of Financial Studies 22, no. 5 (2009): 1915–1953.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

March would have recognised this instantly. James March, the political scientist and organisational theorist who co-founded modern decision theory with Herbert Simon at Carnegie in the 1950s, spent sixty years studying how organisations learn, decide, and fail. His central finding is that organisations face a tension they can never fully resolve: the tension between exploitation (getting better at what you already do) and exploration (discovering what you should be doing instead). Both are essential. Both compete for the same scarce resources. And the mechanisms of organisational life, the incentives, the measurement systems, the career structures, systematically favour exploitation. AI, March’s framework predicts, will make this asymmetry catastrophically worse.

1. The Garbage Can: How Decisions Actually Happen

March’s first major contribution to decision theory, developed with Michael Cohen and Johan Olsen in 1972, was the garbage can model of organisational choice. It describes how decisions happen in what March called “organised anarchies”: organisations characterised by problematic preferences (people do not agree on what they want), unclear technology (people do not fully understand their own processes), and fluid participation (who shows up to which meeting is somewhat random).

In a garbage can, four streams flow through the organisation independently: problems, solutions, participants, and choice opportunities. A meeting is a choice opportunity. The people who happen to attend bring whatever problems and solutions they are currently carrying. Decisions arise not from rational matching of problems to solutions but from the timing of when these streams happen to intersect. Solutions go looking for problems. Problems go looking for solutions. What gets decided depends as much on who is in the room and what is on their mind as on the quality of the analysis.

This is not a cynical observation. It is an empirical one. And it describes AI adoption in most enterprises with uncomfortable accuracy. The team that adopted the AI coding tool did so not because a rigorous analysis determined it was the highest-value use case. It adopted it because the tool was available, a champion happened to be on the team, and the timing coincided with a budget cycle. The enterprise that chose to invest in a customer service chatbot did so not because customer service was the strategic priority. It did so because the vendor’s solution was mature, the customer service head was an early adopter, and the board had asked for visible AI wins. The garbage can is not a failure of rationality. It is how organisations with bounded rationality, contested preferences, and fluid attention actually function.

Mintzberg would recognise this as emergent strategy: the pattern formed by the accumulation of garbage can decisions over time. Lindblom would call it muddling through. March adds what neither provided: a formal model of why rational decision-making in organisations is structurally impossible under common conditions, and why this is not necessarily a problem to be solved but a reality to be navigated.

2. Exploration and Exploitation: The Tension That Never Resolves

March’s most cited work, published in 1991, names the tension at the heart of every AI strategy. Exploration is search, experimentation, play, risk-taking, variation, discovery. Its returns are uncertain, distant, and diffuse. Exploitation is refinement, efficiency, selection, implementation, execution. Its returns are reliable, proximate, and precise.

Organisations must do both. They cannot survive by exploiting alone, because the environment changes and what they are good at becomes obsolete. They cannot survive by exploring alone, because exploration without consolidation produces endless experimentation with no payoff. The problem is that the two compete for the same resources: time, attention, money, and talent. And three forces systematically tilt the balance toward exploitation.

• Temporal proximity: exploitation returns come sooner. A team using AI to accelerate its existing delivery pipeline shows results this quarter. A team experimenting with AI to discover entirely new capabilities might show results next year, or never. Spatial proximity: exploitation returns are captured locally, by the team that did the work. Exploration returns may benefit other parts of the organisation, or other organisations entirely.

• Precision: exploitation returns are measurable and attributable. You can show the board a graph. Exploration returns are ambiguous and hard to attribute. You cannot put “discovered something unexpected” in a quarterly review.

• The consequence: organisations systematically over-exploit and under-explore. They become astonishingly effective in the short run and self-destructive in the long run. March’s phrase for this is the competency trap. The better you get at something, the less likely you are to try alternatives. Success reinforces current practice. Failure is ambiguous and avoided. The organisation converges on a local optimum and mistakes it for the global one.

Christensen described the market-level consequence: incumbents over-exploit existing value networks while disruptors explore new ones. Taleb’s barbell strategy is the structural response: extreme safety (exploitation) combined with small speculative bets (exploration). Boyd’s OODA loop requires periodic destruction of existing orientation (exploration) before rebuilding (exploitation). March provides the organisational learning theory that explains why all of this is so hard: the adaptive mechanisms of organisational life refine exploitation more rapidly than exploration, and reason itself inhibits the foolishness that exploration requires.

3. The Technology of Foolishness: Why You Must Act Before You Know What You Want

In 1971, March published a short essay called “The Technology of Foolishness.” Its argument is deceptively radical. Rational decision-making assumes you know your preferences before you choose your actions. First you decide what you want, then you figure out how to get it. March argued that this assumption is often false, and that the most important preferences are sometimes discovered through action, not prior to it.

Playfulness and experimentation are not failures of rationality. They are essential mechanisms for discovering new possibilities. An organisation that insists on knowing the ROI before it experiments has already foreclosed the discoveries that experimentation would produce. You cannot calculate the return on something you have not yet imagined.

Ackoff’s idealised design is institutionalised foolishness in March’s sense: it deliberately suspends existing preferences to discover new ones. Lindblom’s muddling through is the modest, everyday version. March provides the theoretical justification: sometimes the only way to find out what you want is to do something and see what happens. This does not mean acting randomly. It means creating structured opportunities for play, where the consequences of failure are small and the potential for surprise is high.

For AI adoption, the technology of foolishness is the antidote to the business case-first approach. The organisation that demands a three-year ROI projection before approving an AI experiment will never discover what AI can do for it, because the most valuable applications are precisely the ones nobody can predict in advance. The business case for the iPhone could not have been written in 2004. The business case for AI-augmented professional work cannot be written in 2026. It must be discovered through structured foolishness: cheap experiments, reversible bets, and the organisational tolerance for not knowing the answer before you start.

4. Two Logics: Why People Do What Their Role Prescribes

With Johan Olsen, March distinguished two fundamental logics guiding decision-making. The logic of consequences asks: “What outcome do I want, and how do I achieve it?” This is rational calculation. The logic of appropriateness asks: “Who am I, and what does someone like me do in a situation like this?” This is identity-based reasoning.

Most organisational behaviour follows the logic of appropriateness. Professionals do what their role prescribes, not what calculation optimises. The senior architect reviews code because that is what senior architects do, not because a cost-benefit analysis determined it was the highest-value use of their time. The governance committee requires an impact assessment because governance committees require impact assessments, not because this particular assessment will produce information that changes the decision.

Bourdieu called this habitus: the embodied dispositions that generate practice without conscious calculation. Kegan showed that Order 3 professionals (the socialised mind) operate almost entirely through the logic of appropriateness; the capacity to step back and use the logic of consequences independently requires Order 4 development. Weber showed that bureaucratic rationality is an institutionalised logic of appropriateness: roles, rules, and procedures define correct behaviour regardless of outcomes.

For AI adoption, the logic of appropriateness explains resistance that the logic of consequences cannot. The professional who refuses to use AI is not making a rational calculation that AI produces worse outcomes. They are responding to a deeper question: “Is someone like me, a person with my expertise and standing, the kind of person who uses AI to do their work?” If the answer is no, no amount of evidence about AI’s capability will change the behaviour. The resistance is not irrational. It is operating under a different logic entirely. Until the identity changes, the behaviour will not.

5. The Myopia of Learning: Why Success Teaches the Wrong Lessons

With Daniel Levinthal, March identified three forms of learning myopia that explain why organisations draw the wrong conclusions from their own experience. Temporal myopia: favouring proximate consequences over distant ones. The AI pilot that produced quick wins gets funded; the long-term capability investment that would produce larger but slower returns does not. Spatial myopia: favouring effects felt locally over effects felt elsewhere. The team that benefits from AI adoption reports success; the downstream teams that inherit the technical debt do not. Failure myopia: learning more readily from success than from failure, even though failure contains richer information.

Organisations cope with confusing experience through simplification (reducing complex events to simple stories) and specialisation (assigning different parts of the organisation to learn different things). Both contribute to myopia. The simplified story of the successful AI pilot obscures the conditions that made it successful, conditions that may not exist in the next context. The specialised learning of the AI centre of excellence does not transfer to the teams that must actually use AI in their work.

Senge’s beer game demonstrates spatial myopia: rational local decisions produce systemic irrationality. Dekker showed that organisations learn the wrong lessons from failure because they simplify systemic causes into individual error. March adds the temporal dimension: the lessons that matter most are the ones whose consequences are furthest away, and those are precisely the ones organisations are worst at learning.

6. Slow Learners and the Value of Naïveté

March’s most counterintuitive finding concerns the relationship between individuals and what he called the organisational code: the established beliefs, procedures, and strategies that constitute the organisation’s collective knowledge. In his model, individuals learn from the code (socialisation) and the code learns from individuals (updating). The problem is speed.

If individuals are socialised too quickly, the code converges on a local optimum before sufficient exploration has occurred. The organisation settles on an answer before it has asked enough questions. Fast learners, the people who absorb the organisation’s norms most efficiently, accelerate this convergence. Slow learners, the people who resist socialisation, maintain diversity longer. They keep exploring possibilities that the fast learners have already abandoned.

March’s conclusion is striking: “The development of knowledge may depend on maintaining an influx of the naive and ignorant.” The newcomer who asks “why do we do it this way?” is not a nuisance. They are a source of the variation that the system needs to avoid premature convergence. The experienced professional who has fully absorbed the organisation’s code is, paradoxically, less valuable for exploration than the junior hire who has not yet learned what is supposed to be impossible.

For AI adoption, this inverts the conventional wisdom. The standard approach is to start with the experts: the senior architects, the experienced engineers, the domain specialists. March’s model suggests that the experts are the most trapped by the competency trap. Their deep investment in the existing code makes them the fastest to converge on the existing way of doing things, now with AI bolted on. The junior practitioners, the newcomers, the people who do not yet know the rules, may discover the uses of AI that the experts cannot imagine, precisely because they are not yet socialised into what the organisation already believes.

7. What March Means for Your AI Strategy

March’s work assembles into a single, uncomfortable diagnosis. Your AI strategy is probably a garbage can decision (the timing was right, the champions were available, the board wanted visible action). It is almost certainly biased toward exploitation (making existing processes faster) at the expense of exploration (discovering what AI changes about what you should be doing). It is being evaluated through the logic of appropriateness (is this what organisations like ours do?) rather than the logic of consequences (will this produce the outcome we need?). Your organisation is learning myopically from early successes, drawing conclusions from small samples, favouring proximate results, and ignoring the distant consequences. And your most experienced people, the ones you have put in charge of AI adoption, are the most likely to be caught in the competency trap.

None of this means your AI strategy is wrong. It means it is normal. March’s contribution is not to prescribe a better decision process. It is to describe how decisions actually happen in organisations and to suggest that the gap between how we decide and how we think we decide is itself the thing most worth understanding.

Beer’s POSIWID applies: the purpose of your AI strategy is what it does, not what the strategy document says. If it accelerates exploitation while starving exploration, that is its purpose. If it rewards fast learners who converge on the existing code while marginalising the slow learners who maintain diversity, that is its purpose. The first act of intelligence, March would say, is to see the system as it is, not as the strategy deck describes it.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Audit your AI portfolio for the exploitation trap.

List every AI initiative your organisation has funded. For each one, ask: does this make us better at what we already do (exploitation), or does it help us discover what we should be doing instead (exploration)? Count the ratio. If it is more than 4:1 in favour of exploitation, you are in the trap March described. You are using AI to converge faster on your current strategy. The antidote is not to stop exploiting; it is to fund at least one initiative whose purpose is structured foolishness: an experiment with no predetermined ROI, a small team given permission to discover something nobody asked for, a bet whose value cannot be calculated in advance because the thing it might find does not yet have a name.

Further Reading

James March: Exploration and Exploitation in Organizational Learning - The most cited paper in organisational learning. The exploration-exploitation tension, the competency trap, and the model of mutual learning between individuals and organisational code. Full text freely available as PDF via NTNU.

Michael Cohen, James March, and Johan Olsen: A Garbage Can Model of Organizational Choice - The formal model of decision-making in organised anarchies. Four streams, no rationality, and a description of organisational decision-making that most practitioners find uncomfortably accurate.

James March: A Primer on Decision Making: How Decisions Happen - The most accessible single volume. Covers bounded rationality, the garbage can, exploration and exploitation, and the technology of foolishness in clear, often witty prose. Start here.

James March: The Technology of Foolishness - The short essay arguing that organisations need structured playfulness to discover preferences they do not yet know they have. The theoretical justification for experimentation before business cases. Freely available.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

This is the story of AI-augmented development in many enterprises right now. The implementation is fast. Some decisions are absent. And the decisions are all that matter, because every module boundary, every interface, every contract between components is a choice about what to reveal, what to hide, what to promise, and what to defer. The object-oriented design tradition spent six decades proving this. Their conclusion is the Deciding phase hypothesis arrived at from the opposite direction:

Design is a sequence of decisions under constraint, and no amount of generated code changes what the decisions are or who must make them.

1. The Simulation Premise: Describing the World in Code

The story begins in Norway in the early 1960s. Ole-Johan Dahl and Kristen Nygaard, working at the Norwegian Computing Center, needed to simulate complex systems with concurrent processes. Their solution was Simula, the language that introduced classes, objects, inheritance, and virtual procedures. The concepts were not invented as programming conveniences. They were invented as modelling necessities. Nygaard’s insight was that the concepts needed to describe a system should be the concepts used to program its simulation.

This was a radical philosophical wager: that the structure of software could mirror the structure of reality. An object in the programme corresponded to an entity in the world. A class described a kind of thing. Inheritance expressed the relationship between kinds. The simulation was not a metaphor for the system; it was a description of it.

Every subsequent object-oriented thinker inherited this wager and progressively qualified it. The history of OO design is a history of deepening scepticism about what software can and cannot describe, and under what conditions. Each generation added a constraint. The accumulation of constraints is what turned a programming paradigm into a decision discipline. And the constraints map, with uncomfortable precision, onto the problems this series has been diagnosing from the organisational side.

2. Messaging and Autonomy: Kay’s Biological Metaphor

Alan Kay, working at Xerox PARC in the 1970s, took Dahl and Nygaard’s objects and reimagined them through a biological lens. Objects were not data structures. They were autonomous agents, like cells, each containing its own state and process, communicating only through messages. The sender could not know or control what happened inside the receiver. Kay later said he regretted coining the term “objects” because it focused attention on the lesser idea. The big idea was messaging.

This matters for decisions because messaging creates genuine autonomy. If objects interact only through messages, then each object’s internal decisions are hidden from every other. The system’s behaviour emerges from the pattern of messages, not from any central plan. Kay was describing, in software, what Beer would recognise as a viable system: autonomous units coordinating through defined channels, each managing its own variety internally.

Kay’s wager was that the messaging metaphor could describe any system because it mirrors how complex systems actually work. Not representation (objects look like things) but interaction (objects communicate like organisms). The organisational parallel is immediate: the question is not what your teams contain but how they communicate, and whether the communication channels create autonomy or dependency. Conway formalised this. Kay built the programming model that makes it visible.

3. The Secret Inside the Module: Parnas and Information Hiding

David Parnas, writing in 1972, asked a question that seems simple and is not: on what criteria should you decompose a system into modules? The conventional answer was to follow the processing steps. Parnas’s answer was different: each module should hide a design decision. The interface reveals what other modules need to know. Everything else is secret.

This is not just data hiding. It is decision hiding. The question is not “what data does this module store?” but “what decision does this module encapsulate?” Two systems can be identical in runtime behaviour and radically different in modular structure. The modular structure determines what can change independently, what can be developed in parallel, and what can be understood without understanding everything else.

Parnas’s insight connects directly to Simon. Simon argued that complex systems must be nearly decomposable to be manageable: strong interactions within modules, weak interactions between them. Parnas provides the criterion for where to draw the boundaries: at design decisions that are likely to change. Evans operationalises the same principle at the domain level: each bounded context hides its domain model behind a boundary, and what crosses the boundary is the contract, not the model.

For AI transformation, Parnas’s insight is the one that bites hardest. AI can generate implementations with extraordinary speed. It cannot decide what to hide. Every module boundary is a judgment about what will change, what should be isolated, and what other teams need to know.

That judgment SHOULD be the human contribution, and no amount of generated code substitutes for the judgement of the appropriate service boundaries.

4. The Abstraction Guarantee: Liskov and Substitutability

Barbara Liskov, one of the first women to earn a PhD in computer science in the United States, spent decades at MIT formalising what it means for one component to be safely substitutable for another. Her Liskov Substitution Principle (1987) states that if S is a subtype of T, then objects of type T can be replaced with objects of type S without altering the correctness of the programme. This is not a syntactic rule. It is a semantic guarantee: the replacement must honour the original’s behavioural contract.

Liskov added a constraint the earlier thinkers lacked: the history constraint. The pattern of state changes in a subtype must be consistent with the supertype’s possible histories. You cannot simply match the interface. You must match the behaviour over time. This is the most rigorous position in the OO tradition: world-description through provable correctness.

The organisational parallel is the promise that teams make to each other. When one team replaces a service, the consuming teams should not break. That requires not just interface compatibility but behavioural compatibility: the new service must honour the same contracts under the same conditions over the same time horizons. Liskov showed that this guarantee is not a matter of goodwill. It is a matter of formal discipline. Without it, every substitution is a gamble.

5. Making the Rules Explicit: Meyer’s Design by Contract

Bertrand Meyer, working independently from Liskov, arrived at the same formal structure from a different direction. His Design by Contract (1986) uses a business metaphor: software components interact like parties bound by a contract. Every interaction has preconditions (what the caller must provide), postconditions (what the supplier guarantees), and invariants (what must always hold). Contracts are not documentation. They are executable, checkable specifications embedded in the code.

Meyer’s position is Popperian: a correct programme is one whose claims about its own behaviour are falsifiable and have not been falsified. The contract defines the boundary of correct behaviour. Code outside this space is by definition defective. This connects to Argyris more directly than any other OO thinker. Argyris showed that the governing variables controlling organisational behaviour are invisible until someone makes them explicit. Meyer showed the same thing in software: the assumptions governing component interaction are invisible until they are formalised as contracts. In both cases, making the implicit explicit is the precondition for change.

Meyer acknowledged that not all contracts can be fully formalised. Some aspects of what a component should do can only be stated in natural language. But the aspiration is to formalise as much as possible, because every formalised constraint is one fewer hidden assumption waiting to fail in production.

6. Responsibility Before Structure: Wirfs-Brock’s Behavioural Turn

Rebecca Wirfs-Brock inverted the conventional approach to object design. Before her 1989 OOPSLA paper, the dominant method was data-driven: identify the entities, define their attributes, then add behaviour. This was entity-relationship modelling dressed in object-oriented syntax, and it produced static, anaemic systems. Wirfs-Brock started from the other end: what is this object responsible for? What does it do, not what does it contain?

Her metaphor was explicitly organisational. A software system is like a community. Each object has a role, duties, and collaborators. Design is the process of assigning responsibilities to the right objects and defining the collaborations between them. The pattern of collaboration, who talks to whom about what, defines the architecture.

Beer would recognise this instantly: the viable system is defined not by its components but by the relationships between them. Conway would add that the collaboration pattern will mirror the communication structure of the team that built it. Wirfs-Brock showed that the same principle operates inside the software: the system’s architecture is its collaboration structure, and designing the collaboration is the real design problem.

7. The Trajectory of Scepticism

Grady Booch, whose textbook defined OO analysis and design for a generation, framed the entire tradition as a response to complexity. The object model (abstraction, encapsulation, modularity, hierarchy) exists not because it mirrors the world but because it mirrors how the human mind manages what it cannot hold all at once. This is Simon’s bounded rationality applied to software: no one can hold the whole system in their head, so the decomposition strategy is the design.

The trajectory from Dahl and Nygaard to Evans (already covered in this series) is a trajectory of deepening scepticism. Each generation said: you can describe the world in software, BUT only through messages (Kay), BUT only by hiding what changes (Parnas), BUT only with behavioural guarantees (Liskov), BUT only with explicit contracts (Meyer), BUT only through responsibility-based collaboration (Wirfs-Brock), BUT only by managing complexity hierarchically (Booch), BUT only within bounded contexts with ubiquitous language (Evans). The accumulation of “buts” is the discipline’s intellectual maturation.

Every one of these constraints is a decision. What to hide. What to promise. Where to draw boundaries. How to allocate responsibility. Which aspects of the world to describe and which to deliberately ignore. The OO tradition proved empirically what Simon theorised: design is not implementation. It is the sequence of decisions that determines what the implementation can be. AI can now handle the implementation at extraordinary speed. The decisions remain exactly as hard as they were in 1972, when Parnas first showed that the criteria for decomposition were more important than the decomposition itself.

8. What This Means for Your AI Transformation

Every thinker reviewed here was solving an organisational problem disguised as a technical one. Dahl and Nygaard asked: how do teams communicate about systems? Kay asked: how do autonomous agents coordinate? Parnas asked: how do teams work independently? Liskov asked: how do you guarantee that replacing one component with another will not break the system? Meyer asked: how do you make the rules of collaboration explicit? Wirfs-Brock asked: how do you design a system as a community? Booch asked: how do you keep the whole thing comprehensible?

These are not software questions. They are the questions this entire series has been asking from the organisational side. The convergence is not a coincidence. It is evidence that the Deciding phase hypothesis is correct: decisions are design challenges, and design is a sequence of decisions under constraint. The software tradition and the management tradition arrived at the same conclusion independently, over the same decades, from opposite directions.

AI-generated code does not change this. It accelerates implementation. It does not accelerate the judgment about what to implement, where to draw the boundaries, what to hide, and what to promise. The organisation that treats AI as an implementation accelerator while investing in the decision discipline will build systems that endure. The organisation that treats AI as a substitute for design decisions will generate code faster than it has ever generated technical debt.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Ask “what is this module hiding?” before you ask “what does this module do?”

Take one AI-generated component your team has recently built. Identify the design decisions embedded in it: where are the boundaries? What information is hidden behind each interface? What contract does each interface promise to its consumers? If your team cannot answer these questions, the component is not designed; it is merely implemented. Before generating the next component, write down the three decisions it must encapsulate. Then generate. The decisions come first. They always did.

Further Reading

David Parnas: On the Criteria To Be Used in Decomposing Systems into Modules (Communications of the ACM, 1972). The foundational paper on information hiding. Twelve pages that changed how software systems are structured. Freely available.

Bertrand Meyer: Object-Oriented Software Construction - The definitive statement of Design by Contract and the most rigorous treatment of what correctness means in object-oriented systems.

Rebecca Wirfs-Brock and Alan McKean: Object Design: Roles, Responsibilities, and Collaborations - Responsibility-driven design as an alternative to data-driven modelling. The organisational metaphor applied to software.

Grady Booch: Object-Oriented Analysis and Design with Applications - The standard textbook. The complexity argument and the four fundamentals of the object model.

Alan Kay: The Early History of Smalltalk - Kay’s own account of how objects, messaging, and the Dynabook vision emerged. Freely available.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

If you have sat in that room, you know it was not a failure of information or process. It was a failure of developmental capacity. The room was full of talented professionals who could not do what the situation demanded: hold a position that contradicted the consensus, evaluate competing options against self-authored criteria, and commit to structural change that would make colleagues uncomfortable. Robert Kegan, the developmental psychologist who spent four decades at the Harvard Graduate School of Education, has the structural explanation for why. Most adults have not developed the complexity of mind that genuine decision-making requires. And most organisations are designed to make sure they never do.

1. Why Agreement Is Not Decision

Kegan’s framework, introduced earlier in this series, describes five orders of mental complexity, each representing a qualitatively different way of constructing meaning. Order 1, the Impulsive Mind, is governed by impulses and perceptions; the child is their experience. Order 2, the Imperial Mind, is governed by needs and interests; the person can reflect on impulses but is embedded in their own desires, seeing other people instrumentally. Around 6% of adults remain primarily here. Order 3, the Socialised Mind, is governed by interpersonal relationships and the expectations of valued others; the person can reflect on their own needs but is embedded in their social environment. Order 4, the Self-Authoring Mind, is governed by an internal system of values; the person can reflect on relationships and social expectations but is embedded in their own ideology. Order 5, the Self-Transforming Mind, can hold even its own value system as an object of scrutiny, seeing across multiple frames without needing to resolve them. Development moves through these orders sequentially, but it is not age-determined; adults at any age may be at different stages, and most spend significant time in transitions.

For professional decision-making, three orders matter. The Socialised Mind (Order 3) constructs meaning through the expectations of the boss, the team, the profession. Roughly 46% of adults operate here, with a further 12% below. The Self-Authoring Mind (Order 4) has an internal compass and can generate independent evaluations; approximately 35% of adults reach this stage. The Self-Transforming Mind (Order 5) can integrate contradictions and see the limits of its own framework; less than 1% of adults operate here. The critical gap: most modern professional work demands Order 4 capacity, but the majority of adults are at Order 3 or in the transition between the two.

The implication for decisions is devastating. An Order 3 professional in a strategy meeting does not make a decision. They read the room. They detect what the senior voices favour, what the group seems to be coalescing around, what would be safest to endorse. They do this not out of cowardice but because their meaning-making is constituted by those social signals. Asking an Order 3 mind to override the consensus is not asking them to be brave. It is asking them to dismantle the structure through which they understand the world. They will not do this, and calling it a “culture problem” misses the point entirely.

A room full of Order 3 professionals produces consensus. It does not produce decisions. Decisions require someone to evaluate options against criteria they have authored themselves, to accept that reasonable people may disagree, and to commit knowing that the commitment forecloses other paths. That is Order 4 work. Most steering committees are staffed by people whose developmental capacity has not been assessed, whose meaning-making has never been examined, and whose agreement is mistaken for commitment every single week.

Simon argued that all decision-making is bounded: limited information, limited computation, limited time. Satisficing, choosing the first option that meets your criteria, is rational under these constraints. But Kegan exposes a prior constraint Simon did not name. You cannot satisfice if you cannot author your own criteria. An Order 3 professional does not satisfice; they conform. They adopt the criteria of whoever holds authority in the room. The decision looks satisficed. It is actually socialised. And the difference matters enormously, because a socialised decision will be abandoned the moment the social signal changes.

2. The Hidden Veto: Immunity to Change in Strategic Decisions

Kegan and Lisa Laskow Lahey’s immunity map, a four-column diagnostic of why willing people fail to change, is usually applied to individual behaviour. But it works at the level of strategic decisions too, and when you apply it there, the results are uncomfortable.

Column 1: “We are committed to investing decisively in AI.” Column 2: what the organisation actually does instead. It launches pilots that never scale. It commissions studies that delay action. It creates governance processes that require so many approvals that experimentation is functionally impossible. Column 3: the hidden competing commitments. “We are also committed to not making a bet that could fail visibly.” “We are committed to not being the executive team that wasted the AI budget.” “We are committed to not disrupting the relationships with the business units that fund us.” Column 4: the big assumptions. “We assume that a visible failure will be career-ending. We assume that the organisation punishes risk more than it rewards learning. We assume that the safe path is to invest enough to show effort but not enough to produce exposure.”

These assumptions are not irrational. In most enterprises, they are empirically correct. The immunity is not a bug; it is an accurate reading of the actual incentive structure. Taleb would recognise the dynamic immediately: the organisation has designed a system that is fragile to initiative. Any individual who bets and loses is punished; any individual who delays and waits is rewarded with survival. Via negativa applies. The obstacle to decisive AI investment is not the absence of courage. It is the presence of a punishment structure that makes decisive investment irrational for any individual decision-maker. Until you remove that, no amount of strategy will produce commitment.

Boyd’s OODA loop requires something Kegan makes explicit: the capacity to destroy your existing orientation and build a new one. That is a Subject-to-Object move. The orientation that worked last year, the assumptions about what the market rewards, what customers value, what the technology can do, must become visible before it can be reconstructed. But if that orientation is Subject to the leadership team, if it is the lens through which they see rather than an object they can examine, then the “Orient” step in Boyd’s loop is blocked. The organisation cycles through Observe-Decide-Act without ever genuinely reorienting. It gets faster at doing the same thing. Boyd called this a death spiral. Kegan explains the developmental mechanism that produces it.

3. The Order 3 Organisation: How Structure Enforces the Ceiling

Organisations are not developmentally neutral. They are designed, usually without anyone noticing, to operate at a particular order of mind. Most large enterprises are Order 3 organisations. Their structures reward alignment, penalise dissent, and treat consensus as evidence of good leadership.

Consider the signals. Performance reviews evaluate “collaboration” and “stakeholder management,” which in practice mean “did you keep everyone comfortable?” Promotion criteria include “executive presence,” which often means “did you read the room correctly and position yourself accordingly?” Strategy processes demand “alignment” before action, which means no decision survives contact with a dissenting senior leader. Every one of these signals tells the Order 3 professional: your job is to socialise, not to author. The organisation says it wants independent thinkers. Its incentive structure selects for sophisticated conformists.

Beer’s Viable System Model requires each operational unit to exercise autonomy within agreed constraints, with variety attenuated at the boundaries rather than crushed at the centre. Kegan shows why this is so hard to implement. Autonomy requires Order 4 capacity: the ability to generate independent judgments about what your unit should do, even when those judgments conflict with what the hierarchy expects. An Order 3 manager running an “autonomous” unit will default to checking with the centre before acting, not because they lack authority but because their meaning-making requires external validation before a decision feels real. The Viable System Model on paper; a command-and-control organisation in practice.

Conway showed that you ship your org chart. Kegan adds: your org chart ships your developmental ceiling. If the structure rewards Order 3 behaviour, it will produce Order 3 decisions. If it rewards Order 3 decisions, it will attract and retain Order 3 leaders. The loop is self-reinforcing. An organisation that wants better decisions must change its structure, not exhort its people.

4. What AI Makes Visible

AI adoption is not the cause of the developmental mismatch. It is the thing that makes the mismatch impossible to ignore.

Before AI, an Order 3 professional could navigate most situations by reading social cues and aligning with established practice. The existing playbook was sufficient. The pace of change was slow enough that consensus and correct action overlapped most of the time. AI breaks this. The technology changes what is possible faster than social consensus can form around what to do. By the time the team has agreed on an approach, the tools have moved on. By the time governance has approved an experiment, three better experiments have become available.

This means AI transformation systematically demands the one thing Order 3 minds cannot provide: independent judgment in the absence of established consensus. There is no established best practice for how a legal team should use large language models. There is no settled professional consensus on how AI changes the role of a software architect. There is no authority to defer to, because the authorities are as uncertain as everyone else. The Order 3 professional in this situation does not freeze from fear. They freeze from a structural inability to generate a position without a social anchor.

Kahneman showed that humans are predictably irrational, subject to biases that distort judgment. Klein showed that expert intuition compensates in high-validity environments. Kegan adds a layer beneath both: the developmental capacity that determines whether a person can even access their own judgment independently, or whether their “judgment” is actually a sophisticated recitation of what the group appears to believe. No amount of debiasing helps if the mind producing the judgment cannot operate independently of its social environment. You are not correcting bias. You are asking for a capacity that has not yet developed.

5. Growing Minds, Not Just Skills

Kegan’s most practical idea for the Deciding phase is not the DDO, which remains demanding and rare. It is the insight that development from Order 3 to Order 4, the transition from socialised to self-authoring, can be supported by specific organisational practices.

The first practice is making assumptions visible. The immunity map is the tool. Run it on a stalled decision, not on an individual’s behaviour. Surface the hidden competing commitments that prevent the leadership team from committing. Name the big assumptions. Write them on the board. The act of making them visible is itself a developmental intervention, because it takes something that was Subject (invisible, controlling) and makes it Object (examinable, testable). Argyris called this surfacing the theory-in-use. Kegan explains why the surfacing itself changes the system.

The second practice is designing for dissent. If the organisation rewards alignment, it selects for Order 3. If it structurally requires people to argue against the emerging consensus, it creates conditions for Order 4 development. This does not mean artificial devil’s advocacy. It means evaluation criteria that require decision-makers to articulate what they would lose by choosing the preferred option. It means promotion processes that reward the quality of someone’s reasoning, not the popularity of their conclusions. It means leaders who model the capacity to hold a minority position without treating it as a crisis.

The third practice is Taleb’s barbell applied to development. Protect the core operations (let the Order 3 organisation keep the lights on; it is genuinely good at this) while creating small, safe spaces where people can practise self-authoring: making independent judgments, testing them against reality, surviving the discomfort of disagreeing with people they respect. These are not innovation labs. They are developmental environments. The output is not a product. It is a more complex mind.

Ackoff would call this dissolving the problem rather than solving it. The problem is not “how do we get better decisions from our current people?” The problem dissolves when you redesign the organisation so that the conditions for developmental growth are present, and the people develop the capacity to decide. You do not solve a developmental mismatch with better decision frameworks. You dissolve it by growing the minds the frameworks require.

6. The Decision Your Organisation Has Not Made

Every organisation that undertakes a transformation is making an implicit bet about the developmental capacity of its people. Most organisations make this bet without knowing they are making it. They assume that smart people with good information will make good decisions. Kegan’s research says this assumption is structurally wrong. Smart people with good information whose meaning-making is socialised will make consensus decisions dressed up as strategic ones.

The decision your organisation has not made is whether it is willing to invest in developing the complexity of mind that genuine decision-making requires. Not training. Not workshops. Not leadership offsites with personality assessments and trust falls. Developmental work: making the invisible visible, supporting the discomfort of holding independent positions, building structures that reward self-authoring rather than sophisticated conformity.

This is the bridge between deciding and building. You cannot build what you cannot decide to build. And you cannot decide what your developmental capacity will not let you decide. The organisation that wants to build differently must first develop the capacity to choose differently. Everything else is performance.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Surface the hidden commitment behind your stalled strategy.

Pick the AI decision your leadership team has been circling for months without committing. Write it as a Column 1 commitment: “We are committed to...” Then list what the organisation actually does instead (Column 2). Now ask: if we imagine doing the opposite of those Column 2 behaviours, what feels most dangerous? Write those fears as hidden commitments (Column 3). Finally, name the assumptions that make those hidden commitments feel necessary (Column 4). You will find that the decision is not stalled because of insufficient data or unclear strategy. It is stalled because the organisation is simultaneously committed to acting and to not bearing the consequences of action. Name the assumption. Test it. That is how the immunity breaks.

Further Reading

Robert Kegan and Lisa Laskow Lahey: Immunity to Change: How to Overcome It and Unlock the Potential in Yourself and Your Organization - The full immunity map diagnostic and the developmental theory behind it. Chapter 9, the step-by-step exercise for running your own immunity map, is freely available from Minds at Work.

Robert Kegan and Lisa Laskow Lahey: The Real Reason People Won’t Change (Harvard Business Review, November 2001). The original article introducing competing commitments. Short, sharp, and still the best entry point.

Robert Kegan and Lisa Laskow Lahey: An Everyone Culture: Becoming a Deliberately Developmental Organization - The DDO concept and the argument that organisations prosper when they align with people’s strongest motive to grow. The three case studies (Bridgewater, Next Jump, Decurion) are worth reading regardless of whether you adopt the full model.

Jennifer Garvey Berger: Changing on the Job: Developing Leaders for a Complex World - The most accessible practitioner account of Kegan’s developmental stages applied to leadership. Start here if you want application, not theory.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

The big idea: any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.

If three teams build a compiler, you get a three-pass compiler. If four departments own the customer journey, the customer experiences four handoffs. If your AI platform team sits in a different reporting line from the teams that are supposed to use it, the platform will be designed around what the platform team finds interesting, not around what the users need. This is not a management failure. It is a structural inevitability. Conway showed that the very act of organising a design team means that certain design decisions have already been made, explicitly or otherwise. The class of designs available to you is constrained by the communication paths that exist. Designs that require communication across paths that do not exist cannot emerge.

1. The Homomorphism: Why This Is Not a Metaphor

Conway’s original paper described the relationship between organisational structure and system structure as a homomorphism: a structure-preserving mapping. This is precise language from mathematics, not a loose analogy. The communication graph of the organisation maps onto the module graph of the system. Where teams must coordinate, system components will have interfaces. Where teams do not communicate, system components will not integrate. Where communication is expensive (across time zones, across reporting lines, across organisational boundaries), interfaces will be thick, formal, and slow. Where communication is cheap (within a team, across a shared desk, in the same Slack channel), interfaces will be thin, informal, and fast.

The practical consequence is that you cannot design a system architecture without simultaneously designing (or inheriting) an organisational architecture. And the reverse is equally true: every organisational restructuring is an architectural decision, whether anyone treats it as one or not.

This is where Conway meets the rest of the series. Simon argued that organisations are nearly decomposable systems: tightly coupled within modules, loosely coupled between them. Conway shows where the module boundaries come from. They come from the communication boundaries in the organisation. Evans argued that bounded contexts, the boundaries within which a domain model is consistent, are the critical architectural decision. Conway shows that those boundaries will mirror team boundaries unless you deliberately design otherwise. Beer’s Viable System Model requires each operational unit to be autonomous, with coordination mechanisms (System 2) preventing autonomous units from shaking the system apart. Conway shows the mechanism by which this happens: the interfaces between teams become the interfaces between system components. If coordination is absent, integration is absent. If coordination is overbearing, coupling is tight and autonomy is crushed.

2. The Design Decision You Already Made

Conway’s most underappreciated insight is not the law itself but what follows from it. The initial stages of any design effort, he observed, are concerned more with structuring the design activity than with the system itself. The very act of assigning teams to tasks determines which designs are possible and which are not. You have made your most consequential architectural decisions before anyone writes a line of code or draws a system diagram.

Consider a common pattern. An enterprise creates an “AI Platform Team” and several “Business Unit AI Teams.” The platform team reports to the CTO. The business unit teams report to their respective business leads. The communication path between them runs through two separate reporting lines that converge, if they converge at all, at an executive committee. Conway’s Law predicts the outcome with mechanical precision: the platform team will build a platform that reflects its own priorities, the business teams will build solutions that reflect theirs, and the interface between them will be exactly as clumsy as the communication path that connects them. No amount of governance, no number of steering committees, no weekly alignment meetings will override the structural reality. The communication structure is the design.

Bourdieu would recognise what is happening. The habitus of the platform team, the embodied dispositions, technical preferences, and professional identities formed through years of infrastructure work, generates a particular kind of system. The habitus of the business team generates another. These are not failures of communication. They are the structural reproduction of professional identity through system design. The org chart is not just a reporting structure. It is a description of which designs can exist.

3. The Reverse Conway Manoeuvre: Designing Your Way Out

If the law is a constraint, it is also a tool. The reverse Conway manoeuvre, popularised by Skelton and Pais in Team Topologies, says: define the architecture you want, then design the team structure that will produce it. Do not accept the architecture your current structure generates. Redesign the structure to generate the architecture you need.

This sounds simple. It is extraordinarily difficult, because it requires treating team design as architecture work and reorganisation as refactoring. Most organisations treat team structure as an HR concern and system architecture as an engineering concern. Conway’s Law says they are the same concern. Every team boundary is a system boundary. Every reporting line is a coupling decision. Every matrix structure is an integration pattern. If you would not accept accidental coupling in your code, you should not accept accidental coupling in your organisation.

Boyd’s destruction and creation applies here directly. To adopt the reverse Conway manoeuvre, you must first destroy the assumption that organisational design and technical design are separate disciplines. The mental model that keeps them apart, one the province of “the business,” the other the province of “technology,” is precisely the kind of closed orientation that Boyd showed leads to strategic failure. The organisation that treats reorganisation as an HR initiative and architecture as an engineering initiative has ensured that neither can succeed, because each is constrained by the other.

4. Cognitive Load: The Hidden Constraint

Skelton and Pais extend Conway with a concept that every engineer has experienced and few organisations measure: cognitive load. Every team has a finite capacity for the complexity it can handle. When a team is responsible for too many things, for too many services, too many integrations, too many domains, everything degrades. Not because the people are incompetent, but because the human capacity for holding complexity in working memory is bounded. Simon would call this a consequence of bounded rationality applied to team design. The team satisfices, not because it lacks ambition, but because its cognitive budget is exhausted.

The implication for AI is direct. Adding AI capabilities to a team that is already at cognitive capacity does not produce AI adoption. It produces overload. The team will either ignore the new capability, implement it superficially, or burn out trying to absorb it alongside everything else. Taleb would recognise this as fragility: the system is already at its stress limit, and the additional load becomes the stressor that breaks it. Via negativa applies: instead of adding AI to an overloaded team, remove something from the team’s scope to create the cognitive space for AI to be learned and used.

5. What AI Changes About Conway’s Law

Conway’s Law assumes that systems are designed by humans communicating with other humans. AI changes the communication structure. An engineer working with an AI coding assistant has, in effect, a new team member whose communication bandwidth is unlimited but whose understanding of organisational context is zero. The AI does not know which team owns which service. It does not know the unwritten rules about which databases are off-limits. It does not know the political history that explains why the billing system was never integrated with the customer system. It will happily generate code that crosses every organisational boundary the human developer has spent years learning to respect.

This means AI can either reinforce Conway’s Law or disrupt it. If AI tools are deployed within existing team boundaries, they will accelerate the production of the architecture those boundaries generate: faster delivery of the same structural pattern. If AI tools are deployed in ways that enable communication across boundaries that previously did not exist, such as generating integration code between systems owned by different teams, or producing documentation that makes one team’s domain model accessible to another, they can create new communication paths and therefore new design possibilities.

But here is the catch. Those new communication paths are virtual. They exist in the code the AI generates, not in the organisational relationships between the people who must maintain that code. Conway’s Law does not say systems mirror how people should communicate. It says systems mirror how people do communicate. AI-generated integrations that cross team boundaries without corresponding human relationships will become the seams where the system fails: the code nobody owns, the interface nobody maintains, the integration that works until it does not and no one knows how to fix it.

Ackoff would diagnose this as doing the wrong thing righter. Using AI to generate cross-boundary integrations without redesigning the team structure is solving a coordination problem with technology when the actual problem is organisational. The mess persists because the interactions between teams have not been addressed; you have merely papered over them with generated code.

6. The Org Chart as Architecture Document

The practical implication is uncomfortable but unavoidable: your org chart is your most important architecture document. Not your system diagram. Not your domain model. Not your API catalogue. Your org chart. Because your org chart determines which communication paths exist, which determines which designs are possible, which determines which systems get built.

If you want a different system, you need a different org chart. Not a different strategy document. Not a different governance framework. A different communication structure that makes the design you want structurally possible.

Beer’s POSIWID applies with full force: the purpose of your organisational structure is what it produces. If it produces siloed AI implementations that do not integrate, that is its purpose. If it produces a platform nobody uses, that is its purpose. If it produces an architecture that mirrors five reporting lines and three geographies, that is its purpose. You can write any strategy you like. Conway’s Law says you will ship your org chart.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Draw your AI architecture from your org chart, not your design documents.

Take the teams involved in your AI transformation. Draw their actual communication paths: who talks to whom, how often, through what channels, across what reporting lines. Now draw your target AI architecture. Overlay them. Where the architecture requires integration between components whose owning teams have no regular communication path, mark those interfaces in red. Those are the interfaces that will fail, not because of technology, but because of Conway’s Law. For each red interface, you have a choice: redesign the team structure to create the communication path, or redesign the architecture to respect the team structure. What you cannot do is leave both unchanged and expect the system to work.

Further Reading

Melvin Conway: How Do Committees Invent? - The original paper. Forty-five paragraphs, with the thesis in the third-last one. Conway himself notes this with amusement. Read it for the homomorphism argument and the observation that organising the design team is itself a design decision. Freely available on Conway’s website.

Matthew Skelton and Manuel Pais: Team Topologies: Organizing Business and Technology Teams for Fast Flow - The practical application of Conway’s Law to modern software delivery. The four team types, the three interaction modes, cognitive load as the primary constraint, and the reverse Conway manoeuvre. The most directly useful book for anyone reorganising teams around AI.

Fred Brooks: The Mythical Man-Month: Essays on Software Engineering - The book that named Conway’s Law. Brooks’s own contribution, that adding people to a late project makes it later, is itself a consequence of Conway’s observation: more people means more communication paths, which means more complex system structure.

Ruth Malan and Dana Bredemeyer: Conway’s Law - A rigorous analysis of the implications for enterprise architecture. The argument that architecture and organisational design must be treated as a single discipline.

Disclaimer

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

But Boyd’s framework carries a hidden assumption: that the environment, however fast-moving, is knowable in principle. Orient accurately enough, cycle fast enough, and you will stay ahead. Nassim Nicholas Taleb spent five volumes and twenty-one years as a derivatives trader demonstrating that this assumption is false. Not occasionally false. Structurally false. The domains in which organisations make their most consequential decisions are dominated not by the events their models can anticipate but by the events their models cannot. The question is not how fast you can orient. It is what you do when the thing that happens is the thing your orientation did not prepare you to see.

1. The Turkey Problem: Why Your AI Business Case Is a Confidence Trick

Taleb’s most vivid illustration is the turkey. A turkey is fed by a butcher every day for 1,000 days. Each day of feeding increases the turkey’s statistical confidence that butchers love turkeys. The turkey’s confidence is at maximum on day 1,000. Day 1,001 is Christmas.

The point is not that bad things happen. The point is that the turkey’s model was built from the same data that produced the catastrophe. Every observation confirmed the model. The model was perfectly consistent with the evidence. And the model was lethally wrong, not because the data was bad but because the domain was one in which past data does not predict the future in the ways that matter most.

Taleb divides the world into two domains. Mediocristan is governed by bell curves: height, weight, daily calorie intake. No single observation can dramatically change the aggregate. Averages are meaningful. Prediction works. Extremistan is governed by power laws: wealth distribution, book sales, stock market returns, technological adoption. A single observation can dwarf all others combined. Averages are meaningless. The turkey’s problem is that it lives in Extremistan while using Mediocristan tools.

AI transformation lives in Extremistan. Your business case projects linear adoption curves. Your governance framework assumes risks are enumerable. Your roadmap forecasts three-year ROI based on current conditions. Every one of these is a bell-curve tool applied to a power-law domain. The confidence they generate is the turkey’s confidence: highest just before it becomes lethal.

2. The Fragile, the Robust, and the Antifragile

Taleb’s most important contribution is not the Black Swan. It is what comes after: the fragile-robust-antifragile triad. Fragile things are harmed by volatility: the crystal glass, the leveraged company, the transformation plan that depends on everything going according to schedule. Robust things resist volatility: the rock, the legacy system that keeps working through organisational upheaval. Antifragile things gain from volatility: bones that strengthen under stress, immune systems that improve through exposure, ecosystems where individual failures produce collective learning.

The insight is that robustness is not the opposite of fragility. Antifragility is. Most organisations aim for robustness in their AI strategies: survive the disruption, manage the risk, maintain stability. Taleb says this is the wrong ambition. The right ambition is to build an organisation that gets better because it encounters disruption.

This requires a principle that most organisations find viscerally uncomfortable: antifragility of the system requires fragility of its components. Evolution is antifragile because individual organisms die. The restaurant industry is antifragile because individual restaurants fail constantly. Startup ecosystems are antifragile because most startups collapse. The information generated by failure flows to the system level. Organisations that prevent all failure at the component level make the system fragile; they suppress the signal that failure provides. This is why zero-failure cultures do not produce zero failures. They produce catastrophic ones.

Klein showed that expert intuition works in high-validity environments with regular feedback. Taleb adds the uncomfortable corollary: in Extremistan, the feedback that matters most is the feedback you get from failure, and an organisation that has optimised failure out of its process has optimised learning out of its system.

3. Via Negativa: Stop Adding Things

Taleb borrows from apophatic theology a principle that applies directly to every AI governance framework in existence: via negativa. Improvement comes through subtraction, not addition. Knowing what is wrong is more robust knowledge than knowing what is right. You know what will kill a company with more certainty than you know what will make it successful.

The practical consequence: instead of asking “what should we add to our AI strategy?”, ask “what is currently preventing people from learning to use AI, and can we remove it?”

This connects directly to Beer’s POSIWID: the purpose of a system is what it does. Via negativa says look at what the system actually does that is harmful and remove it. The governance process that takes eight weeks to approve an experiment. The procurement policy that restricts teams to a single vendor. The training programme that teaches people about AI without letting them use it. The risk assessment that treats every novel use case as equally dangerous. These are not safeguards. They are iatrogenics: harm caused by the healer. The governance system designed to manage AI risk is, in practice, the primary obstacle to the learning that would reduce AI risk.

Ackoff would recognise this immediately. His distinction between dissolving a problem (redesigning the system so the problem no longer arises) and solving it (finding the answer within the existing system) is the systems-thinking version of via negativa. You do not need a better AI governance process. You need to remove the conditions that make the current one necessary.

4. The Barbell: How to Transform Without Betting the Company

The barbell strategy is Taleb’s answer to the question of how to act in Extremistan. Combine extreme safety with extreme speculation. Protect the core ruthlessly: keep the business running, maintain revenue, preserve capability. Simultaneously make small, cheap, reversible bets on transformative possibilities. Avoid the middle ground, where risks are hidden and returns are mediocre.

The middle ground is where most enterprise AI strategies live. Moderate investment. Moderate ambition. Moderate risk. Enough commitment to generate cost but not enough to generate learning. Enough governance to slow things down but not enough to prevent genuine catastrophe. The barbell says this is the worst position: you get harmed by Black Swans without benefiting from them.

Boyd’s destruction and creation is the barbell applied to orientation. The safe side is the organisation’s operational capability; the speculative side is the deliberate destruction and rebuilding of mental models. You cannot create a new strategic concept without first destroying the old one. The organisation that protects its current orientation while refusing to challenge it is robust at best; the organisation that treats orientation itself as something to be continuously rebuilt through contact with reality is antifragile.

Simon’s satisficing is option-compatible: you do not need the optimal AI strategy; you need a good-enough strategy that preserves your ability to change course when the environment reveals something your model did not predict. The search for the optimal strategy is itself fragile, because it assumes you can know enough to optimise.

5. Skin in the Game: Who Bears the Cost of Being Wrong?

Taleb’s final volume, Skin in the Game, extends antifragility into ethics. The principle is simple: never take advice from someone who does not bear the consequences of being wrong. The most common asymmetry in enterprise AI transformation is that the people who design the strategy (executives, consultants, governance boards) bear none of the implementation risk, while the people who must change their daily work bear all of it. This asymmetry guarantees resistance, because the people with the most at stake have the least influence on the design.

Argyris diagnosed the same pattern from a different angle: the gap between espoused theory and theory-in-use persists because the people who espouse the theory do not live with the consequences of its failure. Model II learning requires the willingness to expose your reasoning to disconfirmation, to bear the personal cost of being wrong in public. That is skin in the game applied to organisational learning.

The test for any AI transformation initiative: will the people who designed it personally experience the disruption they are imposing? Will the executive who mandated the change use the tools they are mandating? Will the consultant who recommended the strategy be present when the consequences arrive? If the answer is no, the strategy is fragile by design, because the people making the decisions have no mechanism for learning from the outcomes.

6. The Green Lumber Fallacy: What Your Experts Actually Know

A trader named Joe Siegel made enormous profits trading green lumber while believing it was lumber painted green. It is actually freshly cut, undried lumber. Meanwhile, people with sophisticated theoretical knowledge of the lumber market went bankrupt.

The green lumber fallacy is the error of mistaking the kind of knowledge that sounds important from the outside for the kind of knowledge that actually drives performance. It is rampant in enterprise AI. Organisations invest heavily in AI literacy programmes, strategic frameworks, and governance architectures while neglecting the tacit, practical knowledge that people develop through daily use. The engineer who has spent three months using AI-assisted coding tools knows things about what works that no amount of strategic planning can replicate. The customer service representative who has figured out how to use an LLM to handle edge cases has domain knowledge that the AI Centre of Excellence does not possess.

Klein’s pattern library is built through practice in high-validity environments. Taleb’s green lumber fallacy says the same thing from the other direction: the knowledge that matters is not the knowledge that sounds impressive; it is the knowledge that has been tested through contact with reality. Your AI strategy should be designed by the people who use AI, not by the people who study it.

7. What Taleb Means for the Series

Every thinker in the Deciding phase has been building a picture of what clear, effective decisions look like. Simon showed that decisions are bounded by what the organisation can see. Evans showed that precision of language determines precision of thought. Beer showed that information architecture determines what the organisation can know. Boyd showed that the speed and quality of orientation determines whether the organisation can adapt. Taleb completes the picture by insisting on what none of them quite says: that the domain in which these decisions are made is one where the most consequential events are the ones no model anticipated.

This is not fatalism. It is the opposite. Taleb’s entire project is an argument for action: not planned action based on prediction, but positioned action based on the asymmetry between what you can lose and what you can gain. Protect the downside. Create optionality on the upside. Make many small bets where failure is cheap and learning is rich. Remove what is harmful before adding what might be beneficial. Ensure that the people making decisions bear the consequences of being wrong.

Your AI transformation does not need a better forecast. It needs a structure that gets stronger when the forecast is wrong.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Run a fragility audit on your AI transformation.

Take your current AI strategy document, roadmap, or transformation plan. For every major commitment, ask three questions. First: what does this depend on being true? List every assumption about technology readiness, adoption rates, budgets, timelines, and organisational support. Second: what happens if any one of these assumptions is wrong? If the answer is “the plan fails,” the commitment is fragile. Third: who bears the cost of failure? If the people who designed the strategy do not personally experience the consequences of its failure, you have a skin-in-the-game problem that no governance framework can fix. A strategy that survives contact with these three questions is robust. A strategy that gets better because you asked them is antifragile. Most will not survive the first.

Further Reading

Nassim Nicholas Taleb: The Black Swan: The Impact of the Highly Improbable - The flagship work. Mediocristan versus Extremistan, the narrative fallacy, the ludic fallacy, and the argument that the events that matter most are the events our models cannot predict.

Nassim Nicholas Taleb: Antifragile: Things That Gain from Disorder - The positive agenda. The fragile-robust-antifragile triad, the barbell strategy, via negativa, optionality, and the green lumber fallacy. The most directly applicable Taleb book for anyone running a transformation.

Nassim Nicholas Taleb: Skin in the Game: Hidden Asymmetries in Daily Life - The ethics of decision-making under uncertainty. Why symmetry of risk-bearing is the foundation of sound decisions, and why strategies designed by people who do not bear the consequences are structurally fragile.

Nassim Nicholas Taleb: Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets - The foundational text on survivorship bias and the systematic overestimation of skill relative to luck. Where the Incerto begins.

Nassim Nicholas Taleb: Statistical Consequences of Fat Tails - The technical companion. For readers who want the mathematical foundations behind the arguments. Freely available.

Disclaimer

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

Lindblom showed that organisations muddle. Boyd asks: can you muddle faster than the problem changes? And the answer depends entirely on what sits inside the Orient phase, which is where mental models live, where they degrade, and where they must be destroyed and rebuilt if the organisation is to survive. This is the most demanding claim in the Deciding phase, because it does not merely say that decisions should be better. It says that the frames through which decisions are made must be continuously broken and remade, and that the organisation’s survival depends on its willingness to do so.

1. Orientation Is the Schwerpunkt

Boyd called orientation the schwerpunkt, the centre of gravity, of the entire OODA process. Orientation is the lens through which observations are interpreted, decisions are framed, and actions are selected. It is shaped by cultural traditions, previous experience, new information, and the process Boyd called analysis and synthesis. You see what your orientation prepares you to see. You consider the options your orientation makes visible. You dismiss the options it hides.

This is Simon’s decision premises given a dynamic engine. Simon showed that the architecture determines which premises reach which decisions. Boyd shows that the premises themselves are products of an orientation that may be stale, closed, or wrong, and that unless the orientation is continuously updated, the premises degrade. Every decision the organisation makes is only as good as the orientation that generated it.

Senge’s mental models are orientation at the individual and team level. Argyris’s theories-in-use are the defensive structures that prevent orientation from being updated. Bourdieu’s habitus is orientation made sociological: the embodied dispositions that generate practice without conscious deliberation, and that reproduce themselves precisely because they operate below awareness. Boyd adds the epistemological argument for why all of this matters urgently: closed systems degrade.

2. Destruction and Creation: Why Mental Models Must Be Broken

Boyd’s briefing paper “Destruction and Creation” (1976), the only piece of writing he considered truly his own, builds the philosophical foundation beneath the OODA loop. Drawing on Gödel’s Incompleteness Theorems (no system can fully explain itself from within), Heisenberg’s Uncertainty Principle (observation has fundamental limits), and the Second Law of Thermodynamics (closed systems tend toward entropy), Boyd argued that any mental model treated as complete will become mismatched with reality. The mismatch is not optional. It is thermodynamic.

The remedy is a continuous cycle of destructive deduction (breaking existing models into parts, severing the relationships between parts and their original domains) and creative induction (finding new connections among the scattered parts and synthesising new models). Boyd’s famous snowmobile: take skis from skiing, treads from a tank, a motor from a boat, handlebars from a bicycle. Destroy each element’s relationship to its original context. Synthesise something entirely new. This is not metaphor. It is the fundamental process of adaptation.

The series has already encountered this principle in different terms. Argyris’s double-loop learning is Boyd’s destruction and creation applied to governing variables. Ackoff’s dissolving is Boyd’s synthesis applied to messes. Popper’s conjectures and refutations is the same epistemological engine in the philosophy of science. Boyd’s contribution is the urgency: in a competitive environment, the organisation that stops destroying and rebuilding its models does not merely stagnate. It dies. The Second Law guarantees it.

3. The OODA Loop Is Not a Cycle

The common depiction of OODA as a sequential cycle (observe, then orient, then decide, then act, then repeat) is what Boyd spent years trying to correct.

His actual diagram, presented across hundreds of briefings but never formally published, shows at least five feedback paths. Orientation feeds directly into action through what Boyd called “implicit guidance and control,” bypassing conscious decision entirely. Orientation shapes observation, determining what you look for next. Action feeds back into observation, generating new data. The loop is not a loop at all. It is a set of interacting, concurrent processes with orientation at the centre of everything.

This matters for the Deciding phase because it explains why the relationship between deciding and acting is not sequential. Klein’s recognition-primed decision model, discussed earlier in the series, is Boyd’s implicit guidance and control: the expert who acts without conscious deliberation is operating on an orientation so refined that the decide phase has compressed nearly to zero. This is not recklessness. It is deep expertise. The condition for it is that the orientation must be accurate, which means it must have been continuously updated through experience in a high-validity environment (Kahneman and Klein’s two conditions for trustworthy intuition).

Beer’s VSM provides the architectural complement. Boyd describes the dynamic process of orientation and reorientation. Beer describes the structural conditions (recursion, variety management, System 4’s environmental scanning) that enable the process to operate at organisational scale. Boyd without Beer produces individual agility without systemic coherence. Beer without Boyd produces structural elegance without the engine of adaptation. The Deciding phase needs both.

4. AI Accelerates the Loop but Cannot Fix the Orientation

AI transforms every phase of the OODA loop except the one that matters most.

• Observation: AI processes data at speeds and scales no human team can match. Sensor data, market signals, customer behaviour, operational metrics: AI can observe everything, continuously, in real time.

• Decision: AI can evaluate options against defined criteria faster than any human process. Given a clear orientation and well-defined constraints, AI decision support is genuinely transformative.

• Action: AI can execute at machine speed. Automated deployment, real-time pricing adjustment, dynamic resource allocation: the act phase can be compressed almost to zero.

• Orientation: AI cannot do this for you. Orientation is where mental models live: the assumptions about what the data means, what the options are, and what success looks like. AI can enrich orientation by surfacing patterns human analysts would miss. But the destruction and creation cycle, the willingness to break the current model and build a new one, remains a human act. An AI trained on the organisation’s historical data will reproduce the organisation’s historical orientation, including its blind spots, its biases, and its outdated assumptions. Faster cycling through an inherited orientation does not produce adaptation. It produces faster repetition.

This is the trap most programmes fall into. They invest in faster observation, faster analysis, faster execution, and leave the orientation untouched. The organisation cycles faster through the same flawed understanding of its environment, producing more decisions per quarter that are all wrong in the same direction. Boyd would diagnose this immediately: you have accelerated the loop without improving the schwerpunkt. You are inside your own OODA loop, operating against a model of reality that no longer exists.

5. Einheit and the Conditions for Distributed OODA

Boyd’s organisational design principles, drawn from his study of German military doctrine, provide the conditions for scaling the OODA loop beyond the individual. The key concepts are Einheit (shared orientation across the organisation), Auftragstaktik (mission-type orders that specify intent but not method), schwerpunkt (a focal point that aligns all effort), and fingerspitzengefühl (intuitive feel developed through experience and trust).

These map directly to the series architecture. Einheit is Nonaka’s ‘BA’ at organisational scale: a shared context that enables autonomous agents to cooperate without central coordination. Auftragstaktik is Marquet’s intent-based leadership: “I intend to” replaces “permission to.” Schwerpunkt is Rumelt’s kernel: the focal point where resources are concentrated. Fingerspitzengefühl is Klein’s pattern recognition: the expert judgment that makes the decide phase nearly instantaneous.

The design implication for AI transformation:

The organisation that deploys AI effectively is not the one with the fastest models or the largest data sets. It is the one with the strongest shared orientation about what AI is for.

This means… the clearest mission-type intent that enables teams to act without waiting for central approval, and the most developed capacity to recognise when the current orientation has expired and must be destroyed and rebuilt. These are not technology problems. They are leadership problems that technology makes more urgent.

6. Boyd’s Limits

Boyd must be read with his limitations visible. His framework is optimised for competitive and adversarial environments; it is less directly applicable to cooperative, commons-based, or service contexts where the goal is not to outmanoeuvre an opponent. He underestimates political constraints: the power structures that Bourdieu and Giddens describe can prevent reorientation even when the need is obvious. And the psychological cost of continuous destruction is real. People and organisations need stability as well as adaptation. Heifetz’s holding environment, the space in which the discomfort of reorientation can be contained without overwhelming the people who must endure it, is the necessary complement to Boyd’s relentless epistemology.

Boyd never published a book. His ideas survive through briefings, a single published essay, and a handful of interpreters. The fragility of this intellectual legacy is itself a lesson: the thinker who understood tempo better than anyone could not find the time to write it all down.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Name the orientation your AI programme is operating from.

Every AI programme has an implicit model of what AI is, what it changes, and why it matters. This model was formed early, probably during the first executive briefing or vendor presentation, and it has not been revisited since. Write it down. One paragraph. Then ask: is this still true? Has the technology moved? Has the competitive environment shifted? Has the organisation learned anything from deployment that contradicts the original model? If the answer to any of these is yes, your orientation is stale, and every decision flowing from it is compromised. The first act of adaptation is admitting that your current map no longer matches the territory.

Further Reading

John Boyd: Destruction and Creation - The only essay Boyd considered truly his own. The epistemological foundation beneath the OODA loop: why mental models degrade and must be continuously rebuilt.

Robert Coram: Boyd: The Fighter Pilot Who Changed the Art of War - The definitive biography. Essential for understanding why Boyd’s ideas took the form they did and why he never wrote the book.

Grant Hammond: The Mind of War: John Boyd and American Security - The intellectual history. More focused on the ideas than the life. Read it alongside Coram.

Chet Richards: Certain to Win: The Strategy of John Boyd, Applied to Business - The most rigorous application of Boyd to business strategy. Richards was one of Boyd’s closest collaborators.

Frans Osinga: Science, Strategy and War: The Strategic Theory of John Boyd - The academic treatment. Reconstructs Boyd’s intellectual framework from the briefings and traces his sources in science, philosophy, and military history.

Disclaimer

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

Nobody notices that the platform play was the only option that was ever going to survive. The framing assumed AI adoption is an infrastructure problem. The CFO evaluated options against a payback model that treats capability investment as cost. The head of engineering assessed feasibility against the existing team structure, designed around a technology AI is about to make irrelevant. Every participant brought rigorous analysis. Every analysis operated within assumptions that were never examined, because they were never visible. The decision was made before the meeting started. The meeting was the performance of deciding, not the act.

Senge appeared in this series’ Learning phase as the systems thinker who made organisational learning accessible to practitioners. That article explored how the invisible internal representations of neural networks parallel the invisible assumptions that shape organisational behaviour. The Deciding phase requires the argument to become structural. The question is no longer whether mental models exist. It is how they function as decision architecture, how they interact with the cognitive and institutional mechanisms the series has now explored, and what a leader can do about them.

1. Mental Models as Decision Premises

Simon’s previous article in this series argued that organisations shape decisions not by controlling what people choose, but by controlling the premises that enter their choices: the facts, values, goals, and constraints that frame the decision before deliberation begins. Senge’s mental models are the invisible layer beneath even Simon’s premises. They determine which premises are admitted, which are excluded, and which are so deeply assumed that they never register as premises at all.

Consider the difference. A decision premise is something that enters a decision and can, in principle, be identified: “we assume a three-year payback period,” “we require SOC 2 compliance,” “we prioritise customer-facing use cases.” These are visible constraints. They may be wrong, but they are at least articulable.

A mental model is the structure that determines which premises are thinkable. The leadership team that evaluates AI through the lens of “infrastructure investment” has a mental model about what AI is. The premise “three-year payback” is visible. The model “AI is an infrastructure play like cloud migration” is not. It is the water the fish swims in. Every premise that enters the decision has already been filtered through it, and the filtering is invisible.

This is why Kahneman’s decision hygiene, however valuable, has a ceiling. Kahneman showed that structuring decisions reduces noise: independent assessment, aggregation of judgment, explicit criteria. But decision hygiene operates on the premises it can see. It cannot structure what it cannot identify. If the entire leadership team shares a mental model, if everyone in the room assumes AI is an infrastructure problem, then independent assessment will produce independently similar answers, and aggregation will confirm the shared assumption with statistical authority. The noise is reduced. The bias is preserved. The decision is precise and wrong.

Klein’s expert intuition has the same vulnerability. Klein showed that experts in high-validity environments have trustworthy pattern recognition. But the pattern library is itself a mental model. The senior architect whose patterns were built in a pre-AI world will recognise the current situation as something it is not. Their intuition will fire with full confidence, selecting a response calibrated to conditions that no longer obtain. Klein’s conditions for valid intuition require that the environment be regular enough for patterns to hold. Mental models persist precisely because they were once valid. The danger is not the novice who has no patterns. It is the expert whose patterns have expired but whose confidence has not.

2. The Ladder of Inference: How Decisions Climb Away from Reality

Senge’s most practical tool for understanding mental models is the ladder of inference, adapted from Chris Argyris. The ladder describes the cognitive escalation from observable data to action: select data from what is observed, add meaning, make assumptions, draw conclusions, adopt beliefs, take action. The ladder is reflexive: the beliefs at the top influence which data is selected at the bottom, creating a self-reinforcing loop. You see what your beliefs prepare you to see.

In the AI strategy meeting, the ladder operated simultaneously in every participant. The CTO selected data: vendor demonstrations, analyst reports, peer company announcements. She did not select what a domain-driven designer would have prioritised: the structure of the organisation’s business domains, the coherence of its data architecture, the specification capability of its teams. That data was not excluded deliberately. It was not visible from the rung of the ladder she was standing on. Her mental model determined what counted as relevant data, and the data she selected confirmed the model that selected it.

Argyris described this as the self-sealing quality of defensive reasoning. Senge adds the systemic dimension. In organisations, ladders synchronise. Shared culture, shared training, shared incentive structures produce shared data selection, shared meaning-making, shared conclusions. The result is collective certainty built on collectively invisible foundations. Bourdieu would recognise this immediately: the habitus of the leadership class generates perception before conscious thought begins. The ladder of inference is the cognitive mechanism; habitus is the sociological one. Together they explain why the entire leadership team can walk out confident they made a good decision when they never examined a single assumption that mattered.

3. System Archetypes as Decision Traps

Senge’s system archetypes are recurring patterns of systemic behaviour that produce predictable failures. They are not metaphors. They are structural descriptions of how reinforcing and balancing feedback loops interact to produce outcomes that surprise the people inside the system but are entirely predictable to anyone who can see the structure.

Three archetypes are operating in almost every AI transformation.

Shifting the burden. The organisation faces a problem: its teams lack the domain understanding and specification capability to direct AI effectively. The symptomatic solution is to buy a platform, hire consultants, or adopt a vendor’s framework. The fundamental solution is to build specification capability within the teams that understand the business domains. The symptomatic solution is faster, cheaper, and more legible to leadership. It also works, briefly. But each time the symptom is addressed without building the underlying capability, the capability atrophies further. The consultants leave. The platform operates on the consultants’ specifications, which the internal teams cannot maintain or evolve. Dependency deepens. The next time the problem surfaces, the gap is wider and the symptomatic solution is more expensive. This is Beer’s POSIWID in dynamic form: the purpose of the system is what it does, and what this system does is produce dependency, regardless of what it intends.

Fixes that fail. AI-generated code accelerates delivery in the short term. Teams produce more features faster. The metrics improve. Six months later, quality problems emerge: the generated code does not account for edge cases that domain experts would have caught, because the specifications that prompted the generation were too thin. The fix was not wrong. It was incomplete, and the incompleteness only became visible after the short-term gains had been reported and celebrated. The correction now requires admitting that the celebrated gains were partly illusory, which triggers exactly the defensive routines Argyris diagnosed. The fix that failed becomes the fix that cannot be discussed.

Limits to growth. AI adoption accelerates productivity until it hits a constraint: specification quality, data quality, organisational capacity to review and integrate AI output, or the human capacity to understand what they actually want. Each constraint is a balancing loop that the reinforcing loop of adoption ignores. The organisation responds to the slowdown by pushing harder on adoption (more AI, more tools, more automation) rather than investing in the constraint. Senge’s insight is that the leverage is always in the constraint, never in the accelerator. Evans would say the same thing differently: the leverage is in the domain model, not the code generation. Simon would say the leverage is in the decision architecture, not the decision speed.

4. Shared Vision or Shared Compliance

Senge drew a sharp distinction between vision that is genuinely shared and vision that is merely imposed. Compliance produces people who do what is expected. Commitment produces people who want the vision and will create whatever structures are needed. The difference is categorical, not marginal.

Most AI transformation programmes operate on compliance. The strategy is cascaded. Teams are assigned targets. The language of commitment is everywhere: “aligned,” “bought in,” “on board.” But the test is what happens when the plan meets reality and the plan is wrong. Committed people adjust the plan and keep pursuing the vision. Compliant people wait for new instructions, because the plan was never theirs.

This completes a thread running through the Deciding phase. Drucker argued that purpose must be tested against reality, not declared. Beer’s viable system requires each autonomous unit to have purposeful identity, not delegated tasks. Simon showed that compliance ensures only approved premises circulate. Senge adds: without genuine commitment, the organisation will execute the plan as specified and miss the point entirely. Evans’s knowledge crunching requires people to challenge each other’s understanding. Compliance produces polite agreement. Commitment produces the argument that reveals what the domain actually is.

5. Leverage Points: Where to Intervene

Senge borrowed from his mentor Jay Forrester the insight that in complex systems, the point of greatest leverage is almost always counterintuitive. Where common sense says “push harder,” systems thinking says “look elsewhere.” Donella Meadows extended this into a hierarchy: the least effective interventions change parameters (budgets, headcount, timelines); the most effective change the paradigm from which the system arises.

For AI transformation, the hierarchy is instructive. Most interventions target parameters: more budget for AI tools, more headcount for data science, shorter timelines for pilots. Slightly more effective: changing the rules (governance, rewards). More effective still: changing information flows (making specification quality visible, connecting AI output quality to domain understanding). Most effective: changing the mental models from which the system operates. If the leadership team’s mental model shifts from “AI automates existing work” to “AI changes what work means,” every downstream decision changes without any of them needing to be individually redesigned.

This is the structural version of the argument the series has been making since the first article. Argyris says: surface the theory-in-use. Bourdieu says: make the habitus visible. Bateson says: learn about the frame, not just within it. Senge says: find the leverage point where a small change in the model produces a large change in the system. They are all describing the same intervention at different levels of analysis.

6. The Limits of Senge

Senge must be read with two serious criticisms visible.

Stacey’s objection is the most fundamental. Stacey argues that Senge assumes a position outside the system that does not exist. The leader who “surfaces and tests mental models” is themselves embedded in mental models, shaped by the same power dynamics, defensive routines, and habitual perception as everyone else. The discipline Senge prescribes requires capacities that the conditions he diagnoses make nearly impossible to develop. Senge’s learning organisation is a design that cannot be designed, because the designer is caught in the same processes the design is meant to correct. This is a genuine and important disagreement, and it cannot be resolved by choosing one side. The practical path is to hold both: Senge is right that mental models can be surfaced and that doing so has leverage. Stacey is right that the surfacing is always partial, always political, and never innocent.

Giddens adds a structural objection. Mental models do not exist in isolation. They are embedded in structures of signification (shared meaning), domination (power), and legitimation (norms). Changing mental models without changing the power structures and norms that sustain them produces articulate people who behave exactly as before. The CTO who recognises that “AI is not an infrastructure play” but whose budget, reporting lines, and promotion criteria all assume it is will find the recognition evaporating under institutional pressure. Senge’s discipline of mental models underestimates how much institutional reinforcement those models receive.

For the Deciding phase, both critiques point to the same conclusion. Mental models cannot be addressed through workshops, offsites, or facilitated dialogue alone. They must be addressed through structural change: different information flows (Beer’s System 3*), different decision premises (Simon), different domain boundaries (Evans), and different reward structures (Drucker’s theory of the business). The invisible map will not become visible because someone asks people to look at it. It will become visible when the organisation builds the architectural capacity to generate a different view.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

At your next leadership decision meeting, before the discussion begins, ask each participant to write one sentence completing this prompt: “The assumption I am bringing to this decision that I have not tested is...” Collect them. Read them aloud. Do not debate them. Just make them visible.

Further Reading

Peter Senge: The Fifth Discipline: The Art and Practice of the Learning Organization - The foundational text. Mental models, systems thinking, shared vision, and the system archetypes. Still the best single book on why organisations reproduce the patterns they claim to want to change.

Peter Senge et al.: The Fifth Discipline Fieldbook - The practitioner companion. Contains the ladder of inference exercise, the left-hand column exercise, and detailed facilitation guides for surfacing mental models in teams. More useful than the main text for anyone who wants to do something on Monday morning.

Peter Senge et al.: The Dance of Change - Why learning initiatives stall. The ten challenges of sustaining change, organised around the growth processes and limiting processes that the system archetypes describe. Honest about how often the disciplines fail in practice.

Donella Meadows: Thinking in Systems: A Primer - The clearest introduction to systems thinking available. Meadows’s hierarchy of leverage points, from parameters to paradigms, extends Senge’s analysis and provides the framework for identifying where intervention will have the greatest effect.

Daniel Kahneman, Olivier Sibony, and Cass R. Sunstein: Noise: A Flaw in Human Judgment - Decision hygiene structures what is visible. Senge reveals what is not. Read together, they describe the full architecture of decision failure: the scatter that structure can reduce, and the shared bias that structure alone cannot reach.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

The series has spent several articles building the architecture of good deciding: Simon’s bounded rationality, Evans’s domain modelling, Beer’s viable systems, Rumelt’s strategic kernel, Kahneman’s decision hygiene. All of these assume, to varying degrees, that the organisation can achieve some form of structured clarity about what it faces and what it should do. Lindblom’s contribution is the honest admission that in most real situations, it cannot. Not because the people are incompetent, but because the problem is too complex, the values too contested, the information too incomplete, and the politics too real for any rational-comprehensive approach to work.

1. The Rational-Comprehensive Ideal and Why It Fails

Lindblom distinguished between two modes of decision-making. The rational-comprehensive method, which he called the “root” approach, requires the decision-maker to define all values and goals, identify all possible alternatives, evaluate every alternative against every value, and select the option that maximises the overall outcome. This is what strategy frameworks promise. It is what governance boards assume they are doing. It is what nobody actually does.

The root method fails for reasons Simon had already identified: bounded rationality means the decision-maker cannot process everything. But Lindblom pushed further. The failure is not just cognitive. It is political and epistemic.

In any complex organisation, people disagree about values, not just facts.

The CTO who wants to invest in platform capability and the CFO who wants to cut costs are not making an analytical error. They hold genuinely different values about what the organisation should prioritise. The rational-comprehensive method assumes these value conflicts can be resolved before analysis begins. They cannot. They are resolved, if at all, through the decision process itself.

This is the point most transformation programmes ignore. The AI strategy that claims to have aligned all stakeholders around a common vision has not resolved the value conflicts. It has suppressed them. They will resurface when deployment begins and the trade-offs become real: speed versus quality, automation versus employment, centralised control versus team autonomy. Lindblom would predict this with confidence, because value conflict is not a planning failure. It is the permanent condition of any organisation composed of people who want different things.

2. Muddling Through: The Branch Method

Lindblom’s alternative, which he called the “branch” method or “successive limited comparisons,” accepts these limits and works within them.

Instead of starting from first principles and evaluating all options, the decision-maker starts from the current situation and compares a limited set of alternatives that differ marginally from the status quo.

Values and means are adjusted together, not fixed in advance. The test of a good decision is not whether it maximises some predefined objective but whether the decision-makers can agree on it, which is a political criterion, not an analytical one.

This sounds like giving up. Lindblom argued it is the opposite: it is taking seriously the conditions under which decisions actually happen. The branch method has several properties that the root method lacks. Errors are small and reversible. Each step generates information that informs the next step. The organisation learns from actual consequences rather than from predicted consequences, which in complex environments are unreliable. And the method works even when people disagree about values, because agreement on a specific step does not require agreement on ultimate purposes.

Simon’s satisficing operates at the individual level: the decision-maker accepts “good enough” because they cannot compute “optimal.” Lindblom’s incrementalism operates at the organisational level: the organisation moves in small steps because the collective cannot agree on the destination, and even if it could, it could not predict the consequences of a large move. The two are complementary. Simon explains why the individual decision-maker muddles. Lindblom explains why the organisation muddles.

3. Mutual Adjustment: Coordination Without a Coordinator

Lindblom’s deeper insight, developed more fully in The Intelligence of Democracy (1965), is that coordination in complex systems does not require a coordinator. In pluralist systems, decisions emerge from the mutual adjustment of multiple actors pursuing their own interests. No central rational authority designs the outcome. The outcome emerges from the interaction.

This is Beer’s insight from the opposite direction. Beer designed the architecture that enables viable coordination (the VSM). Lindblom observed that coordination happens anyway, through mutual adjustment, even without the architecture. The two are not contradictory: Beer provides the design principles for when you can shape the system; Lindblom describes what happens when you cannot. Most organisations live in Lindblom’s world while aspiring to Beer’s.

The connection to Evans is sharp. Evans’s knowledge crunching is a mutual adjustment process: developers and domain experts iteratively adjust their models through dialogue until something useful emerges. Nobody starts with a complete specification. The specification emerges from successive limited comparisons between what the model says and what the domain expert recognises. Evans described a method for this. Lindblom observed that it happens naturally, and that designing it is less important than protecting it from the rational-comprehensive impulse to replace iteration with planning.

4. Three Archetypes of AI Transformation Failure

Lindblom’s framework diagnoses three patterns that recur in transformation programmes.

• The first is the grand plan that ignores value conflict. The organisation produces a comprehensive AI strategy: use cases prioritised, business cases approved, timelines committed, governance established. The strategy assumes agreement on what, for instance, AI is for. Within months, different parts of the organisation are pulling in different directions because they never actually agreed on the purpose; they agreed on a document. Lindblom would say: start smaller, test actual value in one context, and let the strategy emerge from what you learn. The document is not the strategy. The learning is the strategy.

• The second is the irreversible commitment. The organisation selects a platform, signs a multi-year contract, commits to a vendor, restructures teams around a bet that has not been tested. Lindblom’s criterion of reversibility says this is the highest-risk move you can make: a large departure from the status quo that cannot be undone if the assumptions prove wrong. Taleb would call it fragile. Lindblom would call it the root method applied to a problem that demands the branch method. The corrective is not “do not commit” but “commit in ways that preserve your ability to change course.”

• The third is the productivity trap. The organisation deploys AI to make existing processes faster. This is the most natural incremental step: it departs minimally from the status quo and generates immediate, measurable results. But it is also Senge’s shifting-the-burden archetype in action: the symptomatic solution (faster output) undermines the fundamental solution (rethinking what the process is for). Lindblom would acknowledge the logic of the incremental step while warning that incrementalism without direction is drift. The branch method works not because steps are small but because each step generates learning that informs the next. If the organisation is not learning from the AI deployment, it is not muddling through. It is just muddling.

5. Lindblom’s Limits

Lindblom must be read with his limitations visible. Incrementalism has a conservative bias: it starts from the status quo, which means it systematically favours those who benefit from current arrangements. For problems that require fundamental change, such as addressing structural inequality, responding to existential risk, or transforming an industry’s operating model, incrementalism may be too slow and too constrained. Ackoff would say Lindblom resolves problems (finding acceptable trade-offs) when he should be dissolving them (redesigning the system).

Lindblom himself acknowledged this. In “Still Muddling, Not Yet Through” (1979), twenty years after the original paper, he distinguished between simple incrementalism (small steps from the status quo) and “strategic analysis” (a broader set of methods including informed trial and error, calculated risks, and deliberate testing). The mature Lindblom is not an advocate for drift. He is an advocate for epistemic humility: start from where you are, test before you commit, preserve reversibility, and do not pretend you can see further than you can.

The deepest tension in the series sits here. The Deciding phase has built an architecture for structured clarity: Simon’s premises, Evans’s models, Beer’s systems, Rumelt’s kernel. Lindblom says: all of that is useful, but in the moment of actual decision, under real conditions of uncertainty and disagreement, you will muddle.

The question is not whether you muddle. The question is whether you muddle intelligently: learning from each step, preserving the ability to reverse, and resisting the temptation to mistake the plan for the reality.

(An Organisational Prompt is something you can do now....)

Organisational Prompt

Find one irreversible commitment in your AI programme and make it reversible.

Look at the decisions your organisation has already made about AI: platform selections, vendor contracts, team structures, governance models. Find the one that would be hardest to reverse if the assumptions behind it prove wrong. Then ask: what would it take to make this reversible? Sometimes the answer is a shorter contract. Sometimes it is an abstraction layer. Sometimes it is a parallel path. The point is not to avoid commitment. It is to stop pretending that you know more than you do, and to build your programme so that being wrong about one thing does not make you wrong about everything.

Further Reading

Charles Lindblom: The Science of Muddling Through - The original paper. Still the most concise statement of why rational-comprehensive planning fails and what decision-makers actually do instead. Widely available in academic repositories.

Charles Lindblom: Still Muddling, Not Yet Through - The twenty-year retrospective. Lindblom refines incrementalism into “strategic analysis” and addresses the objection that muddling through is too conservative.

Charles Lindblom: The Intelligence of Democracy: Decision Making Through Mutual Adjustment - The deeper theoretical framework. How coordination emerges from interaction without a central planner.

Charles Lindblom: Politics and Markets - The broader argument about the relationship between market systems and political authority. Read it for the insight that all coordination is a mixture of hierarchy, markets, and mutual adjustment.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

Ikujiro Nonaka and Hirotaka Takeuchi, studying successful Japanese innovators in the 1980s and 1990s, built a model of organisational knowledge creation that answers a question the Deciding phase has been circling since Evans: if the domain expert knows how the business works but cannot write it down, what is the process by which what they know becomes something an AI can act on? Their answer is the SECI model, and its most important claim is that the conversion is not a documentation exercise. It is a creative act that requires specific conditions, specific interactions, and specific kinds of leadership. Most organisations provide none of them.

A footnote before we begin: Nonaka and Takeuchi also wrote “The New New Product Development Game” in 1986, the Harvard Business Review article that introduced the rugby metaphor for overlapping development phases. That article inspired Jeff Sutherland and Ken Schwaber to name their framework Scrum. The thinkers who gave us the theory of knowledge creation also, almost accidentally, gave us the most widely adopted agile methodology. The connection is not coincidental: both contributions rest on the same insight, that knowledge is created through iterative, cross-functional interaction, not through sequential, specialised handoffs.

1. The Tacit-Explicit Distinction: We Know More Than We Can Tell

Nonaka and Takeuchi built on Michael Polanyi’s foundational observation: “we can know more than we can tell.” Tacit knowledge is personal, context-specific, acquired through experience, and deeply rooted in action. The domain expert who can price a complex insurance risk in seconds is deploying tacit knowledge. The experienced developer who looks at a system design and senses it will not scale is deploying tacit knowledge. The leader who walks into a team and feels something is wrong is deploying tacit knowledge. In each case, the knowledge is real, valuable, and almost entirely inarticulate.

Explicit knowledge is the opposite: articulated, systematic, codified, and easily communicated. A specification is explicit knowledge. A policy document is explicit knowledge. An API contract is explicit knowledge. Western organisations, Nonaka and Takeuchi argued, are systematically biased toward the explicit. They invest in documentation, processes, knowledge management systems, and databases. They treat knowledge as something to be captured, stored, and retrieved. And they consistently undervalue the tacit knowledge that makes the explicit knowledge meaningful.

The connection to Argyris is precise. The gap between espoused theory and theory-in-use is the gap between explicit and tacit knowledge. The espoused theory (the process document, the policy manual, the specification) is explicit. The theory-in-use (how people actually work, the workarounds, the informal rules) is tacit. Argyris explained why the gap exists: defensive routines prevent articulation. Nonaka provides the process model for closing it.

The connection to Bourdieu is equally precise. Habitus is tacit knowledge in Nonaka’s terms: the embodied dispositions that generate practice below conscious awareness. The domain expert’s pricing judgment is habitus made productive. The organisation’s resistance to change is habitus made defensive. In both cases, the knowledge governs practice without being available for examination. Simon’s decision premises are the mechanism: the tacit knowledge shapes the premises that enter decisions without anyone noticing, because nobody has made the premises explicit.

2. The SECI Model: Four Conversions

Nonaka and Takeuchi’s central framework describes four modes of knowledge conversion, forming a continuous spiral.

Socialisation (tacit to tacit): knowledge shared through direct experience. Observation, imitation, practice, shared activity. This is apprenticeship: the junior developer who learns how to review code by sitting next to a senior developer. The domain expert who absorbs how the business works by spending years inside it. Socialisation is slow, requires physical or at least sustained proximity, and produces knowledge that remains tacit. It cannot be replaced by documentation.

Externalisation (tacit to explicit): the critical and most creative conversion. This is where tacit insights are made explicit through dialogue, metaphor, analogy, and conceptualisation. The famous Matsushita bread-maker example: an engineer named Ikuko Tanaka apprenticed herself to a master baker at the Osaka International Hotel because he could not articulate what made his bread exceptional. She noticed his distinctive twisting motion when kneading dough and translated that physical observation into a specification for the bread machine’s kneading mechanism. The observation was socialisation. The translation into a specification was externalisation. Without both, the bread machine would not have worked.

This is what specification writing demands. The domain expert knows how the business works. The specification writer must convert that tacit knowledge into explicit requirements that an AI can act on. If the conversion is done badly, the specification captures the espoused theory (what people say the business does) rather than the theory-in-use (what it actually does). Argyris explained why the conversion fails. Nonaka explains what it requires: sustained dialogue, metaphor (”it’s like kneading dough”), analogy (”the pricing logic works like a negotiation, not like a formula”), and the willingness to stay in the conversation long enough for the tacit to surface.

Combination (explicit to explicit): organising and integrating existing explicit knowledge. Merging documents, synthesising reports, restructuring databases. This is the easiest mode to automate and the mode AI performs best. An LLM that summarises a set of policy documents, cross-references specifications, or generates a consolidated report is performing combination. The danger, which Nonaka identified decades before AI made it acute, is mistaking exceptional combination for genuine knowledge creation. AI can recombine explicit knowledge at unprecedented speed. It cannot perform externalisation, because it has no access to the tacit knowledge that externalisation converts.

Internalisation (explicit to tacit): learning by doing. Converting explicit knowledge into embodied practice. Reading the specification and then building until the understanding becomes automatic. This completes the cycle: internalised knowledge becomes the new tacit knowledge that can be shared through socialisation, restarting the spiral. Dweck’s growth mindset provides the psychological precondition: internalisation requires treating explicit knowledge as something to be embodied through practice, not merely memorised.

3. Why Externalisation Is the Bottleneck

The four modes are not equally important. Externalisation, the conversion from tacit to explicit, is the bottleneck of the entire knowledge creation process, and it is the bottleneck of specification-driven development. Everything else depends on it. Socialisation transfers tacit knowledge without making it explicit. Combination reorganises what is already explicit. Internalisation embeds the explicit back into practice. Only externalisation creates the new explicit knowledge that the organisation, and the AI, can work with.

Evans’s knowledge crunching is externalisation in action. The iterative dialogue between developers and domain experts, in which the domain model is constructed through conversation, challenge, and revision, is precisely the process Nonaka describes. The developer asks “how does the pricing work?” The domain expert says “it’s complicated.” The developer proposes a model. The expert says “that’s not quite right.” The model is revised. This cycle, repeated dozens of times, gradually externalises the tacit knowledge that the expert could not articulate in a single sitting.

Klein’s pattern recognition adds a layer. The domain expert whose intuition Klein validated is the person with the richest tacit knowledge. They are also the person for whom externalisation is hardest, because the more expert you are, the more your knowledge has been compressed into patterns that fire below conscious articulation. Asking the expert to explain their judgment is asking them to decompress what years of experience have compressed. The process is uncomfortable, slow, and essential.

Kahneman’s noise enters here too. If externalisation is always imperfect, always a lossy conversion from rich tacit knowledge to simplified explicit representation, then different externalisation sessions will produce different explicit knowledge from the same tacit base. Two specification workshops with the same domain expert on different days will produce different specifications, not because the expert’s knowledge has changed but because the externalisation process is inherently noisy. Decision hygiene, structuring the externalisation dialogue with defined dimensions and independent assessment, reduces this noise without eliminating it.

4. Ba: The Conditions Externalisation Requires

Nonaka introduced the concept of ba (a Japanese term meaning place or context) to describe the conditions required for each mode of knowledge conversion. Externalisation requires what he called dialoguing ba: a context of peer-to-peer interaction, mutual trust, and sustained conversation. This is not a meeting room with a facilitator and a timer. It is a relationship between people who trust each other enough to say “I don’t know how to explain this, but let me try.”

The connection to Edmondson’s psychological safety is direct: dialoguing ba requires that the domain expert can say “actually, it doesn’t work the way the policy says” without professional consequence. The connection to Heifetz’s holding environment is equally direct: the leader’s job is to create and protect the space in which externalisation can happen, which means protecting the participants from the political consequences of making the undiscussable explicit.

Beer’s architecture provides the structural dimension. Nonaka’s ba is the social context; Beer’s System 3* (the audit channel) is the architectural mechanism that connects the externalised knowledge to the decision system. Without System 3*, the knowledge externalised in a workshop stays in the workshop. With it, the new explicit knowledge enters the decision premises that shape organisational action. The architecture and the social context are both necessary. Neither is sufficient alone.

5. Where AI Sits in the Spiral

The SECI model clarifies exactly what AI can and cannot do in the knowledge creation process.

AI excels at combination. It can synthesise, reorganise, cross-reference, and recombine explicit knowledge at a speed and scale no human team can match. This is genuinely valuable. But combination is the mode that creates least new knowledge. It reorganises what is already known.

AI cannot perform socialisation. It cannot learn by sitting next to a master practitioner, absorbing the rhythms and intuitions of a craft. It has no body to observe with, no empathy to share experience through, no relationship in which tacit knowledge transfers.

AI cannot perform externalisation. It can assist: it can ask questions, propose models, challenge descriptions, and generate drafts that the domain expert reacts to. But the conversion from tacit to explicit must happen in the human, because the tacit knowledge lives in the human. The AI is a mirror, not a source. Evans’s knowledge crunching, assisted by AI-generated prototype models that the expert can react to (”that’s not quite right; the pricing actually works more like this”), may be the most productive use of AI in the entire specification process. But the creative act remains human.

AI can accelerate internalisation by generating worked examples, simulations, and practice scenarios from explicit knowledge. A developer learning a new domain can use AI to generate cases that test their understanding, turning the specification into practice exercises that build tacit mastery.

The implication for the Deciding phase: organisations that deploy AI primarily for combination (summarising documents, generating reports, cross-referencing data) are using AI where it adds least value to knowledge creation. Organisations that use AI to support externalisation (generating prototype models for domain experts to react to, proposing specification drafts that surface tacit assumptions through the expert’s corrections) are using AI where it adds most value. The difference is whether AI is reorganising what is already known or helping to surface what has never been articulated.

6. Nonaka’s Limits

Nonaka must be read with his limitations visible. The SECI model emerged from Japanese corporate culture, with its emphasis on socialisation, group harmony, and apprenticeship. Its applicability in Western individualist contexts is contested. The tacit-explicit distinction may be a continuum rather than a dichotomy. The empirical evidence, including the bread-maker case, is illustrative rather than rigorous. And critically, the model does not address power, politics, or conflict. Stacey would argue that Nonaka presents knowledge creation as a manageable, facilitatable process when in reality it emerges from messy, political, anxiety-laden interactions. Argyris would add that the defensive routines preventing externalisation are not merely obstacles to be overcome but structural features of the organisation that serve real protective functions.

The practical limitation is that externalisation cannot be scheduled. You cannot put “convert tacit knowledge to explicit” on a project plan and expect it to happen by Thursday. It happens through relationships, through sustained dialogue, through the kind of unstructured conversation that most organisations have systematically eliminated in the name of efficiency. The leader’s task is not to manage the knowledge spiral but to protect the conditions in which it can turn.

(An Organisational Prompt is something you can do now....)

Identify one piece of tacit knowledge your AI needs.

Pick one domain where your organisation is deploying AI. Ask: what does the most experienced practitioner in this domain know that is not written down anywhere? Not the process documentation. Not the policy manual. The thing they know that nobody has ever articulated, the judgment call, the exception that is not in the rules, the pattern they recognise but cannot explain. Now ask: does your AI deployment plan include any mechanism for converting that knowledge into something the AI can use? If the answer is no, your AI is being built on explicit knowledge only, which means it is being built on what the organisation says it does rather than on what it actually does. The conversion from tacit to explicit is the work your project plan has not accounted for, and it is the work that determines whether the AI will produce useful output or confident nonsense.

Further Reading

Ikujiro Nonaka and Hirotaka Takeuchi: The Knowledge-Creating Company - The foundational text. The SECI model, the knowledge spiral, and the argument that Western organisations systematically undervalue tacit knowledge. Read it for the bread-maker case and the conditions for knowledge creation.

Ikujiro Nonaka: The Knowledge-Creating Company - The article that introduced the ideas to a management audience. Shorter and more accessible than the book.

Ikujiro Nonaka and Hirotaka Takeuchi: The New New Product Development Game - The article that inspired Scrum. Overlapping development phases, cross-functional teams, and the rugby metaphor. Essential for anyone who uses agile methods and wants to understand their intellectual origin.

Michael Polanyi: The Tacit Dimension - The philosophical foundation. “We can know more than we can tell.” Short, profound, and the starting point for everything Nonaka built on.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

Every specification problem is, at its root, an articulation problem. The domain expert who cannot explain why the system should behave this way rather than that way is not stupid. They know. They have been doing the work for years. But the knowledge lives in what Argyris called the theory-in-use: the actual rules governing behaviour, which operate below conscious articulation and are often directly contradicted by the espoused theory, the rules people claim to follow. The specification demands that tacit knowledge become explicit. The defensive routines ensure it cannot.

1. The Undiscussable: Why Specifications Miss What Matters Most

Argyris’s most devastating observation is that organisations develop elaborate mechanisms for not discussing the things that matter most. A topic becomes undiscussable when raising it would threaten someone’s competence, status, or control. The undiscussability itself then becomes undiscussable: everyone knows the topic cannot be raised, but nobody can say so. The silence is perfectly maintained by people who are not conscious of maintaining it.

In specification work, the undiscussables are the business rules that nobody has ever written down because writing them down would expose contradictions, incompetence, or political arrangements that benefit from ambiguity. The pricing logic that varies by client relationship but is officially uniform. The approval workflow that is formally three steps but informally seven, with the extra four existing to protect specific people’s authority. The risk threshold that the policy document says is one thing but the actual practice says is another, because the policy was written for the regulator and the practice was designed for the commercial reality.

These are precisely the rules the AI needs to know. They are precisely the rules nobody can say.

Evans’s knowledge crunching assumes that developers and domain experts will sit together and, through iterative dialogue, surface the domain model. Argyris explains why this process reliably fails in practice: the domain expert cannot articulate the theory-in-use because it has never been conscious, and the organisation cannot surface it because doing so would make the undiscussable discussable. The developer asks “how does the pricing work?” The domain expert gives the espoused theory. The specification is written against the espoused theory. The AI generates code that implements the espoused theory. The system goes into production and produces wrong answers, because the actual pricing follows the theory-in-use, which nobody articulated because it was never safe to do so.

2. Skilled Incompetence in the Deciding Phase

In the Learning phase, skilled incompetence described the ability of successful professionals to avoid examining their own reasoning. In the Deciding phase, it has a sharper manifestation: the ability of organisations to produce decisions that look rigorous while avoiding the reasoning that would make them genuinely informed.

The AI governance board is the canonical example. The board meets. Papers are circulated. Risks are assessed. Matrices are completed. A decision is recorded. At no point does anyone say: “We do not actually understand what this AI system will do in production, because the specification it was built from does not describe how the business actually works.” That sentence is undiscussable, because it would imply that the specification process the board oversees is not working, which would threaten the authority of the people who designed it, which would make them defensive, which would trigger the very Model I behaviours (unilateral control, suppress negative feelings, maximise winning) that Argyris documented.

The board’s skilled incompetence is not that it makes bad decisions. It is that it makes decisions that are disconnected from the information that matters, while appearing to be thoroughly informed. The paperwork is impeccable. The reasoning is invisible. Kahneman would call this noise masked by process. Beer would call it an accountability sink. Argyris names the mechanism: defensive routines have colonised the decision architecture, ensuring that the information the architecture was designed to process never enters it.

3. The Ladder of Inference: How Specifications Drift from Reality

Argyris and his colleagues developed the ladder of inference to show how people move from observable data to action through a series of increasingly abstract steps, each of which introduces assumptions that are never tested. You observe data. You select data (filtering what you notice). You add meaning (interpreting what you noticed). You make assumptions (based on the meaning you added). You draw conclusions. You adopt beliefs. You take action. Each rung of the ladder takes you further from the observable reality and closer to a self-reinforcing interpretation that feels like fact.

Specification writing climbs the ladder of inference at every step. The domain expert observes a business process. They select the parts they consider important (filtering out the exceptions, the workarounds, the unofficial practices). They add meaning (”this is how we handle onboarding”). They make assumptions (”the AI needs to replicate this process”). They draw conclusions (”the specification should describe these steps”). They adopt beliefs (”this specification accurately represents our business”). They hand the specification to the AI.

The problem is not at any individual rung. The problem is that nobody climbs back down. Nobody tests whether the selected data was the right data. Nobody checks whether the meaning added was accurate. Nobody challenges whether the assumptions hold. Argyris showed that in Model I behaviour, people advocate their position without inviting inquiry. The specification writer who presents their specification as “how the business works” is advocating without inquiry. The reviewer who approves it without asking “what did you leave out and why?” is colluding in the ascent.

Simon’s decision premises reframe this structurally. The ladder of inference describes how premises become progressively more detached from the observable world. By the time the premise reaches the decision (or the specification), it has been filtered through so many layers of interpretation that it may bear little resemblance to the reality it claims to describe. Simon asks how the right premises reach the right people. Argyris asks why the premises that do arrive have been systematically distorted by the defensive needs of the people who produced them.

4. Model II as a Specification Discipline

Argyris’s Model II is usually presented as a personal skill: make your reasoning explicit, invite genuine challenge, combine high advocacy with high inquiry. In the Deciding phase, it becomes a specification discipline.

A Model II specification process looks like this. The specification writer presents the specification and simultaneously presents the reasoning behind it: “I specified the pricing logic this way because I believe the discount structure works like this. Here is the evidence I used. Here is what I am uncertain about. Here are the parts where I had to guess because nobody could give me a clear answer.” They then invite challenge: “Where am I wrong? What have I missed? What do you know that contradicts what I have written?”

This is what Evans’s knowledge crunching requires but does not describe the conditions for. Evans assumes the dialogue will happen. Argyris explains why it will not happen unless the conditions are explicitly created. The domain expert who says “actually, the discount structure does not work that way; it depends on the relationship manager’s judgment, which is never documented” is making an undiscussable discussable. They will only do this if the environment rewards honesty rather than punishing it, which is Edmondson’s psychological safety operating as a precondition for Model II behaviour.

Klein’s pre-mortem is Model II made structural. Instead of asking people to change their defensive routines (which Argyris acknowledged is extraordinarily difficult), the pre-mortem creates a context in which the undiscussable becomes expected. “Imagine this specification has been implemented and the system is producing wrong answers. Why?” The answers will contain the undiscussables: the business rules nobody wrote down, the exceptions nobody mentioned, the political arrangements that the specification politely omitted. The pre-mortem works not because it changes people but because it changes the question.

5. Why the Gap Between Espoused Theory and Theory-in-Use Is the Specification Gap

The deepest connection between Argyris and the Deciding phase is this: the gap between espoused theory and theory-in-use is precisely the gap between the specification and reality.

Every organisation has an espoused theory of how it works: the process documentation, the policy manuals, the architecture diagrams, the operating procedures. And every organisation has a theory-in-use: the actual practices, workarounds, informal agreements, and undocumented decisions that govern what people really do. The two rarely match. The gap between them is not a documentation failure. It is a structural feature of organisations that have optimised for the appearance of order while accommodating the messiness of reality.

AI does not accommodate the gap. AI takes the espoused theory (the specification, the documentation, the formal rules) and implements it literally. The theory-in-use, the part that makes the business actually work, is invisible to the AI because nobody has articulated it. The result is a system that perfectly implements what the organisation says it does and completely fails to do what the organisation actually does.

POSIWID applies at the specification level: the purpose of the specification is what it produces. If the specification produces a system that does not match reality, then the specification’s actual purpose was to document the espoused theory, not to describe the business. And this is almost always its actual purpose, because documenting the espoused theory is safe (it matches the official narrative) while documenting the theory-in-use is dangerous (it exposes the gap).

Drucker’s theory of the business sits one level above this. The theory of the business is the set of assumptions that generates both the espoused theory and the theory-in-use. When the theory of the business is valid, the gap between the two is small and manageable. When the theory is invalid, the gap widens because the espoused theory continues to express the official assumptions while the theory-in-use adapts to a reality the assumptions no longer describe. The specification inherits whichever version it is given. Without Argyris’s diagnostic, nobody can tell which version that is.

6. Argyris’s Limits

Argyris must be read with his limitations visible. His framework was developed in Western, individualistic contexts, and its applicability in collective cultures is contested. The distinction between Model I and Model II can be overly normative: Model II is presented as universally superior, but in some organisational contexts, the defensive routines serve genuine protective functions that Model II behaviour would strip away without providing an alternative.

Stacey poses the deepest challenge. Argyris assumes there exists a position from which reasoning can be examined and improved: you can step outside your defensive routines and observe them. Stacey argues this position does not exist, because the observer is embedded in the same responsive processes as the observed, and the act of examination is itself shaped by the dynamics it claims to examine. The debate is genuine. This series holds both: Argyris provides the diagnostic that Stacey says is impossible but practitioners find indispensable.

The practical limitation is that Model II behaviour is extraordinarily difficult to learn. Argyris himself found that even after years of training, most professionals could articulate Model II principles (which became their new espoused theory) while continuing to operate in Model I (the unchanged theory-in-use). The programmes reproduced the very gap they were designed to close. This is not a reason to abandon Argyris. It is a reason to complement him with structural interventions, like Klein’s pre-mortem and Kahneman’s decision hygiene, that reduce the dependence on individual behavioural change and instead redesign the decision environment.

(An Organisational Prompt is something you can do now....)

Find one undiscussable in one specification.

Take a specification your organisation has recently produced, one that is considered complete and approved. Sit with the domain expert who provided the business rules, in private, without the project manager or the governance people present. Ask: “Is there anything about how this actually works that is not in this document?” Then be quiet. Wait. The silence will be uncomfortable. What follows will be the most valuable information in the entire project, because it will be the information that the specification process was designed, structurally, not to capture. You do not need to fix the process today. You need to see the gap. Once you have seen it in one specification, you will see it in all of them.

Further Reading

Chris Argyris: Teaching Smart People How to Learn - The single most important Argyris article. Why the most successful professionals are the worst at learning, and why leadership development programmes reproduce the gap they are designed to close. Freely accessible.

Chris Argyris: Overcoming Organizational Defenses - The fullest treatment of defensive routines, the ladder of inference, and Model I/Model II applied to organisations. The book to read if you want to understand why your specification process captures the espoused theory and misses the theory-in-use.

Chris Argyris and Donald Schön: Organizational Learning II: Theory, Method, and Practice - The collaborative framework that extends single-loop and double-loop learning to the organisational level. Deutero-learning, the capacity to learn how to learn, is the concept this series keeps returning to.

Chris Argyris: Knowledge for Action - The practitioner-oriented treatment. Case studies of organisations attempting Model II and the specific ways they fail. Read it for the honest assessment of how hard this is.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.

Klein is a cognitive psychologist who founded the Naturalistic Decision Making movement. Where Kahneman studied decision-making in the laboratory, Klein studied it in burning buildings, intensive care units, military command posts, and offshore oil platforms. Where Kahneman found systematic error, Klein found systematic competence. The same cognitive mechanism, System 1 pattern recognition, produces both. The difference is not in the person. It is in the environment. This distinction, which Klein and Kahneman eventually agreed on after years of adversarial collaboration, is the most useful framework in the decision science literature for anyone trying to figure out which of their organisation’s experts to trust and which to overrule.

1. Recognition-Primed Decision: How Experts Actually Decide

Klein’s central finding is that experts do not decide the way decision theory says they should. They do not generate multiple options, weigh them against criteria, and select the best. They recognise the situation, generate a single course of action based on pattern recognition, mentally simulate it to check whether it will work, and act. If the simulation reveals a problem, they modify the action or generate the next most plausible option. The process is serial (one option at a time), not parallel (comparing multiple options simultaneously).

Klein calls this the Recognition-Primed Decision model. He discovered it by studying fireground commanders: people who make decisions about where to send crews into burning buildings, with lives at stake, under extreme time pressure, with incomplete and changing information. These commanders almost never compared options. They looked at the fire, recognised a pattern from their experience, knew what to do, and did it. When Klein asked them to explain their decisions, they often could not articulate the reasoning. They said things like “it just felt right” or “I could see it was going to go bad.” This is not mysticism. It is pattern recognition operating below conscious articulation but above random guessing.

The model has three levels. At Level 1, the situation is immediately recognised and the action is obvious: the experienced firefighter sees a backdraft pattern and orders evacuation without deliberation. At Level 2, the situation requires diagnosis: the pattern is not immediately clear, so the expert runs mental simulations until one fits. At Level 3, the situation is complex enough that the expert must evaluate a course of action by imagining its consequences, modify it if the simulation reveals problems, and iterate. Even at Level 3, the process is not comparison. It is generation, simulation, and modification of a single line of action.

For the series, this matters because it describes how the best people in your organisation actually work. The senior architect who looks at a system design and says “that won’t scale” is not guessing. They are recognising a pattern from hundreds of systems they have seen before. The domain expert who reads a specification and says “that’s not how we do it” is not being obstructive. They are matching the specification against a library of domain situations built over years. The experienced leader who walks into a struggling team and senses something is wrong before anyone has said a word is reading cues that their pattern library can decode and their conscious mind cannot yet articulate.

2. The Pattern Library: What Expertise Actually Is

Klein’s research redefines expertise. It is not superior analytical ability. It is a richer, more accurate library of situation-action patterns built through experience. Simon estimated that expertise requires roughly 50,000 chunks of domain knowledge, accumulated over approximately ten years of deliberate practice. Klein’s fieldwork confirms this: the expert’s advantage is not that they think harder but that they see more. They perceive cues that novices miss. They recognise patterns that novices have never encountered. They generate expectations about what will happen next, and when those expectations are violated, they know something has changed.

Four elements activate simultaneously when an expert recognises a situation: cues (what they notice in the environment), expectancies (what they predict will happen next), goals (what they are trying to achieve), and actions (what to do about it). These do not fire sequentially. They fire as a package. The firefighter does not first perceive the cue, then predict the trajectory, then identify the goal, then select the action. They perceive the situation and know what to do, in a single cognitive act. This is what “intuition” means when it works: not a feeling disconnected from evidence, but compressed expertise recognising a familiar pattern and activating the appropriate response.

The implication for organisations is that expert judgment is not a soft skill to be tolerated. It is an asset to be cultivated, protected, and deployed strategically. The organisation that replaces expert judgment with checklists in domains where expertise is valid has destroyed its most valuable decision-making resource. The organisation that defers to expert judgment in domains where expertise is invalid has handed its future to confident pattern-matchers operating in an environment that does not reward pattern-matching.

The question, as always, is which domains are which.

3. When Intuition Works: High-Validity Environments

The Kahneman-Klein adversarial collaboration, published in 2009 after years of argument, produced a resolution that is more useful than either position alone. They agreed: intuition is trustworthy when two conditions are met.

First, the environment must be sufficiently regular that patterns exist to be learned. Chess is regular: the same positions recur and the rules do not change. Firefighting is regular: fire behaviour follows physical laws, and while each fire is different, the patterns are learnable. These are high-validity environments. There is a stable, underlying structure that rewards pattern recognition.

Second, the decision-maker must have had prolonged practice with valid feedback. The feedback must be prompt (you learn quickly whether your decision was right), clear (the outcome is unambiguous), and connected to the decision (you can attribute the outcome to your choice, not to luck or other factors). A chess player gets immediate, unambiguous feedback after every move. A surgeon gets feedback within hours: the patient recovers or does not. A firefighter gets feedback within minutes: the building behaves as predicted or it does not.

When both conditions are met, intuition is not just acceptable. It is superior to analytical methods. The expert operating in a high-validity environment with years of valid feedback will consistently outperform the checklist, the algorithm, and the committee. This is Klein’s core finding, and it has been replicated across domains from military command to intensive care nursing to chess.

Evans’s knowledge crunching produces high-validity environments by design. When developers and domain experts work together iteratively, testing the model against reality and refining it through feedback, they are building the conditions Klein describes: a domain with learnable regularities and prompt, clear feedback. The domain expert who has been through months of knowledge crunching has valid intuition about the domain model. Their judgment about what the specification should say is trustworthy, because it has been calibrated by the exact process Klein’s research describes.

4. When Intuition Fails: Low-Validity Environments

Kahneman’s contribution to the collaboration was equally important. He insisted, and Klein agreed, that many professional environments do not meet the two conditions. The environment is irregular, the feedback is delayed, or the feedback is ambiguous. In these environments, expert intuition is unreliable regardless of the expert’s experience or confidence.

Stock picking is a low-validity environment: the market is too complex and too influenced by other actors for patterns to be reliably learnable. Political prediction is a low-validity environment: the feedback is delayed by years and confounded by countless variables. Long-range strategic forecasting is a low-validity environment: the outcome depends on factors the forecaster cannot observe or control.

AI strategy is a low-validity environment. The technology changes faster than any executive can accumulate valid experience. The feedback is delayed by months or years. The feedback is ambiguous: when an AI initiative fails, it is never clear whether the failure was caused by the strategy, the implementation, the technology, the culture, or the timing. The executive who says “I have a gut feeling about where AI is heading” is exhibiting exactly the confident pattern-matching that Kahneman’s research shows is unreliable in environments this novel.

This does not mean the executive’s judgment is worthless. It means their judgment about AI strategy should be treated differently from the domain expert’s judgment about specification quality. The first operates in a low-validity environment and should be structured, tested, and challenged. The second operates in a high-validity environment and should be trusted, protected, and amplified. The organisation needs both. The decision architecture must distinguish between them.

Beer’s System 3* (the audit channel) is the architectural mechanism for making this distinction. The audit channel provides direct, unfiltered access to what is actually happening. In Klein’s terms, it tests whether the environment is providing valid feedback. If the audit reveals that the domain expert’s intuitions are consistently confirmed by the AI-generated output, you are in a high-validity environment and the expert’s judgment should be trusted. If the audit reveals that the strategic forecast is consistently wrong, you are in a low-validity environment and the judgment should be structured.

5. The Pre-Mortem: Klein’s Most Practical Tool

Klein’s most widely adopted contribution is the pre-mortem. The method is simple: before a decision is implemented, the team imagines it has already been implemented and has failed. Each member independently writes down the reasons for the failure. The results are collected and discussed.

The pre-mortem works because it inverts the cognitive dynamics that Kahneman identified. WYSIATI (What You See Is All There Is) suppresses awareness of what could go wrong, because the plan is coherent and the team is committed. The pre-mortem gives explicit permission to name what could go wrong, bypassing the social pressure to agree. Overconfidence is reduced because the team has been asked to generate failure narratives, not success narratives. And because the exercise is individual before it is collective, it captures the disagreement that Kahneman’s decision hygiene requires: the independent judgment that group dynamics would otherwise suppress.

For AI transformation, the pre-mortem has a specific application. Before deploying an AI-assisted workflow, before rolling out a specification-driven development process, before restructuring teams around domain boundaries, imagine it has failed. What went wrong? The answers will surface the assumptions the plan relies on but has never tested. They will name the dependencies the plan assumes but has never verified. And they will reveal the political objections that will emerge once the plan threatens the people whose roles depend on the current architecture.

The pre-mortem is Argyris made structural. Argyris showed that defensive routines suppress the information the organisation needs. The pre-mortem creates a structured context in which the undiscussable becomes not just discussable but expected. It is not a cultural intervention. It is an architectural one. And it works in organisations that would resist Argyris’s deeper prescription, because it does not require anyone to change their defensive routines. It requires only that they answer a question.

6. Klein’s Limits

Klein must be read with his limitations visible. His model is descriptive, not normative: it describes how experts do decide, not how they should. The expert whose pattern library contains bad patterns will execute those patterns with the same speed and confidence as the expert whose library is good. RPD does not distinguish between valid and invalid expertise. The Kahneman-Klein resolution does, but only by stepping outside Klein’s framework and asking about the environment.

Klein’s model also struggles with genuinely novel situations. If no pattern exists in the expert’s library, RPD has nothing to work with. The expert in an entirely new domain, the experienced insurance underwriter encountering AI-generated risk models for the first time, has no relevant patterns. Their intuition will default to the closest available analogue, which may be dangerously wrong. Taleb’s Black Swan territory is precisely where Klein’s model has least to offer and where structured, humble, experimental approaches have most value.

The deepest tension is with Simon. Simon says: design the decision environment so the right premises reach the right people. Klein says: trust the expert who has been calibrated by the right environment. These are not contradictory. They are complementary, and the organisation needs both. Design the environment (Simon) to produce experts with valid pattern libraries (Klein), and then trust those experts to decide. The architecture creates the conditions for expertise. The expertise produces the decisions. Neither works without the other.

(An Organisational Prompt is something you can do now....)

Run a pre-mortem on your next AI decision.

Before you approve the next initiative, the next team restructuring, gather the people who will be affected. Tell them: “Imagine it is six months from now and this has failed completely. What went wrong?” Give them five minutes to write independently. Then read the answers aloud. The things they write will be the things they already know but have not been able to say. The pre-mortem does not require courage. It requires only a question and five minutes of silence. The information that emerges will be more valuable than the analysis that preceded it, because the analysis was constructed by people who wanted the plan to succeed, and the pre-mortem was constructed by people who were given permission to imagine it failing.

Further Reading

Gary Klein: Sources of Power: How People Make Decisions - The foundational text on naturalistic decision-making. The RPD model, the fireground studies, and the argument that expertise is pattern recognition, not analysis. The most important book on how experts actually decide.

Gary Klein: Seeing What Others Don’t: The Remarkable Ways We Gain Insights - How breakthroughs happen: by challenging assumptions, making connections, and noticing contradictions. The insight research that complements the RPD model.

Gary Klein: Streetlights and Shadows: Searching for the Keys to Adaptive Decision Making - Ten claims about how we should make decisions, and the research that challenges each one. The best Klein book for a reader sceptical of the “trust intuition” message.

Daniel Kahneman and Gary Klein: Conditions for Intuitive Expertise: A Failure to Disagree - The adversarial collaboration. When intuition works and when it does not. The single most useful paper in the decision science literature for practitioners.

I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.