Category: Operating Models & Flow

Nearly nine in ten change programmes fall short of what they set out to do. Your AI transformation is being set up to join them, and the reason has almost nothing to do with the technology.

A bonus edition of Come Prepared to Die, outside the numbered chapters.

Look squarely at the last big change programme you ran or sat inside. Agile, most likely, or the DevOps push, or the one with the framework and the certified coaches and the reorganised standups. My read, over two decades in and around this work, is that almost all of them fell short of what their framers intended when they wrote the Manifesto, and that most of us who led them know it privately even where we defended them in public. Bain looked at 250 change programmes and found 12% achieved what they set out to do; the rest split between failing outright and settling for a shortfall they learned to call success.

Agile didn’t fail because Agile was wrong. Your AI transformation is being set up to fail for the same reason.

Agile was never a methodology, it was an organisational capability

You don’t get agility by running the ceremonies any more than you get a butterfly by pinning wings to a caterpillar. Jay Galbraith gave us the picture decades ago, and it still holds. He called it the Star Model and laid an organisation’s design out as five points pulling on one another: strategy, structure, rewards, processes and people. An organisation’s behaviour emerges from how all five are arranged together, not from any single one of them. Further, whether that behaviour is worth anything turns on whether it fits the situation the organisation is actually in. An organisation design tuned for a stable world produces orderly behaviour that is exactly wrong for a volatile one.

Software development—especially now that AIs are involved—is volatile, uncertain, complex and ambiguous, which is the VUCA the war colleges coined for exactly this kind of ground. The behaviours that pay there are adaptive. It’s true that some of the work is merely complicated rather than genuinely complex, and there an orderly design still earns its keep; but betting on the organisation staying in calm, predictable water is a bold call. Better to assume complexity and downgrade to orderly than to assume orderly and get thrashed about. The Org Topologies work Craig Larman does with Alexey Krivitsky and Roland Flemm builds straight onto the Star Model, and it treats agility as a property of the whole design, not a set of practices a team can adopt.

Before the design argument, the money one. AI cuts task time. On its own it doesn’t move revenue, margin or cash. The gain converts only if the freed capacity gets redeployed to something the business sells, and that decision sits across function boundaries, which puts it with whoever holds P&L authority over the whole workflow rather than with the department that bought the tool. Where nobody holds that, the capacity turns into idle time or more work-in-progress, and the company pays for licences and a change programme while the benefit leaks between functions.

The first wall: what you’re allowed to touch

The thing an Agile transformation is trying to move lives in the whole organisation, and the effort is scoped to one corner. The people brought in to run the change, the coaches and the transformation office, generally only touch local processes inside product and engineering. The wall is porous, not solid: a CTO or CPO with real authority inside their own department can move some local structure, some of the people, even some of the local rewards, and a change effort they back reaches that far with them. What none of them reaches is the design of the organisation around the department, the reward system that sits above it, or the behaviour of stakeholders who never report in. For those, the change effort holds neither the remit nor the standing.

And where it does push, the system pushes back. Larman put this in his Laws of Organisational Behaviour years ago: organisations are implicitly optimised to protect the power and positions of middle managers and specialists, so any change initiative gets reduced to redefining the new terminology to mean roughly the old status quo. So the boundary works as a machine as much as a fence. Push a change through it and the change comes back out wearing the new words and the old shape. Nobody built it on purpose. It defends itself anyway, and very well.

Larman and Bas Vodde have a line for what the wall costs you: be agile, not do agile. Doing agile is the local practice a team can run inside its own boundary, the part an outside change effort is allowed to install. Being agile is a property of the whole star, and reaching it means changing the points that effort was never given the authority to touch.

The second wall: how deep you’re allowed to go

Even inside what it can touch, the effort is held at the surface. Peter Block, in Flawless Consulting, separates the content level of a consultant’s work, the frameworks and recommendations a manager can absorb without changing how they see themselves, from the affective level, where trust, power and identity actually live. Real change doesn’t happen unless the affective level shifts as well. Most consultants won’t go there, Block says, because it makes them vulnerable, and they collude with the client in pretending the organisation is a rational machine rather than a political one. Jerry Weinberg drew the same wall as a number in The Secrets of Consulting: never promise more than about 10% improvement, because 10% is the most you can deliver without threatening the client’s paradigm. The ceiling is set exactly where the discomfort would start.

Consultants and coaches get blurred together here, and they are trained for different halves of the problem. Consultants work at the content level. They bring the diagnosis, the framework, the recommendation, and most of them have neither the training nor the invitation to work at the affective level at all. Coaches are built the other way round. They are trained for the affective level, for what a person believes and fears and protects, and most of them don’t carry the technical content of how a software organisation is actually put together. The rare practitioner holds both, and getting there takes two separate educations, run by different institutions and certified by different bodies. Nothing in either pipeline produces the other. I took both. It bought me no authority at all: neither trade, alone or combined, was ever handed the power to change the design.

Above that wall sit the leader’s own paradigm, the mostly-unexamined model of what an organisation is and how it should work; their read of the context they are actually in, which may be years out of date; and the goals they are optimising for, which may not be the ones the situation rewards. Those aren’t the only inputs to a strategy, and the arrow doesn’t run only downward. The design already in place decides which strategies are thinkable at all, and a company whose rewards and reporting lines were built for the old model will keep choosing strategies that fit it. These three matter because of where they sit: above the wall, on the leader’s own ground, and no content-level intervention reaches any of them. A consultant can redesign a standup. A coach can hold the room while a CEO looks at what they believe an organisation is for. Neither one can do the looking for them.

The two walls together box the effort into the smallest, lowest part of the star: local in scope, shallow in depth. The whole-system property it is chasing is a feature of the entire design and of the identity above it, not of any single point you are allowed to touch. More consulting, better consulting, another framework, and you are still inside the box.

The same trap, one rung up

I’m not the only one saying this. Stefan Wolpers, writing on the Scrum.org blog in January 2026, calls it the Agile-AI isomorphism: organisations that installed Scrum ceremonies without changing structure, culture and governance failed at Agile, and organisations installing AI tools without changing those same conditions risk failing at AI. The predictor of success, he argues, is whether the organisation genuinely changed last time or merely bought the process.

So what has the organisational response to AI been so far? IBM surveyed 2,000 CEOs early in 2026 and reported that 76% of their organisations now have a Chief AI Officer, up from 26% a year earlier. Read quickly, that looks like the authority wall coming down at last. A C-suite owner, finally.

I read it the other way, and I think the number itself gives me the grounds to. Mintzberg, citing Rumelt’s survey of the Fortune 500, records the last structural change of that size: divisionalisation went from a fifth of those firms in 1949 to three-quarters by 1969, and he files even that under fashion rather than fit. Twenty years, not twelve months. What can happen that fast is a title. A CTO takes the AI hat, a VP gets re-lettered, a CEO ticks “yes” on a survey run by a vendor that sells AI transformation. The evidence is in the same study. IBM reports 76% with a Chief AI Officer while only about a quarter of their people use AI regularly at work. The title has run a full lap ahead of the work.

And the work, where it runs at all, is mostly not paying its way. MIT’s NANDA initiative reviewed about 300 publicly disclosed enterprise AI initiatives through 2025, interviewed 52 organisations and surveyed 153 leaders, and found 95% showed no measurable impact on profit and loss. Take that number at the weight it can bear: the work is preliminary, it hasn’t been peer-reviewed, the sample isn’t random, and a short measurement window will under-count anything still maturing. The models were rarely the binding constraint. What failed was the integration into how the business actually works.

NANDA didn’t test authority, mandate, or the leader’s paradigm, and I’m not going to borrow certainty from their result. That reading is mine, so I checked it. A title isn’t evidence of authority unless the charter carries decision rights over structure, rewards and cross-functional organisation, so that is what I coded across 50 AI-transformation roles at 49 organisations. I registered a prediction before I looked and got it wrong: I expected at least 70% scoped to the AI function alone, and it came in at 64%. The other half held. Two roles in 50 held a P&L, both for an AI business; none could change how the company is organised. Of the 13 reporting to a CEO or board, none had either. The altitude was real; the remit wasn’t. These are charters as written rather than authority as exercised. The rubric, the 50 rows and every coding call I had to defend are written up separately.

I wanted to run the same coding against the Agile era. If both eras chartered the work below the level where the design gets changed, the parallel stops being an analogy and becomes a measurement. I couldn’t do it. The coding needs the role’s reporting line, and for the Agile years that field has mostly gone from the public record. So the Agile half of this stays an argument rather than a finding.

That is Larman’s Law arriving on schedule, one rung higher than the Agile PMO and wearing a better suit. What the 76% measures is how fast an organisation can announce it is Agile AI-native. Copilot, like Jira before it, was bought to make the organisation faster and can only make the individual faster.

Worse than Agile in two ways

The 10X Org authors have a name I keep borrowing: the Ferrari Effect. Buy a fleet of Ferraris and put them on a one-lane road behind the trucks, and all you get is faster cars in the same traffic. AI dropped into a misaligned structure does exactly this. It amplifies whatever the organisation was already optimising for, so if the design was tuned for utilisation and local efficiency instead of flow and adaptiveness, AI makes you worse at the wrong thing, faster. Nothing an organisation does converts into performance except through its fit with the situation, and behaviour and culture both pay that same toll. A faster car doesn’t improve the fit. Fix the road first.

The first way is that AI doesn’t stay neutral while you misuse it. Trained on the internet’s management writing, it hands back the fashionable answer more readily than the fitting one. Researchers writing in the Harvard Business Review in early 2026 ran thousands of simulated strategy decisions through leading models and found they reliably reached for whatever matched current management language; they named the output trendslop. Agile at least failed in silence. AI fails while affirming you, in fluent and confident prose, that you are doing the right thing. The one tool you would want to expose your paradigm is the tool most likely to sell it back to you.

The second way is that AI widens the gap between a startup and an incumbent further than Agile ever could. A startup carries none of the incumbent’s inertia. It has no legacy design to defend, and at that size the founder simply is the structure, so no wall stands between the engineers and the design of the company. There is no gap between the paradigm and the design, and nothing to revert to. Every incumbent was a startup once. The org design grew organically after that, along the old hyper-specialisation lines, optimising for efficiency and utilisation rather than for delivering value, and each layer of that growth is now something with a constituency to defend it. The startup begins in the configuration you keep reverting away from.

In the Agile era that gap had a ceiling. A well-run startup could out-ship an incumbent and still lose, because reaching scale took people and the incumbent had them. Headcount was the incumbent’s answer to speed, and it was a good one. My read is that AI moves that exchange rate. When leverage per person rises far enough, a small organisation whose design fits its situation can reach a size that used to need a large one, and headcount stops being the answer it was. The compensating strength the incumbent was relying on is the one AI erodes first. As I write, ElevenLabs and Anysphere’s Cursor are running on a small fraction of the headcount of the classical software leaders. Some of that edge is genuinely technical: ElevenLabs trains its own speech models, and Cursor’s harness is the product rather than a wrapper on someone else’s. But comparable models reach everyone eventually, and the providers will keep building better harnesses for all of us. What no incumbent can buy from a vendor is an organisation that was never taxed by a design built for a different world.

What you can do from inside the box

Most of the people reading this are the CTO, not the CEO. You can’t redesign the company. You can do something narrower and more useful. Pick one value stream where AI is meant to pay. Baseline the commercial number it is meant to move. Then map every approval and decision right sitting between an engineer’s idea and that number changing, and notice how much of the map lies outside your department. Take it to the person who owns the design, along with one 30-day experiment that needs exactly one decision from them. Either they make it, and you have found out the design can move; or they don’t, and you have learned more about your ceiling than another quarter of pilots would have told you.

Where I could be wrong

A good-faith explanation competes with mine. The technology is young, the data plumbing is bad, and most of the 2025 pilots were badly scoped experiments run by people learning on the job. On that reading the numbers improve on their own as the tools mature, and nobody has to touch the org chart.

A second explanation is harder for me to dismiss. The causal arrow might run the other way: firms that found real value in AI then changed decision rights and reporting lines because the economics finally justified it, which would make an operating-model change the consequence of success rather than its precondition. The two readings differ on timing, so the test is whether the structural change came before the commercial result or after it. I haven’t found enough cases where both dates are public to settle it.

If immaturity is the cause, results should climb with model capability while the design stays where it is. My prediction is that task-level speed keeps climbing and the business-level numbers stay flat, because the constraint has moved somewhere the tooling cannot reach. I would be wrong if you can show me an organisation that got a durable commercial result from AI while its decision rights, its incentive measures, its funding ownership and its cross-functional process ownership all stayed put, or a workflow redesign inside one department that moved a business number and held for 18 months. One such case and I have to narrow this. Several and it is wrong.

Before publishing that offer I went looking myself, against four criteria fixed in advance: a realised commercial result on a P&L line rather than an adoption or task-time metric, held across four quarters, no reporting-line or incentive or new-function change in the same period, and no statement from the accountable leader describing a changed view. I found 18 public cases that came close enough to code. None met all four. That is weaker evidence than it sounds. Organisations publish what changed and almost never publish that they changed nothing and it worked, so the public record is far better at showing movement than at proving stillness.

The wall you cannot delegate

The change lives at the top of the organisation, in structure and rewards, and at the deepest level of engagement, in trust and identity. Both of those are the leader’s own ground. That ground belongs to the leader, not to the coach, the transformation office, or the Chief AI Officer, whose written charter, in the 50 I coded, almost always stopped short of the operating model around the AI work. The wall you can’t pay someone to cross for you is the one that runs through your own assumptions about how the organisation should be built, and whether the goals you have been optimising for still fit the situation you are actually in.

This is also why sponsor continuity matters, but departure is a warning sign rather than a law of organisational physics. A design is exposed when its decision rights, rewards and governance still depend on the person who sponsored it. The practical test is whether the new design has become how the organisation governs itself before that person goes. Craig Larman has said, in the LeSS courses I have sat in, that he has never seen an Agile transformation outlast a change of leadership. I take that as a severe practitioner warning and no more, because I tried to test it and couldn’t: a first pass found reversion signals far more often after a sponsor left than when one stayed, but a properly matched replication failed its own coverage rules. So the status is a risk worth auditing, not a mechanism I can show you.

Deming is supposed to have answered executives who asked him to train their people: come yourself, or send no one. Robert Kegan and Lisa Lahey give the mechanism in Immunity to Change. A paradigm becomes available to change only when it moves from something you are to something you have. Turning that on your own paradigm is the hard part, because the thing doing the looking is the thing you are trying to look at, which is why it so often takes someone outside the pattern to help you see it.

This is the argument underneath my book, Come Prepared to Die. I won’t rehearse it here. The short version is that the structural case and the inner one are the same case seen from two sides. The person who owns the design can’t delegate the work of examining the assumptions behind it, and no title, and certainly no model, can do that work on their behalf. For the change to outlive them, its decision rights, rewards and governance also have to become properties of the organisation rather than permissions rented from one sponsor.

The uncomfortable question

If you are standing up an AI transformation right now, ask a narrower and more uncomfortable question than which tools to buy. What is your organisation actually optimised for? Who holds the authority to change that? And does the person holding it know what you know? If the effort is once again boxed into the delivery corner and handed to someone without the remit, then you already know how it ends.

I work with CTOs and CPOs at software companies with roughly 25–500 engineers, where the engineers are faster with AI and the business isn’t yet seeing the full value. The assumptions this piece works on are often part of what’s delaying it, and I help leaders find and test their own. If it’s live for you, book a free 30-minute call at hi.chrisgagne.com and bring the one question that would make it worth your time. If you know a CTO or CPO in that spot, pass this piece on. If you’d rather read on than talk, the newsletter goes on past chapter 23, monthly, at https://www.linkedin.com/newsletters/come-prepared-to-die-7472144387981062144/

Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.

You defended a decision after it failed. The decision was a hypothesis, and a hypothesis that fails is data. When a decision fails, reading the result and protecting yourself become two jobs competing for the same moment, and it is easy to mistake the second for the first.

Chapter 9 made outcomes the unit of management. When the outcome misses, does the leader defend the decision or ask what it taught them?

The two poles

Pole A: attached to outcome. The decision must yield this result. If it doesn’t, the decision was wrong.

Pole B: attached to inquiry. The decision was a test of a hypothesis. The outcome is data. The question is what to learn from it.

This doesn’t reverse chapter 9. Outcomes are still the unit of management; a missed outcome is exactly the signal that the decision was a hypothesis. Pole A’s error isn’t caring about the outcome. It is fusing the decision’s rightness⁠—and the leader’s⁠—to whether this particular outcome was achieved.

Where Pole A is right

Pole A is right when accountability requires defending the commitment. That may mean contractual delivery against a signed scope, a public commitment to investors with material implications for share price, or a regulatory commitment where non-delivery could cost the organisation its operating licence. Some crisis communication demands the same discipline: the leader may need to hold a position in public for months while the team works on the underlying problem.

