Category: Operating Models & Flow

The fix for one of the PHP2Shell flaws stalled for months on hard trade-offs and too few people to resolve them. Any engineering leader with a hard fix parked in the backlog should recognise the pattern.

In 2024 a developer working for the PHP Foundation found the first signs of a flaw in how PHP handles running out of memory. Every fix the team built carried a cost, nobody had found a way to exploit the flaw, and work on it stalled and restarted for months. In August, AI-assisted researchers showed it could be exploited. On 21 October PHP shipped fixes for that flaw and a second one, both rated 9.2 out of 10 on the industry’s severity scale and both able to let an unauthenticated attacker run code on a server. The release was brought forward a day after the flaws’ identifiers began circulating online.

Headlines from the Wall Street Journal to Wiz’s blog led with the AI. The PHP Foundation’s account of why the first flaw sat unfixed is more useful for leaders, and it was blunt:

“We won’t pretend otherwise: the delay was a structural failure, caused by both the security team’s decision process and its lack of resources.”

The fix stalled on trade-offs and too few people

The flaw surfaced while the developer was fixing an issue from PHP’s first external security audit in years, which the Foundation organised with funding from Germany’s Sovereign Tech Agency. An exploit was theorised, but nobody found a concrete way in, and other issues with clear impact took precedence. The security team built several competing fixes. Each had costs, from backward-compatibility breaks and new denial-of-service risks to changes in third-party extensions that seemed impossible to coordinate. The Foundation described what followed:

“The PHP security team, operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice.”

Few people know the engine well enough to make that call. The Foundation maintains the language with only 13 full-time and part-time engineers, The Guardian reported. The Foundation says its security work depends on “a small group of foundation-funded developers and a little volunteer help”.

AI made the exploit cheaper

The Foundation brought PHP into the Patch the Planet programme, through which Calif began auditing it on 30 July. On 11 August a Calif researcher, helped by OpenAI’s GPT-5.6 Sol, reported remote code execution with the same root cause. From then on the fix was the Foundation’s top security priority, and it was still a big job. Close to 200 files were fixed and more than 10,000 lines of code written, the Journal reported. Recorded Future said release-day reporting didn’t establish how many attacks had succeeded.

AI-assisted research also brought far more reports. Since 1 July, the Foundation said, the team has published 15 CVEs and worked through more than 100 reports that turned out to be invalid, duplicates or not reproducible. AI helps sort them, but a person makes every call. The Foundation was clear about what the tools can’t do:

“Tools now find bugs faster than ever, for defenders and attackers alike, and the number of reports will keep growing. What tools cannot do is decide on the right fix for a long-standing design decision in the engine, weigh the compatibility trade-offs, and review the patch.”

AI made finding the exploit cheaper. The bottleneck stayed where it was: choosing a fix, and having people with the time and expertise to build and review it.

A near miss, with limits

I read this through my book, Come Prepared to Die, which drew on Scott Snook’s Friendly Fire. Snook studied the 1994 shootdown of two US Army Black Hawks over northern Iraq. About 18 months earlier, Air Force F-111s nearly attacked Black Hawks from the same unit under nearly the same conditions. One of the Black Hawk pilots told investigators the unit’s commander had been on the flight: “As far as I know he knew about it and that was about as far as it went.” In the book’s chapter on safety I wrote that the near miss was the leading indicator, and the accident report was the lagging one.

PHP’s warning was tracked and worked on, while Snook’s near miss was never formally reported. Snook also doubted that escalation alone would have taught the right lesson. Recognising a hazard doesn’t mean an organisation can resolve it.

What to do with your own parked fixes

The Foundation created an Ecosystem Security Team in May and says stuck fixes will now reach its leadership sooner. The security team is changing its process so decisions can be made by majority. The Foundation is also asking companies that build on PHP to sponsor it “at a level that reflects how much you rely on it”. If your business runs on PHP, consider making a contribution here.

In Minimum Viable Bureaucracy, the handbook I refined over my last three engagements, a risk that hasn’t become an incident yet still goes to a named owner and into the backlog, ranked by how likely it is to happen and how bad it would be if it did. A flaw nobody can exploit yet can still rank near the top.

In your own backlog, start with high-consequence fixes deferred because exploitation seems hard. Name who owns the decision and can commit engineering time, and set a date to review the deferral. If you accept the risk for now, write down what evidence would reopen it.

Thanks to George Lawton, who suggested I look at PHP2Shell through the lens of the book.

Sources

1. PHP Foundation, “Today’s PHP Security Release, and How We’re Strengthening PHP Security”, 21 October 2026.
2. PHP, release notice and pre-announcement, 20–21 October 2026.
3. Robert McMillan, “AI Just Found a Bug That Puts up to 70% of the World’s Websites at Risk”, Wall Street Journal, 21 October 2026, via To Vima.
4. The Guardian, “What is PHP and how serious is the computer language flaw causing website shutdowns?”, 22 October 2026.
5. Recorded Future, “PHP2Shell Exploitation: Two Critical PHP Flaws Explained”, 21 October 2026.
6. Scott A. Snook, Friendly Fire, 2000, chapter 7.
7. Chris Gagné, Come Prepared to Die, chapter 15.

You split the difference and called it fair. Next quarter, the same argument is back. What brought it back?

Chapter 19 found that Pole B leaders convene the people who know and back the call they make. Even a skilled facilitator can reach an agreement that some participants were afraid to question. Before looking for a solution, find out who can safely say what they want.

The two poles

Pole A: settle within the available options. Allocate the scarce resource or negotiate a compromise, acknowledging what each party will give up.

Pole B: change the available options. Test the assumptions that make the two positions collide and look for a solution that meets both underlying needs. The parties must be able to question whether it does.

Where Pole A is right

When the resource is genuinely fixed, dividing it is the work: this cycle’s bonus pool, one open VP seat, the headcount available before a deadline. You can still question whether those constraints hold, but a decision may be needed before they can change. Mary Parker Follett, a management thinker writing in the 1920s, argued for integration: finding a solution that meets both parties’ needs. She also recognised that this wouldn’t be possible in every conflict.

Sometimes the search for an integration costs more than it is likely to save, and a quick fair split, openly made, is worth the time it saves. A clean division can also protect a working relationship better than an optimal solution reached through a bruising process.

Where Pole B is right

Pole B is right when the underlying needs can both be met, even if the stated positions appear incompatible. In Follett’s example from the Harvard Library, she wanted to avoid a draught and another reader wanted more air. They opened a window in the empty next room. Both got what they wanted without either having to give something up.

When a compromise keeps re-opening, an unmet need may be bringing it back. The circumstances may also have changed, or the settlement may have been temporary from the start. Recurrence is a reason to investigate.

In decisions

Pole A leaders make and explain an allocation or negotiate a split. Pole B leaders look for a change that meets both needs.

Take a recurring settlement to whoever has authority over the disputed decision. That may be the compensation owner, the budget owner, or the CEO. Ask what each side actually needed and what both were assuming had to be true for these to be the only options. Then question the allocation of authority itself. Follett argues that authority belongs to the job; does the person making this call have the knowledge and responsibility the work requires?

The sentence your CEO can carry to the board: “We need to understand why these settlements keep coming back before we negotiate them again.”

Follett’s three ways

In “Constructive Conflict,” a lecture she gave in 1925, Follett asks the reader to treat conflict as neither good nor bad, “not as warfare, but as the appearance of difference, difference of opinions, of interests. For that is what conflict means⁠—difference.” Difference is unavoidable, so the task is to use it, the way a mechanical engineer both fights friction and runs the belts on it.

“There are three main ways of dealing with conflict: domination, compromise and integration.”

Domination is one side winning. Easy in the moment, she says, and not usually successful in the long run. Compromise is the accepted way of making peace by giving something up. Follett argues that the curtailed desire can bring the conflict back. Integration meets both needs: “when two desires are integrated, that means that a solution has been found in which both desires have found a place, that neither side has had to sacrifice anything.” “Compromise does not create,” she writes, “it deals with what already exists; integration creates something new.”

Follett begins with disclosure: “The first rule, then, for obtaining integration is to put your cards on the table, face the real issue, uncover the conflict, bring the whole thing into the open.” Then you break the demand into its parts, distinguish the declared motive from the real one, and look for a solution that serves both. Before asking people to put their cards on the table, I want to know what it could cost them.

Artificial harmony

A team can also avoid addressing the conflict at all. Patrick Lencioni calls the apparent agreement artificial harmony. It makes the work harder because people have to discover what their colleagues think after the meeting has ended.

Lencioni describes teams resorting to “veiled discussions and guarded comments” when they can’t argue openly. They feign agreement in the meeting and carry the disagreement into hallway conversations and personal attacks. A meeting with no visible disagreement and a car park full of it afterwards is a reason to ask what people couldn’t say in the room.

The power question

Who at the table can safely state a real need, refuse, appeal, or walk away? These are different capacities, and each needs a separate check.

Stating a need takes safety. Amy Edmondson’s work on psychological safety examines whether people can take interpersonal risks, including admitting a weakness or naming a problem. Lencioni’s vulnerability-based trust matters here too. Neither, by itself, gives an employee authority to refuse a decision.

Refusing takes standing. Chris Voss, the FBI hostage negotiator, writes that “‘No’ is the start of the negotiation, not the end of it.” His “No” expresses the autonomy of a party inside a negotiation. An employee also needs to know what happens if they refuse their manager. A negotiation technique can’t supply that protection.

Appealing takes a route that the other party doesn’t control. In her paper on responsibility, Follett challenges the illusion of final authority and insists that “authority belongs to the job and stays with the job.” An appeal that runs back only to the person you are appealing to isn’t an appeal.

Walking away takes material independence. Who can afford to leave this negotiation, and what would leaving cost them?

Ask who can fire each participant, cut their bonus, or deny their promotion. Who controls the minutes, the information, and the appeal? Barry Oshry built the Power Lab, a residential simulation with built-in differences in power and resources, to study how position shapes what people see. When two parties (his Ends) look to a third (the Middle) to move their competing agendas, “Ends become decreasingly responsible for resolving their own issues and conflicts, while Middle becomes increasingly responsible for resolving these.” Look especially carefully at whoever sits in that middle, and at whose needs are missing from the discussion.

Follett describes power-with as “a jointly developed power, a co-active, not a coercive power.” She argues that “genuine power is capacity” and that “you cannot confer power, because power is the blossoming of experience.” I take this to mean that integration can also strengthen people’s ability to participate in later decisions. Unequal authority doesn’t make every agreement coerced, but it does require us to examine what an apparent yes means. Someone may be unable to leave a job and still reach an agreement that meets their needs. If they can’t question the proposal without risking their livelihood, we need to address that risk before relying on their assent. An allocation requires the same care.

When a party attacks the conditions

Threats or retaliation can make a negotiation unsafe to continue. In that situation, protect people’s ability to participate before asking them to seek a joint solution.

Karl Popper warned in The Open Society and Its Enemies that unlimited tolerance could destroy a tolerant society, while cautioning against suppressing views that could still be challenged through rational argument and public opinion. His paradox of tolerance helps me think about this limit. His discussion concerns the defence of a society. Applying it to a leadership meeting is my analogy.

A colleague remaining unconvinced is insufficient evidence of bad faith. I’d ask what evidence could change their position and make my own answer available too. If they refuse to name any conditions for reconsideration, we can record that refusal and ask why. We still have to distinguish an inference about their motives from what they actually did.

Where the conduct prevents others from participating, name it and hear the response. If someone must be excluded from part of a decision, specify the restriction, its duration, and how it can be challenged. Review needs to sit with someone independent of the disputed conduct; a manager further up the same chain may not provide that. If no such route exists, acknowledge the limitation and seek one.

“They are acting in bad faith” is an easy label for a leader to abuse. Excluding someone is an exercise of power with consequences for them. I’d want the judgement open to challenge and the person making it to remain willing to reverse it.

Goldratt’s cloud

The best instrument I know for testing the conflict is Eliyahu Goldratt’s Evaporating Cloud, from his 1994 business novel It’s Not Luck. It is a diagram of five parts: a shared objective, two requirements the parties believe necessary to achieve it, and two prerequisites that appear to conflict. The assumptions connecting those parts are what you test.

When a colleague admires the cloud as a presentation technique, the protagonist answers: “this technique claims that you should not attempt to strive for a compromise. It advocates examining the assumptions under the arrows in order to break the conflict.” The practical advice is to “concentrate on the arrow that irritates you the most.” Read it aloud as a full sentence: “in order to have X we must have Y, because,” and finish the “because.” You now have an assumption you can challenge.

Goldratt teaches the tool through a teenager’s curfew. The shared objective is a good family life. His character wants his daughter home before ten for her safety; she wants to stay out later to be accepted by her friends. The assumption connecting the early curfew to safety is that coming home late is itself the danger. Once they look at how she’ll get home, she asks him for a ride, and he agrees. Both needs can be met. The cloud helps them test what each has assumed about the conflict, including assumptions they brought to it themselves.

When the opposition is real

Sometimes no change you can make will give both parties what they need. Calling that outcome a win-win conceals the loss. A fair allocation may be the best available decision.

The person making the allocation needs legitimate authority over it. They should disclose the constraints and criteria, hear objections before the call, and explain who will go without what they wanted. Those affected need a route to challenge the decision. Candidly owning an allocation doesn’t excuse an abuse of authority; the person deciding must also be answerable for how they used it.

You can also settle provisionally while you keep looking for an integration. Check whether the formulation is poor, whether someone affected is missing, or whether the deadline arrived before a solution did. Follett stresses the intelligence and inventiveness integration requires. Failing to find one isn’t proof that none exists. Record what remains unresolved and agree when to revisit it.

Voss’s “no deal is better than a bad deal” challenges the reflex to split the difference. His approach may produce a more favourable bargain or a decision to walk away. Goldratt’s cloud asks whether both underlying needs can be met by changing an assumption. I’d choose between these approaches according to the conflict and the parties’ ability to take part.

The AI overlay

In an AI deployment, the interests to reconcile belong to the people and institutions involved. A model’s output may supply an argument worth examining, but the model isn’t another stakeholder whose needs the settlement must satisfy.

Whose needs does the tool serve, and whose work does it now read or direct? Name who chooses the vendor, writes the policy, and decides when an output becomes an action. Also ask who bears the consequences of a mistake. “The model decided” is domination hiding behind a machine. Apply all four questions to the people affected: can they state a need, refuse a proposed use, appeal an outcome, and walk away? What would each choice cost them?

A representative case

Consider two engineering leaders disputing a shared platform team’s roadmap. One needs a reliability standard held. The other needs a launch date met. The platform team has a fixed number of weeks, so the decision appears to require a trade-off. In Oshry’s terms, the platform team is the Middle, and both leaders are about to hand it their conflict.

Suppose you declare reliability “a standing standard” and announce that both needs are met, while assigning the reliability work to people outside the negotiation. The work didn’t stop eating weeks; it moved onto on-call rotations, maintenance, and the product teams who now inherit the acceptance criteria and never got a vote. Those people need to be part of the decision before you can claim to have met everyone’s needs.