The leaders I have worked with in those domains had good reason to default to Pole A. Defending the commitment was their job, and the discipline they built doing it made them trustworthy enough to lead where keeping a commitment mattered. That same discipline built the relationships with boards, investors, regulators, and key customers where a senior leader now has standing, and none of it was waste.

Pole B depends on that trust. The senior leader doesn’t need to apologise for having earned it.

Where Pole B is right

Pole B is right when the decision was a hypothesis dressed up as a commitment, or when defending it is doing more for the leader’s identity than for the outcome. The second case is harder to see from inside because defending commitments under uncertainty is a discipline most leaders have built over a career.

Most decisions made in complex conditions under uncertainty are hypotheses. The leader makes them with limited information and under time pressure, while the team still needs something definite to work towards. Accountability often demands the language of commitment because that language helps the team coordinate. The leader who speaks commitment in public can still be running inquiry in private.

The leader who speaks commitment in public can still be running inquiry in private.

Once the leader treats the decision as settled, inquiry becomes much harder.

Counterfactual thinking as identity-protection

Amy Edmondson, in Right Kind of Wrong, uses a classic Olympic-medallist study to show how framing decides whether a result is felt as failure at all. Bronze medallists framed their result as a success (a medal at the Olympics!), while silver medallists framed theirs as a failure relative to gold through what psychologists call counterfactual thinking.

The counterfactual governs whether an outcome is even felt as a failure. The silver medallist’s if only is Pole A’s emotional signature.

A related obstacle to learning is what Edmondson calls self-serving analysis: “I was right, but someone or something else messed it up.” It protects identity rather than learning from the result.

Counterfactual rumination has a recognisable form: if only X had gone differently, the decision would have worked. I told myself a version of it for years. In 2014 I published a list of recommended Agile reading, put Jeff Sutherland, Scott Downey and Björn Granvik’s shock-therapy paper on it, and noted that I’d prescribe the same thing: adopt Scrum 100% from the start. Going back to it now, the paper is stricter than I had remembered. The coach sets the rules, and a team earns the right to change one only after “three consecutive, successful Sprints”, a “240% increase in Velocity” and a business reason every member agrees to; the Scrum framework itself never changes. When a team fell short, the paper found the cause in enforcement: the one low-performing team was the one whose Scrum Master “failed to enforce constraints”. The belief that produces is closed. A team that broke through had proved the rules; a team that hadn’t broken through had not yet earned the right to question them. Nothing a team did could count against it, and that took me years to see. A leader practising inquiry can stay with a harder account: the decision didn’t work; here is what it taught us; here is what we will hold differently.

Both responses look similar from the outside. They diverge in what happens next: one goes looking for evidence, the other for a version of events in which the call was right.

Edmondson’s four criteria

Pole B requires more than openness or humility. In Edmondson’s teaching on how to fail well, an intelligent failure meets four criteria:

It enters new territory: no one had the answer in advance.

It serves a goal worth the attempt.

It is informed by available knowledge: you had reason to believe the hypothesis could be right, and the failure isn’t one your homework would have caught.

It keeps the risk as small as possible while still producing meaningful learning.

A bonus: the learning is mined and shared, so the failure doesn’t recur.

Edmondson separates intelligent failure from error: “Error implies that there was a ‘right’ way to do it in the first place. Intelligent failures are not errors.” The Pole A leader who treats every failed decision as an error to be explained is using a vocabulary that doesn’t fit the work.

Edmondson’s failure taxonomy has three types:

Basic failures are caused by error in known territory.

Complex failures occur when multiple causes line up, warning signs get missed, and a recovery window closes unused.

Intelligent failures are the ones that clear those four criteria.

Every failure is worth learning from; inquiry isn’t reserved for the intelligent kind. What the criteria help judge is narrower: whether the failure was worth running, or whether it is an avoidable mess dressed as a noble experiment.

Toyota Kata: problems are jewels

Mike Rother’s Toyota Kata puts Pole B into daily lean-improvement practice. The improvement kata runs through PDCA cycles in which each obstacle becomes the next thing to learn from. “Problems are jewels” is the Toyota colloquialism: the problem is the curriculum.

The mentor asks the mentee five questions:

What is your target condition?

Where do things actually stand right now?

Which obstacles are now in the way of reaching the target condition, and which one are you tackling next?

What will your next step be?

When can we go and see what that step has taught us?

Question 5 prompts inquiry. The next step is an experiment with a specified learning horizon, and the next coaching cycle starts by examining what was learned.

The kata turns Pole B into a daily practice the team holds together. Inquiry no longer depends on one leader’s capacity to sustain it alone.

Embrace change, then pivot

The engineering half of Pole B’s precondition is familiar: a team that can refactor, pair, and integrate continuously doesn’t need to defend yesterday’s design when today’s evidence contradicts it. Continuous integration makes the technical pivot cheap. AI-assisted refactoring and code generation push the cost of change lower still.

But cheap-to-change code isn’t enough to pivot a strategy, and the harder precondition is organisational. To pivot is to abandon work already in flight. A team running several epics at once to keep everyone busy⁠—the high-utilisation trap from chapters 4 and 7—faces writing off several of them at once to pivot, so it is tempted to defend the plan instead. The team carrying one small bet can drop it and turn. Low epic-level WIP makes a pivot affordable; high WIP pushes toward Pole A even when the leader wants Pole B. The context keeps the team shipping yesterday’s answer after today’s evidence has disproved it because the sunk cost is too high to accept.

A pivot follows validated learning: we tested a hypothesis, the evidence came in, and the next hypothesis follows from what we learned. A board is more likely to absorb that when the evidence, the learning, and the next test are all on the page. An unexplained reversal is a harder sell. The difference isn’t that the words are prettier. A pivot names a decision still under inquiry; abandonment names a retreat.

A pivot names a decision still under inquiry; abandonment names a retreat.

This is chapter 9’s practice at the strategic level: we named the bet, said what it should produce, read the result, and named the next bet. The board still gets its number, the same trade chapters 7 and 9 made.

The protector part’s job

When a failed decision threatens a leader’s identity as competent, what Internal Family Systems calls a protector part—here, the Defender⁠—generates counterfactuals and attributes the result to factors outside the leader’s control. The leader appears confident. Inquiry has stopped.

Pole B calls for recognising the Defender part, naming what it is defending, and asking it to step back and give space so the rest of the leader’s judgement can engage the evidence. Chapter 11, Just This, takes up that work directly. A leader who is actually confident, sure of the value they bring, can be wrong now and then and interrogate their own decisions without waking the Defender.

A representative case

Picture a Series A founder who has committed publicly to a particular customer segment (the commitment is in the deck the investors funded). Six months in, customer-acquisition cost in that segment is running well above the model’s projection and the success metrics are trending the wrong way, while the team has begun landing customers in an adjacent segment where the numbers are far better.

Across a series of leadership meetings, the founder defends the original selection with increasingly sophisticated arguments. By the third meeting the arguments are more sophisticated than the numbers are good. That reads two ways around the table: rigour about a hypothesis the team hasn’t properly tested, or a leader defending a choice. The founder holds the first reading.

In this case the intervention comes from outside. In a one-on-one, an outside coach asks, what would it cost you to publicly update the strategy? The real answer names the cost: the founder’s identity as the leader who picked the right thing, and the investors who will read the update as the founder was wrong. Over several weeks, the founder works through that cost and updates the strategy in a board memo, describing the change as a pivot informed by six months of validated learning. The pivot language gives the board a way to absorb the change.

The board’s response surprises the founder. They are relieved; they had been wondering when the founder would name what the metrics had shown for two quarters. In Edmondson’s terms, the founder nearly squandered a recovery window.

Honour what was genuine in the original defence. The founder was also doing part of the job well: holding the strategy through enough friction to test it. A genuine commitment and the Defender were operating on top of each other. Updating both lets the founder enter the next decision with judgement and identity intact.

The diagnostic

Three questions for last Tuesday’s post-mortem.

• Which pole was I claiming? In the language I used about the failed decision, did I describe it as a hypothesis we tested, or as a commitment we kept (or failed to keep)?
• Which pole did my response show? When the evidence came in, did I generate alternative pasts where the decision would have worked, or did I stay with what the evidence taught us?
• Which pole does the work require? If the accountability frame genuinely requires defending the commitment in public, Pole A is defensible. If the public commitment is being used to keep you from treating the decision as a live hypothesis, the Defender is running.

The failed-decision post-mortem is where this choice bites hardest at the top. If you sit in the CTO or VPE chair, have the private conversation with the CEO. Bring one specific decision from the past quarter that didn’t work and ask, not what went wrong but what hypothesis were we testing, and what did we learn?

Ask it in private first. If the CEO can work through the learning in a one-on-one, they can carry it into the board conversation.

If the Defender is running strongly, drop the diagnosis and ask the question that gives it space: what would make updating this strategy safe to say out loud? Sometimes the answer is data; sometimes it is a sponsor’s backing, a staged disclosure, or wording that keeps the legitimate commitments intact. The sentence your CEO can carry to the board is, “We learn at the rate we can say a decision didn’t work.”

We learn at the rate we can say a decision didn’t work.

Chapter 7’s optimum failure rate is the aggregate version of this: cheap experiments should fail about half the time. A team whose exploratory bets almost never fail is probably running confirmations, and confirmations teach little. A failure rate near zero on exploratory work is worth examining: it is often Pole A in the language of excellence.

The exercise

Apply the Toyota Kata five questions to your next stuck decision. Pick a current open question where you have been defending the position you committed to two months ago, then walk through the questions with a coach or peer who isn’t invested in the answer: target condition, actual condition, obstacles, next step, and the question, when can we go and see what that step has taught us?

If you can’t specify a date by which the next step’s learning will be visible, you are still running Pole A. The Pole B answer specifies the learning horizon.

For the companion exercise, the decision audit, take a recent decision that didn’t work. Did you defend the decision or refine the model? Name your response out loud to someone you trust enough to disagree with you. The harder, identity-level work starts there.

Going upstream

In-text: Amy Edmondson, Right Kind of Wrong, on the four criteria for intelligent failure, the three failure types, and the counterfactual-thinking pattern; Mike Rother, Toyota Kata, on problems are jewels and the five coaching questions.

Also touched: The protector named here as the Defender is Internal Family Systems language (Richard Schwartz, No Bad Parts); the Just This chapter works it directly.

Go deeper: Kent Beck, Extreme Programming Explained, on embrace change and the continuous-integration discipline that makes pivoting cheap; Eric Ries, The Lean Startup, on the pivot and validated learning; and Taiichi Ohno, Toyota Production System, on overproduction, the waste behind the many-epics-in-flight trap above.

Watch. Astro Teller, The unexpected benefit of celebrating failure (TED, 16 min). Kill-and-pivot stories from Alphabet’s X: bonuses paid to everyone on teams that chose to kill their own projects, from pairs to groups of 30+.

Ten chapters in, the tools have become something to grip, and the grip tightens with every one you add. Every framework in this book becomes a trap the moment you obey it instead of using it.

Chapter 11, Just This, asks you to notice that reflex before choosing a tool. The one you pick up first may already be telling you what to see, before you have met the situation actually in front of you.

I work with CTOs and CPOs at software companies with roughly 25–500 engineers, where the engineers are faster with AI and the business isn’t yet seeing the full value. The assumptions this chapter works on are often part of what’s delaying it, and I help leaders find and test their own. If it’s live for you, book a free 30-minute call at hi.chrisgagne.com and bring the one question that would make it worth your time. If you know a CTO or CPO in that spot, pass this chapter on. If you’d rather read on than talk, the newsletter goes on past chapter 23, monthly, at https://www.linkedin.com/newsletters/come-prepared-to-die-7472144387981062144/

Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.

Russell Ackoff liked to “build the best car in the world” as a teaching example. Take one of every make sold in America, he said, and have your engineers pick the best of each part: the best engine, perhaps the Rolls Royce; the best transmission; the best alternator; the best of every component a car needs. Now bolt those best parts together into one automobile. You wouldn’t get a functional automobile.

The performance of a system isn’t the sum of the performance of its parts. It is the product of how those parts interact, which means you can improve every part on its own and wreck the whole doing it with far less effort or neglect than you might have expected.

Eli Goldratt put it in a sentence: a system of local optimums isn’t an optimum system at all; it is a very inefficient system. The way most senior leaders structure improvement work⁠—every department on its own metric, optimised in parallel, the whole supposedly improving as the sum⁠—is wrong in any system whose parts share constraints.

Chapter 7 treated the plan as a hypothesis. When functions share a constraint, parallel optimisation can reduce total throughput, so where in the system that hypothesis concentrates matters.

The two poles

Pole A: local optima. Improve each department on its own metrics. The whole will improve because it is simply the sum of the parts. Run the function-level reports; reward the function leaders who move their numbers; trust composition.

Pole B: system constraint. Identify the one constraint that limits the whole. Exploit it. Subordinate everything else to it. Decide what will raise throughput, and protect it. There is a greater wholeness that is more than just the parts; it emerges when those parts interact.

Pole A is right in some contexts, while Pole B is the operational discipline most engineering leaders need to recover. Pole B rests on one deeper claim: a constraint helps organise the system.

Where Pole A is right

Pole A is right only when the system genuinely decomposes. That includes independent product lines with no shared engineering and separate geographies running their own supply chains. Decoupled value streams with no shared bottleneck resource also qualify. The clearest case is low-variability work run in independent operations whose bottlenecks don’t interact, so optimising each step in isolation adds up to a better whole.

Most senior leaders inherit Pole A from a time when their mandate was smaller and easier to decompose, and the local metrics genuinely did roll up. The reports were true then. The discipline you built while running departmental P&L reports got you here; none of it was wasted. The question is whether that discipline still fits the system you run now.

In contemporary knowledge work (most software, product development, and cross-functional services), operations rarely decompose so cleanly. The output of resources and people passes through shared bottlenecks, as do queue capacity and management attention (even when the org chart hides them). Most systems that leaders expect to break into independent parts won’t.

Where Pole B is right

Pole B is right where events depend on prior events and demand varies. In Goldratt’s manufacturing context, improving local efficiency on non-bottleneck resources reduced total plant throughput by pushing more work onto the bottleneck and consuming time that couldn’t be recovered.

Deming’s funnel experiment, walked in chapter 6, makes a neighbouring point for a stable process: adjusting after every miss caused by ordinary variation makes the output less stable, not more.

Pole A leaders set utilisation targets per function and ask whether each function is fully booked. Pole B leaders ask which one resource is governing how fast the whole system can move today, then protect it. Their rigour lies in subordination: they choose what can wait so the constraint can work.

At one client, I led more than 30 stakeholders, C-level leaders among them, through ranking the whole organisation’s epic portfolio. They voted on pairs of epics in Delphi rounds, holding up Plickers cards to show a strong or moderate preference for one or the other. The engineers ranked each epic on complexity, uncertainty and effort. Once lower-ranked epics were stopped or cut, work in process fell overnight and the teams started turning out work fast. I have little to no recollection of getting everyone onto a single backlog like that before.

CTOs and VPEs: a constraint that sits inside engineering is yours to work. One that crosses functions, or needs capital or a change to the org structure, needs CEO sponsorship. For that second kind, put the actual constraint in front of your CEO (the one resource, decision, or capability governing the speed of the whole engineering system), alongside the current investment split across functions. The CEO then authorises the subordination of non-constraints, usually by defending the Pole B investment against pressure from other function heads whose metrics suffer when their resources serve the constraint instead of their own dashboards. Your CEO can carry that choice to the board in one sentence: “One constraint sets our speed; every other optimisation is spend that does not raise throughput.”

Goldratt’s five focusing steps

In the Theory of Constraints, first identify the constraint. Second, decide how to exploit it, squeezing every useful hour from the bottleneck before adding capacity. Third, subordinate everything else to that decision, so non-constraints serve the constraint’s pace instead of their own. Fourth, elevate the constraint by adding capacity once exploitation is maxed. Fifth, return to step one because the constraint will move as soon as you fix the current one.

Goldratt wrote the warning in step five in capitals: go back to step one, but don’t allow INERTIA to become the system’s constraint. Yesterday’s exploitation rules and subordination policies can outlive the constraint they were built for. They harden into the new constraint.

The five steps force a CEO-level choice about which function’s metric is allowed to wait. In software development, I suspect the switch to a single backlog later in this chapter is the most consequential application. Step five is where inertia bites: the architecture review board that once caught real problems, kept after the teams learned to catch them earlier, becomes the queue every change now waits in. The same ageing happens to leadership rules. A CTO who makes every architecture call personally may not show up as a constraint at ten engineers; at 200, that habit is what the rest of the work queues behind.

The doctrine is right as far as it goes. It usually leaves out the people whose continuous adjustments make a constraint productive.

Juarrero: constraints are causes

Alicia Juarrero’s distinctive contribution to the philosophy of action, in Dynamics in Action, is that constraints structure action and make it possible. I read that as giving Goldratt’s claim its causal basis and changes what constraint means. In a hierarchical organisation, constraints link levels by closing off alternatives at one level and opening new ones at another.

The kind operations leaders need she calls a second-order context-sensitive constraint: parts interact until the whole they form starts limiting and steering those same parts. A shared review queue is the everyday case. No one designs it as a governor, but once every team routes work through it, the queue’s depth begins deciding what each team can start, and the teams that created it now take their pace from it.

Goldratt’s constraint, whatever most limits the system’s throughput, becomes the organising principle around which the rest of the system works. It changes what is possible. Subordination recognises that the constraint helps hold the system in coherent operation.

The plant’s bottleneck sets the rhythm for everything upstream and downstream. A hospital’s emergency department is where the rest of the hospital’s flow rates are settled. On an engineering team, a senior architect may be where open design questions are forced into closure. A leader who treats the constraint only as a restriction will optimise around it; a leader who treats it as a cause will build the rest of the system to support the work it does.

Treat the constraint as a restriction and you optimise around it; treat it as a cause and you build the system to support it.

People continuously create the structure

Juarrero’s account changes how I read the subordination step: the constraint matters because people continuously adjust around it. Practitioners hold its productive structure in place through moment-by-moment compensation for the conditions it creates. Stop that compensation and the constraint becomes a bottleneck with none of the work around it that made it useful.

An engineering manager who treats the constraint as a mechanical feature to optimise around will miss the operators’ continuous work of creating structure. The team may read that optimisation as a vote of no confidence in their judgement and scale back the small adjustments they had been making. The system then degrades in ways the manager can’t read until something visible breaks. The constraint didn’t get worse. The work around it did.

The constraint didn’t get worse. The work around it did.

Pole B asks leaders to identify the constraint and name what practitioners already do to make it productive, then protect that work from optimisation programmes that would interfere with it.

Snook: the fallacy of social redundancy

Scott Snook’s Friendly Fire shows how social redundancy can make a system unsafe. In the 1994 Black Hawk shootdown met in chapter 5, 26 people died while an AWACS aircraft watched. The AWACS had 19 crew members. “More people looking over shoulders than there were shoulders to be looked over.”

Snook calls the operating assumption the fallacy of social redundancy. Technical systems add redundant components to cut the chance of an accident, but the group dynamics of the shootdown led Snook to conclude that two controllers needn’t beat one, and four leaders can be worse than two. Technical redundancy assumes that components are independent. People are interdependent, so adding more of them can diffuse responsibility, Latané and Darley’s bystander mechanism named in a different domain 26 years earlier.

Pole A usually answers a near-miss with more oversight: reviewers, approvers, and escalation paths. Snook argues that this can make the system less reliable. My reading for this chapter: clear ownership of the constraint, with leaders protecting the people who hold it, does more than another layer of oversight.

Team-level backlogs are local optimums that cap revenue

A bottleneck step, a senior architect, and an AWACS crew all make the constraint visible as a resource, person, or team. I met another form every day for years without recognising it, until a short film named it for me: several backlogs where the product needs one.

The film is by Michael James, Benjamin R. Leffler and Yoko Hinoue. James is a Scrum trainer whose work I keep sending to clients; the film sits on the LeSS channel, and the idea runs through Bas Vodde and Craig Larman’s work on Large-Scale Scrum (LeSS). When an organisation scales from one team to many, it usually gives each team someone to act as product owner, then asks that person to manage a team backlog and grow team output. James calls this deviation a “team output owner” because output is what the organisation rewards with its design, if not its platitudes.

Each team output owner orders a private list to deliver the most value they can see, and each is doing thoughtful, careful work. The system sets the trap. “Keeping separate team backlogs, separate lists obscures this problem,” James says. “Our team’s top priority is less important than the work other teams don’t even have time to start.” Vodde and Larman’s remedy in LeSS is a single product backlog, one Product Owner with real authority, and teams that self-select from the shared ordering.

Imagine three teams, each able to ship three items in a sprint, with each team working from its own backlog. Team one has items worth $100, $90, and $80 at the top, followed by $70, $60, and $50. Team two has $30, $20, and $10, then three $5 items. Team three has three $10 items, then three $5 items. With three owners and three lists, each team ships its own top three: team one delivers $270, team two $60, and team three $30. The organisation delivers $360. Every team is busy, and every team is shipping the best work on its list.

Pool those lists and choose nine items for the whole product. The top nine are $100, $90, $80, $70, $60, $50, $30, $20, and $10. The same nine slots of capacity now deliver $510, with the same people working at the same pace. Pooling drops the three $10 items that team three would have shipped and uses those slots for team one’s stranded $70, $60, and $50. The extra $150 was sitting below a line drawn by the org chart while team three shipped small change because small change was the best work it could see. Goldratt’s sentence describes the prioritisation layer as exactly as it describes the plant floor: a system of local optimums isn’t an optimum system.

I didn’t want to trust a toy example on its own, so I built the measurement into Delivery Intelligence, the cost-of-delay tool from chapter 4, and ran it against the live backlogs of three value streams, 25+ teams in all. For every story, it forecasts three completion-date ranges from the same points-over-velocity arithmetic, using three widths of pooling, each range running from a P70 to a P95 date rather than a single point. A Team ETA uses one team’s throughput. A Capability ETA uses every team in the capability, while a Value Stream ETA uses the whole value stream. In the forecasts, the wider pool reaches the highest-ranked work sooner, for the same reason the pooled backlog beat the three private ones.

The tool also flags the failure directly. When a story’s Team ETA is meaningfully sooner than its Capability ETA, the tool marks it as a local optimum: fast on its own list, but sitting where the most valuable work isn’t. The mark fired more often than I would have liked. Each one is an example of the same trade as the $360 that should have been $510, one story at a time, as the forecast sees it; the forecast assumes another team could pick the work up, so each is a candidate to check rather than a loss already counted. Where work is genuinely team-local, the Capability and Team ETAs agree and no mark fires, which is what makes the flag worth reading when it does.

The obvious objection to one list is that teams can’t pull each other’s work: different skills, different systems, different context. Larman and Vodde’s LeSS treats that as a condition to grow out of rather than a fact to design around, deliberately encouraging multi-learning and a higher proportion of feature teams, and treating single-specialist teams as a pattern to leave behind. AI cuts the cost of the growing-out, a change since they wrote: an engineer picking up an unfamiliar service now has something that will read the codebase alongside them, explain the local conventions, and draft the first change. A team that can pull any high-value item is therefore the condition worth building toward. Teams don’t have to become identical tomorrow. They keep their skills, context, and sense of a shippable whole, but they self-select from one prioritised list instead of grinding through a private one. Collaboration across a team boundary becomes part of a developer’s job rather than a coordinator’s, and the system begins to reward the multi-learning that makes the next item pullable. In this case, the ordering itself is the constraint. Fragment that ordering into per-team lists and the system manufactures a local optimum at the exact point where it should decide what to build next, the most expensive place to put one.

A representative example

Picture a platform team whose senior architect is the obvious constraint. Every significant design question routes through her, and her calendar is solid for eight weeks. The engineering director responds by hiring a second senior architect to “share the load.”

Throughput falls. After three months, the first architect is spending time coordinating with the second on questions she once answered herself. The team escalates to both of them. Other engineers sense that someone is now responsible for everything and scale back the small, fast decisions they once made on their own. The constraint has been exploited badly. Hiring was the obvious local move and the wrong system move.

The fix is unglamorous. The first architect’s role is renamed, and her decision remit is narrowed to three specific architectural axes where the team needs her critical judgement until they can learn more from her about why she makes the decisions she does. The second architect moves to a different team. For every design question outside those three axes, the other engineers have authority to decide and ship; they bring decisions to the architect after making them.

Throughput recovers. The architect’s calendar opens up, and the team’s confidence in its own decisions returns. The constraint is unchanged (the architect’s judgement on three specific axes), but the system around her now protects the team’s ongoing decision-making instead of interfering with the work only she can do.

In the vocabulary of the five steps, hiring was step four, elevate, run before steps two and three. The working fix uses exploitation and subordination through a policy change, with no new capacity. That is The Goal’s signature result: elevation is the last resort, and the reflex to elevate first is the reflex the five steps exist to interrupt.

Honour what the hire was trying to do. The engineering director sees a stressed senior architect and asks an obvious, humane question: how do I take work off her plate? Pole A answers by hiring another architect, a defensible act of care for one person. Pole B asks what the system has stopped asking of the rest of the team because she is doing it. Both questions are legitimate. The first adds complexity and cost but can’t repair the system on its own.

The diagnostic

Use three questions for last Tuesday’s improvement-programme meeting.

• Which pole was I claiming? When we discussed where to invest in improvement, did I name the constraint, or did I list the function-level metrics each leader had agreed to move?
• Which pole did the improvement programme actually run? Look at the resourcing. How much investment went into the constraint, and how much went into improvements that bypass it? Most programmes I see run the second pattern even when their leaders speak the first language.
• Which pole does the system require? Pole A is sound when the work genuinely decomposes into separate product lines or geographies. When resources, attention, queues, and decisions pass through shared bottlenecks, Pole A produces the inefficiency it is trying to solve.

Start where the three answers diverge.

The exercises

The character factory game

Take five minutes with your team. You have three customers (Letters, Numbers, Vowels), and each wants a complete set of 26: the full alphabet, the numbers 1 to 26, or the vowels repeated out to 26. No customer is happy with a partial set; 25 of 26 is worth nothing. Fold a sheet of paper into three columns, one per customer, and use one side per round, a minute each.

Round one: keep every customer moving at once. Work across the columns (A-1-A, B-2-E, C-3-I), writing one character for each customer, round after round, so nobody waits. Stop after a minute. All three sets will be half-built, with no customer served. I have never seen anyone finish a set this way.

Round two: finish one customer, then the next. Write the full alphabet and hand Letters a complete set; write the numbers, then the vowels. Stop after a minute. You will deliver at least one finished set, usually two, and sometimes three. Your hand moved at the same speed in both rounds. The delivered value changed.

This is the subordinate step made physical. Round one treats all three customers as equal claims on the hand and finishes nothing; round two picks one, lets the other two wait, and delivers. The game makes the cost visible: two customers wait while you finish the first. That is exactly the discomfort the five focusing steps ask a leader to hold. Subordination means letting non-constraints wait, and the reflex to keep everyone moving serves nobody.

The lesson concerns how many things the system carries at once. The game produces silence, then an “oh.” Writing a, b, c, d, e is easier than a, 1, A, b, 2, E because every jump between customers asks the mind to reload a different context; real product development pays the same switching tax. A team that keeps four features half-built pays that tax every time it moves between them, so the same people ship less than they would by finishing one and then the next, with no change in effort. The character factory is a minute-long rehearsal of what a quarter of scattered work does to a team.

The game descends from Henrik Kniberg’s Multitasking Name Game; I learned the letters/numbers/Roman-numerals variant from Monica Yap and replaced Roman-numerals with repeating vowels to lower the cognitive load.

Goldratt’s Dice Game

Also consider the Dice Game, sometimes called the TOC simulation. Put six stations in a line and give each station a die. Each station rolls and produces its output, which becomes the input to the next. Run 20 rounds. Track output per round against the average die roll of 3.5.

Output per round falls below 3.5 in almost every run, and the shortfall adds up round after round. Variability combines with dependent events: a downstream station can pass along only what arrived from upstream, so high rolls are wasted while low rolls leave inventory between stations. Throughput stays below capacity while the piles grow. In 15 minutes, the game makes Goldratt’s claim physical. Ask players to look at where output has piled up before you debrief; those piles are the queues the rest of this book teaches leaders to read. The visible inventory makes the cost of parallel local optimisation harder to dismiss in the debrief.

Identify the Brent

In The Phoenix Project, Brent is the engineer every project routes through. Most teams have someone in that role. Name yours out loud. Then ask: what would the next step be if Brent left? The answer reveals where the constraint actually is.

Going upstream

In-text: Eli Goldratt, The Goal (the canonical novel), gives us the five focusing steps, the claim that a system of local optimums isn’t an optimum system at all, and the step-five inertia warning. Alicia Juarrero, Dynamics in Action, Ch 9 on the three orders of constraint, supplies the claim that constraints are causes. Scott Snook, Friendly Fire, Ch 4, names the fallacy of social redundancy.

Watch. Eli Goldratt, Lectures: Thinking Globally (10 min). Its companion on constraint physics is the Theory of Constraints (TOC) 3 Bottle Oiled Wheels Demonstration (5 min).

On the backlog as local optimum, watch Michael James, Benjamin R. Leffler & Yoko Hinoue, How Misconceptions About the Product Owner Role Harm Your Organization (video, 9 min), for the team-output-owner pattern and the single product backlog as its remedy.

Also touched: W. Edwards Deming, Out of the Crisis, on common-cause variation and the funnel experiment. Russell Ackoff’s best-car example is from his filmed conversation with Deming (the interview tapes, transcribed at github.com/tonyaajjackson/deming-ackoff-transcript). Gene Kim, Kevin Behr and George Spafford, The Phoenix Project, for Brent. Henrik Kniberg’s Multitasking Name Game, which the letters-and-numbers game descends from.

Craig Larman & Bas Vodde, Large-Scale Scrum, give the single-product-backlog remedy and the structural argument against per-team backlogs. I first met that argument by way of Larman’s CLP/CLE course.

Go deeper: two other traditions make the same operational claim. Richard Cook, How Complex Systems Fail, Points 16 and 17, treats safety as emergent and created through people’s continuous adaptation (Chapter 15 develops this and its inversion under AI). USMC, MCDP-1 Warfighting, Ch 4, gives the main effort and Schwerpunkt, the same subordination discipline. For the systems-archetype reading, see Peter Senge, The Fifth Discipline, especially shifting the burden and the tragedy of the commons.

An engineering organisation can raise throughput every quarter while the people paying for its software feel no change. That gap is where a feature factory lives. Output and outcome differ; subordinating everything to the constraint pays only when that constraint drives the right number. In chapter 9 you ask which number your work is actually judged on.

I work with CTOs and CPOs at software companies with roughly 25–500 engineers, where the engineers are faster with AI and the business isn’t yet seeing the full value. Improving any step but the constraint adds cost without speed, so I find the one setting your pace, such as a review queue or backlogs split by team. If it’s live for you, book a free 30-minute call at hi.chrisgagne.com and bring the one question that would make it worth your time. If you know a CTO or CPO in that spot, pass this chapter on. If you’d rather read on than talk, the newsletter goes on past chapter 23, monthly, at https://www.linkedin.com/newsletters/come-prepared-to-die-7472144387981062144/

Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.

Your plan isn’t a commitment, even if you’ve made, received, or even extracted one about it. It is a hypothesis with an expected outcome and a date you sincerely hope reality will deliver on.

Chapter 6 moved the lever off the people and onto the conditions they work inside: a behaviour that every deadline punishes won’t hold, however hard you push the person. One of the biggest conditions a leader can set is ‘the plan’ itself.

The two poles

Pole A: plan as commitment. Strategy as document. Vision as destination. Decide early; execute against the commitment. Variance reads as failure.

Pole B: plan as hypothesis. Strategy as verb. Set direction; find adjacent possibles. Treat each plan as a hypothesis with an expected outcome. Check what actually happened. Act on the difference. Cross the river by feeling the stones.

Plans are useful. Boards and investors ask for them; contractual commitments need them. My sense is that this is shifting⁠—some boards and investors now prize the responsiveness of a team that can re-plan over the reassurance of a plan that won’t move⁠—but the ask still arrives. A team without any plan is a team performing improvisation as a personality trait. The question is what the plan is for, and what the leader does when reality and plan disagree.

Where Pole A is right

When the planning horizon closes before conditions can shift around it, the cost of changing the plan is high, and accountability requires commitment. Some examples: manufacturing the next batch of pharmaceuticals on a stable specification, building the bridge whose engineering has been certified, closing the quarter’s books under a fixed regulatory window, and running the integration cutover whose vendor contracts can’t be moved.

In those domains plan-as-commitment is sound. The variance from plan really is diagnostic and the team’s job is to close the gap. The learning mostly happened during the design phase, and execution comes close to being just execution. Still, close isn’t identical: even the mature line keeps a gap between the procedure and the floor for the unexpected.

Most senior leaders I work with came up through some version of that domain. They learned plan-as-commitment in their twenties and thirties from leaders running it well. What if none of it was wasted? The discipline you built in those years is the discipline that lets your team ship anything at all. The job now is to notice the situations where it has stopped fitting, and to make Pole B available without abandoning Pole A.

Where Pole B is right

When none of the conditions above hold. Most software-permeated work, strategy, and market positioning under technological change. Most product decisions. Most situations where the rate of change in the conditions outside the firm has begun to exceed the rate at which the firm can update its plan from inside.