Smaller batches and progressive delivery are candidates to test. Forsgren, Humble and Kim found in Accelerate that high-performing teams achieved both speed and stability. That gives these leaders reason to question the assumed trade-off, but it doesn’t establish that a change in delivery method will meet this launch date and this reliability standard.

Suppose the cloud exposes a belief that meeting the launch date requires releasing every planned feature together. Test that with the launch owner: what must be available on that date, and which capabilities can follow? Then ask the engineers whether the smaller release can meet the reliability standard within the available time, including the investment in changing delivery practices. Integration depends on both answers, with the people doing the work able to contest the estimates. If the launch genuinely requires every feature, or the reliability work still exceeds the time available, the proposed solution has failed the test.

Next quarter, suppose the same two leaders need the same senior engineer for work that can’t be shared or resequenced before their deadlines. Check those constraints with them before making the allocation. If they hold, the decision-maker must hear both leaders and explain the criteria for the call. The leader who loses needs to know what work will go undone and how to challenge the decision. A date to revisit it next cycle doesn’t replace a chance to object now.

The diagnostic

Three questions for last week’s contested settlement.

• Which pole was I claiming? Did I describe the outcome as something new that both sides won, or as a fair split, or as a firm call I made?
• Which pole did the outcome actually show? Did both parties get what they came for, or did someone give something up? Who bore the loss, and could they have safely objected? An agreement staying unchallenged tells you little if challenging it would cost someone their job.
• Which conflict is this really? Test the premise that makes the positions incompatible. If the constraint holds, make and explain the allocation. If you have run out of time to investigate, record a provisional settlement. Where conduct prevents people from participating, protect the process before continuing. Recurrence tells you to look again. It doesn’t tell you that you misjudged.

The exercise this week

Take one live conflict on your team that keeps re-opening. For each party, check the ability to state a need, refuse, appeal, and leave. Ask what they risk by disagreeing. Establish a protection for any risk that could prevent a straight answer. If the manager controls both the decision and the minutes, for example, arrange for participants to record objections in their own words and have them reviewed independently.

Then write the cloud. State the shared objective, each side’s requirement, and the two prerequisites in conflict. Complete the “because” sentence under each arrow and test one assumption. Ask whether the proposed change meets both needs, who must do the work, and whether those people can object. If the test fails, settle provisionally and keep looking, or explain why the remaining constraint requires an allocation.

You may leave the meeting with a tested integration, an acknowledged allocation, or a provisional settlement. Record which it is and what happens next.

Going upstream

Start with Mary Parker Follett’s Dynamic Administration, particularly “Constructive Conflict” and her papers on power and responsibility. Eliyahu Goldratt’s It’s Not Luck gives you the Evaporating Cloud and worked examples of testing the assumptions beneath a conflict.

Patrick Lencioni’s The Advantage and The Five Dysfunctions of a Team discuss artificial harmony and fear of conflict. Amy Edmondson’s The Fearless Organization examines psychological safety. Barry Oshry’s Seeing Systems shows how organisational positions shape people’s experience and behaviour. Chris Voss’s Never Split the Difference makes the case against reflexive compromise. Nicole Forsgren, Jez Humble and Gene Kim’s Accelerate reports the research on software delivery performance.

For further reading, Jeffrey Pfeffer’s Power examines organisational power. Karl Popper’s The Open Society and Its Enemies contains the paradox of tolerance; his discussion of defending a tolerant society needs care when applied to workplace decisions.

I work with CTOs and CPOs at software companies with roughly 50–500 engineers on exactly this kind of paradigm work. If it’s live for you, I’m happy to talk: schedule a 30-minute virtual coffee at hi.chrisgagne.com. If it’s live for someone you know, pass this chapter on.

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

Some conflicts persist because an assumption of your own makes the stated options seem exhaustive. In chapter 21, you learn to recognise those assumptions and question them.

You’re the last word on the technical call. You’re also the bottleneck on every material technology decision.

Chapter 18 found that a leader’s assumptions about workers show in the org design, not the stated values. The expert stance reverses those Theory Y intentions at the moment of the call.

The two poles

Pole A: expert. The leader is the most senior technical authority. Problems escalate up to where the expertise is.

Pole B: facilitator. The leader’s role is to make others’ decisions possible. Expertise lives at the work.

Where Pole A is right

When the leader is genuinely the deepest expert and the call is technical. The founding CTO making the last call on a foundational architecture decision. The chief surgeon overruling on the table. The lead investigator on a specific case where the situation depends on their direct expertise. Pole A is right in those contexts, and while a team is still building the competence the call needs, as chapter 17 found.

Where Pole B is right

Almost every senior leadership context outside narrow technical-founder situations. By the time leaders reach senior roles, their expertise is usually a layer or two removed from where the work is being done. When it is that far removed, deciding anyway works from less of the live context than the team has, and can teach the team to stop deciding.

In decisions

Pole A leaders decide contested technical calls. Pole B leaders convene the people who know and back the call they make.

Take the last contested technical decision that routed to you and ask where the fix sits: how should decisions like this route, and what would have to be true for them to stop routing to me? Most of it is inside your own function, and there it isn’t an ask at all: I intend to push architecture calls to the team closest to the system, because that is where the expertise lives; unless you see something I don’t, it starts with the next decision.

What belongs to the CEO is the part only the CEO can move: holding the function heads accountable for building the capability rather than escalating it, and authorising the change when the routing crosses your boundary. Take that part to them in the same open form: what would have to be true for the function heads to build this capability instead of escalating it? The authorisation is often a small word change to what Marquet calls the genetic code: the words the organisation runs on.

The sentence your CEO can carry to the board: “Every decision that escalates to us loses some of the context it needed on the way up.”

Schön’s reflective practitioner

I take Donald Schön’s The Reflective Practitioner as the canonical critique of technical rationality: the assumption that expertise consists of applying codified knowledge to standardisable problems. Schön found, across many professional practices, that real expert work is situational. The cases that count are the ones that don’t fit the textbook. The expert’s actual capability is reflection-in-action: thinking inside the practice and adjusting in real time to build a unique response to a unique situation.

Schön’s critique cuts hardest at the expert-as-authority model. If real expertise is situational, the senior person who decides from a distance is working with less of the situation’s live context than the practitioner who is in it. The senior person’s broader experience matters for some questions and is irrelevant for others. Pole B leaders learn to tell those questions apart.

If real expertise is situational, the senior person who decides from a distance is working with less of the situation’s live context than the practitioner who is in it.

Schön goes further with what he calls the reflective contract: a relationship in which the practitioner can admit uncertainty. The client gets a partner in inquiry rather than a vending machine for answers. The leader promoted into senior expertise can step into that contract with their team. Most of the leaders I’ve worked with don’t. The expert posture is what got them promoted, and the switch is uncomfortable in exactly the ways promotions aren’t.

Block on the consultant-leader collusion

Preferring what Peter Block calls the content level over the affective level keeps Pole A in place. The content level is the technical question, the framework, the deliverable. The affective level is the relational dynamics, the power and trust in the room, and the question of who the leader takes themselves to be. For years I worked the content level too, as chapter 1 says; what I would add here is that the preference is mutual, and that is what makes it stick. Block’s word for what it produces is collusion, and calling the content-over-affect preference itself collusion is my generalisation of his pattern. The consultant gets to look smart; the leader gets to look in charge; the conditions that produced the problem stay untouched.

The leader has to make the same Pole B shift in the consultant relationship. Here, the leader sits in the consultant’s chair vis-à-vis the team. Pole A says the leader is the deepest expert present. Pole B says the leader’s role is to make the team’s existing expertise legible to itself.

In your last contested team decision, who was at the centre: you, with the answer, or the team, with the problem they own? Putting yourself there closes the immediate decision faster and takes the call out of the team’s hands, which makes the next contested call more likely to route to you.

The Scheins’ four kinds of inquiry

The Scheins’ Humble Inquiry grounded the expert-vs-facilitator argument for me for years. The same recordings chapter 5 drew on show a second pattern in the early sessions: I would explain the framework, parts theory, polyvagal, whatever fitted, while the client was still in the middle of a felt sense. What was missing was the humble question that would have kept them in it. Humble inquiry is the canonical question Pole B asks: the genuine question to which the asker doesn’t know the answer. It’s the right starting place, and the rest of their framework does other work.

Humble inquiry, one of the Scheins’ four types, is the question the asker has no answer to. Diagnostic inquiry steers the conversation toward what the asker thinks is relevant: causes, feelings, actions taken. Confrontive inquiry goes further and inserts the asker’s own idea in the form of a question. Process-oriented inquiry is the question about how the conversation itself is going.

The four aren’t a hierarchy. The Pole B leader carries all four and picks among them as the situation calls. Their own counsel is to blend the helping forms with humble inquiry according to the needs of the situation and to stay conscious of the switch; their warning is that the helping forms take charge of the conversation and slide toward telling.

Ask: which kind of inquiry am I in right now, and which would best serve the situation?

Weinberg’s secrets

Jerry Weinberg’s 10% rule from chapter 1 applies here too: never promise more than 10% improvement. My read is that the rule holds because anything more requires moving from content to affective level, which the leader will resist. Weinberg’s real prize is the credibility of the naive question. His Golden Lock names the trap⁠—I’d like to learn something new, but what I already know pays too well—and the seniority version is my extension: the senior person who has stopped being able to ask basic questions because appearing not to know would threaten their standing. The Pole B leader recovers the capacity to ask the question the team needs asked, even when the asking exposes that they don’t know the answer. NUMMI’s 1984 team member handbook told the people on the line the same thing, in an aphorism chapter 23 comes back to: learn to say “I don’t understand.” It is a harder sentence for the person who is supposed to know.

The question costs status. Ask it anyway.

O’Neill⁠—backbone and heart

Mary Beth O’Neill distinguishes two operating models for the helper more sharply than Block does: the rescue model, which puts the helper at the centre (the helper has the answer, the client has the problem, the helper fixes it), and the client-responsibility model, which puts the client at the centre (the client owns the problem, the helper supports their own work on it). Block’s collusion is the rescue model, and expertise is what excuses it. The expert-leader running the rescue model uses role-authority to take responsibility for the call. The team learns not to bring discretion; the rescue reproduces its own need.

Her title names the stance the Pole B shift asks for: backbone and heart, knowing your position and stating it clearly while staying engaged in the relationship, so the team feels met rather than processed. The harder part is holding it even when the team is waiting for the leader to decide.

Joiner’s Catalyst stage⁠—and the levels around it

In Bill Joiner and Stephen Josephs’ terms, the Pole B shift is the transition from Achiever to Catalyst. Chapter 12 met their ladder from the other end. Joiner and Josephs put about one manager in ten past Achiever, so the exercise below practises a Catalyst behaviour; it doesn’t claim thirty days moves a plateau.

The Achiever makes the decisions; the Catalyst develops the people who will make them. That change is uncomfortable because Achiever skills are rewarded and visible, while Catalyst skills stay invisible until the team starts producing decisions the leader couldn’t have made themselves.

The Achiever makes the decisions; the Catalyst develops the people who will make them.

The ladder matters whole, not collapsed to Catalyst. Each level keeps the ones before it, so a leader can still step back into Expert when they are the deepest expert on the specific question: the founding CTO on a deep technical call, the chief surgeon on the table. The error is generalising that posture to situations that need Catalyst or Co-Creator. The Synergist moves fluidly between leadership styles as the situation fits, without turning any of them into an identity.

A representative case

This is a composite of leaders I have sat across from. A senior architect gets promoted to VP of Engineering, deserved on contribution, and it is a problem in waiting. Six months in, the VP is making most of the architecture decisions for the engineering organisation, and most of their engineering managers have stopped bringing recommendations. They were promoted because they were Experts or Achievers, and nobody explained the need for them to become Catalysts.

The Pole B shift is slow. The first move is Marquet’s I intend to: the VP makes every engineering manager state intent rather than ask permission. Then the VP has to stop having an opinion on every technical call and ask the team for its recommendation without offering their own. Hardest of all, the VP has to publicly back the team’s call when it differs from what they would have done, not in the private moments where it is politically safe but in the all-hands meetings where their own credibility is on the line.

What changes if it lands is not the quality of any single call. Some will be better than the VP would have made and some worse. What changes is that the calls get made without the VP in the room, and the company can operate without them, which it could not before. The VP also gets their evenings back. Marquet names the cost of the other way in his own telling of the I intend to shift: if you are always the answer man, you can never go home and eat dinner.

The VP doesn’t stop being technically deep; they stop putting the technical depth into the seat the team is supposed to occupy.

From facilitator to practitioner

The expert is the helper who knows the answer: Pole A, the technical-rationality position. The facilitator is the helper who makes the team’s answer possible: Pole B, the Catalyst-stage position. The practitioner figure that chapter 22 will name is the deepest version of the Pole B shift: the helper who can stay steady with a leader while their old sense of the job comes apart, without pushing it to a tidy resolution, when the situation calls for more than facilitation.

The facilitator and the practitioner are both asked to step out of the content the team is responsible for. Bring the developed self O’Neill calls signature presence, the helper’s own self as the instrument that makes the team’s work possible. Hold the conditions and leave the decisions with the team.

The diagnostic

Three questions for last Tuesday’s contested call.

• Which pole was I claiming? Did I describe my role as expert or as facilitator?
• Which pole would my actual behaviour show? Did I make the call myself or convene the people who knew?
• Which pole does the situation actually require? Unless I am genuinely the deepest expert on the specific question, or the team hasn’t yet built the competence the call needs, Pole B.

The exercise this week

Run the convening exercise once this week. Pick a decision you would normally make as the technical authority. Set out the problem to the team in 20 minutes. Ask the team to recommend. Listen, without correcting, for the full conversation. Back the recommendation publicly, even if it isn’t what you would have done.

In my experience, the team reads your willingness to back its recommendation more than the recommendation itself. The exercise is one decision. For the next 30 days, track how many contested technical calls the team resolves without you and how many still route back.

If the recommendation is genuinely wrong on the merits⁠—rare in my experience, but it happens⁠—start by asking the team what evidence would change their recommendation, and share the evidence you have that they don’t. If the evidence persuades them, the team makes the better call. If it doesn’t, you have a real disagreement. In a Pole B decision, the conversation continues and the call remains with the team. In the narrow Pole A case, the leader makes the call and owns why.

Going upstream

Watch. Edgar Schein, Humble Inquiry lecture, a short talk for leaders on his own channel.

In-text: the two main works named in the body. Donald Schön, The Reflective Practitioner, on technical rationality and the reflective contract. Edgar Schein and Peter Schein, Humble Inquiry (2nd ed.), on the four kinds of inquiry, not just the humble one.