Mary Poppendieck named the broader pathology “the tyranny of ‘the plan’” and traced the origin of its doctrinal instrument⁠—the PERT chart⁠—to the Polaris submarine programme in the late 1950s. The doctrinal history inverts the version most leaders were taught.

PERT charts weren’t invented because they worked as planning instruments. Poppendieck’s reading of Harvey Sapolsky’s 1972 history of the Polaris programme is brutally disillusioning. As she tells it, the programme’s own technical officers worked around PERT because they judged it unreliable, and the contractors saw it as worthless; it survived only because it kept the money flowing. William Raborn needed something he could show Congress to keep the programme funded across multiple election cycles. PERT was that something. Poppendieck’s gloss: Raborn used PERT as a façade to keep Congress funding the programme, presenting it as a fail-proof management system that no longer depended on people but on the system itself.

This pattern outlived Polaris. A board asking for a one-to-two-year plan is asking a fair question⁠—can this team deliver?⁠—with the instrument it has been handed. What the board needs is performance and a way to hold uncertainty; what it asks for is the plan, because the plan is the artefact that looks like control. That was Raborn’s discovery; my read is that a plan can still do that job for a board today. Weighting for risk is a CFO’s bread and butter; nobody in that boardroom reads the schedule as a promised return. The damage happens when the plan is received as a commitment: everyone downstream must now act as if the risk were smaller than it is.

What actually made Polaris work was reliable workflow and people who kept control of their own decisions. Levering Smith, the technical director, held the requirements himself, his personal signature on every key interface drawing for the first eight years. (I don’t think this would carry forward to most complex knowledge work these days.) Three contractors competed on each major subsystem⁠—set-based design, running rival designs in parallel, is nobody’s idea of efficient⁠—and the best design won. Technical officers acted on what they were learning in real time, not on what the PERT chart said.

Unfortunately, this façade became literal doctrine. On Poppendieck’s account, parts of later project-management training, PMI’s included, got built on planning rules the original programme never used.

The doctrine encodes a simple mechanism: decompose the work, sum the estimates, call the total your schedule, and manage to it. (Reinertsen’s flow economics separates those steps: summing gives a fair estimate of total scope, but scheduling at task level buries the signal in noise, and pressing people to conform to that schedule buys contingency padding that lengthens the timeline.) When reality diverges⁠—and by goodness it will⁠—the paradigm reads the gap as an execution problem: escalate, replan, trade scope. Those responses are often locally right. The other reading, that the plan was a hypothesis and the divergence is information, isn’t available in the design, because the org is split into people who plan and people who execute, and in knowledge work that split was never real. If you have ever sat on the executing side of that split, none of this surprises you.

The design⁠—planners who think, executors who comply⁠—is Theory X dressed up as project management. Variance from plan is the signal; conformance is the definition of success; and the harder people try to execute a wrong plan, the less the organisation learns about why it is wrong, because under conformance pressure it isn’t safe to say so.

Mintzberg’s institutional critique

Henry Mintzberg, author of The Rise and Fall of Strategic Planning, studied how strategy actually gets made inside large organisations and concluded that planning doesn’t make strategy: companies plan once they already have intended strategies, so planning elaborates and programmes strategies already formed. The plan can coordinate what the organisation has begun to do; it doesn’t originate it. The pretence that it did is what damages the organisation’s ability to learn from the decisions it actually made.

Mintzberg names three fallacies planners fall into: that the future forecasts cleanly enough to plan against (predetermination), that the strategist can stand outside the work to design it (detachment), that decomposition and procedure can stand in for synthesis (formalisation). They collapse into one line of his: because analysis isn’t synthesis, planning isn’t strategy.

Mintzberg’s prescription was crafting strategy, the title and argument of his 1987 Harvard Business Review article: strategy-making as a craft, “as different from planning as craft is from mechanization.” His image is the potter at her wheel, shaping clay she knows intimately⁠—”managers are craftsmen and strategy is their clay”⁠—rather than the architect drawing a building from a plan. Strategy emerges from action, and action keeps testing it. Strategies are partly deliberate and partly emergent in every real organisation.

The hindsight problem

Pole A’s confidence in variance-as-failure rests on the plan looking reasonable after the fact, a dependency the planning literature rarely makes explicit. The plan that “should have worked” is a retrospective construction; hindsight has stripped the live uncertainty out of the historical record. Variance reads cleanly as failure only because the plan reads cleanly as the right plan.

Sidney Dekker, citing Fischhoff’s 1975 work on hindsight, puts the cognitive effect plainly: once you know an outcome, you raise your estimate of how likely it always was, and as a reviewer who knows how the event ended you overstate your own ability to have predicted and prevented it, all without noticing the bias at work. In folk terms: hindsight is 20/20.

The variance from plan that Pole A reads as failure is partly a real signal about execution and partly a hindsight artefact. The Pole B leader can’t eliminate the hindsight bias; nobody can. What you can do is design plans whose variance carries information about the conditions that produced the variance, rather than plans whose variance only carries information about the team’s commitment.

Safe-fail rather than fail-safe

Alicia Juarrero’s Dynamics in Action gives the architectural principle: in complex systems, you can’t design failure out. The system has too many interactions; the conditions are too underspecified; the future is too dependent on local adjustments you can’t anticipate. Juarrero’s own claim is that trying to design fail-safe social systems⁠—legal, educational, penal, or otherwise⁠—that never go wrong is hopeless. The only viable alternative, she argues, is to assemble safe-fail family and social organisations: structures flexible and resilient enough to limit the damage when things go wrong.

The architecture of safe-fail is the architecture Pole B requires. Smaller batches. Faster feedback. Reversible decisions where reversibility is achievable. Multiple parallel small bets instead of one large commitment. Plans whose failure modes were anticipated in the planning, with recovery designed into the architecture rather than punished after the fact. (Chapter 14 takes safe-fail into incident response.)

A plan that ignores this is performing commitment.

Validated learning

At one engagement, I handed the teams their first bottoms-up forecast and cautioned in the same breath that it would be off by at least a factor of two. It was still the best we had, because it was built from backlog items with real acceptance requirements rather than vague targets. I also told them the Cone of Uncertainty would narrow as we went. I was repeating what everyone repeats. Todd Little measured it: across Landmark Graphics’ project data, the uncertainty in the remaining duration, relative to what remained, stayed roughly constant from start to finish, a factor of three to four between p10 and p90, and where there was a cone at all, it ran inverted. He called it the pipe of uncertainty. That strengthens the case for holding a plan as a hypothesis: a number and an error bar, with no promise that the bar shrinks on its own, is the shape a Pole A board can hold. Pole B doesn’t manage to the plan. It manages to the smallest test that resolves the largest risk. This keeps queues short by refusing to over-plan; chapter 4’s adaptiveness metric measures exactly this. A long roadmap is a queue by another name. The further out it reaches, the longer each item waits before it meets reality, and the more of it reality has already invalidated by the time you arrive. Ryo Lu, the Cursor head of design from chapter 3, put the working posture plainly in a 2025 interview: his team doesn’t really keep a roadmap, “because the world is changing faster and faster, there’s new models dropping every day.”

The long-horizon roadmap went, and my read of that posture is that the short-horizon plan gets denser⁠—specs, acceptance gates, hypotheses about what the next model makes possible⁠—because in agent-driven work the plan is the context the work needs before it can start. The commitment artefact disappeared and the hypothesis stayed, rewritten as fast as the ground moves. If you are mid-flight on an AI re-platforming, model capabilities shift with each release cycle and yesterday’s build-versus-wait call can invert. A six-quarter AI roadmap is the purest case here, already invalidated by the time you arrive. That work is Pole B by construction.

The commitment artefact disappeared and the hypothesis stayed, rewritten as fast as the ground moves.

Tracking learning per unit of investment is what makes Pole B legible to a Pole A board. We committed to learn X by date Y at cost Z. Here is what we learned. Here is the next hypothesis the learning produced. The plan-as-hypothesis disposition gets a vocabulary the board can hold without abandoning accountability. The board still gets a number. The metric is now learning rate, not feature count.

Reinertsen’s principle, from information theory, is that an exploratory test generates the most information when it fails about half the time; validation tests, he says, should pass. Robert Wilson and colleagues showed that, for a broad class of learning algorithms on two-choice tasks, training goes fastest at about 15% error. Reading the two as the ends of a band, with the 15% end on the costly bets, is my own extrapolation, not a claim either source makes. The band gives a board a reality check rather than a target: cheap probes should be failing near half the time, big bets nearer one in six or seven. A plan portfolio that never misses in a volatile market is telling you one of three things: the hypotheses were foregone conclusions, the record is being tidied after the fact, or rescue work is absorbing the variance before it ever reaches the record. None of them is planning.

The doctrinal voice

Marine Corps doctrine⁠—the Corps’s capstone manual, MCDP-1 Warfighting—names the same posture more forcefully than the management version: “We must not strive for certainty before we act, for in so doing we will surrender the initiative and pass up opportunities.” A plan held as a hypothesis is how a leader acts before the certainty arrives.

A representative case

Chapter 1’s fixed-date project ran on exactly that reading: it hit its date, so the plan looked confirmed, while the rescue work absorbed every wrong assumption before it reached the record.

I taught the practices that date defeated. The task now is to name what that discipline once bought⁠—predictability across a launch, a clean integration, an investor round closed on the strength of the document⁠—and then to name what the situation now requires.

The team defending a wrong roadmap usually defends it by interleaving epics, running several at once to keep everyone busy against the plan. That is chapter 4’s high-utilisation trap laid over a stale plan: the wrong work, pushed slowly, in batches too big for anyone to course-correct. The roadmap doesn’t just point the team the wrong way. It multiplies what the wrong direction costs.

The diagnostic

Three questions for last Tuesday’s planning meeting. The point isn’t to grade yourself. The point is to notice which pole was running:

• Which pole was I claiming? In the meeting, when I described what we were doing, did I describe it as a hypothesis we were testing, or as a commitment we were defending?
• Which pole did my response to plan variance show? When the team came in with news that something wasn’t going the way the plan expected, did I demand the variance be closed, or did I ask what we had learned that the plan hadn’t assumed? If I must make commitments, do I build in enough slack for the unknown, ideally using probabilistic forecasting techniques?
• Which pole does this work actually require? If the work is in Cynefin’s Complex domain, the plan was always a hypothesis. The Pole A pretence was costing the organisation the learning. If the work is genuinely Complicated⁠—cause and effect yield to expertise and analysis⁠—with a stable specification, the Pole A response was right.

CTOs and VPEs reading this: the last quarterly roadmap is the artefact to take upstairs, because the commitment-versus-hypothesis split is settled by the accountability language your CEO holds with the board, not by you. Take the roadmap and set beside it the two or three hypotheses it was implicitly testing, rewritten, after the fact, in the format if we do X, we expect to observe Y by date Z. Show which hypotheses were confirmed and which weren’t. The point isn’t to relitigate the quarter; it is to find out whether the team was learning faster than the roadmap was tracking. A CEO who sees that the variance from plan was in fact validated learning⁠—not execution failure⁠—has the vocabulary to carry that story to the board. That vocabulary shift is what lets your team plan straight rather than performing commitment. The sentence your CEO can carry to the board: “Our variance from plan was the learning arriving faster than the roadmap could track it.”

Take it up before your next planning cycle locks; the artefact loses its bite once a fresh roadmap replaces it. You will know it worked when next quarter’s plan ships with its hypotheses attached, and the board’s variance questions shift from “why the slip?” to “what did we learn?”

The exercise

For your next quarterly planning cycle, run a Klein premortem before you lock the plan. Gary Klein’s prescription is straightforward and surprisingly hard to do without flinching. Bring the planning team together. Imagine it is months into the future and the plan has failed. That is all anyone knows. Each person writes down, in the next few minutes, every reason they think it failed; the discussion that follows can run an hour. Klein’s claim for the exercise is modest and exact: it breaks the team’s emotional attachment to the plan’s success and surfaces the likely sources of breakdown: the silent assumptions the plan was resting on. His sharpest evidence for why it’s needed: of 20 Army helicopter crews rehearsing a troop drop through a one-minute window between artillery barrages, none asked in rehearsal what to do if they arrived early or late, and one made the window.

Whatever the premortem surfaces then needs a home. A ROAM board is a simple way to give it one: each risk gets sorted as Resolved, Owned, Accepted, or Mitigated, so a named risk either has an owner and a plan or a deliberate decision to live with it. Run it per epic or hold one board across the quarter.

For the companion hypothesis rewrite exercise, take your current quarterly plan and rewrite each milestone in the form “if we do X, we expect to observe Y by date Z; the hypothesis is falsified if we observe instead [specific outcome].” Notice which milestones are hard to rewrite. Those are the ones running as Pole A. The Pole B response isn’t to rewrite all of them⁠—some genuinely are commitments⁠—but to know which is which, and to set the team’s relationship to each accordingly.

Going upstream

In-text: the key references named in the body. Henry Mintzberg, The Rise and Fall of Strategic Planning (the canonical primary; Ch 5 is the heart of the critique), and “Crafting Strategy,” HBR 1987, for the potter. Mary Poppendieck, The Tyranny of “The Plan”, InfoQ (60 min): the canonical talk or my transcript; worth the hour for the Polaris story alone. Gary Klein, Sources of Power, on the premortem; the named exercise is set out in Klein’s “Performing a Project Premortem,” HBR 2007. Ryo Lu’s no-roadmap line is from his November 2025 interview with Peter Yang, as reported by DevClass.

Also touched: references gestured at by surname in the body. Sidney Dekker, on hindsight bias, citing Baruch Fischhoff, “Hindsight ≠ Foresight: The Effect of Outcome Knowledge on Judgment Under Uncertainty” (Journal of Experimental Psychology: Human Perception and Performance, 1975). Alicia Juarrero, Dynamics in Action (Ch 15 for fail-safe vs safe-fail). Todd Little, “Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty” (IEEE Software, 2006), for the pipe of uncertainty. Donald Reinertsen, The Principles of Product Development Flow, on why granular estimates add up to a fair scope total but a poor schedule: pooled task variances make the sum steadier than its parts, while scheduling each task, and pressing people to hit it, buys padding that lengthens the timeline. Dave Snowden & Friends, Cynefin: Weaving Sense-Making into the Fabric of Our World, for Pole B’s strategy-as-verb, adjacent-possibles framing (McCrone & Snape on strategy as a verb; Blignaut on crossing the river by feeling the stones).

Go deeper: further reading that extends the threads above, beyond what the body anchors. On the hindsight artefact, Dekker quotes Anthony Hidden’s 1989 Clapham Junction report: “There is almost no human action or decision that cannot be made to look flawed and less sensible in the misleading light of hindsight.” On safe-fail at the system level, Richard Cook, How Complex Systems Fail (point 5: complex systems run in degraded mode; point 14: change introduces new failure modes). On the operational unit of management, Eric Ries, The Lean Startup: validated learning, vanity versus actionable metrics, innovation accounting. On the optimum failure rate, Don Reinertsen’s Principle of Optimum Failure Rate, in The Principles of Product Development Flow (50% for exploratory tests that generate information); for the 15% end, Robert Wilson and colleagues, “The Eighty Five Percent Rule for Optimal Learning” (Nature Communications, 2019). On the doctrinal voice, USMC, MCDP-1 Warfighting (Ch 4; official PDF), which reached this posture through Boyd’s fighter-pilot air-combat analysis: “We must not attempt to impose precise order on the events of combat since this leads to a formularistic approach to war.” “Maneuver warfare exists not so much in the specific methods used⁠—we do not believe in a formularistic approach to war⁠—but in the mind of the Marine.” Further reading: Mary and Tom Poppendieck, Lean Software Development and Leading Lean Software Development (Frame 13: schedule as plan vs schedule as hypothesis, via Steven Spear’s Chasing the Rabbit); Mike Rother, Toyota Kata, on PDCA as hypothesis-testing; Patton, on the good plan violently executed now.

The improvement plan you just signed off tests everywhere at once, though a plan held as a hypothesis has to be tested somewhere. As Goldratt put it, in a line operations management has spent decades trying to unsay, a system of local optimums isn’t an optimum system at all; it is a very inefficient system. That is the plan you built, and it breaks wherever functions share a constraint, which covers most systems a leader ever meets. In chapter 8, you work through the rule. Improving a non-constraint changes nothing.

I work with CTOs and CPOs at software companies with roughly 25–500 engineers, where the engineers are faster with AI and the business isn’t yet seeing the full value. When dates keep slipping, I help leaders hold the roadmap as bets to test, so the board’s question shifts from “why the slip?” to “what did we learn?” If it’s live for you, book a free 30-minute call at hi.chrisgagne.com and bring the one question that would make it worth your time. If you know a CTO or CPO in that spot, pass this chapter on. If you’d rather read on than talk, the newsletter goes on past chapter 23, monthly, at https://www.linkedin.com/newsletters/come-prepared-to-die-7472144387981062144/

Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.

The pattern is familiar to anyone who has tried to install discipline by decree. Take the Definition of Done. We agreed on it together: what “done” means for a Backlog Item, and an even higher quality bar for larger releases. I trained to it, we ran good exercises against it, and everyone left sure they could live by the new Definition of Done. And the one behaviour that mattered⁠—a team holding that bar when the sprint clock is running out⁠—still wouldn’t stick. Every sprint, when the review loomed and the demo had to land, the Definition of Done was the first thing to go.

The Definition of Done is an andon cord, a “stop the line” mechanism. Pulling it means saying “this isn’t a quality product yet” on the afternoon the sprint review is booked and the stakeholders are already on the calendar. The answer that carries the day is the one the GM plant boss gave for years before NUMMI: get it out the door, we’ll fix it later. The person holding the bar is a blocker; the low-quality demo ships.

I’ve taught a couple of dozen two-day Agile courses over the years, and there were times I felt I was close to gaslighting people. These weren’t generic, by-the-book courses; I’d adapted the training hard to the organisation in front of me, and it was sound. The gap between even that adapted process taught in my course and the organisational reality waiting for them back on the job couldn’t have been starker, and some part of me knew it while the room was still enjoying itself.

It was the pattern from chapter 1’s fixed-date project, sprint after sprint: the training was pushing the behaviour, and the conditions around it were punishing it. The programme was sincere, and the conditions were doing their work the whole time, often firmly in the other direction.

“The training was pushing the behaviour. The conditions were doing their work the whole time, often firmly in the other direction.”

Chapter 5 located the say-do gap inside the leader. The same gap is built into the conditions, where working harder on the people is the wrong lever.

The two poles

Pole A: push people. Announce the change, run the training, hold people accountable for the new behaviour, repeat the messaging, review the scorecard, escalate when the behaviour doesn’t show up. The locus of intervention is the individual. The assumption is that people are the variable to move.

Pole B: change the conditions. Redesign the environment so the new behaviour is the easier behaviour. Identify the loop that punishes the new behaviour. Change the loop. Watch what follows. The locus of intervention is the system. The assumption is that behaviour is a property of the conditions that surround it.

Where Pole A is right

Pole A fits when the new behaviour is genuinely a matter of capability or specification, and when the surrounding conditions already reward it. Time-critical regulatory shifts. New compliance rules with specifiable steps. The introduction of a tool whose use is the change. New entrants to a craft, where the missing thing is practice and feedback, and the senior practitioners are visibly rewarded for the same behaviour. In these settings, pushing isn’t coercive; it’s teaching. The training transmits something real, and the conditions back up the teaching once the training ends.

Kotter’s eight-step change sequence⁠—urgency, coalition, vision, communicate, empower, short-term wins, consolidate, anchor in culture⁠—is the canonical articulation of Pole A done well, though its fifth step, removing the structures, systems and supervisors that block the change, is already Pole B. In situations where vision, urgency, and coalition genuinely shift the conditions a behaviour faces, the sequence describes the work, and the leader who runs it well moves the org further than the leader who doesn’t.

The best version of Pole A is the discipline of communicating clearly, training capably, and watching whether behaviour follows. When it does, the work is done. When it doesn’t, Pole A’s options run out, and the leader needs to consider Pole B.

Where Pole B is right

Pole B fits when the behaviour the leader wants is being punished by the conditions surrounding it. When the engineer who says “this isn’t done yet” and holds the release is overruled or sidelined while colleagues watch, every additional round of training pushes against the context. The training is sincere. The inertia wins. Sometimes the read arrives in a retrospective: a team names something the leader cares about that simply can’t be honoured, given the strategy, the reward system, or who reports to whom. Their skill isn’t the problem, and there may be nothing wrong with the choice to try Scrum here.

Chip and Dan Heath, in Switch, built their change model on three handles: Jonathan Haidt’s Rider and Elephant, plus the Path, their own addition. Rider: the rational planning function. Elephant: the emotional and instinctive system. Path: the situational environment the Rider is trying to steer the Elephant down. The Heaths warn how natural it is to speak only to the Rider. A leader who does writes the strategy memo, makes the deck, and runs the all-hands. The Elephant goes unconvinced and the Path goes unredesigned, and the Elephant takes the default path because the default path is the easier one.

City planners lay a paved path; people cut across the grass anyway, wearing a bare track that engineers call a desire path. The sidewalk is the trained behaviour, the socialised route. The worn track through the grass is what the conditions actually reward, and no amount of signage moves the feet. It is the same gap chapter 5 named between work-as-imagined and work-as-done, pressed into the ground where anyone can see it.

The Heath brothers argue that ambiguity is the enemy, and that any change that takes hold depends on translating vague goals into concrete, specifiable behaviour. They name a counterexample from public health: the West Virginia 1% milk campaign asked people to buy 1% milk instead of whole milk when grocery shopping, not to eat healthier; market share of low-fat milk rose from 18% to 41% and held at 35% six months later. The campaign also used emotional appeals, but the Heaths file it under directing the Rider: the ask was scripted, and what looked like resistance was a lack of clarity.

You can also sort the places to intervene in a system by leverage. Parameters sit at the bottom; feedback loops in the middle; the shared mental model the system runs on sits at the top. Pushing on a parameter while that model holds the old behaviour in place is the lowest-leverage intervention there is: what Donella Meadows called diddling with the details while the governing paradigm keeps producing the very behaviour the change was meant to correct. A leader mandates 20% of every sprint for paying down technical debt: a parameter. The governing paradigm underneath⁠—velocity is the scoreboard, features are what get celebrated—is untouched, so the 20% gets reallocated to feature work the moment a deadline tightens, sprint after sprint. The formal policy changed. What the organisation actually rewards didn’t.

“The formal policy changed. What the organisation actually rewards didn’t.”

W. Edwards Deming’s sharper word for the same trap is tampering. In his funnel experiment, a marble is dropped through a funnel onto a target; the resting point is measured; the funnel is adjusted to compensate for the last error; the marble is dropped again. Three of his four adjustment rules⁠—two of them outright compensation, the third a chase⁠—make the variance worse than leaving the funnel alone. The line Deming quotes approvingly from Lloyd S. Nelson in Out of the Crisis: “In the state of statistical control, action initiated on appearance of a defect will be ineffective and will cause more trouble.” Tampering is what the leader does when each missed metric, in a process running within its normal variation, prompts a new policy, a new review meeting, a new training, a new dashboard. The variance grows. The new policy meets the next missed metric. Another new policy is added. The leader is busy, the system is louder, and nothing improves.

A leader who has never heard of failure demand is still paying for it. John Seddon carried the diagnosis from manufacturing into services and named it failure demand, the demand an organisation creates for itself by failing to do something, or to do it right, for the customer the first time. In one bank case it ran at 46% of total demand; the bank had opened three call centres and then had to add a fourth and a fifth, to handle demand nearly half of which it had generated itself. The Pole-A response⁠—train staff harder, set tighter targets, monitor more⁠—accelerates the cycle. The Pole-B response⁠—study demand as customers present it to find the failure-generating step, then redesign the upstream process so it stops generating failure⁠—eliminates the self-generated waste.

Heifetz called the container in which conditions change a holding environment: “all those ties that bind people together and enable them to maintain their collective focus on what they are trying to do.” It is the structural and relational container an organisation needs when it is doing adaptive work that can’t be coerced. The leader who is trying to push behaviour through training alone is asking training to do work only a holding environment can do. Where the container exists, the sprint the team can’t finish to standard ends differently: the review slips, the stakeholder is told it isn’t done yet, and nobody’s standing drops for saying so.

The change you have been trying to make in the other person is also a condition you can change in yourself. The leader who has been trying to fix the team-lead who won’t escalate risks can ask, instead, what changes in their own system⁠—what unspoken rule, what reflex, what protective stance⁠—would change the dynamic the team-lead is responding to.

At Student of Fortune, the online tutoring marketplace I co-founded, tutoring meant selling answers: someone posted a question, someone posted an answer, and the answer was what sold. The pricing I designed let an answer keep selling, so one found with a web search could earn again and again. I built the anti-fraud tools and ran much of the moderation with my partners, one user at a time. We could have blocked the obvious cheating questions, such as requests to write an essay, and we chose not to because it would have cost revenue. In September 2008 I decided to get out, partly over that choice.

In decisions

Pole A leaders, on a typical Tuesday: announce the new programme; circulate the deck; book the trainings; set the scorecard; review the scorecard the following Tuesday; raise the heat on the team-leads who haven’t moved their numbers; book a coaching session for the one whose numbers are worst.

Pole B leaders, on the same Tuesday: ask what would happen to an engineer who tried the new behaviour in their team yesterday; trace the loop that would punish it; identify the smallest change to the loop that would stop the punishment; make that change; book a check-in for two weeks out to see whether the behaviour follows.

The first Tuesday feels more decisive. The second feels slower and less certain, and its first visible result may be weeks out, where the first produces another deck. Then the behaviour the deck kept failing to mandate starts showing up on its own, because the loop that punished it is gone. (The push-the-people reflex has a training-room cousin. In New Zealand we called it sheep-dipping: run everyone through a two-day course⁠—a quick dunk in the bath⁠—and Bob’s your uncle.)

The NUMMI joint venture in Fremont, California⁠—the partnership between Toyota and General Motors that ran from late 1984⁠—is, I suspect, among the most cited cases in the Lean tradition for what happens when a leader changes the conditions. GM had closed the Fremont plant in 1982 with a workforce whose reputation as the worst in the American auto industry was, in the union’s own telling, well-earned. Two years later the same plant⁠—with mostly the same workers⁠—became one of GM’s best on quality and absenteeism, by running Toyota’s production system instead of GM’s. The artefacts changed. The structural conditions changed. A new team member handbook, a welcome letter from Toyoda himself, and a reserve fund that put per-hour cash behind a no-layoff intent all pointed the same way; chapter 23 walks these reception artefacts in full. The structural rewards aligned with the new behaviour. The new behaviour followed.

Chapter 3 walked Ernie Schaefer’s account of why GM’s early attempts to transplant NUMMI elsewhere struggled: GM kept asking about the floor⁠—the assembly line, the visible practices⁠—when the real issue was how the rest of the organisation’s functions support that system. The same point lands from the conditions side here. The visible practices⁠—the andon cord, the kaizen card, the team huddle⁠—aren’t the system; the conditions that surround them are. NUMMI changed workers’ paradigms by changing their conditions: chapter 1’s counterweight at factory scale. Few people inside the building can change the CEO’s conditions; the CEO is the one person who can. That asymmetry is why the leader has to see their own conditions first, not last.

The same asymmetry shows up in a Scrum team a generation later. At the old GM Fremont plant, as the UAW’s Bruce Lee remembers it, a worker who stopped the line was fired, so quality and safety were the first casualties. A Scrum team is taught retrospectives and pull-based flow in a two-day course, then handed back to a Release Train Engineer, a project manager under a newer title, measured on a calendar someone above them set. The andon cord lives only on the training slide. No one present has the authority to pull it.

Trace the loop, and if it closes above your authority layer⁠—as it usually will⁠—that puts it on your CEO’s desk, not yours. Put in front of them the specific loop⁠—traced end-to-end⁠—that punishes the behaviour you have been trying to install for the past six months. Name the moment in the loop where the CEO’s behaviour, or a structural choice the CEO owns (an approval gate, a career ladder, a reward), is the condition that closes against the new behaviour. Nothing in the CEO’s conditions has ever made this loop visible. Your job is to make it visible without blame, and to ask, before the map comes out, whether the CEO wants to see it: an extension of chapter 3’s rule to ask for the CEO’s account before the artefact comes out. A loop the CEO agreed to examine is data. The same loop, arriving uninvited, is an accusation wearing a diagram. This is why change that only pushes up from the bottom stalls. Individual contributors and line managers can expose the loop, and they often see it first, but they can’t rewrite the approval gate, the career ladder, or the reward that closes it. Change that only pushes down from the top installs the deck without ever learning where the loop actually bites. The work has to run both directions at once: the people living inside the loop name it, and the person who owns the conditions changes them. The sentence your CEO can carry to the board: “We have been asking people to out-perform conditions we designed.”

The same loop, arriving uninvited, is an accusation wearing a diagram.

“We have been asking people to out-perform conditions we designed.”

The diagnostic

Three questions to stay with this week. None of them require an answer in the meeting; they require a straight read of a real decision.

• Pick a behaviour you have been trying to change in your organisation for at least six months. Programme, scorecard, training, accountability: the full Pole-A kit. The behaviour hasn’t yet moved. What would happen to a team-lead who genuinely tried the new behaviour in their team yesterday? Trace the loop end-to-end. Where does it close back on the team-lead? What does the loop reward? What does it punish?
• Looking at the loop you just traced, what is the smallest change to the conditions that would stop punishing the new behaviour? Not the largest change. The smallest one that would actually move the loop. The Heaths’ Switch line, paraphrased: ambiguity is the enemy; the change has to be specifiable as a concrete next step.
• What is the change inside your own system⁠—the rule, the reflex, the protective stance⁠—that would have to shift for you to make the change you just identified in the second question? Naming the inner change is the same question, asked at the level the leader actually operates at.

The exercise: Rider / Elephant / Path mapping

This is a team-based exercise the leader can run with their leadership team in one 90-minute session. Pick a change initiative that isn’t sticking. Draw three columns on a whiteboard: Rider, Elephant, Path. List under Rider everything you have invested in the rational case for the change: strategy memos, decks, all-hands, the scorecard. List under Elephant everything you have invested in the emotional and instinctive case: stories of teams that have made the change well, recognition, how the change feels to the people living it. List under Path everything you have invested in changing the situational environment: structural changes, removed obstacles, redesigned rewards, new defaults, environmental cues. Compare the columns. Read your columns against the bias the Heaths warn about: we blame the person and overlook the situation. If Rider dominates yours, test whether clarity alone is enough. If Path is thin, that is where the change has been sliding back, because most teams invest where it is rational to invest and the Path stays sloped against them. The exercise produces a small list of Path interventions to make in the next 30 days. (Framework: Heath & Heath, Switch; the mapping exercise is my own application.)

Going upstream

In-text: Chip and Dan Heath, Switch: How to Change Things When Change Is Hard, for the Rider / Elephant / Path model and the mapping exercise. W. Edwards Deming, Out of the Crisis, on common-cause variation, tampering, and the funnel experiment. Ronald Heifetz, Alexander Grashow, and Marty Linsky, The Practice of Adaptive Leadership, on the holding environment.

Also touched: John Kotter, Leading Change, for the Pole-A canon and the eight-step sequence. John Seddon, Freedom from Command and Control, on failure demand and the service-industry version of tampering: “The single greatest lever is the eradication of failure demand.”

Go deeper: Donella Meadows, Thinking in Systems, on the twelve leverage points, with transcending paradigms at the top of the ranking; the same leverage frame carries chapters 2 and 21. The holding environment runs older and wider than Heifetz: the phrase was Donald Winnicott’s first, and Robert Kegan carries the same construct into developmental work (Kegan and Lisa Lahey, Immunity to Change, on the developmental face of why change resists).

You set a date, someone commits to it, and now the date is a promise the whole system will defend past the point where reality has already answered. The hardest condition to see is the one that looks like resolve. Watch what happens the week the estimate slips: the response is to protect the date, not to read what the slip is telling you. In chapter 7, you ask whether the plan on your wall is a commitment you owe or a hypothesis you are still testing.

Continue reading: Chapter 7 asks whether the plan on your wall is a commitment you owe or a hypothesis you are still testing.

I work with CTOs and CPOs at software companies with roughly 25–500 engineers, where the engineers are faster with AI and the business isn’t yet seeing the full value. Training won’t hold against conditions that punish the behaviour, so I trace the loop to the approval gate, career ladder or reward that closes it. If it’s live for you, book a free 30-minute call at hi.chrisgagne.com and bring the one question that would make it worth your time. If you know a CTO or CPO in that spot, pass this chapter on. If you’d rather read on than talk, the newsletter goes on past chapter 23, monthly, at https://www.linkedin.com/newsletters/come-prepared-to-die-7472144387981062144/

Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.

You judge yourself by your intentions. The people around you judge you by your decisions when emotions and the stakes are high. They have better data.

Any paradigm dichotomy in this book can be self-reported into the flattering pole. This chapter’s gap between what the leader says they believe and what they observably did⁠—under pressure⁠—offers data the leader didn’t already have.

Chapter 4 sat with the gap between utilisation and flow: we say we want efficiency, then keep everyone busy, and a system where everyone is busy but nothing reaches the user isn’t efficient at all. The same gap shows up inside the leader, between what they say they value and what they observably do under pressure.

The two poles