Also touched: the helper models named in the body, with full references here. Peter Block, Flawless Consulting, on contracting at the affective level and the forms of consultant-client collusion: pretending the organisation is rational rather than political, skipping the touchy contracting subjects, rushing to solutions before the problem is owned. Jerry Weinberg, Secrets of Consulting, for the named laws and the 10% rule, and More Secrets of Consulting for the Golden Lock. Mary Beth O’Neill, Executive Coaching with Backbone and Heart, on signature presence (the coach’s own developed self as the instrument), the rescue versus client-responsibility model (a contrast she credits to her colleague Rob Schachter), and the four-phase coaching methodology of Contracting, Planning, Live-Action, and Debriefing. Bill Joiner and Stephen Josephs, Leadership Agility, on the five-stage developmental model⁠—Expert, Achiever, Catalyst, Co-Creator, Synergist⁠—worked at full strength, with the percentages, in chapter 12. The NUMMI line is from the plant’s own 1984 team member handbook, page 53, scanned from the Walter P. Reuther Library archive. Marquet’s answer-man line is from his 2013 Inno-Versity talk, Greatness, and not from either of his books.

Go deeper: Jerry Weinberg, More Secrets of Consulting: The Consultant’s Tool Kit, for the catalogue of named devices in his Consultant’s Self-Esteem Tool Kit, six of them inherited from his teacher Virginia Satir, the rest his own and his colleagues’. My own earlier pass at this argument is the 2018 Scrum training Agile Fundamentals: Going from Expert Individual Contributor to Humble Leader, which runs the same shift through Cynefin and Toyota’s NUMMI handbook.

I work with CTOs and CPOs at software companies with roughly 50–500 engineers on exactly this kind of paradigm work. If it’s live for you, I’m happy to talk: schedule a 30-minute virtual coffee at hi.chrisgagne.com. If it’s live for someone you know, pass this chapter on.

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

Work on yourself all you like. The structure nobody redesigned folds that growth back into the slot you left. When a compromise you split last quarter comes back to your desk, chapter 20 has you examine the gap between two people who want different things. You ask what brought it back and whether everyone at the table could safely say what they needed. You use a diagnostic to tell whether you’re holding an integration, an allocation to make in the open, or a settlement to keep provisional while you look further.

Your stated values are Theory Y. The approval thresholds, access controls, and review gates inside your function are Theory X. Your team reads the org design, not the values.

Chapter 17 found that authority scales when it lives where the information lives and the leader states clear intent. Leader-leader can’t run on Theory X assumptions about workers. Unless those assumptions change, the structure pulls the protocol back to leader-follower at the next reorg.

The two poles

Pole A: Theory X. Design control structures around the worst-case employee. Oversight as the default. Trust is a reward earned through visible compliance.

Pole B: Theory Y. Design control structures around the average employee. Trust the system to handle the exceptions. Remove the obstacles, and let people do good work.

Douglas McGregor drew the distinction in The Human Side of Enterprise in 1960. More than 60 years on, most organisations I have seen still operate on Theory X assumptions even when leadership quotes Theory Y.

The web of our own weaving

McGregor didn’t stop at calling Theory X wrong about people. His claim was that managerial strategy produces the workers it predicts. He called it a web of our own weaving. The leader who treats workers as untrustworthy designs controls that punish discretion. The workers learn that discretion is punished, so they stop bringing it. The leader observes the absence of discretion, concludes the original assumption was correct, and tightens the controls. The system has made its own evidence.

This turns the question from a values question⁠—do you trust your people?—into a feedback-loop question: what is your org design⁠—strategy, processes, and rewards as much as reporting lines⁠—producing in the people who run inside it? As a values question, Theory X / Theory Y is the kind of debate the leader has every five years at an off-site and forgets by the following Monday. As a feedback-loop diagnosis, it is something the leader can read and action immediately.

Run McGregor’s loop backwards. List the behaviours your control structure is currently producing in your engineers. Then ask whether those behaviours were latent in the people or installed by the structure. In my experience the answer is some of both, and the structural share rises the longer they’ve been inside the organisation.

Where Pole A is right

McGregor allowed that authority is “an appropriate means for control under certain circumstances,” and two contexts still call for it.

First: genuinely high-stakes regulated work where the cost of a single bad actor is catastrophic. This includes nuclear plant control rooms, aviation cockpit checklists, surgical theatre protocols, anti-money-laundering compliance, and pharmaceutical batch release. The tight control here is the right engineering response to predictable work with tightly bounded failure modes, and it rests on a different assumption from Theory X: it guards against the fallibility of trusted experts, not the reluctance of workers presumed to dislike work.

Second: routine low-skill, low-discretion work where the task itself doesn’t generate intrinsic motivation and the structure carries the load. High-turnover transactional roles and certain warehouse or contact-centre tasks fit this description, particularly where the work is the work and capability development sits outside it. Where the job’s design leaves little to motivate, the structure has to compensate, though NUMMI, later in this chapter, shows how much of that is the design rather than the task.

The error is generalising from these contexts to most knowledge work. Most knowledge work, including cross-functional work, is neither. Roles that depend on intrinsic motivation usually need Pole B, yet many inherit Pole A structures through habit rather than engineering judgement.

Where Pole B is right

Theory Y fits wherever the work depends on judgement the worker has and the control structure can’t supply. That is McGregor’s claim about knowledge work, and software-dependent organisations are where it bites hardest; run the Vodde exercise below with your teams and see for yourself.

A Theory X org design taxes the capacity the work runs on whenever the task is non-routine, the person closest to it knows more than the layer above, and the outcome depends on initiative. The engineer who must seek approval for time to refactor and the team whose every experiment routes through a change-approval board face the same constraint. The structure punishes the initiative the work needs.

Remove the obstacle and the average person does good work, because the work itself supplies the motivation the controls were trying to manufacture.

The AI shift shows how much work already depended on human judgement. As AI absorbs the routine and the rule-bound, what stays human is the judgement-heavy, initiative-bearing work where Theory Y is an economic necessity, not an emotional preference. My read is that the judgement-heavy work was always the larger share, and the Theory-X-shaped routine sitting on top of it hid how much. Strip the routine away and most of what remains needs Pole B. The leader still running Theory X org designs across that work is paying a compounding tax on the one capability the AI era requires most: judgement.

Honour the past⁠—why Theory Y didn’t diffuse cleanly

Theory Y has had 60-odd years to spread, but it hasn’t. A leader who waves it around as the obvious correct answer still has to reckon with the question McGregor’s successors faced: Why didn’t it diffuse?

Theory Y adoption has been real but partial, often reversed by leadership succession, and dependent on conditions most companies didn’t sustain. A leader installs a Theory Y organisation design, the design produces results, the leader leaves or gets promoted, and the new leader treats the design as overhead and reverts to Theory X defaults. The workers who had developed inside the Theory Y structure now look like overpaid prima donnas to a Theory X eye.

A successor can restore the old controls faster than workers learned to use the discretion the first leader gave them. Kochan, Orlikowski, and Cutcher-Gershenfeld saw the pattern in the field: at one Pratt & Whitney plant, successes were periodically set back when plant managers or union leaders turned over, and by their 2003 estimate about a third of US workplaces had adopted some features of the newer work systems, while very few had transformed.

The leader who currently runs Theory X org designs isn’t necessarily running them out of bad faith or ignorance of McGregor. They are running them because Theory X is what the system selected for, what their training reinforced, and what their predecessors left behind. The leader’s previous paradigm got them here. The past wasn’t wrong; the past fit its conditions.

McGregor also named a failure mode for the leader who thinks they’ve adopted Theory Y but hasn’t: old wine in new bottles, relabelling Theory X with Theory Y vocabulary. He wrote of decentralisation, management by objectives, consultative supervision, and democratic leadership in his own era. The contemporary equivalent is psychological safety as a poster sitting on top of an unchanged escalation pattern, or empowerment as a slogan sitting on top of an unchanged approval workflow. Each is a Theory Y label sitting on top of an unchanged Theory X structure.

Bas Vodde’s exercise⁠—McGregor’s diagnostic, repackaged

Bas Vodde, Craig Larman’s collaborator on Large-Scale Scrum (LeSS), teaches an exercise that catches the gap in flight. Draw a horizontal axis. Theory X to the left, Theory Y to the right. Sticky-notes above the line for observed attitudes and behaviours of fellow colleagues. Sticky-notes below the line for the organisation design the team is operating inside. The gap between the two rows is the diagnostic.

In the Vodde class I sat in on, and in my own work since, the pattern is consistent. Above the line: Theory Y. Below the line: Theory X. The leader’s values are above the line. The structure they run is below the line. Both are sincere. The team reads the structure.

The exercise works because it externalises what the leader already knows. The gap was visible to the team before the exercise; the exercise makes it visible to the leader. After that, the old account is harder to sustain.

The gap the exercise shows isn’t new. McGregor named the same gap in the original book: managers give “a good deal of lip service” to the worth of the average person while policy and practice say otherwise; the leader who quotes Theory Y while running Theory X is doing what McGregor was already cataloguing in 1960. Vodde’s contribution is the experiential packaging: the sticky-notes, the horizontal axis, the visible gap. McGregor named the diagnostic; Vodde made it teachable in 20 minutes with a pad of sticky notes.

The operating conditions Theory Y assumes

Theory Y assumes the work can supply its own motivation, and Daniel Pink’s Drive later named what that takes: that the worker chooses how to do it, that the work develops skill the worker values, and that it connects to something larger than the worker. Where those conditions hold, intrinsic motivation does most of the work the Theory X structure was trying to do. Where they don’t, no Theory X structure can fully substitute. The structure can extract compliant behaviour; it can’t extract the discretionary effort the work actually needs.

Theory Y structures don’t cause good performance, they permit it. Given the competence, resources and goals worth sharing, the good performance comes from the intrinsic motivation. Theory X structures suppress it; Theory Y structures stop suppressing it. From a control frame, Theory Y looks like abdication. From an autonomy frame, it looks like freedom. The Pole B leader sees it as removing the brakes.

Theory Y structures don’t cause good performance, they permit it.

The compliant, externally-motivated worker Theory X assumes and the intrinsically-motivated, autonomy-driven worker Theory Y assumes can be the same person under different structures. The surrounding structure draws out the behaviour. Chapter 6’s NUMMI is the starkest comparison we have: when the plant reopened under Toyota’s system, over 85% of the workforce were old hands from GM Fremont, and within three months the cars coming off the line were getting near perfect quality ratings. Bruce Lee, who ran the union local and fought to have them rehired, put the reading plainly: “I believed that it was the system that made it bad, not the people.” This is McGregor’s web of our own weaving, still being woven in approval thresholds and sign-off chains.

The coupling with leader-leader

Theory Y makes Marquet’s leader-leader possible. Chapter 17’s leader-leader protocol depends on subordinates having the orientation and motivation to act on intent rather than instruction. After years of Theory X, people have learned not to bring discretion to work. Install leader-leader at that point and they keep escalating decisions the new structure expects them to make. The confusion is learned.

The two axes are coupled. Pole A on this axis forces Pole A on leader-follower. You can’t run leader-leader on Theory X assumptions; the assumptions defeat the protocol. A Pole B shift on either axis is incomplete without the Pole B shift on the other.

The leader-leader chapter’s submarine case turned on exactly this: the structural change could work because the captain trusted the crew to have the orientation Theory Y predicts, and the crew rose to it. The change ran on one set of assumptions about people, held consistently enough that the structure could move.

Where Theory Y gets misread

Of the companies I have been inside, most had softened the structures with culture work and kept the underlying assumptions. I have not been inside one that rebuilt the structure around Theory Y assumptions from the ground up.

Theory Y is not a developmental destination, though it gets read as one. McGregor’s claim was that the assumptions a leader holds about workers produce the workers they predict, and that for most knowledge work those Theory Y assumptions produce a better outcome than Theory X ones.

McGregor’s account of authority was situational. Pole A fits some situations; Pole B fits more situations than most leaders think. The developmental reading is a later overlay.

A representative case

Picture a mid-sized engineering organisation with a documented value of trust your people. The values slide is shown in every monthly all hands. The actual budget approval process requires four signatures for any spend above $500. Travel requires CEO approval. Time-off requests go through three managers. Code-review policy requires two reviewers for every change, regardless of risk profile.

A new VP of Engineering runs Vodde’s exercise in their first week. The above-the-line stickies describe colleagues worthy of trust. The below-the-line stickies describe a system of suspicion. The gap is obvious to everyone on the team and has been invisible to everyone in leadership for years.

The Pole B move takes six months. Budget authority pushes down to team leads for spend below $5K. Travel approval delegates to engineering managers. Time-off requests require only the engineer’s own calendar coordination. Code review reduces to one reviewer for low-risk changes.

In McGregor’s vocabulary, the web is now working in the other direction. The Theory X structure had been producing Theory X behaviour. The structural change permits Theory Y behaviour. The engineers haven’t changed; the structure has stopped suppressing the discretion they already had.

The AI overlay

AI tooling extends both poles. Pole A leaders use AI for monitoring and compliance: automated detection of policy violations, AI-driven approval workflows, predictive surveillance of engineer behaviour. The Pole A AI stack codifies Theory X assumptions into infrastructure. Pole B leaders use AI to extend autonomy: agents that handle the routine approvals so the human chain doesn’t bottleneck, AI assistants that make the intent-contract legible across larger teams. The Pole B AI stack codifies Theory Y assumptions into infrastructure.

Both poles can use the same tools. Their configuration tells the truth about the leader’s assumptions, so a leader genuinely unsure which pole they’re on can read it off the AI stack they have built.

At one client, I built a bot that checked the tracker’s stories against dozens of data-quality rules and commented on any story that broke one, because the CTO needed the tracker to be true. It was deterministic and rule-based, and its job was to normalise the data so the reports meant something, though on paper a bot that comments on everyone’s work looks a lot like the control tooling Pole A leaders build. Each comment went to the story’s owner, and I limited repeat comments as a deliberate choice about trust. The teams took the bot as a helpful tool, and open issues fell. The CTO had teams run their stand-ups against it.

Ask the model which way to configure and it leans toward the paradigm you bring it. A leader who believes people need watching will get a confident, well-sourced design for monitoring, approval gates, and surveillance, because the management corpus the model learned from is thick with exactly that. A monitoring-framed prompt tends to return monitoring designs; an autonomy-framed prompt returns autonomy designs. The tool deepens the groove.

AI tooling makes paradigm-misfit cheap to deploy; chapter 3’s redesign question applies here too. The tooling is the same either way: same models, same licences. What differs is what the deployment produces in the people running inside it, and the web McGregor named now gets industrialised at AI scale, in either direction, faster than the organisation can decide which web it actually wants to weave.

The diagnostic

Three questions for last Tuesday’s structural decision.

• Which pole was I claiming? Did I say I trust the team or that I needed to maintain controls?
• Which pole would the actual structure show? If I ran Vodde’s sticky-note exercise tomorrow, what would the gap reveal?
• Which pole does the work actually require? Most knowledge work is Pole B. The Pole A defaults are leftovers from a paradigm that fit other conditions.