Pole A: espoused theory. The leader’s stated principles, values, and intentions are taken as the relevant data. When results miss the target, change the action while leaving the underlying assumptions intact. What the leader does under threat isn’t examined, because the stated values are assumed to be the ones in play.

Pole B: theory-in-use. The leader’s actual behaviour⁠—especially under threat or embarrassment—is taken as the data. The gap between espoused and in-use is diagnostic, and what the mirror usually finds under threat or embarrassment is what Chris Argyris called Model I: be in unilateral control, win rather than lose, stay rational, suppress the negative feeling, and protect others from discomfort by telling them what they want to hear. “The problem is not me, but you,” as William Noonan renders the inner monologue in Discussing the Undiscussable. Under threat, Model II is the aim: valid information, free and informed choice, and the responsibility to monitor what the choice produces. Aggressive and vulnerable, in Argyris’s phrase. Strong advocacy paired with genuine inquiry into one’s own contribution. William Noonan, working in the same lineage, gives the stance four thought enablers: granting legitimacy to the other person’s view, assuming the partiality of your own, attributing positive intent, and acknowledging unintended impact. The conversation later in this chapter, when the answer stings, draws on them.

In Argyris’s terms, espoused theory versus theory-in-use is about evidence, meaning which account of you counts as the data. Model I versus Model II is about the values actually steering you. Model I is itself a theory-in-use, and it’s most people’s: when people give or hear advice, Argyris found, they have Model II’s consequences in mind, but “when they act, however, almost all act consistently with Model I.” The axis pairs the two because treating your behaviour as the data is the only way to find out which model is running.

Where Pole A is right

Pole A does real work in external communication. Principles need to be stated clearly, and an organisation needs them on the record. The values poster on the wall isn’t lying, even if it doesn’t tell the whole story. Pole A is the leader naming what the organisation aspires to. The leader who refused to state aspirations because they couldn’t guarantee perfect alignment with behaviour would be over-correcting. The stated principles are the target the organisation aims for.

Pole A also holds in the founder-vision frame. The first year of any new organisation often runs on what the founder says they intend, because in small companies it remains possible to shape culture directly. There, Pole A sets the orientation the behaviour will eventually be measured against.

Pole A is what most leaders were trained to operate by. The MBA programme, the leadership-development workshop, the board-prep coaching all teach Pole A. The leader who came up through those teachings isn’t naïve. They are doing the discipline they were taught, which was sufficient for the contexts those teachings were built for. The test is whether the contexts the leader now meets are still those contexts.

Where Pole B is right

For the leader’s own self-assessment. For any conversation where defensive reasoning is already running and the next decision will repeat the last one unless the gap is named. Revisit one of these conversations later and you may find Pole A was running underneath your Pole B account in at least some of the territory.

Self-assessment without Pole B just restates the espoused theory and treats the restating as data. The leader who concludes from self-reflection alone that they are still operating from their stated values has not yet done Pole B’s work. Pole B’s work begins when someone else, or some recording of the behaviour, surfaces a behaviour the leader didn’t recognise as their own.

In Argyris’s daily three-step, under threat or embarrassment, bypass the threat. Don’t name the elephant. Then cover up the bypassing: act as if nothing was bypassed. Then cover up the covering up: treat the act of acting-as-if as natural rather than as itself an avoidance. By step three, the organisation has lost access to its own behaviour. The leader running the three-step isn’t pretending. They are skilled. The steps are automatic, while the leader remains unaware they are producing them.

This is what Argyris called skilled incompetence: people become expertly bad at uncomfortable conversations. The fluency is what makes the incompetence durable.

I suspect the most fluent skilled-incompetence partner a leader now has is a large language model. Give it one side of the story and a prompt that asks whether you were right, and its agreeable defaults do the rest: trained to please, rewarded for the answer that goes down well, never tired and never embarrassed. What comes back is your own defence, polished and returned as analysis. Anthropic’s own sycophancy research found the pattern across five frontier assistants and linked it, at least in part, to the training signal: matching the user’s stated view is one of the strongest predictors of which answer a human rater prefers. The witness round later in this chapter exists because people flatter under threat. The model flatters faster, at scale, on demand, and it never gets uncomfortable enough to stop. It is the espoused-theory mirror the leader was already prone to, now automated and always on.

You can configure it the other way, of course. Prompt it to disagree, ground it in a corpus you trust, and it will push back all day. But a model pushing back from a source you haven’t learned to judge only gives you a confident answer pointed somewhere, with no way to tell a good direction from a bad one. Choosing the corpus the model should trust, and knowing when its disagreement is worth more than your own, is the paradigm-level judgement no configuration supplies. That judgement stays scarce.

The ladder of inference

The ladder is the cognitive mechanism running under the three-step. Argyris drew it. Others draw it with different rungs, but the shape is shared. In Rick Ross’s rendering for The Fifth Discipline Fieldbook, we observe a fragment of someone’s behaviour, select what to attend to, and add meaning to it. From the meaning we make assumptions, and from the assumptions we draw conclusions. The conclusions harden into beliefs, and we act.

By the time we are acting, the original observable behaviour is several rungs down a ladder we built ourselves, mostly invisibly, mostly automatically. Most leadership disagreements are collisions between two leaders standing on the top rung of two different ladders, their observable data several rungs out of reach. The Pole-B response is to walk back down the ladder, name the rungs out loud, and check whether the observable data still supports the action when the meaning is exposed for inspection.

Most leadership disagreements are collisions between two leaders standing on the top rung of two different ladders, their observable data several rungs out of reach.

This is the operational discipline of the chapter, and the hardest to install. The defensive routine speeds up at the moment of threat. The ladder gets climbed faster, with fewer checks, when the stakes are higher. The Pole-B discipline is to slow down exactly when the leader most wants to accelerate.

Snook’s practical drift

Scott Snook’s Friendly Fire is the multi-level version of the gap, at organisational scale. Snook reconstructed the 1994 incident in which two U.S. Air Force F-15s shot down two U.S. Army Black Hawk helicopters over northern Iraq. Chapter 14 walks it level by level. Reading across the levels, Snook found a whole system producing what he named normal behaviour, abnormal outcome.

Snook’s term for it is practical drift: local practice slowly uncoupling from written procedure. It is the shift from work-as-imagined to work-as-done, the distinction Erik Hollnagel develops in Safety-I and Safety-II. It is what the organisation actually does, week by week, as the procedures designed for an idealised version of the work get adapted by the people doing the actual work. The gap is the organisational design. Everyone in the organisation is doing what made sense locally. The system, at the cross-level, still produces a friendly-fire shootdown.

Sidney Dekker calls the same macro pattern drift into failure: complex systems slide toward the boundary of safe operation in small, locally rational steps. The same gap opens in software: the runbook nobody has followed in full since the last incident, because the incident taught everyone a faster path that never got written down. Left unexamined, the same local adaptation is what Snook watched become drift. The gap between work-as-imagined and work-as-done is the organisation’s actual operating system, and pretending otherwise is what produces the friendly-fire outcome.

Use the Kegan-Lahey Immunity Map

Robert Kegan and Lisa Lahey’s four-column Immunity Map, introduced in chapter 2, is the developmental face of this gap: a sincere commitment to a goal sitting on top of a hidden competing commitment to self-protection, sustained by big assumptions held as fact.

The Immunity Map isn’t a quick diagnostic the leader can knock out between meetings. It is a developmental exercise worked over weeks, and Kegan and Lahey offer the choice of company plainly: solo with their structured prompts, with a partner, or with a coach. The solo path can still be helpful, though it can also reinforce the same beliefs. The commitment is hidden from the same person trying to surface it, and a witness catches what the solo work can easily bypass. Run it alone for now if alone is what you have; but bring the columns to someone who watched you before you trust them.

The gap resists self-report: the same thinking that produced it edits the account in its favour. A witness, or a recording, is what that editing can’t reach. Listening back to recordings of my own coaching, I heard a move I’d never caught live: I sometimes moved to the next question too quickly, which was not what I was taught and not what I thought I was doing. That is why Pole B has to be relational.

The gap is a fact about how cognition is built, not a moral failing. Pole B can feel like an attack on values. Its narrower claim is that behaviour under pressure is stronger evidence of the operating system than stated values.

In decisions: last Tuesday

Pole A leaders judge themselves by their intentions, run after-action reviews on the what, and end disagreements with a winner. Pole B leaders judge themselves by recent observable interactions, run after-action reviews on the what we believed coming in, and end disagreements by asking which observable example would change the other person’s view, and whether the same example would change theirs.

The two postures look similar from outside until the moment of threat. The leader running Pole B in calm conditions sometimes slips into Pole A under pressure and doesn’t notice. The leader running Pole A in calm conditions doesn’t have the Pole B response available under pressure; it isn’t in the muscle memory. The gap-detection itself requires Pole B, which means the leader running Pole A can’t self-diagnose into Pole B without an external mirror.

This is the one axis a CTO or VPE can’t route to the CEO by forwarding a chapter, because the espoused-versus-in-use gap only surfaces in an external mirror. So open with your CEO on a recent decision where what they said they valued and what the organisation observed diverged, not on the framework. Put one specific observable example from the past quarter in front of them, described in behavioural terms, without blame, and ask a genuine question: what were you trying to do in that moment, and what did the team see? In that witness round, you are the witness. The sentence your CEO can carry to the board: “People follow what we did last quarter, not what we said at the all-hands.”

The diagnostic

Three questions for last Tuesday’s hard conversation.

What was I claiming I believed about the right way to handle this? State the principle, briefly, in one sentence.

What would a colleague who watched me say I did? Not what I intended. What was observable. One sentence.

Which one would the situation actually have asked for, if I had run Pole B? A Pole B response under threat looks like I think X; I notice I’m running it confidently; what would change my mind? Was that available, and did I take it?

The gap I see most often is between question one and question two. The leader’s stated principle was Pole B. The observable behaviour was Pole A.

The exercise: the witness round

Pick three or four people who watched you make recent decisions in a territory you care about, and send them the same question. Ask it in plain behavioural terms, because they haven’t read this book and don’t think in poles: in our last three meetings about X, what did you actually see me do when the pressure was on, and did it match what I said I wanted? One sentence each is enough. Compare their answers to your own.

The gap, when it appears, is the data the leader’s self-assessment couldn’t have produced.

Pick people who watched the decisions, not people who agreed with the decisions. Pick people who are senior enough to tell you the truth, not people who will soften the answer to spare you. And pick an axis you are willing to be wrong about. The witness round on an axis the leader is determined to have already nailed produces no signal, because the leader’s response to any contradicting data will be to reject the witness, and the round will have been theatre rather than diagnostic.

One gate before you send anything: the round’s validity depends on a climate you built before you asked. Run the bad-news check from chapter 2 first⁠—when someone brought you bad news this quarter, what happened to them?⁠—because if the real answer isn’t anything good, the witness round will only collect politeness. Two or three items from Amy Edmondson’s seven-item psychological-safety scale, asked anonymously, give you a read on whether the channel is open: whether a mistake on the team gets held against you, and whether members can bring up problems and tough issues. Read a unanimous no-gap result as ambiguous rather than as a clean bill: it means either there is no gap, or your witnesses are afraid to tell you. A unanimous result tempts us to call the channel healthy; treat that confidence as one more reading, not as proof.

The leader who runs the witness round straight, and runs it regularly on different axes, will build a mirror for themselves that the immune system can’t fully control. To keep the mirror from decaying between rounds, give its output somewhere to live: a recurring slot in the staff meeting⁠—what did the dissenter say this month?—or a blameless channel where near-misses and contradicting observations arrive without an invitation. The quarterly round feeds the standing structure; it can’t substitute for it.

When the answer stings

The witness round earns its keep on the day the answer is one you don’t want. This is a composed conversation, built to show the moves rather than transcribed from a single session.

The claim, from column one of a leader’s Immunity Map: I delegate the architecture calls. The witness’s answer might be: You ask for our recommendation, and then you re-decide it in the meeting. We’ve stopped writing the recommendations carefully, because we know they aren’t the decision.

When this lands on me, first comes heat, before any thought. Second comes the silent rebuttal, fully formed: that’s not fair, I re-decided twice all quarter, both times for good reasons, he’s conflating two different meetings. Third comes the reflex the heat is funding: explain the two meetings. That third move is the bypass. It converts the witness’s data into a charge to be answered, and the witness learns what every team learns from a defended leader: don’t say the true thing twice.

The move that holds the round open instead, in words:

“So when I asked for the recommendation on the queueing redesign and then changed it in the meeting, that read as the pattern: the recommendation isn’t the decision. Have I got that right, or would you change it?”

Paraphrase first, in their terms, low on the ladder. Then the test.

“That’s it. It’s not that you change them. It’s that we can’t predict which ones you’ll change.”

New data. Your version had the count: twice. The witness’s version had the variable: unpredictability. The defence would have argued the count and never surfaced the variable.

“I didn’t know the unpredictability was the cost. I can’t promise never to re-decide; sometimes I’ll have context you don’t. What would make that visible before the meeting instead of inside it?”

Name your own constraint plainly. Then put the design question where the information lives.

You feel the heat and hold it, then paraphrase and put it to the test. You receive the correction, and you design forward together. Running all four concedes nothing about whether you over-decide; the moves ask you to find out what the witness actually saw, which was never quite the thing the heat said was being alleged. The failure version is one move long: “that’s not what happened.” It feels like accuracy. It is where the data stops.

Going upstream

In-text: Chris Argyris, Overcoming Organizational Defenses (Model I/II, the three-step, skilled incompetence, and the ladder of inference). Robert Kegan and Lisa Lahey, Immunity to Change, for the developmental side. Scott Snook, Friendly Fire, for the organisational-level version and practical drift. Peter Senge, The Fifth Discipline Fieldbook, for Rick Ross’s rendering of the ladder.

Also touched: William Noonan, Discussing the Undiscussable, in the Argyris/Schön/Action Design lineage (“the problem is not me, but you” and the four thought enablers). Sidney Dekker, Drift Into Failure, on locally rational drift toward the boundary. Amy Edmondson, “Psychological Safety and Learning Behavior in Work Teams” (Administrative Science Quarterly, 1999), for the seven-item scale two of whose items the witness-round gate borrows. Mrinank Sharma and colleagues, “Towards Understanding Sycophancy in Language Models” (Anthropic, 2023), for the finding that five frontier assistants all run sycophantic and that matching a user’s view predicts which answer human raters prefer.

Go deeper: Charles Perrow, Normal Accidents, supplies the structural precondition: systems that are both interactively complex and tightly coupled turn small local adaptations into catastrophic outcomes. The U.S. Marine Corps MCDP-1 Warfighting supplies the doctrinal version in full: the local adaptation built in on purpose before it has a chance to become drift.

Watch: Roderic Yapp, Double-loop learning: a case study from the front-line (TEDxWandsworth, 17 min). Two front-line case studies, Afghanistan platoon houses and a mental-model challenge, that name the espoused/in-use gap directly. Companion: Chris Argyris, Chris Argyris Talks About Culture and Management (4 min). The framework’s primary author in his own voice, defining theory-in-use and running the canonical bypass the threat, cover up the bypassing, cover up the covering up sequence.

You sign the policy, deliver the training three times, stand up a scorecard, and still the one behaviour it all exists to produce, engineers flagging risk early, won’t hold. Every tightened deadline punishes it. Careful practice goes first. The gap between what you say you value and what you did under pressure sits in the leader and also opens inside the change programmes you run. In chapter 6, you ask what your organisation does to the engineer who stops the line the Tuesday the plan goes before the CEO.

Continue reading: Chapter 6 asks what your organisation does to the engineer who stops the line the Tuesday the plan goes before the CEO.

I work with CTOs and CPOs at software companies with roughly 25–500 engineers, where the engineers are faster with AI and the business isn’t yet seeing the full value. When a leader delegates a call and then re-decides it in the meeting, the team stops writing its recommendations carefully, and I help leaders see that gap. If it’s live for you, book a free 30-minute call at hi.chrisgagne.com and bring the one question that would make it worth your time. If you know a CTO or CPO in that spot, pass this chapter on. If you’d rather read on than talk, the newsletter goes on past chapter 23, monthly, at https://www.linkedin.com/newsletters/come-prepared-to-die-7472144387981062144/

Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.

“Keep everyone busy” feels like a responsible management goal. In high-variation work like software development it makes the system much slower, and the maths behind that is teachable.

Chapter 3 asked whether AI is a tool or an impetus for redesign. Now ask whether the system around it can actually move.

The two poles

Pole A: utilisation. Keep resources busy. Any idle capacity is waste. Efficiency and output reports are the management metric. Manage costs first. Pole A leaders allocate every engineer to multiple projects and ask, are you fully booked? They fill an engineer’s calendar at 100% before the sprint starts.

Pole B: flow. Value throughput is the goal. Queues are the enemy: they limit our adaptiveness, sapping NPS and revenue because we can’t respond quickly to customer needs and changes in the market. Capacity margin is a feature.

Pole B leaders protect slack, accept idle time at non-constraints, and ask, “what are my queue lengths today?” as a leading indicator of lead times. These leaders don’t fill the calendar to the top. They protect slack, say 20–30% to start, tuned against the queues and the cost of delay, let the work pull through, and watch the queue lengths shorten.

A quick flow primer

Donald Reinertsen, in The Principles of Product Development Flow, draws the unforgiving maths: queue size⁠—and therefore wait times⁠—against capacity utilisation.

For deterministic, predictable processes⁠—a machine fed a steady, scheduled stream of identical jobs⁠—utilisation below 100% capacity doesn’t invoke queues. A printer that runs 30 pages a minute, fed exactly 30 a minute, never backs up; queues form only when you ask for more than 30. (Let the jobs arrive in bursts instead, and the queue returns even below 30: it is variability, not load alone, that builds the line.) This is the mental model many managers use: “meat widgets” in Craig Larman’s particularly pointed phrasing.

Stochastic, highly-variable processes⁠—like almost all research and software development⁠—follow an entirely different curve: a hockey stick. The average queue is governed by a doubling rule: each time you halve the excess capacity, the queue roughly doubles. The jump from 60% to 80% doubles it. From 80% to 90% doubles it again. From 90% to 95%, again. Push utilisation toward the wall and queue time, not work time, comes to dominate cycle time, and small upsets in arrivals cascade into long delays. The optimum isn’t the peak; it sits well short of it, and how far short rises with your cost of delay.

Establish stable flow first, then increase utilisation. (For another visual representation of this, watch Henrik Kniberg, The Resource Utilization Trap, about 6 minutes.)

Where Pole A is right

Genuinely fixed-throughput operations with stable demand and homogeneous work. Large call centres, where many agents share one queue and pooling absorbs much of the variability any one agent would face. Very mature manufacturing lines on a stable specification. The conditions are narrow, but they exist.

A leader running utilisation in those conditions is reading the system correctly. With effectively zero variability, with value-add steps so decoupled that no step waits on another, or with enough pooling to absorb the variation, high utilisation does compound into more output.

One reaction to learning about flow is to make Pole A look stupid. This is a mistake and we can celebrate the application of Pole A in the applicable contexts. The pin factory worked 250 years ago, the 1980s call centre worked (and still does), and the high-volume assembly line works today. The leader who came up running utilisation reports came up under conditions where the reports were the right report.

The reality test is the same as in chapter 3. Is the work actually pin-factory work? For most software-dependent organisations’ portfolios in 2026, no. Some of it is. Most of it isn’t.

Where Pole B is right

Pole B better fits systems with variable demand, heterogeneous work, or genuine complexity: most knowledge-work organisations, product-development pipelines, and engineering departments. The work moves the constraint around rapidly, so there is rarely a single fixed station to keep busy (chapter 8 shows why the constraint still governs even as it moves). What you manage instead is flow.

Pole A’s intuition is most exposed where the leader sees utilisation and velocity as independent variables, when the relationship between them is the curve from the primer: mathematical and unforgiving. By Reinertsen’s running tally of his conference audiences, nearly everyone measures cycle time and almost no one measures queues. Queues are the one number the curve says governs the rest.

Idle isn’t waste: a pizzeria example

I often give the example of a pizzeria. The oven fits one pizza and takes 15 minutes to bake it. The chef needs no more than five minutes to remove, cut, and box the hot pizza and prepare the next one. So 10 of every 15 minutes, the chef has nothing to do at the oven. It would be clear to any manager not to expect the chef to stay constantly busy preparing pizzas for an oven that can’t bake them at the same rate; that is wasteful. Virtually any other activity, including remaining idle, would deliver more net value. Better still, point the spare capacity at the bottleneck (perhaps the chef learns a little engineering and doubles the oven’s capacity in their spare time), and you get the most value of all. Trust the chef with the slack.

Un-baked pizzas pile up as inventory, which is to say frozen cost, not value. What’s your backlog of half-specified roadmap items, if not the same pile?

Cost of Delay is the economic argument

For a Pole-B leader in a Pole-A org, I know no sharper approach than quantifying the cost of delay. Reinertsen’s E3 principle is the canonical statement: if you only quantify one thing, quantify the cost of delay. Every queue carries a cost of delay, and the cost of delay is what makes utilisation expensive. Worse, when I went looking, I found no off-the-shelf tool that could estimate and track the cost of delay in a software context, so I built one for my own client work. Even so, most organisations still lack the means.

In my tool, each story can carry the dollar value the business expects from it. Rolled up across the epic, those values let the tool put an estimated figure on the delay. While I was there, nobody filled in those dollar fields. I’d assumed stakeholders would be willing to enter the figures. Asking for them story by story, rather than by epic, was a bit too granular, and I think entering them was extra work for people used to passing requests along without a value attached; a stated value is also one you can be held to.

Every queue carries a cost of delay, and the cost of delay is what makes utilisation expensive.

The argument flips intuition because Pole A’s intuition is correct about a different variable. The cost of an engineer’s idle hour sits on the P&L as a line item. The cost of an extra week in cycle time is invisible until you put a dollar amount on it. The dollar amount, when you actually run the calculation, is usually multiples of the apparent saving from “no idle time.” Reinertsen put numbers on that asymmetry as a McKinsey consultant in 1983: a product six months late to market lost 33% of its five-year profit, while shipping on time at 50% over budget cost about 4%.

The dollarisation wins the boardroom: the flow argument loses with most CFOs as queueing theory and wins as a cost-of-delay number in dollars per month. Another client was carrying a cost of delay about an order of magnitude larger than the cost of the work itself.

Would you rather cut costs by 10%, or raise them by 10% if it brings revenue forward and grows it by more? The value reaches the market sooner, and you have longer to exploit it. The upside needn’t even be direct revenue; it can be learning that arrives sooner and compounds into revenue later. The balance is lopsided, and the lopsidedness comes from where the money sits. BCG’s 2019 analysis of 35 software companies put median R&D spend among high-growth firms at 26% of revenue. Even a heroic 50% cut to that spend, which guts the capacity that builds the upside, claws back about 13% of revenue in cost, a hard ceiling, while the upside from shipping sooner carries no such cap.

The opportunity cost compounds even further when work is completed in parallel, not serial. The utilisation reflex does more than keep individuals busy; it keeps many projects in flight at once, and that high work-in-process is its own tax. Take three equal-sized epics, worth different amounts once shipped, one team, the same seven months. Run them the Pole-A way, all three in flight, everyone busy, and you defer the value of all three: nothing ships until late, so nothing earns until late, and every switch between them costs time besides. Finish them one at a time instead and the same work, from the same team, delivers three to four times the value by the same date; the figure below works the numbers. The gain comes mostly from finishing one thing at a time; sequencing by cost of delay adds to it.

The AI overlay

Krivitsky, Larman, and Flemm call this the Ferrari Effect in 10X Org: picture each piece of work as a Ferrari built for speed, then jam them all on a one-lane road behind the same trucks. More Ferraris just means more traffic. AI hands every engineer a Ferrari; it doesn’t widen the road. The road is your structure, the handoffs and dependencies that decide whether work can reach a customer without waiting on someone else. Drop AI into a structure full of waiting and it amplifies the dysfunction already there. Their sequence puts organisational design first, then AI.

When AI speeds the coding and leaves the constraint and the handoffs untouched, the time it saves waits somewhere else, in a review queue or at a handoff, and lead times barely move: a little faster⁠—maybe⁠—but far less than the coding speed-up promised, because the gain hits one node in a system already saturated everywhere else.

Further, the tool the leader consults will back the approach. Ask an AI agent how to capture the productivity gain, framed as a question about individual output, and the answer usually comes back in the paradigm it was trained on: load every engineer, raise utilisation, fill the queue. The advice is fluent and confident and aimed at the pole the leader already leans toward, because, as chapter 1 argued, an LLM’s output often regresses to the mode of what it was trained on, not the truth.

The roadmap is the longest-lived, most fashionable queue in most software organisations, and nobody calls it a queue. A roadmap becomes a damaging queue when stale, committed items are treated as obligations rather than revisable hypotheses. Craig Larman, in his Certified LeSS Practitioner course, names a proxy for an organisation’s adaptiveness: the percentage of items in Sprint Planning and Product Backlog Refinement that didn’t exist before the last Sprint Review. An organisation adapting to its situation produces a high number against that metric; an organisation still working a years-old roadmap produces a low one. What most software companies call a roadmap reads as a vestige of annual planning. I ran the roadmap for StubHub’s recommendations engine and read it as diligence. I can’t remember a Product Owner job description that didn’t say ‘own the roadmap for X’. Ryo Lu’s no-fixed-roadmap line in chapter 3 wasn’t bravado. It was a Pole-B leader naming the queue out loud, and celebrating its clearing.

The diagnostic

Three questions for last Tuesday’s allocation meeting.

• Which pole was I claiming? If asked, would I have said I’m optimising for flow or for utilisation?
• Which pole would the last sprint actually show? If a colleague counted how many engineers had no slack, would the number be small (Pole B) or close to all of them (Pole A)?
• Which pole does this work actually require? Heterogeneous, ambiguous, learning-heavy work calls for Pole B. Routine high-volume work with stable specification calls for Pole A. Most knowledge-work portfolios contain some of both, and the proportion is the question.

Ask what you reward when the quarter is measured, not what you would say in a strategy session. Most leaders never chose Pole A; they have simply never priced the queue, so the resource-management spreadsheet decides for them.

If you are reading this as the CTO or VPE thinking about your CEO: on this axis, the action is at the metrics layer your CEO controls. Put a single page in front of them showing the cost of delay on one current initiative, in pounds or dollars, dollarised against the quarter. Reinertsen’s point is that the variable that matters most is invisible in the default management report. Make it visible in the CEO’s unit of account. The test is whether the restructuring decision moves once the cost of not restructuring shows up in the number the CEO briefs the board on. Chapter 3’s rule holds here too: a number gets you in the door, but the win is a named decision with an owner and a date, not the number itself. The sentence your CEO can carry to the board: “We have been paying for idle-time savings with delay costs many times larger.”

The exercise: sum the queues, then price them

If you summed the total queue lengths sitting across all your backlogs right now⁠—the tickets parked between stages, the work that entered the system but never left it⁠—what number do you get? If you can, adjust for planned and unplanned work, and for how much your delivery rate swings iteration to iteration. Most leaders have never added it up, because almost nothing totals it for them. An estimate may be the best you can achieve.

Second: convert it into an estimated cost of delay. Take one initiative sitting in that queue, put a pounds-or-dollars figure on a week of delay against it, and multiply across the wait. Expect the figure to dwarf the idle-time saving the utilisation report is protecting. When I’ve run this with clients, it produces the same silence-then-ooooh a live demo does, because the variable nobody has dollarised is the variable nobody has been managing.

Going upstream

Watch. Henrik Kniberg, The Resource Utilization Trap (6 min): Reinertsen’s curves felt rather than read. Yuki Sugiyama et al., Shockwave traffic jams recreated for first time (3 min): a phantom traffic jam forming on a circular track without any bottleneck, Reinertsen’s utilisation and flow maths in the wild. Recommended if you have the time: Don Reinertsen, The Logic of Flow: Some Indispensable Concepts, with slides (FlowCon San Francisco 2014, 33 min).

In-text: the references named in the body. Donald Reinertsen, The Principles of Product Development Flow (the canonical: the three curves, the cost-of-delay E3 principle, the 100-percent-measure-cycle-time / 2-percent-measure-queues tally). The adaptiveness proxy metric comes from Craig Larman’s Certified LeSS Practitioner course. Reinertsen’s 1983 McKinsey analysis, published as “Whodunit? The search for the new-product killers” in Electronic Business, is where the six-months-late / 50-percent-over-budget asymmetry comes from. The R&D-spend benchmark is Boston Consulting Group, How Software Companies Can Get More Bang for Their R&D Buck (November 2019), whose analysis of 35 companies puts median R&D spend among high-growth software firms at 26% of revenue. The Ferrari Effect is from Alexey Krivitsky, Craig Larman, and Roland Flemm, 10X Org: Powered by Org Topologies.

Go deeper: the Theory-of-Constraints lineage this chapter rests on, developed in full in chapter 8: Eliyahu Goldratt, The Goal (don’t maximise utilisation everywhere). The software translation: Jez Humble and David Farley, Continuous Delivery (the deployment pipeline as single-piece flow), and Gene Kim, Kevin Behr, and George Spafford, The Phoenix Project (Goldratt staged in IT operations, with Brent as the constraint made personal). The cost-of-delay and dollarisation lineage: Mary and Tom Poppendieck, Lean Software Development and The Tyranny of “The Plan”; Stephen Fox and Richard Gregory, The Dollarization Discipline. The instrumentation that makes the queue maths visible to non-specialists: Daniel Vacanti, Actionable Agile Metrics for Predictability (cumulative flow diagrams, cycle-time scatter plots, service-level expectations as probabilities). The doctrinal tempo extension, developed further in chapter 17: USMC, MCDP-1 Warfighting (tempo is itself a weapon; the main effort / Schwerpunkt); Robert Coram, Boyd: The Fighter Pilot Who Changed the Art of War (the OODA fast-transient theory). The further software-engineering translation: Gene Kim, The DevOps Handbook (the Three Ways of DevOps), and Gene Kim and Steven Spear, Wiring the Winning Organization (slowification, simplification and amplification); Forsgren, Humble, and Kim, Accelerate (the four delivery metrics; Ron Westrum’s pathological / bureaucratic / generative culture typology, taken up again in chapter 16).

Inside the leader, a gap runs between what you say you believe and what you visibly did when the stakes rose. Chris Argyris called it the distance between espoused theory and theory-in-use. It is the utilisation trap’s gap again, between the efficiency we claim to want and the busyness we actually reward. In chapter 5 you look for it in yourself. On most axes you can sort yourself into the pole that flatters you. This one doesn’t, because your team watched you decide. They have better data.

Continue reading: Chapter 5 finds the same gap inside the leader: the difference between the values you state and the ones you run on under pressure.

I work with CTOs and CPOs at software companies with roughly 25–500 engineers, where the engineers are faster with AI and the business isn’t yet seeing the full value. When AI speeds the coding but the handoffs stay put, lead times barely move, so I help leaders find the queues and put a price on the wait. If it’s live for you, book a free 30-minute call at hi.chrisgagne.com and bring the one question that would make it worth your time. If you know a CTO or CPO in that spot, pass this chapter on. If you’d rather read on than talk, the newsletter goes on past chapter 23, monthly, at https://www.linkedin.com/newsletters/come-prepared-to-die-7472144387981062144/

Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.

The cheap mistake is the tokens. The expensive one is the org design you left in place.

Chapter 2 named the meta-skill of holding a paradigm as an object. Practise it first on your AI rollout itself. If the board is already asking what the AI spend has bought, start here.

The two poles

Pole A: AI as productivity layer. AI is a tool that can make existing tasks faster and cheaper. The organisation chart, role boundaries, and career ladders stay. Capable people get more done. Pole A treats AI as an adoption exercise: roll out training to start, identify the laggards, then conduct layoffs to capture the gain as a smaller team hitting the same OKRs.

Pole B: AI as impetus for org redesign. AI surfaces a question the old org chart had already stopped answering well: which work is human. Pole B hires intelligent, independent-minded, liberal-arts generalists who set their own direction, people who can define an outcome, specify the constraints, choose which work goes to AI and which stays human, and verify what comes back. Good taste now matters as much as execution skill. The specialist-scarcity logic only holds while expertise stays scarce, hard to get, and in unlimited demand for that exact skill, and Krivitsky et al. argue in 10X Org that AI dissolves exactly that. Pole B treats the generalist as the new central role.

Where Pole A is right

Pole A is right where the work is genuinely procedural, or where regulatory constraints prevent role redesign inside the planning horizon. It also has a fair case as a bounded experiment while you are still finding where the jagged edge sits: putting AI into today’s roles shows, task by task, what it can carry before you redraw roles around a capability that moves every quarter.

Chapter 2 walked Adam Smith’s 1776 pin factory: identical units, effectively unlimited demand, hyper-specialisation that compounds. AI in a pin-factory context behaves like Pole A predicts: the role exists for AI to make faster and still works after AI makes it faster. The leader doing Pole-A pin-factory work and getting Pole-A pin-factory gains is doing the right thing in the right context.

The reality test for Pole A is whether the work the AI is making faster is actually pin-factory work. Most of the work running through a software-dependent organisation isn’t.

Where Pole B is right

Pole B is right wherever AI has already moved past your org chart’s design assumptions, especially where competitors are redesigning or newly forming. That describes most software-permeated (or software-vulnerable) industries right now.