CTOs and VPEs: run Vodde’s sticky-note exercise one layer up, with your CEO as co-author rather than subject⁠—each of you holding the pen on your own rows⁠—before you assume the gap is yours to close. Above the line, the stated values from the culture page, the values slide, and the all-hands language. Below it, three things the CEO directly controls: budget approval thresholds, headcount sign-off, and strategic hire veto. McGregor’s web works in both directions: if the CEO runs Theory X assumptions above the CTO layer through approval workflows, access controls, and budget signatures, the org design will pull back any Theory Y installation below. The gap is what your engineers read.

Ask for one small, specific structural change that brings one below-the-line item into line with the stated value. The CEO doesn’t have to redesign the organisation. They have to move one threshold. The sentence your CEO can carry to the board: “Our company runs on the org design, not the values slide.”

The exercise this week

The reflection is solo. The exercise is for the team.

Run Bas Vodde’s sticky-note exercise with your direct reports this week. 20 minutes. Draw a horizontal line on the wall. Theory X to the left, Theory Y to the right. Each person writes three sticky-notes above the line (three behaviours or attitudes they observe in the team) and three sticky-notes below the line (three structures or processes the team is operating inside). Place the stickies on the axis. Stand back and look.

Where is the gap widest? Which structure is most clearly Theory X? Which Theory X structure is doing real work (high-stakes risk surface, low-discretion routine work), and which is just inherited habit? What’s the smallest structural change that would let the team’s actual Theory Y behaviour stop being suppressed?

Above the line: Theory Y. Below the line: Theory X. Structures that match the value are worth strengthening.

Going upstream

In-text: Douglas McGregor, The Human Side of Enterprise: the canonical primary. A web of our own weaving, old wine in new bottles, and the lip-service passage all live here.

Also touched: Bas Vodde, Craig Larman’s LeSS collaborator, for the above-the-line / below-the-line sticky-note exercise. The NUMMI figures and Bruce Lee’s line come from This American Life’s “NUMMI” episode (2015).

Go deeper: Daniel Pink, Drive, on the operating conditions Theory Y assumes⁠—autonomy, mastery, purpose⁠—and the Type X / Type I distinction; the short version is RSA ANIMATE: Drive (11 min). L. David Marquet, Turn the Ship Around!, covers the Theory Y assumptions behind the leader-leader protocol developed at length in chapter 17. For the empirical-diffusion question⁠—why Theory Y reverts at leadership succession⁠—see Kochan, Orlikowski, and Cutcher-Gershenfeld, Beyond McGregor’s Theory Y (MIT Sloan, 2003).

I work with CTOs and CPOs at software companies with roughly 50–500 engineers on exactly this kind of paradigm work. If it’s live for you, I’m happy to talk: schedule a 30-minute virtual coffee at hi.chrisgagne.com. If it’s live for someone you know, pass this chapter on.

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 are the last word on every technical call. You are also the bottleneck on every decision that touches one. Your Theory Y intentions reverse well before the next reorg. They reverse here, at the point of decision, when the expert posture in you takes the call the team could have taken. The self-image survives intact. The choke stays. In chapter 19, expert vs facilitator, you hand one of those calls to the team and back what it recommends.

You spent Tuesday in approval meetings. You spent Wednesday wondering why your team can’t make a decision without you, and why the function still can’t ship faster. The structure is leader-follower, all the way down.

Chapter 16 named the discipline of small batches and pull. Most software organisations route every non-trivial decision through the senior person’s calendar, including decisions about what gets pulled.

Between the visible Tuesday calendar and the felt Wednesday frustration sits a paradigm so habitual that the people inside it usually can’t see it as a paradigm: authority lives with the senior person at each layer, subordinates seek permission, orders are detailed, and the senior person’s bandwidth is the rate limit of the whole layer below.

Marquet calls it leader-follower.

This industrial-management inheritance remains the default. I suspect most software-dependent organisations run it across at least one major function without anyone at the executive level recognising it as a paradigm rather than the way things are.

David Marquet, who took command of the USS Santa Fe in 1999, a submarine with the worst retention record in the force, gives it the operational name leader-leader. Authority lives where the information lives. Subordinates state intent. The leader replies Very well. Orders carry purpose and constraints, and the team chooses the action.

Marquet was the captain. His executive officer, the XO, ran the officers; his chief of the boat, the COB, was the senior enlisted man aboard and ran the chiefs. The crew did the work. The captain’s job was to mandate the structural shift, model the language, and refuse to make the decisions the captain shouldn’t be making.

In 1998, the year before he arrived, the boat had re-enlisted three sailors out of a crew of 135. In Marquet’s first full year it re-enlisted 36, and by 2001, the last year of his command, it had earned the highest grade on its reactor-operations inspection that anyone had seen. The book’s afterword reads like a command roster: officer after officer of that wardroom went on to command submarines of their own. Santa Fe shifted from one leader and 134 followers to 135 leaders.

At the executive level, Marquet’s captain is the CEO. The XO and COB are the senior leadership team: the CTO, the VPE, the heads of function. The crew is the rest of the organisation.

An organisation-wide, durable shift usually requires CEO participation.

The CTO who tries alone usually produces leader-leader inside one team while the surrounding structure pulls it back at the next reorg or budget cycle. Santa Fe is the exception, and Marquet made it work as captain: the head of his own organisation, inside a Navy he didn’t control, with a commodore keeping everyone else off his back.

The two poles

Pole A: leader-follower. Authority and decision rights concentrate with the senior person. Subordinates seek permission before acting. The leader spends Tuesday in approval meetings because the structure requires the approvals. Orders specify what to do. Compliance is the metric of execution. The leader’s working day fills with decisions that arrived at the desk because no one else had the authority to make them. The bandwidth of the leader is the rate limit of the team.

Pole B: leader-leader. Authority and decision rights live where the information lives, which is almost never with the senior person. Subordinates state what they intend to do. The leader communicates purpose and constraints, not action.

Marquet’s specific protocol is “I intend to…” The officer or sailor states what they’re about to do. The captain says Very well.

Marquet frames the shift as three replacements: trading pressure and conformity for clearly stated intent, swapping the urge to prove oneself for improving and learning, and giving up the show of certainty for openness and curiosity. Subordinates aren’t waiting to be told. They are thinking, intending, and acting. The leader contributes through the quality of the intent they communicate.

Marquet calls this moving authority to the information rather than moving information to authority.

Where Pole A fits

Pole A isn’t a mistake and fits a specific kind of situation.

Genuine emergencies. The fire on the bridge. The outage at 3 a.m. that has the customer’s revenue line on the floor. The litigation hold that requires a single decision-maker with counsel within the hour. These are the conditions Marquet himself names as the exception: “Emergency situations required snap decision making and clear orders.” Marquet himself reserved the authority to fire weapons because he didn’t want the conscience of taking another human being’s life on anyone’s mind but his.

The vast majority of situations don’t require immediate decisions. Some do. A leader who can’t pull rank when the building is on fire is running a different failure mode.

Competence not yet built. A new team may not have the competence Marquet names as the second pillar of leader-leader. “Control without competence is chaos.” When the technical understanding needed to make a decision well isn’t yet present in the team, the leader doesn’t get to delegate decisions that depend on that understanding. The work is to build the competence. Until then, the structure holding the work sits closer to Pole A than Pole B.

Speed over quality. Some decisions need to be made now and don’t need to be optimal. The leader’s signature unblocks the work. “A little rudder far from the rocks is a lot better than a lot of rudder close to the rocks,” Marquet writes. But rocks exist, and sometimes a lot of rudder is the right call.

Respect those situations. Pole A fits them.

Much of the calendar of most senior engineering leaders, however, is filled with approval-type meetings that reflect none of the above. Those meetings come from a structure that hasn’t been redesigned for the work the team is actually doing.

Where Pole B fits now

Three changes have broadened Pole B’s fit.

First, the information has dispersed. The senior engineering leader 15 years ago could plausibly hold the whole technical surface of a small company in their head. Today, in my experience, once an organisation passes about 30 engineers operating across cloud, data, and AI layers, nobody holds that surface any more. The information lives where the work happens. Authority that doesn’t live there is making decisions on stale, limited data.

Second, the speed of consequence has risen. The interval between we made the decision and the consequence is visible in production has compressed from quarters to weeks and, in many cases, days or even hours. The Pole A bandwidth⁠—every non-trivial decision queueing at the leader’s desk⁠—was already slow when the consequence cycle was quarterly. With a daily consequence cycle, the leader can’t gate every decision and still ship.

Third, AI agents in the loop change the scaling maths of authority. A leader running leader-follower with AI agents is asking the agents to wait for approval on actions the leader isn’t equipped to judge quickly enough. A leader running leader-leader with AI agents communicates purpose, constraints, and antigoals, then lets the agents⁠—and the humans working with them⁠—choose the actions. The right model supplies the competency, the harness context supplies the clarity.

The quality of the leader’s intent becomes the variable that scales.

An agent does twenty minutes of work, then waits a day for the approval, because the person who has to give it moved on to something else and won’t be back until tomorrow. The gate costs twice. It costs the wait, and it costs the leader the practice: the routine calls that built the judgement now go to the agent, and the leader who kept the approval kept only the accountability.

The doctrine is older

Marquet didn’t invent Pole B. He made it work inside a US nuclear submarine.

Military practice had already named the approach under the heading of mission tactics: specify the mission and desired end-state, leave the action to the people closest to it, and accept that detailed plans go useless on contact while the intent survives.

Commander’s intent—a crisp statement of the goal that never specifies so much detail that unpredictable events render it obsolete⁠—is the operational name for the language practice that makes Pole B work.

Credit, blame, and visibility all centralise under Pole A. If you are being promoted on the decisions that carry your name, the case for leader-follower writes itself. John Boyd used to put the choice to his protégés as a fork in the road: you can be somebody, taking the rank and the position and the rest of what the system hands out, or you can do something, which usually costs you the first. Pushing authority down is the second road. It gives away exactly the visibility the promotion runs on.

McChrystal: the contemporary case at scale

Stanley McChrystal gives us the contemporary case for leader-leader at scale in his account of the Joint Special Operations Task Force in Iraq from 2003 to 2008, written with Tantum Collins, David Silverman, and Chris Fussell in Team of Teams.

The Task Force began as what McChrystal calls an awesome machine, a Taylorist clockwork that synchronised intelligence, operations, and analysis with assembly-line precision. It was superbly tuned for the world it had been built for. Al Qaeda in Iraq was defeating it through a network whose decentralised decisions ran at a tempo the Task Force couldn’t match.

McChrystal’s two-part response carries the same teaching at the scale of a 7,000-person organisation in active combat.

Shared consciousness: information transparency across teams, with the daily Operations and Intelligence brief eventually drawing some 7,000 people, many from partner organisations outside the Task Force.

Empowered execution: decision authority pushed to the level closest to the action, under a rule of thumb McChrystal describes this way: if something supports our effort⁠—as long as it is not immoral or illegal⁠—you could do it.

This wasn’t the absence of leadership.

The scaling problem he names⁠—too many decisions, too fast, with information distributed in ways the leader can’t hold⁠—is the one AI is now laying bare inside software organisations. Authority that lives with the leader scales linearly with the leader’s bandwidth. Authority that lives where the information lives scales with the quality of the intent the leader can communicate.

Authority that lives with the leader scales with the leader’s bandwidth. Authority that lives where the information lives scales with the quality of the intent the leader can communicate.

McChrystal had five years of command inside active combat to make the move. The CEO usually has a less unforgiving deadline, but the structural argument is the same. The shift is the CEO’s to make, not the CTO’s.

The cockpit-gradient story chapter 1 named via Korean Air 801 is the same move in another institution: lower the authority gradient so the first officer can call a missed approach without the captain’s permission.

The cautionary case: Snook on the fallacy of social redundancy

Delegation without the intent contract isn’t leader-leader. It is delegation theatre.

Chapter 8’s fallacy of social redundancy, from Scott Snook, is the assumption that adding more people to a decision automatically adds reliability. It doesn’t. If the structure doesn’t specify how the people share information, decide, and commit, adding them adds confusion, not safety.

The leader who reads Turn the Ship Around! and concludes that they should stop giving orders is reading half the book. Marquet’s second pillar⁠—competence⁠—is the part that gets skipped. As Marquet argues, control handed to people who lack the competence to use it well produces chaos, not leadership.

The shift to leader-leader depends on technical and operational understanding being present in the people closest to the work. Where years of leader-follower structure have taught people not to think, the change must develop competence while the structure shifts. This isn’t a single decision made on a Tuesday morning. It is a programme of work that takes years.

My extension of Snook: a leader who delegates without the intent contract, competence-building, language discipline, and the psychological safety to exercise nominal authority can produce a worse outcome than one who keeps the authority. Pole B requires more discipline than Pole A.

Marquet’s 21 specific mechanisms

Marquet’s first book names 21 specific mechanisms that made leader-leader work on Santa Fe: eight control mechanisms (divest and distribute control), five competence mechanisms (build the technical understanding authority depends on), seven clarity mechanisms (make sure people know what we are trying to do), and a closing 21st that stands outside the pillars.

Two show how small changes rewrote authority.

Find the genetic code for control and rewrite it. Marquet’s chiefs admitted they didn’t run the ship; he asked whether they wanted to. What they came back with was a signature. A leave chit is the form a sailor fills in to ask for time off, and Navy regulations said the XO signed every one. So a junior sailor’s request for Christmas leave collected seven signatures on the way up, four along his own enlisted chain and three more from the officers above it, then travelled back down again. Fourteen steps, on a form printed with five signature lines. Marquet found one of those requests sitting in an inbox while the sailor waited to learn whether he could book a flight home. The chiefs’ proposal was to strike XO from the regulation and write in COB, which moved the last signature out of the officer chain and into their own. One word. Marquet calls that word the genetic code.

It didn’t stay one word. The chiefs could only own leave planning if they owned the watch bill, the roster that says who stands which watch and when. They could only own the watch bill if they owned qualification, the process that decides who is certified to stand each station at all. Managing leave, Marquet writes, was only the tip of the iceberg. The ship called the whole thing Chiefs in Charge.

Use “I intend to…” to turn passive followers into active leaders. Marquet’s own account is that they eventually inverted the whole arrangement: instead of one captain issuing orders to 134 men, the boat became 135 independent, committed, engaged people all thinking about what needed doing and how to do it well.

In Leadership Is Language, Marquet adds the andon cord: a preplanned pause signal, named in advance, that any team member can pull when something is off. It comes from Toyota’s assembly line, where pulling the cord lights the lantern that calls for help, the worker shifts from production to problem-solving, and the managerial discipline is to say thank you to the person who pulled it. Chapter 23 tells what happened when GM installed the cords without the conditions. Software organisations can use the same deliberate pause.

Treat the 21 mechanisms as a curriculum: 21 operationally specified drills, each tied to a named situation Marquet walked through on Santa Fe over a single tour.

The 21st mechanism is Don’t Empower, Emancipate. It is the one this book most needs and the summaries most often drop. Marquet’s verdict on the empowerment industry is that attempts to empower him felt like manipulation, because the power was still being dispensed from above; emancipation recognises that the authority over your own work was never the captain’s to grant.