Krivitsky et al. argue that nobody needs 1,000X more databases. When AI dissolves specialist scarcity, the existing org chart⁠—not the technology budget⁠—becomes the binding constraint. The Pole-A reflex is to consolidate⁠—one “hyper-efficient” DBA for the whole org looks more attractive than ever⁠—which still leaves the org chart in place, just bent the wrong way. Pole A leaders may discover two years late that their biggest cost curve was the incumbent org design itself, with token spend a rounding error against it. By then the redesign is no longer cheap, the Y Combinator startup looms larger than ever, and the window closed while managers were looking at the per-developer velocity reports. Most of what software touches now has a low barrier to entry. This context is so novel that I wonder if any prior moats will be durable unless incumbents build on them with an adaptive org redesign first.

The 10X Org operating-model material describes what the redesigned org chart looks like in practice: broader mandates, smaller teams, more outcome-orientation at the team level, less hand-off and inventory between teams. Jay Galbraith’s Star Model is underneath: strategy, structure, processes, rewards, and people have to move together. Pole A redesigns collapse to terminology and tools, leaving Galbraith’s five points largely where they were. Pole B leaders accept that the AI shift exposes all five points at once.

What the past 18 months show

10X Org made its case in the future conditional: AI-native organisations would outcompete incumbents constrained by industrial-age headcount logic. Among the leaders, that future has already arrived. Anysphere’s Cursor reportedly reached roughly $2B in annualised revenue by early 2026 with a headcount in the low hundreds. The Lean AI Native Leaderboard, on its 2025 reading, benchmarked the top ten AI-native firms at $3.48M of revenue per employee against $610K for the top ten classical SaaS companies, a 5.7x gap among the leaders. Take each figure as a timestamped illustration, consistent with the thesis rather than proof of what caused the gap: the Cursor headcount, the leaderboard’s multiple, the formation rate will all move quarter on quarter. I don’t expect the direction to reverse. New formation as of early 2026 is following the same line, with roughly half of one recent Y Combinator batch building AI-native services or AI-enhanced software.

The operating playbook Cursor’s head of design, Ryo Lu, describes matches what 10X Org prescribed: PM work spread across the builders, no fixed roadmap, the world changing faster than any plan can hold. Sierra’s Bret Taylor puts the incumbent failure mode in one phrase: large companies fail at AI because they are shipping their org charts. The mechanism is Conway’s 1968 law: organisations build systems that mirror their own communication structure. The case that the structure has to change first is this chapter’s, built on that law.

AI capability is jagged

Karpathy’s jagged intelligence names a paradox: the same system operating as a genius polymath in mathematical reasoning and a confused grade schooler in common-sense spatial reasoning. Ethan Mollick’s jagged frontier gives the working rule: tasks that feel equally hard to a human can sit on opposite sides of an invisible capability line, and you can’t know which side a task is on without trying it. The redesign question becomes which jagged edge fits which work? That question has to be asked task by task, with empirical testing, in the actual context the work runs in, and the answer changes quarterly.

Karpathy’s vibe coding names the mode; the trap is what you do with it: build by prompt, trust what comes back, forget the code exists. He frames it as floor-raising, and explicitly distinguishes it from agentic engineering, where⁠—his words⁠—you’re still responsible for your software just as before. The Pole-A trap is vibe-coding work that needed agentic engineering: the loose, sketch-driven build ships, and the plausible code didn’t match the actual contract.

Klarna made the same edge-misjudgement at scale, and it is one dated instance of the pattern, not the whole case: it walked back a sweeping AI-for-support move in 2025, its CEO conceding the company had leaned too hard on cost and efficiency and that quality had suffered, and it began rehiring humans for the cases where AI parity hadn’t held. The capability looked sufficient at the edge it was tested against, but the work it was actually meeting lived a few inches further in: the company had automated the cost away without automating the work.

Pole B done well holds the jaggedness explicitly. It asks, for each piece of work being redesigned: which jagged edge are we standing on, how do we test that empirically, and what is our recovery plan when the jagged edge moves?

A worked example: the inverse of NUMMI

In the 1980s GM set out to learn Toyota’s production system through NUMMI, its joint venture with Toyota at Fremont, and Toyota flew the plant’s workers to Toyota City in Japan, in groups of 30, for training. The visible practices on the floor could be photographed and presumably copied in other plants. The invisible system⁠—the supporting management functions, the supplier relationships, the relationship between the Team Member Handbook and daily work⁠—couldn’t be seen, let alone readily transplanted into GM’s existing structure. Ernie Schaefer, the GM plant manager who later tried to replicate NUMMI elsewhere and failed, came to understand why only later, and described it on This American Life’s “NUMMI” episode in 2015:

“You know, they never prohibited us from walking through the plant, understanding, even asking questions of some of their key people. You know, I’ve often puzzled over that⁠—why they did that. And I think they recognized we were asking all the wrong questions. We didn’t understand this bigger picture thing. All of our questions were focused on the floor, you know? The assembly plant. What’s happening on the line. That’s not the real issue. The issue is, how do you support that system with all the other functions that have to take place in the organization?”

On Schaefer’s reading, Toyota let GM walk the plant freely because the answer GM needed wasn’t on the floor; it was in the supporting system, and GM wasn’t asking about that.

The Pole A leader is asking the GM-1985 question about AI: where on the line can we deploy this? The Pole B leader is asking the question NUMMI itself was an answer to: what does the org have to become for this to meaningfully compound?

Pole A is also much easier to delegate. The CEO can hire a trainer, brief the senior and middle managers, and stand up a rollout without ever changing their own week, let alone the whole org. Pole B has no such proxy. Deming put the responsibility where the systems are: management owns the systems, and therefore owns most of what goes wrong inside them. The redesign reaches the strategy and structure only the CEO owns, so it is the CEO’s own work, and far more of it. That a pole can be delegated at all is a tell that it isn’t touching the system. But the pull toward Pole A isn’t weakness; it is the rational preference for the option you can hand off.

I find this example particularly helpful because it is a case of Pole A failing not for lack of effort or for lack of access. The GM workers were on the floor at Toyota. Toyota answered their questions. The transplant beyond NUMMI largely failed anyway, because the answers were sitting in the supporting system, not on the plant floor, and GM’s supporting system was Pole A’s supporting system. Jeffrey Liker, who has studied Japanese auto manufacturing since the 1980s, was asked on the same episode why GM’s senior management wouldn’t accept that Toyota built better cars: “I think there was pride and defensiveness. I’m proud because I’m the biggest automaker in the world. I’ve been the best. I’ve dominated the market. You can’t teach me anything, you little Japanese company.” The resistance wasn’t only passive. Dick Fuller, who ran IT at NUMMI, remembers a GM manager who toured the plant, went home, and wrote a report that amounted to “won’t work here.” “I think part of that,” Fuller said, “was a threat to him. It was a threat to him to see that it was working so well.” This is Weinberg’s 10% ceiling from chapter 1, seen from the manager’s side.

Another change-agent, Jeff Weller, sent in the 1990s to convert plants, was simply thrown out of one: “I was asked in one plant to leave, because they were not interested in what I had to sell.”

The plant manager was still king, and nobody above him overruled him: in a company that big, Weller said, it doesn’t work that way. The same holds now for AI inside legacy org designs: the tool is on the floor, the supporting system is the org design, and the org design keeps doing what it was built to do.

I suspect most software-dependent organisations in 2026 are still running the GM-1985 playbook: on the floor asking Schaefer’s wrong questions about AI, while the supporting system⁠—the org chart, the career ladders, the approval gates⁠—keeps the existing pattern intact by design.

What your last Tuesday actually shows

GM’s managers walked the NUMMI floor asking the wrong questions because they had already decided what the factory was for. The answers they got were locally correct and systemically useless. The same happens with AI procurement. You can be rigorous about what you bought and still be answering local-optima questions when the context is asking for system solutions.

I built a tool to sharpen incident learning, and it does that: it can articulate a systemic issue more precisely than most review meetings manage. What it cannot do is give a team the authority to change the conditions it has just named. The constraints that mattered were usually well out of reach of anyone in the room, or within one degree of it.

So: three questions for last Tuesday’s AI decision:

Which pole were you claiming? In the deck, the procurement memo, the rollout email, which pole did the language point toward?

Which pole would the implementation actually show? Three months out, does the team (or team-of-teams) become more adaptive, with a broader work mandate, fewer hand-offs, easier to redirect? Or just more efficient at the same work? If it is the second, Pole A delivered what Pole A promised. That describes what was chosen, and it is worth reading as data rather than as a failure.

Which pole does this situation require? This is the Cynefin question, and my rule of thumb for it: complex work whose consequences arrive in months calls for Pole B, the redesign. Complicated work with a stable specification makes Pole A a reasonable fit. Most senior-leadership portfolios hold some of both, so the strategic question is the proportion across the whole portfolio, one tool at a time.

The most visible gap sits between question one and question two. Leaders claim Pole B in the deck and ship Pole A in the implementation, and the team sees only the second. That gap is recoverable once you name it: you ran an efficiency play, it worked, and here is what it taught you about the redesign question underneath. The more consequential gap sits between either of those and question three. A leader whose claim and procurement both say Pole A is internally consistent, and may still be inconsistent with a context that has already moved.

The tells live in the procurement spreadsheet and the headcount plan. Pole A signs against hours-saved-per-role tools and reads efficiency dashboards, with an implicit objective of a payroll reduction that dwarfs the rise in token spend. Pole B puts its money into hiring multi-skilled generalists ahead of tool-rollout training, and makes new roles official before the AI capability is fully stable. Both are coherent. Where your three answers diverge is the next conversation to have with the CEO.

For the CTO or VPE: the decision on this axis sits at the strategy and structure layer the CEO owns. Put the procurement spreadsheet and the headcount plan in front of the CEO at once, side-by-side with the Pole A / Pole B claim in the last board deck, and ask them to read the gap. Run the same check one layer down on yourself first: do your own hiring plan and engineering ladder ship the pole your strategy deck claims? The gap hits harder upward when you have already closed it in your own house.

Before the meeting, read its history: what happened to the last person who brought this CEO unwelcome news? If the answer is bad, that pattern is the first problem, not this chapter’s. Once you’re in it, go first⁠—disclose your own gap on the same axis, before the CEO’s⁠—with the norm said aloud: nothing here gets used as a club, by either of us. Ask for their account before the artefact comes out. If the CEO defends the gap rather than looking at it, treat that as data rather than proof: test whether you are disagreeing about the facts, the stakes, or the frame itself. Describe what you see, flatly, then stop. As you close, end with a named decision, an owner, and a date; agreement without a date isn’t yet a win.

And if you are the CEO reading this over a colleague’s shoulder: your half is the receiving side. Ask for the story behind the deck, thank whoever went first, and hold the no-club norm yourself. The safety is real only when the most powerful person present refuses to weaponise what’s said.

The CTO’s hiring plan is where this shows up at the role level. Pole-A hiring backfills narrow specialists and adds AI tools: more frontend engineers, more backend engineers, each productivity-boosted. Pole-B hiring inverts it: a smaller team of generalists, each able to define outcomes and orchestrate AI rather than execute against a specification. By the time the redesign window closes, the Pole-A CTO has built a bench of narrow specialists AI is dissolving, and now has to retrain them, lay them off, or watch the AI-native competitor recruit them.

The question to bring is which roles in this company still depend on the narrow-specialist assumption AI is dissolving? For scale, as of early 2026 the top AI-native firms are running several multiples ahead of their classical peers on revenue per employee. This is a CEO decision about what the org is, not a technology decision about what the tools do. The sentence your CEO can carry to the board: “We’ve been investing in AI tools and not in how we’re organised to make them pay.”

An exercise: the shadow org chart

You can start tomorrow, alone, without anyone’s permission: take one engineering team or team-of-teams and redraw it on a blank page as if AI capability had been assumed from the day the team was formed. Ignore the current titles, skill sets, and reporting lines. Sort the team’s actual work into three bands: AI-autonomous, where a human reviews outputs but doesn’t generate them; AI-supervised, where a human directs the AI and verifies what comes back in real time; and fully human. Then draw the team that work implies: how many people, in what roles, reporting to whom. Lay the shadow chart beside the real one. The gap between them is your own estimate of how far the redesign has to travel, and you built it without a meeting.

Then ask a second question: for each role that survives, what does the human job on the other side actually look like? Map it: title, career ladder above and below, hiring filter, on-ramp. Expect one of two results. Either the new role doesn’t exist yet in the org chart, and the redesign work begins in earnest. Or it exists, but sits inside a career ladder built for the old role, with progression criteria that still reward the old behaviour. Roles are downstream of strategy, structure, processes, and rewards; the map makes the downstream relationship visible. Be mindful not to lean on existing skill-based roles; consider what skilful generalists with good taste can do.

At one client, I paired with the CTO on the career ladders. The specialised developer roles became a single Engineering role, and we thought through how each role would use generative AI. My reasoning was that AI speeds the work and moves the delay to the handoffs between specialists, so teams that own the whole problem get more from it.

Then run the map a second time with the CEO against the org chart, without the team present, and name who decides what changes on the back of it and on what timeline. If the answer is the role redesigns, bring it to the team and redo the map with them: the leadership-only version is a hypothesis about work-as-imagined, and chapter 14 explains why it will be wrong about work-as-done. If the answer is the work has dissolved, that is a different conversation that doesn’t belong in this exercise. The team is owed the truth, not an exercise that arrives looking like an ambush. The solo shadow chart is yours to run tomorrow; the shared redesign is a CEO decision about strategy and structure, and the CTO carries the role-bifurcation half.

The cheap mistake is the tokens. The expensive one is the org design you left in place.

Sources for the AI buyer who wants to go upstream

In-text: Krivitsky et al., 10X Org: the structural case behind this chapter, including the specialist-scarcity claim and the nobody needs 1,000X more databases argument. The paradigm-and-identity extension is mine. The Lean AI Native Leaderboard on the 5.7x revenue-per-employee gap. Ernie Schaefer’s account of why the NUMMI transplant failed, and Jeffrey Liker on the pride and defensiveness he saw in GM’s senior management, both from This American Life’s “NUMMI” episode (2015). Andrej Karpathy’s 2025 LLM Year in Review for jagged intelligence and vibe coding, and his Sequoia AI Ascent interview for agentic engineering and the still-responsible-for-your-software line. Bret Taylor on companies shipping their org charts.

Also touched: Jay Galbraith, Designing Organizations, on the Star Model: strategy, structure, processes, rewards, and people moving as one. Dave Snowden’s Cynefin framework for the complex-versus-complicated test in question three; chapter 7 takes it up.

Go deeper: Watch. Craig Larman, Craig Larman’s Take on 10X ORG: Why He Thinks This Book Matters (5 min), names the dichotomy directly: Pole A as the cost-curve trap, where AI is cheap, always-on labour and a human who offers only a 10% improvement won’t compete; Pole B as the 10x redesign claim, with 10xOrg, Org Topologies, and Large-Scale Scrum (LeSS). Read. Org Topologies (start with their primer) on the operating-model maps that go with the redesign. On the macroeconomic frame, Daron Acemoglu and Simon Johnson, Power and Progress, and Acemoglu’s The Simple Macroeconomics of AI (2024 paper); Power and Progress’s “so-so automation” names the Klarna pattern above. Ethan Mollick’s Co-Intelligence for the practitioner-side empirical material and the jagged frontier framing named above. Conway’s 1968 law, that organisations design systems mirroring their own communication structure, behind Taylor’s phrase. Cursor’s Head of Design Ryo Lu on how the work actually runs, in his November 2025 interview with Peter Yang, as reported by DevClass: a lot of the PM jobs are spread across the builders in the team, and no fixed roadmap (chapter 7 quotes his reason). Further AI-native revenue datapoints: Sierra at $100M ARR in 21 months on outcome-priced agents, ElevenLabs past $500M ARR in early 2026 with about 530 people, and the W26 batch analysis counting half the companies as AI-native or AI-enhanced. Klarna’s walk-back: it had replaced the equivalent of some 700 support agents with an AI assistant before reversing in 2025.

The org design you left in place is also deciding how fast work moves through it. “Keep everyone busy” feels like responsible management. In high-variation work like software it slows the whole system down hard, and the maths that proves it takes minutes to learn. Chapter 4 shows you that curve, and where your own org chart already sits on it.

Continue reading: Chapter 4 shows you that curve, and where your own org chart already sits on it.

I work with CTOs and CPOs at software companies with roughly 25–500 engineers, where the engineers are faster with AI and the business isn’t yet seeing the full value. When AI speeds the work, the delay tends to move to the handoffs between specialists, so I help leaders build teams that own the whole problem. If it’s live for you, book a free 30-minute call at hi.chrisgagne.com and bring the one question that would make it worth your time. If you know a CTO or CPO in that spot, pass this chapter on. If you’d rather read on than talk, the newsletter goes on past chapter 23, monthly, at https://www.linkedin.com/newsletters/come-prepared-to-die-7472144387981062144/

Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.