If you are the CTO reading this book’s notes to the CTO as a permission structure⁠—waiting to be authorised into leader-leader⁠—you are running the contradiction Marquet’s first chapter names. The mirror is something you offer the CEO. The authority over your own span you take.

The enabling condition: psychological safety

Marquet’s sixth play in Leadership Is Language is connect. Without it, the other five collapse back into their Industrial-Age forms.

Connect requires what Amy Edmondson has documented for nearly three decades as psychological safety: the shared belief that the team is safe for interpersonal risk-taking.

Without it, the I intend to statement doesn’t get made because the person who would make it is calculating the political cost of being wrong. Without it, the subordinate who sees something the captain has missed doesn’t say it because the cost of being seen to question is too high.

The El Faro case study at the heart of Leadership Is Language is, in part, an Edmondson case: the third mate’s hesitant, self-diminishing, deferential, and nervous language pattern made it easy for the captain to reject the unwanted information, and the ship sank inside the next 12 hours.

Without psychological safety, the leader running leader-leader is running leader-leader on paper and leader-follower in practice. The team’s behaviour is the data, not the leader’s stated principles.

Edmondson’s toolkit for building the condition is specific enough to schedule, and it has three practices.

Frame the work: say out loud, before the work starts, what kind of work this is⁠—how much uncertainty it carries, how interdependent it is, what failure rate is expected⁠—because a team told the work is novel treats error as data, and a team told nothing treats error as exposure.

Invite participation: use situational humility (I haven’t run a migration like this before; what am I missing?), direct proactive inquiry at named people, and build structures⁠—the witness round of chapter 5, the dissent slot, the pre-mortem⁠—that make voice the default rather than an act of courage.

Respond productively: thank the messenger before judging the message, treat the failure as the system’s output before anyone’s fault, and sanction clear violations openly, because safety isn’t the absence of standards.

A mirror only does its work if the CEO can hear it. These three practices build the conditions in which hard information is received rather than rejected.

Run them on your own team first. The team deserves it, and the CEO will learn the practices by watching you survive them.

In decisions

For a CTO or VPE, two surfaces matter: the CEO’s calendar and what that calendar enables or prevents one layer below, in the CTO’s calendar, the VPE’s calendar, and the senior leadership team’s behaviour.

The CEO who runs leader-follower above the CTO often produces a CTO who runs leader-follower below: the structure inherits.

Pole A leaders’ calendars fill with approval meetings. Pole B leaders’ calendars fill with conversations that begin I intend to… The conversation is shorter than the approval meeting, more frequent, and harder to schedule, because the team isn’t waiting for the leader. The leader is reachable rather than gating.

Pole A leaders write task lists. Pole B leaders write a paragraph of purpose, a list of what must not happen, and a constraint envelope. The team writes the task list.

Pole A leaders judge themselves by whether the decision was right. Pole B leaders judge themselves by the quality of the intent statement they communicated and the quality of the conversation when intent met reality.

Pole A leaders are surprised when work stalls without them. Pole B leaders are surprised when work stalls with them, and treat the surprise as a signal.

For the CTO or VPE, the structural fix is at the CEO layer.

Installing leader-leader below a CEO who runs leader-follower above is the hardest version of the change, and the cases I know that held had cover from above. Marquet’s first attempt, on Will Rogers, died exactly that death; on Santa Fe, as captain this time, he made it stick by embedding mechanisms that kept working after he left.

The CEO controls whether your mechanisms compound or stay local.

Put your own calendar from last week in front of your CEO, mark every approval meeting, and write one question under each: was this decision mine to make? Then do the same with the CEO’s calendar.

The conversation isn’t about their leadership style. It is about the structure the CEO’s calendar is producing one layer below.

McChrystal’s point holds: Shared consciousness and Empowered execution have to move together, and only the CEO can signal that Empowered execution now applies at the function-head layer. That signal is worth more than any number of leader-leader training programmes below it.

The sentence your CEO can carry to the board: “Authority should live where the information lives.”

The diagnostic

Three questions to work through this week. Solo. Not for sharing.

• Walk through your last week’s calendar. For each meeting where you exercised approval authority, ask: was the approval gating the work? Or was the work waiting for permission because the structure said permission was required? Count the second category. That number is the slack the structure has been hiding.
• Recall the last three decisions you made under time pressure. For each, ask: did the people closest to the work have the information needed to make this decision well? If yes, ask: why was the decision yours? If no, ask: what would it take to put the information where the decision belongs?
• Listen for the language your team uses when they bring you something. The phrases that map to Pole A are Request permission to…, I would like to…, What should I do about…, Do you think we should… The phrases that map to Pole B are I intend to…, I plan on…, I will… The ratio is the data. If you don’t hear any I intend to… in a week, the structure is likely running leader-follower regardless of what your stated principles say.

In the language of chapter 5, these exercises compare espoused principles with observed behaviour.

A team-based exercise

Run one of Marquet’s mechanisms with your direct reports this week. For the CEO, direct reports are the senior leadership team: the CTO, the VPE if you have one, the CFO, the heads of function.

The cleanest first step is the I intend to protocol on a single category of decision. Pick something⁠—a senior hire, a contract above your sign-off threshold, a strategic deal, a budget reallocation, an engineering deployment that has been routing through you⁠—and write the intent template with the team.

The phrasing must come out as: I intend to [action], because [purpose], within [constraint], unless [antigoal triggered].

Marquet’s own protocol is the first two slots plus an invited veto; the constraint and antigoal slots are my extension for AI-era delegation, where the agent can’t read the situation.

For the next two weeks, decisions in that category arrive as I intend to statements. Your response is Very well, or⁠—if the intent is materially off⁠—a conversation about purpose, not a re-decision of action.

If you are the CTO reading this and the CEO isn’t yet running the protocol with you, run it down: with your direct reports, on a category you have authority over. The structural argument still works one layer at a time, even when it can’t be made org-wide until the CEO joins in.

Watch the team’s intent quality. It will be uneven at first, then improve fast if the protocol holds. Watch yourself for the urge to re-decide.

What I am good at is translation, and its shadow is over-carrying: becoming the one who holds the integration for everyone. Every time I do that, the room gets one more decision it does not have to make and one less it knows how to make.

The urge is information. It is the pattern that built leader-follower in you, still active. Notice it, name it for what it is, and let it pass without re-deciding.

Going upstream

In-text: Marquet, Turn the Ship Around!: the 21 mechanisms, the Santa Fe turnaround story, the operational curriculum. Marquet, Leadership Is Language: the language-as-lever distillation, El Faro as cautionary case, the six plays. Stanley McChrystal et al., Team of Teams: the contemporary case at scale, Shared consciousness, Empowered execution. Amy Edmondson, The Fearless Organization: psychological safety as the enabling condition. Marquet’s line on keeping the authority to fire weapons is from his 2013 Inno-Versity talk, Greatness.

Also touched: Scott Snook, Friendly Fire: the fallacy of social redundancy, which this chapter extends to delegation without the intent contract.

Go deeper: MCDP-1 Warfighting: the doctrinal source for mission tactics and commander’s intent. Robert Coram, Boyd: The Fighter Pilot Who Changed the Art of War: the Auftragstaktik lineage and Boyd’s to be or to do. Chip and Dan Heath, Made to Stick: commander’s intent in prose-accessible form for non-military readers.

I work with CTOs and CPOs at software companies with roughly 50–500 engineers on exactly this kind of paradigm work. If it’s live for you, I’m happy to talk: schedule a 30-minute virtual coffee at hi.chrisgagne.com. If it’s live for someone you know, pass this chapter on.

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

Leader-leader only runs on what you actually believe about the people you delegate to. In chapter 18, you examine those beliefs through McGregor’s Theory X and Theory Y, because a protocol without the right assumptions underneath it drifts back toward the old permission-seeking the moment the org chart is redrawn.

You set WIP limits and they’re being ignored. Your batches are getting larger. Your lead times are getting longer. The PMO says everything’s fine.

Chapter 15 closed the safety cluster: a quiet dashboard can’t tell skill from luck. Back in the work itself, most planning still gets batch size wrong and pushes work onto teams beyond their sustainable capacity.

Chapter 4 asked whether the system was busy or moving. This axis asks how work is sized and routed, one level down in the same system.

The two poles

Pole A: batch and push. Aggregate work into larger units to amortise transaction costs. Schedule and dispatch work to resources based on forecast. A central plan governs.

Pole B: single-piece and pull. Reduce batch size. Resources pull work when they have capacity. Demand signal at the customer end governs upstream.

Batch size and push-versus-pull are two separate levers. Batch size is how much work travels together, and it operates at three levels: the commitment horizon the board signs off, the size of a work item entering the team, and the size of a change reaching production. Push versus pull asks what triggers the next piece of work, a forecast schedule or free capacity downstream. WIP limits are the control that exposes both. The poles name the correlated ends of those levers rather than a single dial.

Where Pole A is right

When transaction costs are genuinely fixed and high, demand is predictable, and inventory is cheap to hold: classical Economic Order Quantity (EOQ) logic in mature physical operations. The 1913 model assumes a fixed transaction cost and predictable demand, and prices the cost of holding inventory as an input. Raise that input and the model itself calls for a smaller batch. In the small slice of contemporary work that still meets them, the Pole A maths holds.

A pharmaceutical manufacturing line with a multi-hour changeover and a regulated batch certification has fixed transaction costs the operator can’t reduce. A semiconductor fab with a stable product mix has forecast accuracy a software team can’t match. The EOQ logic in those settings is sound maths. The planning most engineering organisations inherited was built for those settings, and the leaders who built it weren’t wrong about the world they built it for.

Where Pole B is right

Pole B is right wherever transaction costs can themselves be reduced and the learning rate matters, where forecast accuracy is low, variation is high, and the holding cost of inventory is high. A deploy whose entire changeover is a CI run measured in minutes sits at the opposite end from the pharma line above. Software work with reducible transaction cost, uncertain demand, or costly ageing inventory tends toward smaller batches.

In decisions

Pole A leaders schedule long roadmaps⁠—queues if we are willing to use a more truthful name⁠—and allocate capacity with long planning intervals. Pole B leaders ship continuously, set WIP limits, and let teams pull from a prioritised and pruned backlog.

The batch-versus-pull axis is set by the planning the CEO runs with the board, and that is the conversation a CTO or VPE has to take upward. If the CEO commits to a quarterly or yearly roadmap with the board, the engineering organisation is pushed to batch work into large commitments no matter what the team-level discipline says.

Put two measures in front of them: the cost of delay on one current initiative, in the CEO’s unit of account, and the change in cycle time the team achieved when WIP limits were last set and held. If you have never held one, the exercise at the end of this chapter produces a first reading of that number in a sprint. Don’t turn this into an Agile lesson. Show the downstream cost: the planning they use with the board propagates into batch sizes the company and customer eventually pay for.

The board wants confidence about risk and return; a 12-month feature list is a proxy for that, and a poor one, since I’ve never seen one delivered as written. OpenAI and Anthropic commit billions of dollars in compute years ahead (OpenAI’s Stargate announcement of January 2025; Anthropic’s ten-year AWS agreement of April 2026) and, as far as I have found, publish no dated feature roadmap. They commit capacity and direction, not the sequence. An incumbent with contracts and regulators can’t copy that outright, and doesn’t need to. Start with a count. How much of the roadmap is genuinely contracted, and how much is merely scheduled? In the organisations I see, the contracted share is small, and the rest had been treated as fixed anyway. Ask to take delivery rate and a record of what you redirected and why to the board instead.

The sentence your CEO can carry to the board: “The planning calendar we run with the board becomes the queue our pending value stands in.”

The planning calendar we run with the board becomes the queue our pending value stands in.

The EOQ trap

I suspect the Economic Order Quantity model is the least examined planning artefact in operations, and part of the reason is that almost nobody in software names it. The logic arrives second-hand, built into the planning calendar and the release train, and an assumption nobody names is one nobody audits. The 1913 model weighs two costs, which Reinertsen calls the transaction cost (the cost of sending a batch on) and the holding cost (the cost of not sending it). It assumes a fixed transaction cost (the same whatever the batch size), accurate demand forecasts (which means uncertainty is small), and a holding cost that rises in a straight line with the batch (which means a big batch costs only proportionately more to hold). It then derives the optimum batch size: the one at which the two costs together are lowest.

The maths is correct. Reinertsen’s own demolition runs through the cost legs: the “fixed” transaction cost isn’t fixed (Japanese manufacturers cut die changeovers from 24 hours to under ten minutes, using the single-minute exchange of dies (SMED) methods Shigeo Shingo pioneered), transaction costs actually grow with batch size, and holding costs grow faster than linearly.

The trouble starts when one input no longer holds. If transaction costs can be reduced⁠—through tooling, automation, practice⁠—the optimum batch size collapses. Low forecast accuracy does the same because the cost of being wrong about a large batch is much higher than about a small one. So does high inventory holding cost, especially when inventory has a short shelf life or hides quality problems. Transaction cost is structural as much as technical. A method that convenes a two-day planning event for a whole programme every quarter carries a far higher transaction cost per batch than one that plans in a few hours each sprint. Hyper-specialisation compounds it. When every department is optimised on its own, finishing anything means crossing more of them, and each crossing adds coordination the batch has to carry. The dependencies raise the transaction cost, and the higher transaction cost argues for the bigger batch.

In 2014 I co-facilitated the first PI Planning event in one of Cisco’s divisions (SAFe’s big-room planning for a whole programme). It ran two days and launched a 15-team Agile Release Train.

Of the three, the transaction-cost leg is moving fastest right now. AI-assisted engineering cuts the cost of producing and testing a change, which moves the optimum down the same way SMED did. My hunch is that it also moves the constraint, toward review, integration, and the demand governance deciding what gets built at all, none of which got faster at the same rate. If that holds, the WIP limit belongs where the work now waits: on review and integration, not on authoring. Don’t build faster than you can safely integrate, into production, into how the organisation works, and into your customers’ hands. If you can, spend the difference making integration faster and safer.

The fact that the planning still defaults to legacy EOQ-shaped logic⁠—large batches, long forecasts, central planning⁠—is doctrinal lag. The maths says one thing; the org chart says another; the doctrine sided with the org chart. The critique predates Agile and DevOps: Goldratt’s The Goal ran it in narrative form in 1984, halving batch sizes against the economic-batch-quantity doctrine. Reinertsen supplies the general mathematics.

Reinertsen on batch-size economics

Donald Reinertsen’s The Principles of Product Development Flow spells out, at industrial scale, how batch size, queues, and economic cost of delay lock together, with a precision the fragments of Lean and Agile most leaders inherit leave out.

Batch size moves five variables at once: as batches shrink, cycle time, queue size, and risk fall while feedback rate and learning rise. The cost of reducing batch size⁠—usually a transaction cost per batch⁠—has to be weighed against the compounding benefit.

Reinertsen’s running diagnostic comes from his own surveys of product developers, only 3% of whom had a formal programme to cut transaction costs, such as manual reviews, test setups, handovers and planning events. Transaction-cost reduction is almost always achievable and almost always underinvested. It stays underinvested as a matter of inherited default, not because the economics favour the old batch size. Cheap switching makes adaptiveness affordable. The test is simple: after fresh evidence arrived, did the next item pulled actually change? A team can hold a hard WIP limit against a backlog nobody has touched in a year, and all the discipline buys is faster delivery of a stale plan.

Reinertsen’s cost of delay, the economic argument chapter 4 made in full, applies directly to batch size. The visible cost (an engineer’s idle hour) wins planning conversations by default; the invisible cost, the delay a deep queue causes, never shows up until someone dollarises it.

Anderson’s kanban

In Kanban, David Anderson asks teams to follow an operational discipline: make workflow visible, cap work in progress, measure and manage flow, state process policies aloud, and use explicit models to find where to improve. The board is the truth; the plan is the hypothesis.

The failure I meet most often is treating kanban as a visualisation layer rather than a discipline. You adopt the board, the WIP limits get ignored, batches keep entering above the system’s capacity, and the conclusion is that kanban doesn’t fit your kind of work. When items keep entering above the cap, the board is serving as a status display rather than flow control. The WIP limit is the operative constraint. The board makes the constraint visible.

The operating system

Follow one item through. It is pulled when a slot opens rather than pushed when someone plans it, so it moves without waiting behind a batch. It ships small enough that the team learns something within days rather than at the end of a quarter. What they learn changes how the next one is pulled. Gene Kim’s DevOps Handbook names those three motions the Three Ways: Flow, Feedback, and Continual Learning. The first two you can build. The third is what the org design either permits or prevents, and it is what keeps the other two from eroding.

In the State of DevOps data the fastest-deploying organisations, deploying on demand many times a day, also carry the lowest change-failure rates. The Pole A intuition that fast deployment is reckless is inverted by the measurement. Small change size is the likeliest mechanism⁠—less can go wrong in a five-line change than in a 500-line one⁠—though the surveys measure association rather than cause.

A representative case

The version I ran started somewhere less tidy than a planning problem. Demand was arriving well above delivery capacity. When we read queue length as time-to-clear at the observed rate, the answers came back in months and years. Nobody had been lying about the roadmap. The arithmetic had simply never been done out loud.

Three changes.

First, make the queue visible in time rather than in items. A count of stories is a number; months to clear at the current rate is a decision.

Second, put a hard edge on intake. Work went into two lanes with a stated order, and a displacement rule: when incoming unplanned work would push an iteration past the team’s raw velocity, enough planned work had to come out, with a comment on both stories recording what changed and why. The trade stopped being invisible.

Third, set a work-in-process threshold and let it stop the line. More than 1.3 stories per builder, or more than three-quarters of an iteration’s worth in process, and intake froze. Both numbers were starting defaults, open to revision in retrospective, and they got argued about, which was the point: arguing about the threshold is arguing about capacity. What the rules produced belongs to the client, so the case stops here.

The diagnostic

Three questions for last sprint’s allocation:

• Which pole was I claiming? Did I describe the work as batched-and-pushed or single-piece-and-pulled?
• Which pole would the actual batch sizes show? If I measured the average size of work items entering the system, would it look like Pole A or Pole B?
• Which pole does this work actually require? EOQ wants a fixed transaction cost, demand you can treat as known, and a holding cost that rises in a straight line. Where transaction cost can be cut, demand is uncertain, or holding cost climbs faster than the batch, the economic batch size drops. How far is a question for measurement, not doctrine.

The exercise

Run a WIP-limit experiment for one sprint. Set a hard team-wide WIP limit: say four items in progress total or half a sprint’s velocity, not per person. Pull from a ruthlessly pruned backlog. Measure lead time and cycle time before and after. The team finds out which items have been passively blocked: sitting in progress because nobody had to kill them. The team feels how unfamiliar it is to pull rather than push. And the leader gets an early lead-time signal that no roadmap-status conversation produces.

A second variant for teams already running kanban: run a kata cycle on one constraint. Pick the stage where work piles up, name a target condition (how that stage should operate to produce a specific cycle time), identify the next obstacle, run a small experiment, learn, repeat weekly. Run the Toyota improvement kata as a four-week experiment.

Going upstream

Watch. Henrik Kniberg, High WIP, Context Switching vs One Piece Flow (Vimeo, 7 min). Don Reinertsen, GOTO 2012 Interview on flow (24 min). Companion short hook: Reinertsen, Economics of Batch Size and the “Father-Egg” Story (4 min).

In-text: The two main sources named in the chapter. Don Reinertsen, The Principles of Product Development Flow (the Q-series, E-series, and B-series principles together, including batch-size economics and the EOQ demolition). David J. Anderson, Kanban (the WIP-limit discipline behind the exercise).

Also touched: Eli Goldratt, The Goal, for the 1984 batch-halving antecedent to the EOQ critique (worked at full length in chapter 8). Gene Kim et al., The DevOps Handbook (Chapter 1 on the Three Ways), the structure that lets Reinertsen and Anderson compose into one operating system.

Go deeper: The lineage that names the same single-piece discipline at different layers, demoted here and carried elsewhere in the book. Mary and Tom Poppendieck, Lean Software Development (the seven principles for translating lean to software: cutting waste, building in learning, deferring commitment, shipping quickly, giving teams authority, designing quality in from the start, and optimising the whole rather than the parts) and The Lean Mindset, for the Toyota-Production-System-to-software translation. Jez Humble and David Farley, Continuous Delivery, for the deployment pipeline that makes large batches structurally expensive (developed in chapter 4). Kent Beck, Extreme Programming Explained, for embrace change and the short-cycle cultural discipline. Mike Rother, Toyota Kata, for the coaching and improvement kata behind the exercise variant; the constraint-first selection above is the Goldratt overlay, since Rother starts from the pacemaker process, and he is precise that a number alone is a target, not a target condition. Gene Kim et al., The Phoenix Project, for the narrative form. Nicole Forsgren, Jez Humble, Gene Kim, Accelerate, the State of DevOps reports across four years, for the empirical correlation: high software-delivery performers are twice as likely as low performers to exceed profitability, productivity, and market-share goals, and the fastest-deploying organisations carry the lowest change-failure rates.

I work with CTOs and CPOs at software companies with roughly 50–500 engineers on exactly this kind of paradigm work. If it’s live for you, I’m happy to talk: schedule a 30-minute virtual coffee at hi.chrisgagne.com. If it’s live for someone you know, pass this chapter on.

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

Small batches and pull only move work if someone holds the authority to decide what gets pulled, and in most structures that person is you. The queue forms on your calendar. Tuesday fills with approvals, the team stalls on any decision you haven’t signed, and the function gains no speed for all the oversight. You are the bottleneck. In chapter 17 you set David Marquet’s leader-leader against the default that put you there, leader-follower.

The incident counter your team reports up is at zero. What it can’t show you is how the work actually gets done safely and how to keep it that way.

Chapter 14 walked through the anatomy of incidents. The safety metric you use decides what gets funded.

The deviation-versus-conditions question asks about a specific incident. Incident counts raise a system-level question: which view of safety drives the metrics and the investment? Both matter, and each demands its own focus.

The two poles

Pole A: safety as absence. Safety is the absence of events. The fewer accidents, incidents, and near-misses, the safer the system. Safety investment is insurance against accidents.

Pole B: safety as presence. Safety is the presence of the ability to succeed under varying conditions. Safety investment is investment in adaptive capacity.

Where Pole A is right

Pole A fits tractable, complicated systems with stable specifications: the lost-time injury rate on a mature manufacturing line, the field-failure count for a long-standing physical product, or the audit-finding count on a stable regulated process. The absence metric tracks what’s happening because the variability is genuinely low.

In those settings, Pole A is a strong metric because work-as-imagined and work-as-done are tightly aligned. The operations leader who uses it on a mature, stable manufacturing line is doing the right work. The same metric becomes structurally misleading in another domain.

Where Pole B is right

Pole B fits intractable, complex sociotechnical systems where work-as-done routinely adjusts to conditions work-as-imagined didn’t anticipate. A software platform under continuous deployment fits. So does a clinical service operating with staffing variability, or any system where the absence-of-events metric stops moving while everyone reports getting away with more than they used to.

In decisions

Pole A leaders count injuries. Pole B leaders ask, “How are we able to do this work well 999,999 times out of a million, and what do we need to preserve about that?”

Safety-as-presence is a capital-allocation argument, and that is the version a CTO or VPE should carry up to the CEO. Put one picture in front of them: what the engineering budget actually bought last year, split four ways (firefighting, early warning, learning, and rehearsal). There is no standard right balance; the mix depends on the domain. In the organisations I have worked in, firefighting took most of it and rehearsal took least.

In the engineering organisations I’ve seen, this split rarely came from a choice. Urgent, visible response work kept winning over anticipation.

The CEO-level change is to make Anticipate a named budget line, sized as a share of what you already spend on incident response rather than asked for as new money, so it survives the next planning cycle without requiring an incident to justify it. The exercises themselves don’t wait for the budget line; running them inside engineering is your span, and that part isn’t an ask: I intend to run a failure-injection exercise each quarter, because a green dashboard tells us nothing about the failures we haven’t met. The first is a tabletop, the second runs in staging, and we go near production only once we have shown we can stop one safely. Unless you see something I don’t, the first one runs this month. The sentence your CEO can carry to the board: “A quiet dashboard can’t tell skill from luck; we’re now funding the catching, not just the counting.”

Safety-I and Safety-II

In Erik Hollnagel’s Safety-I and Safety-II, Safety-I⁠—Pole A⁠—studies what goes wrong. Its unit of analysis is the incident, and its improvement loop finds what caused the incident and seeks to prevent it from recurring. Its methods include fault-tree analysis, root-cause analysis, and near-miss reporting.

Safety-II⁠—Pole B⁠—studies what goes right. Its unit of analysis is the everyday successful operation. Its improvement loop seeks to understand how things work when they work, and preserve the conditions that produce success. Its methods include appreciative inquiry, work-as-done observation, and resilience engineering.

Hollnagel’s claim is that Safety-I produces diminishing returns in complex sociotechnical systems. Most of the time, the system runs successfully despite gaps in work-as-imagined because people inside it make invisible adjustments. Studying only the failures misses what’s actually keeping the system safe. Safety-II keeps Safety-I and adds the missing half.

Studying only the failures misses what’s actually keeping the system safe.

The causality credo and the hypothesis of different causes

Hollnagel names the unstated assumption under Safety-I: the causality credo. In Hollnagel’s words, it is the faith that “since all adverse outcomes have a cause (or causes) and since all causes can be found, it follows that all accidents can be prevented.” Closely related is what he calls the hypothesis of different causes: the belief that things going right and things going wrong have different causes.

Resilience engineering rejects both. “Failures were the flip side of successes… things that go right and things that go wrong happen in basically the same way.”

The same pipeline, the same time pressure, and the same workaround produce Tuesday’s save and Thursday’s outage; only the conditions differed. Successes also carry useful information. They are where the adaptive capacity lives.

The Pole-B metric framework coheres only after leaders reject the causality credo. Pole B measures what works while it is working.

The four resilience potentials

Hollnagel proposes four potentials as necessary and, within the book’s argument, sufficient for resilient performance.

Respond: knowing what to do: drawing on prepared actions, adapting how the system is currently running, or improvising new responses to whatever changes, disturbances, or opportunities arrive, whether routine or not. The capacity to handle what is happening now.

Monitor: knowing what to look for: keeping watch on the things that do or could affect performance in the near term, both inside the system and out in the operating environment. The capacity to see what is developing.

Learn: knowing what has happened: single-loop learning that draws lessons from specific experiences, and double-loop learning that revises goals or objectives. The capacity to extract lessons from both success and failure.

Anticipate: knowing what to expect: looking ahead to possible disruptions, novel demands, fresh opportunities, or shifts in operating conditions further out in time. The capacity to imagine what is developing beyond what current monitoring can see.

Together, the four form what Hollnagel calls the Resilience Assessment Grid. Organisations tailor its diagnostic and formative questions to their own work, apply them repeatedly, rate the answers on a Likert-type scale, and use a radar chart to track and manage change over time. Safety is the presence of adaptive capacity; the grid names four potentials an organisation can assess and fund.

I ran the analytics product at PagerDuty, which meant building the reports engineering leaders were actually asking for, and I am one of four named inventors on a PagerDuty patent for an operations maturity model, which scores an organisation’s incident practice from its own operational record⁠—time to acknowledge, time to resolve, escalation rate⁠—and benchmarks it against comparable organisations. Every one of those measures sits inside Respond. I do not remember anyone asking us for a number that would show them what they were failing to anticipate. We built the instruments for the potential that was already funded.

Pole B leaders need to know which of the four potentials this organisation is strong in, which it is weak in, and how that investment changes over time. The engineering organisations I’ve worked with fund Respond and Learn—Respond because incidents demand it, Learn because retrospectives ritualise it⁠—while Monitor is patchy and Anticipate is starved by default.

Cook’s points 16, 17, 18

Richard Cook’s How Complex Systems Fail gives three points central to this axis, starting with Point 16: safety is something the whole system produces, not a trait of any one part. You can’t add up safe individual workers, safe individual procedures, safe individual tools, and arrive at a safe system. The safety emerges from how the parts interact under load.

Point 17: People continuously create safety. Most of what keeps the system running is invisible adjustments by people inside it. The procedure said one thing; the operator did something subtly different that worked better in this specific situation; the system survived. This happens continuously. Pole A metrics don’t see it because the metric asks did an incident happen?, and no, the incident didn’t happen, because the operator adjusted. Pole B asks the adjustment to become visible.

The procedure said one thing; the operator did something subtly different that worked better in this specific situation; the system survived.

Point 18: keeping operations failure-free depends on people who have firsthand experience of how things fail. The skills the operator uses to keep the system running come from familiarity with how it can break. Reduce failure to zero and you also reduce the operator’s familiarity with the failure modes, unless you keep that familiarity alive by rehearsal. The system becomes brittle in the long run because the people running it lose the experience they would need to recover when something does go wrong.

The Pole A leader who succeeds completely produces a fragile organisation.

Cook’s three points and Hollnagel’s four potentials teach the same thing at two scales. Cook names what safety is in a complex system; Hollnagel names how an organisation invests in it. The operator’s mid-incident adjustment is Cook’s Point 17 in the flesh, and Hollnagel’s grid is how an organisation buys more of it.

Snook’s F-111 near miss

Scott Snook’s Friendly Fire documents an instructive counter-case to the 1994 friendly-fire incident the previous chapter described. In September 1992, a flight of Air Force F-111s nearly engaged two Black Hawks from the same Eagle Flight detachment at Bashur, identifying them only on a second pass, in the Black Hawk pilot’s testimony: “At the last minute, the guy said those look like two Black Hawks.” About 18 months before the eventual shootdown, the same conditions nearly produced the same outcome.

The 1992 near miss didn’t result in deaths. It also didn’t result in changes to the system. It surfaced only by chance, days later, over drinks at the Incirlik officers’ club, where the F-111 pilot told the Army aviators how lucky they were: his flight had been on the trigger and only then realised the targets were friendly. It was never reported up the chain. Nothing was done; nothing was learned.

The near miss had the same structure as the eventual shootdown: no fighter-helicopter direct comms, fighters unaware of the helicopter mission, AWACS failed to relay. About 18 months later, the same conditions produced the accident.

A Pole B organisation would have treated the near miss as critical data. The organisation it actually happened in didn’t; as Snook puts it, the emphasis was on the “miss” and not on the “near”.

The near miss was the leading indicator. The accident report was the lagging one.

Snook’s own reading is harsher still: even had the near miss been reported, he doubts it would have changed anything, because the organisational response to a report is to add rules, not to address the structural disconnects a report exposes. Reporting a near miss into a system that answers with procedure buries it a second time. Pole B demands investment in the cultural conditions where near misses get heard and the response is structural rather than procedural.

Snook’s F-111 case shows what happens without a reporting culture, the condition under which what people saw travels up the chain. Just culture is the other condition: engineers don’t volunteer near misses to organisations that punish their existence.

The AI overlay

The automated dashboard reads incident counts as a primary signal. It can’t see the incidents operators prevented. AI tools sharpen a Pole-A trap that was always there, and they do so in the way chapter 13 described through Bainbridge’s ironies.

As AI takes over more of the visible adjustment work, it strips out the slack the absence metric was living on. The metric never surfaced the invisible adjustments and human improvisations that kept the system running; now fewer operators remain to make them. Recovery gets harder.

Organisations risk arriving at a state where the dashboards show everything is fine and the operators report being unable to recover when anything actually breaks. AI exposes how thoroughly Pole A had already hollowed out Cook Point 18: the absence metric had been spending down the operators’ familiarity with failure for years, and AI can remove the last of the slack that hid the bill.

Under AI, Pole B leaders actively study the augmented system’s failure modes while the dashboard is green. They use red-team exercises, deliberate failure injection, and post-incident reviews that ask what did the AI miss, and what would we miss if the AI weren’t here? Bainbridge adds another demand: preserve human access to the patterns automation has displaced, so human monitoring remains real. A green dashboard makes these exercises hard to fund. Pole B treats that lack of visible failure as the reason to run them.

A representative case

Suppose a large engineering organisation ends the year with no reportable incidents at all. The leadership team celebrates. A senior engineer privately raises a concern: the team has been working around several known issues for the entire year, and the lack of incidents has more to do with luck and operator skill than with system improvement. The leadership team has a green dashboard, a year of delivery wins, and a concern arriving without data behind it. They don’t act on it. The next year, two of the worked-around issues converge into a major outage that takes down the platform for nine hours.

The post-incident review goes two directions at once. The Pole A direction looks for the proximate cause of the outage. The Pole B direction eventually asks what did the operators know in advance, and why didn’t the organisation hear it?

Hollnagel’s Monitor potential had been missing from the organisation’s investment all along, whatever the dashboards suggested. The operators were monitoring; the organisation wasn’t. The Pole B answer reorganises how near misses get surfaced and resourced. The Pole A answer adds more monitoring of the wrong kind: more dashboards, more alerts. Both moves get made. Only one addresses the cultural condition that produced the year of unsurfaced workarounds.

For engineering leaders, the year of zero incidents is the year to invest in Hollnagel’s Monitor and Anticipate potentials, provided you first run the test that says which kind of quiet year you had. Ask the operators what they worked around. A system whose operators report nothing may be genuinely well designed; a system whose operators have been working around known issues all year has been spending down its slack, and the incident count can’t tell the two apart. Snook, in the same chapter as the F-111 near miss: “Just because it isn’t broken, doesn’t necessarily mean that it isn’t breaking.” Use the quiet period to find out what the operators’ invisible adjustments are holding together. Pole A treats the quiet as success; Pole B treats it as the window during which Pole B investment is cheapest.

The diagnostic

Three questions for last quarter’s safety review:

• Which pole was I claiming? Did I treat safety as the absence of bad outcomes or as the presence of adaptive capacity?
• Which pole would the actual investment show? Where did the engineering budget you steward actually go: into incident prevention or into resilience capacity? And across Hollnagel’s four potentials, which got the investment? Expect Respond and Learn to dominate, and check whether Monitor and Anticipate were funded at all. Is that distribution the one this system needs?
• Which pole does the system actually require? If your system is complex and sociotechnical, expect Pole B to be the under-funded half, and let the audit in the next section say whether yours is.

The three answers matter most when they diverge.

The exercise

Run a near-miss audit on the last quarter. Collect every near miss, every save, every moment the operators adjusted to keep the system running. Sort them by which of Hollnagel’s four potentials actually did the catching: Respond (the team handled it well when it arrived), Monitor (the team saw it developing), Learn (an earlier review had changed how the team works, and that change made the catch), Anticipate (the team had imagined this further out and was ready). When a save involves more than one, credit the earliest in the chain: if the team saw it developing, score it Monitor, whatever Respond did afterwards. Learn sits outside that chain: tag a save Learn as well whenever a past review made the catch possible. Sorted that way, the distribution shows how early you catch things. The fat buckets show where the organisation’s catching actually happens, whether or not it meant it to; the thin ones are where to start asking questions, since a potential that works well upstream can leave few saves to count. A fat Respond bucket is its own warning: the system is catching things at the last possible moment. A second variant for teams that have a strong retrospective practice already: run a Safety-II audit. What’s going right that the team doesn’t have visibility into? Where do operators tell you things work despite the procedure, not because of it? Those answers show where the Monitor potential needs investment, and they are the answers Pole A dashboards systematically miss.

Going upstream

In-text: Erik Hollnagel, Safety-I and Safety-II, and the operational companion Safety-II in Practice (Chapters 4 and 5 for the four resilience potentials and the Resilience Assessment Grid). Richard Cook, How Complex Systems Fail (points 16, 17, 18). Scott Snook, Friendly Fire, on the 1992 F-111 near miss (Chapter 7, the conclusion).

Also touched: The reporting-culture and just-culture conditions that surface near misses are James Reason’s informed culture subcultures, worked at length in chapter 14.

Go deeper: The sources under chapter 14—Sidney Dekker, Safety Differently and John Allspaw, How Your Systems Keep Running Day After Day—both teach this dichotomy at the metrics-and-investment level too. The line of representation that chapter 14 adapts is from Cook, Allspaw, Woods et al., STELLA Report (2017). For pre-accident-investigation methodology: Todd Conklin, Pre-Accident Investigations.

I work with CTOs and CPOs at software companies with roughly 50–500 engineers on exactly this kind of paradigm work. If it’s live for you, I’m happy to talk: schedule a 30-minute virtual coffee at hi.chrisgagne.com. If it’s live for someone you know, pass this chapter on.

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 set WIP limits and the team ignores them. The batches keep growing, the lead times keep stretching, and the board still hears the trains are running on time. Chapter 4 asked whether your system was busy or moving. You answered that. The batches swelled anyway, because the size of a batch gets decided one layer down, where you weren’t looking. Chapter 16 hands you that layer: how the work gets shaped and pulled, and why the planning rules you inherited keep the swell off the board’s dashboard. You run a WIP-limit experiment for one sprint.

You’re looking for the deviator who failed. The deviator was doing what the system trained them to do.

Bainbridge’s irony from chapter 13, that automation hollows out the operators it relies on, runs into incident response next, where blaming the operator leaves the conditions that produced the incident untouched.

The two poles

Pole A: deviation. When work goes wrong, the explanation is a deviation from procedure, competence, or intent. The fix clarifies the standard or addresses the deviator. Human error is a sufficient diagnosis.

Pole B: conditions. Real work continually adjusts to underspecified conditions. The gap between work-as-imagined and work-as-done is where both safety and risk live. Failure is the unexpected combination of normal variability. Human error is a symptom of that gap, not a diagnosis.

Where Pole A is right

Pole A fits tractable failures with a clean mechanism and locatable responsibility: a broken bearing, a software null-pointer exception, a structural calculation error, or an individual whose behaviour was genuinely reckless. Even that last item carries Dekker’s caveat: a proven bad apple is still a system responsibility: someone hired, credentialed, and scheduled them. Further, reckless is an infinitely negotiable label through which the deviation reflex re-enters, so treat it as where an investigation starts, not as its conclusion.

Pole A is right when the failure is a discrete event in an otherwise stable system and responsibility can be named without distortion. Root-cause analysis works for that kind of failure. Many engineering-organisation failures aren’t that kind.

Where Pole B is right

Pole B fits any incident where failure came from the unexpected combination of normal variability.

A hotfix I reviewed corrected one defect and introduced another: some transactions went through twice. The change passed every check the team had. The tester couldn’t run the production-like daily workflow in the test environment. The relevant edge case was absent from the manual test steps. There was no automated integration test for that path. The engineer making the change was carrying several high-risk fixes and preparing to hand work over, and the hand-off was rushed, with the important context living partly in private conversations.

The monitoring detected the original failure mode. It didn’t detect a transaction that succeeded twice, so customers reported the result. The response then crossed engineering, service and product: every affected transaction had to be found, stopped where possible, put right and explained. The original defect still existed, because its fix had been reversed.

Access, test design, workload, knowledge concentration, hand-off quality, monitoring and time pressure all contributed. Asking the engineer to be more careful would have left every one of those conditions intact.

In decisions

Pole A leaders trace the incident back to the decision that broke the standard, then reinforce the standard and coach the person who missed it. Pole B leaders go to the gemba—the actual place where the work happens⁠—and ask “what surprised you?” and “where did you have to improvise?” Then, they change the system people are operating within.

Take your last meaningful incident and lay two analyses side by side. The first is your standard after-action review. The second report is what the on-call rotation knew beforehand and had no reliable channel to surface. That second report doesn’t exist until someone goes to the gemba and sources the knowledge, which takes effort and trust. The full protocol is at the end of the chapter.

The gap between the two analyses is what Vaughan calls structural secrecy. Ask what this organisation has collectively stopped being able to see.

The after-action review sits inside your own span, and that part doesn’t have to be an ask: I intend to redesign our reviews so the broader context is examined every time. Our current review isn’t going deeply enough, so unless you see something I don’t, the redesigned review starts with the next incident. The sentence your CEO can carry to the board: “What reaches us has been filtered; the deeper, unexamined context is where the next incident is hiding.”

The Old View and the New View

Sidney Dekker’s Old View, one of two epistemic frames in The Field Guide to Understanding ‘Human Error’, holds that human error causes accidents. People who err are bad apples: remove them, retrain them, or stiffen the rules. The New View holds that human error follows from trouble inside the system. People who err are the symptom; the conditions that shaped their behaviour are what needs explaining.

Dekker’s case, made across 30 years of safety-science work, is that the Old View’s empirical props⁠—accident-proneness statistics and Heinrich’s triangle⁠—fail under the data, while its remedies suppress the information safety management needs.

Heinrich’s triangle holds that minor incidents and fatalities sit in fixed proportion, so a falling count of small events implies the big ones are under control. Incident dashboards run on that logic. Heinrich built the triangle from insurance and actuarial science: the ancestor of the modern incident dashboard is an underwriter’s loss table from nearly a hundred years ago. Dekker’s counter-example is Deepwater Horizon, where executives aboard were celebrating seven years without a lost-time incident on the day the rig killed 11 people and caused the largest accidental marine oil spill in history. The record was real and accurately measured lost-time injuries on deck, but the well was a different risk class entirely. Construction shows the same split over decades: minor-injury frequency falling while the absolute count of fatalities and life-altering injuries holds steady. The ratios vary wildly between industries, jobs and places, and the safer a system gets, the less the small stuff predicts the large. Dekker’s charge is stronger than inaccuracy. The belief sedates: it “rocks you to sleep with the lullaby that the risk of major accidents or fatalities is under control as long as you don’t show minor injuries, events or incidents.” The quotation marks in Dekker’s book title compress the argument into typography: human error is a label someone applies, and labels aren’t categories of behaviour.

The other prop is older, and it keeps coming back. In the mid-1920s the Boston public transport company found that 27% of its drivers caused 55% of its accidents, and psychologists in Britain and Germany independently proposed that some workers were simply accident-prone. Every engineering leader has seen the software version: one name recurs across the incident log, and the pattern looks like a person. The refutation is a denominator problem. The method needs every driver to face the same expected accident rate, and some drove the busy centre while others drove quiet suburbs at night. Dekker states it flatly: practitioners aren’t all exposed to the same kind and level of accident risk, which makes it impossible to compare their rates and conclude that personal characteristics explain the gap (p. 12). The engineer who appears in every incident review usually owns the gnarliest service. By the end of WWII the field had concluded that proneness was “much more a function of the tools and tasks he or she was given, and the situations they were put into” than of personal characteristics. The idea survives because blaming the worker leaves management “scot-free” of responsibility for design, selection and training.

The Old View persists because it offers a fast, visible act at the moment the pressure is highest, and conditions-work offers nothing that week. Naming the deviator is easy and fast. Understanding, naming, and resolving the conditions is hard and slow.

A client once ended a coaching engagement I was part of. My account of why has always been that a fellow coach quit in frustration. I never went looking for the other story: what the client was reacting to, and what I was doing.

Naming the deviator is easy and fast. Understanding, naming, and resolving the conditions is hard and slow.

Practical drift, at four levels

Chapter 5 met Scott Snook’s Friendly Fire, his study of the 1994 shootdown of two American Black Hawks by two American F-15s over northern Iraq, in which 26 people died. Here it is the anatomy of the incident itself. I think Snook’s book is the single most important book-length review of how organisational accidents actually happen.

Snook refuses to pick one level like a Pole-A reading would. The pilots fired the missiles, so the pilots are the cause. Or the AWACS crew failed to challenge the engagement, so the AWACS crew is the cause. Or the rules of engagement were ambiguous, so the rule-makers are the cause. Each was true at its level, but none is the whole story.

Snook’s four-level causal map names the structure: individual (what the pilots saw and did), group (what the AWACS crew did), organisational (how the no-fly zone command structured decision rights), and cross-level (how the layers interacted under conditions of practical drift). Each layer has its own causal story, none sufficient on its own to explain the accident.

Picking one level is, in Snook’s framing, how resolution gets felt without being reached. The simple story picks one level and calls it the cause; the multi-causal story holds all four at once.

Snook named the pattern of small-step accommodation across these levels practical drift: “the slow steady uncoupling of local practice from written procedure”. The 2×2 he drew has two axes: is the action rule-based or task-based, and is the system loosely or tightly coupled. Four quadrants follow: Designed, Engineered, Applied, Failed. On Snook’s account, most organisations live in Applied, where local task logic and loose coupling keep everything working.

The shift from Applied to Failed comes when coupling suddenly tightens. Everyone is doing what local practice says. The aggregate produces an outcome no one actively chose. The matrix is a cycle: the organisation that has just been to Failed writes tighter rules, which is the shift back to Designed, and the drift begins again from there.

Snook’s verdict is that the shootdown was, in the strict sense, normal. Normal people behaved in normal ways inside normal organisations, exactly as the theory would predict given the circumstances each level faced.

The Pole A response to practical drift looks for the moment someone broke a rule. There was no single decisive moment. Pole B asks one pair of questions at all four levels: what did work-as-imagined say should happen, and what had work-as-done drifted into?

Structural secrecy: what makes drift invisible

Structural secrecy is Diane Vaughan’s name, in The Challenger Launch Decision, for the way an organisation’s own patterns of information, structure, processes and regulatory relations undercut its attempt to know and interpret its own situation, and it is what makes Snook’s practical drift hard to recognise as a signal from inside the organisation. That runs at every level, not only the top. It is the ordinary functioning of a multi-level organisation, without concealment by intent.

That hotfix ran on exactly that. The context needed to catch the edge case lived in private conversations during a rushed hand-off, so it was in the organisation and not in the review. The monitoring watched for failures, and a transaction that succeeds twice is still a success, so the system had no way to see what it was doing. Nobody concealed anything. Each representation showed a true slice, and the slices didn’t add up to the situation.

Of Vaughan’s Challenger forces, structural secrecy matters most to a senior leader. In Vaughan’s own case the channels were open and the top knew what the work group knew; the filter was as much in the shared construction of risk as in transmission.

Dekker carries Vaughan’s concept into the safety bureaucracy itself: the cultural, organisational, physical and psychological separation between operations on one side and safety regulators, departments and bureaucracies on the other, a gap that widens as the safety function grows its own remit and budget. Clarke and Perrow’s 1996 fantasy documents sit in that gap: safety plans that bear no relation to actual work, written to persuade regulators and boards that the hazard is handled. They are the paperwork that makes an organisation feel like it can see.

Structural secrecy and practical drift feed on each other. Not knowing what other units do lets work groups drift into locally practical arrangements, and the distance that opens between groups deepens the secrecy in turn.

Cook’s 18 points

I suspect Richard Cook’s How Complex Systems Fail (a short treatise first published in 1998) is the densest one-document statement of the New View. It contains 18 numbered claims. Three matter most for this axis; the point titles below are my paraphrases, not Cook’s.

Point 7: There is no isolated root cause for failure in a complex system. Failure emerges from multiple latent conditions interacting under specific circumstances. The search for a single root cause is, in this framework, a categorical mistake. The system produces failure the way a wet floor produces a slip. The floor alone is harmless. It takes the wet floor, the smooth shoes, the box someone is carrying that they can’t see past, and the hurry, all present at once, and the slip is what that combination does.

Point 8: Hindsight biases post-accident assessments. After the fact, the path to failure looks obvious. The people involved couldn’t see it from inside the situation because the path became obvious only in retrospect. Further, what I’ve seen in incident records isn’t that late reviews get vaguer but that they mostly don’t happen: the document exists as a title wrapped around an unfilled template. The hotfix above was itself the fix for an earlier incident, deployed earlier that same week. Whatever review that earlier one was owed, the next incident arrived first.

Point 15: Post-accident remedies often increase coupling and complexity. The intuitive Pole A response⁠—add a procedure, add an approval gate, add a monitoring system⁠—frequently makes the system more tightly coupled and harder to operate safely. The remedy can make the next incident more likely. Cook’s claim is hard to act on because the alternative⁠—sit with the incident, study the conditions, do less⁠—violates Pole A’s instinct. “Don’t just do something, stand there (in the Ohno circle)!”

Behind Point 15 sits a related design choice, which Alicia Juarrero names fail-safe versus safe-fail (chapter 7): you can try to make the system unable to fail by listing every way it could fail and preventing each one, or you can design it to contain failure when it arrives, because no list is complete in a self-organising system. Her constraint architecture, developed in chapter 8, is the philosophical ground under it. Punishing the operator leaves that architecture untouched, which leaves the next incident pre-loaded.

Behind Human Error

Most incidents carry two stories. In one review I read, the first story arrived in the middle of the night, while the outage was still running: human error was confirmed as the root cause and the team instructed accordingly. It was the fast answer, available at the moment the pressure was highest, and it was wrong. The considered analysis, written later from the same facts, put the cause elsewhere: no change control for the production system, no runbook, no completion checklist, no post-task validation. Nothing about the timeline changed. The explanation did. Even that was a list of missing provisions; the second story goes underneath it, and usually runs like this: The procedure didn’t fit the conditions the operator was facing; the operator improvised; the improvisation worked most of the time… until it didn’t.

Keep working until you have the second story. Sharp end—the operators in the moment⁠—and blunt end—the organisational conditions shaping what the sharp end can do⁠—must both be in the analysis. Punishing the sharp end while leaving the blunt end unchanged is the failure I see most often in the review records I’ve read.

Punishing the sharp end while leaving the blunt end unchanged is the failure I see most often in the review records I’ve read.

The boundary the organisation draws between operator and system is political, and that choice determines who gets blamed. Pole A draws the line so the operator stands alone. Pole B includes the system in the analysis.

Work-as-imagined and work-as-done

Above the line is what the organisation describes about how the work gets done: org charts, policies, procedures, dashboards. Below the line is what actually happens when the work is being done: the improvisations, the workarounds, the implicit knowledge, the social adjustments. The gap between the two is where safety lives, and where risk lives. (The phrase is adapted from the STELLA Report’s line of representation, which draws its line in a different place: the people and their mental models above it, the code and hardware below.)

Erik Hollnagel develops the pair in Safety-I and Safety-II. After-action reviews that stay with work-as-imagined produce policy clarifications. Reviews that reach work-as-done produce systemic learning. Spend enough time in the work for work-as-done to become legible.

The organisation’s above-the-line representation is the documented work. The below-the-line reality is the actual work. Structural secrecy lets both versions coexist without anyone recognising the gap as a signal.

Reason’s informed culture

The cultural toolkit Pole B requires is James Reason’s informed culture—one in which leadership knows what is actually happening at the sharp end⁠—which rests on four interlocking subcultures: a reporting culture where people freely surface errors and near-misses without fear of inappropriate blame; a just culture that distinguishes honest error from the small minority of behaviours that warrant sanction so the reporting culture can survive; a flexible culture that can move authority to the sharp end during high-tempo operations; and a learning culture that turns lessons into reconfigured assumptions and action.

Reason’s just culture assumes the line between honest error and sanctionable behaviour can be drawn clearly and consistently. Dekker’s Just Culture argues there is no line, only people with the power to draw it: the same negotiability that hangs over reckless earlier in this chapter. Treat the distinction as something your organisation negotiates in the open. The taxonomy won’t hand it to you.

Some of the engineering organisations I’ve worked with claim what Ron Westrum called a generative culture and operate, by Reason’s four-subculture checklist, as bureaucratic ones. Reason’s framework gives leaders a way to test that claim: which of the four subcultures are actually present.

Reason’s separate GEMS taxonomy supports a more precise discipline by distinguishing at least three different mechanisms underneath the same outcome⁠—the operator did the wrong thing—and each needs a different response. A skill-based slip is the config pushed to the wrong environment because the two consoles look identical: the response is a guardrail in the interface, not more concentration. A rule-based mistake is the runbook written for the old topology, so the right rule fired on the wrong system: the response is fixing the runbook and teaching when it applies. A knowledge-based mistake is the novel cascade with no runbook at all, where someone improvises a plan that turns out wrong: the response is real support for sense-making in territory nobody has mapped.

The Swiss cheese model is itself a simple story

Deviation and conditions are also two ways of telling the story of a failure. The deviation account is a simple story: one cause, one villain, one fix. The conditions account is multi-causal: several causes operating at once, no single villain, a fix that touches the system. The narrative form determines the intervention that follows, which is Jennifer Garvey Berger’s simple-stories mindtrap operating on an incident review.

James Reason gave the field what became known as the Swiss cheese model: defensive layers with holes that vary over time, and accidents happening when the holes align. The metaphor crossed every tradition in the field, from aviation to healthcare to software. Unsafe acts by front-line workers still do real work inside Reason’s model, and the phrase is Heinrich’s. Dekker dates the thinking underneath the diagram as “getting on in age⁠—soon a century” (p. 123).

The metaphor itself tells a simple story about multi-causal failure. Linear slices. Discrete holes. Causation moves left-to-right through the diagram. The model meant to teach multi-causality is the most Pole-A-shaped way to talk about it.

Even the field that argues hardest for multi-causal stories turns to a linear metaphor when it has to communicate. The Swiss cheese model travels because it is simple. Its simplicity makes it portable and limits what it can teach.

The Pole B approach is to use the model as an entry point and refuse to stop there. When the after-action review uses the Swiss cheese diagram, ask which non-linear interactions, dynamic feedback loops, and structural conditions the linear diagram couldn’t depict. Carry Garvey Berger’s own summary into that room: “in a complex world a simple story is just about always wrong, and will just about always lead us to an emaciated, impoverished set of choices” (p. 39). Her habit is the discipline that room needs: notice your story, then create another, then another.

A representative case

Picture a platform engineering team a few months into a run of deployment outages. The Pole A response from leadership is clear: tighter change-control, more approval gates, after-action reviews focused on what each on-call engineer did wrong. The outages continue. The engineers are exhausted and starting to leave. The ones who were on call when it broke carry it hardest: Dekker calls practitioners harmed by an event they were caught up in second victims, and support for them is an obligation.

When the Pole B move lands, a senior engineer is given a week to do nothing but interview the on-call rotation and the platform team about what the work actually looks like below the line. What the interviews surface is consistent. The change-control system has become so onerous that engineers are batching small changes into larger ones: fewer change reviews, but each change touches more surface. The approval gates have introduced a delay that pushes deployments into peak-traffic windows. The after-action reviews have become defensive theatre that makes engineers reluctant to surface near-misses. Reason’s reporting subculture, which the leadership team thought it had, is structurally absent below the line.

Each Pole A remedy has a mechanism running the wrong way: batching enlarges the blast radius, gate delay pushes deploys into peak traffic, and defensive review suppresses the near-miss reports leadership needs. That is Cook’s Point 15 in operation. The Pole B response⁠—reduce change-control friction, redesign after-action review to surface conditions rather than assign blame, give the on-call rotation slack, build a real reporting subculture by making the engineers who surface near-misses visibly protected⁠—is the one to test against the outage rate. Nothing in the interviews pointed at the engineers; everything pointed at the conditions they were working in. And blame-free still carries accountability: in Dekker’s terms, the account stops being something the operator settles and becomes something the operator tells. Engineers in a blameless review are, in John Allspaw’s phrase, very much on the hook for helping the organisation become safer.

The diagnostic

Three questions for last Tuesday’s incident:

• Which pole was I claiming? Did I treat the incident as a human deviation or systemic condition?
• Which pole would my actual response show? Did I ask who failed? or What surprised you? Where did you have to improvise?
• Which pole does this incident actually require? If the failure was the unexpected combination of normal variability, Pole A is structurally inadequate. If it was a single clean cause with a locatable mechanism, Pole A is apt.

The exercise

Run a second-story protocol on the team’s last meaningful incident, with one constraint: spend at least half a day below the line at the gemba before the after-action review gets written up. Talk to the operators. Ask the two questions Pole B leans on: what surprised you? and where did you have to improvise?

Map what you find at four levels⁠—individual, group, organisational, cross-level⁠—without forcing a single root cause. Compare it with whatever first story the organisation had already produced. The exercise lives in noticing the gap.

A second variant for organisations with mature reviews is to place the incident on Snook’s matrix. Was the action rule-based or task-based, and was the system loosely or tightly coupled? That puts you in Designed, Engineered, Applied, or Failed. Snook’s theory predicts the work leading up to it sat in Applied without anyone seeing it, and that the incident is the slide into Failed. Naming the quadrant tells you which way the drift is running, and whether the remedy you are about to write starts the next lap.

Going upstream

In-text: the primary sources named in the body. For the Old View / New View frame, and for the dismantling of Heinrich’s triangle and the accident-proneness data: Sidney Dekker, The Field Guide to Understanding ‘Human Error’. For the multi-level anatomy and practical drift: Scott Snook, Friendly Fire. For the upstream mechanism, structural secrecy (with the production of culture and the culture of production, the other two forces in her Challenger analysis): Diane Vaughan, The Challenger Launch Decision.

Also touched: For the 18-point statement of the New View, including the no-root-cause and increased-coupling points: Richard Cook, How Complex Systems Fail. For the cultural toolkit⁠—reporting, just, flexible, learning subcultures⁠—and for the Swiss cheese model itself: James Reason, Managing the Risks of Organizational Accidents. On blameless review and the engineer as the person on the hook: John Allspaw, Blameless PostMortems and a Just Culture. On the negotiability of the just-culture line: Sidney Dekker, Just Culture. For the simple-stories habit of carrying two more stories: Jennifer Garvey Berger, Unlocking Leadership Mindtraps.

Go deeper: the convergence pile-ups and further reading. The no-single-root-cause claim arrives from several traditions beyond Cook and Snook⁠—Juarrero, Woods et al., and Hollnagel⁠—each naming it differently. For the second story, sharp-end / blunt-end, Westrum’s pathological / bureaucratic / generative typology of organisational cultures, and interface as line of demarcation for blame (after Kelly-Bootle, 1995): Woods, Dekker, Cook, Johannesen, Sarter, Behind Human Error, second edition. For the line of representation this chapter adapts: Cook, Allspaw, Woods et al., STELLA Report. For the GEMS / skill-rule-knowledge error taxonomy: James Reason, Human Error, and Jens Rasmussen’s SRK framework, carried in Behind Human Error. For the philosophical foundation, enabling constraints and the fail-safe / safe-fail choice: Alicia Juarrero, Dynamics in Action, developed in chapters 7 and 8. For negative capability, the capacity to remain in uncertainty without an irritable reaching after fact and reason: John Keats’s December 1817 letter to his brothers. Watch. Sidney Dekker, Safety Differently (2018 lecture, 33 min); software-native companion, John Allspaw, How Your Systems Keep Running Day After Day (DevOps Enterprise Summit 2017, 33 min). Read. Sidney Dekker, Drift Into Failure; Erik Hollnagel, Safety-I and Safety-II; Todd Conklin, Pre-Accident Investigations; James C. Scott, Seeing Like a State; W. Edwards Deming, The New Economics, on variation.

I work with CTOs and CPOs at software companies with roughly 50–500 engineers on exactly this kind of paradigm work. If it’s live for you, I’m happy to talk: schedule a 30-minute virtual coffee at hi.chrisgagne.com. If it’s live for someone you know, pass this chapter on.

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 incident counter your team reports up reads zero, and you take that for safety, when all it records is the absence of whatever got counted. It stays silent on how the work goes right on the ordinary days, which is what keeps you safe. In chapter 15, you turn from the incident-level call to the system-level question of what the organisation counts as safety. You set safety as absence against safety as presence and look for what a leader would measure in its place.