Russell Ackoff liked to “build the best car in the world” as a teaching example. Take one of every make sold in America, he said, and have your engineers pick the best of each part: the best engine, Rolls Royce; the best transmission, Volvo; the best alternator, Porsche; the best of every component a car needs. Now bolt those best parts together into one automobile. You would not get a functional automobile.
The performance of a system is not the sum of the performance of its parts. It is the product of how those parts interact, which means you can improve every part on its own and wreck the whole doing it with far less effort or neglect than you might have expected.
Eli Goldratt put it in a sentence: a system of local optimums isn’t an optimum system at all; it is a very inefficient system. The implication is huge. The way most senior leaders structure improvement work—every department on its own metric, optimised in parallel, the whole supposedly improving as the sum—is the wrong move in any system whose parts share constraints.
Plan as hypothesis was chapter 7‘s move. This chapter asks where in the system that hypothesis should concentrate, because most organisations optimise every function in parallel and get less throughput for the effort.
🎧 Prefer to listen? This chapter is narrated in my own voice with ElevenLabs on Spotify (~28 minutes). Listen on Spotify.
The two poles
Pole A: local optima. Improve each department on its own metrics. The whole will improve because it is simply the sum of the parts. Run the function-level reports; reward the function leaders who move their numbers; trust composition.
Pole B: system constraint. Identify the one constraint that limits the whole. Exploit it. Subordinate everything else to it. Decide what will raise throughput, and protect it. There is a greater wholeness that is more than just the parts; it emerges when those parts interact.
Pole A is right in some contexts, while Pole B is the operational discipline most engineering leaders need to recover. Both depend on one deeper claim: a constraint helps organise the system.
Where Pole A is right
Pole A is right only when the system genuinely decomposes. That includes independent product lines with no shared engineering and separate geographies running their own supply chains. Decoupled value streams with no shared bottleneck resource also qualify. The clearest case is low-variability work run in independent operations whose bottlenecks do not interact, so optimising each step in isolation adds up to a better whole.
Most senior leaders inherit Pole A from a time when their mandate was smaller and easier to decompose, and the local metrics genuinely did roll up. The reports were honest then. The discipline you built while running departmental P&L reports got you here; none of it was wasted. The question is whether that discipline still fits the system you run now.
In contemporary knowledge work (most software, product development, and cross-functional services), operations rarely decompose so cleanly. The output of resources and people pass through shared bottlenecks, as do queue capacity and management attention (even when the org chart hides them). Most systems that leaders expect to break into independent parts will not.
Where Pole B is right
Pole B is right where events depend on prior events and demand varies. In Goldratt’s manufacturing context, improving local efficiency on non-bottleneck resources reduced total plant throughput by pushing more work onto the bottleneck and consuming time that could not be recovered.
Deming’s funnel experiment reaches the same result for stable production processes. Tampering with common-cause variation increases the variance. An operator who adjusts the funnel after each ball lands produces a wider distribution than one who leaves it alone. Local correction makes the whole system less stable.
Pole A leaders set utilisation targets per function and ask whether each function is fully booked. Pole B leaders ask which one resource is governing how fast the whole system can move today, then protect it. Their rigour lies in subordination: they choose what can wait so the constraint can work.
CTOs and VPEs: the constraint question lands on the CEO’s desk because capital and organisational structures ultimately start there. Put the actual constraint in front of your CEO (the one resource, decision, or capability governing the speed of the whole engineering system), alongside the current investment split across functions. The CEO then authorises the subordination of non-constraints, usually by defending the Pole B investment against pressure from other function heads whose metrics suffer when their resources serve the constraint instead of their own dashboards. The five focusing steps force a CEO-level choice about which function’s metric is allowed to wait. Your CEO can carry that choice to the board in one sentence: “One constraint sets our speed; every other optimisation is spend without resulting in throughput improvements.”
Goldratt’s five focusing steps
The Theory of Constraints has an explicit working procedure. First, identify the constraint. Second, decide how to exploit it, squeezing every useful hour from the bottleneck before adding capacity. Third, subordinate everything else to that decision, so non-constraints serve the constraint’s pace instead of their own. Fourth, elevate the constraint by adding capacity once exploitation is maxed. Fifth, return to step one because the constraint will move as soon as you fix the current one.
Goldratt wrote the warning in step five in capitals, and most retellings drop it: go back to step one, but do not allow inertia to become the system’s constraint. Yesterday’s exploitation rules and subordination policies can outlive the constraint they were built for. They harden within weeks, quietly becoming the new constraint.
The five steps give TOC its working sequence and make Pole B operational. In software development, the single-backlog move later in this chapter is often the most consequential application. Step five also carries this book’s thesis in operational dress: the paradigm chapters apply Goldratt’s inertia warning to leadership identity, where yesterday’s fit can age into today’s constraint.
The doctrine is right as far as it goes. It usually leaves out the people whose continuous adjustments make a constraint productive.
Juarrero: constraints are causes
Alicia Juarrero’s Dynamics in Action gives Goldratt’s claim its causal basis and changes what constraint means. Juarrero’s distinctive contribution to the philosophy of action is that constraints structure action and make it possible. In a hierarchical organisation, constraints link levels by closing off alternatives at one level and opening new ones at another.
Juarrero distinguishes context-free constraints, such as loaded dice or the prior probability of e over z in English, from first-order context-sensitive constraints, such as the sharp rise in the probability of u after q appears. Her third category, the one operations leaders need, is second-order context-sensitive constraint: the closure of positive feedback creates a whole whose distributed organisation then imposes constraints on its own components, top-down.
Goldratt’s constraint, the slowest step in the system, becomes the organising principle around which the rest of the system works. It changes what is possible. Subordination recognises that the constraint helps hold the system in coherent operation.
The plant’s bottleneck sets the rhythm for everything upstream and downstream. A hospital’s emergency department is where the rest of the hospital’s flow rates are settled. On an engineering team, a senior architect may be where open design questions are forced into closure. A leader who treats the constraint only as a restriction will optimise around it; a leader who treats it as a cause will build the rest of the system to support the work it does.
Treat the constraint as a restriction and you optimise around it; treat it as a cause and you build the system to support it.
Treat the constraint as a restriction and you optimise around it; treat it as a cause and you build the system to support it.
People continuously create the structure
Juarrero’s account changes how I read the subordination step. The constraint matters because people continuously adjust around it. Practitioners hold its productive structure in place through moment-by-moment compensation for the conditions it creates. Stop that compensation and the constraint becomes a bottleneck with none of the work around it that made it useful.
An engineering manager who treats the constraint as a mechanical feature to optimise around will miss the operators’ continuous work of creating structure. The team may read that optimisation as a vote of no confidence in their judgement and scale back the small adjustments they had been making. The system then degrades in ways the manager cannot read until something visible breaks. The constraint did not get worse. The work around it did.
The constraint did not get worse. The work around it did.
The constraint did not get worse. The work around it did.
People continuously create the productive structure around the constraint. Pole B asks leaders to identify the constraint and name what practitioners already do to make it productive, then protect that work from optimisation programmes that would interfere with it.
Snook: the fallacy of social redundancy
Scott Snook’s Friendly Fire shows how social redundancy can make a system unsafe. He studies the 1994 Black Hawk shootdown over northern Iraq, where U.S. F-15 fighters shot down two U.S. Army helicopters while an AWACS aircraft watched, killing twenty-six. The AWACS had nineteen crew members. “More people looking over shoulders than there were shoulders to be looked over.”
Snook calls the operating assumption the fallacy of social redundancy. His reasoning starts with an engineering analogy and ends with its social inversion. Technical systems add redundant components to cut the chance of an accident, but the group dynamics of the shootdown led Snook to conclude that two controllers need not beat one, and four leaders can be worse than two. Technical redundancy assumes that components are independent. People are interdependent, so adding more of them can diffuse responsibility, the Latané and Darley’s bystander mechanism named in a different domain forty years earlier.
Pole A usually answers a near-miss with more oversight: reviewers, approvers, and escalation paths. Snook argues that this can make the system less reliable. Adding watchers will not exploit the constraint. Clear ownership will, especially when leaders protect the people who hold it.
Team-level backlogs are local optimums that cap revenue
A bottleneck step, a senior architect, and an AWACS crew all make the constraint visible as a resource, person, or team. Engineering leaders meet another form every day without recognising it: several backlogs where the product needs one.
I first met this pattern in a short film by Michael James, a Scrum trainer whose work I keep sending to clients. James traces the idea to Bas Vodde and Craig Larman’s work on Large-Scale Scrum (LeSS). When an organisation scales from one team to many, it usually gives each team someone to act as product owner, then quietly asks that person to manage a team backlog and grow team output. James calls this deviation a “team output owner” because output is what the organisation rewards with its design, if not its platitudes.
Each team output owner orders a private list to deliver the most value they can see, and each is doing thoughtful, careful work. The system sets the trap. “Keeping separate team backlogs, separate lists obscures this problem,” James says. “Our team’s top priority is less important than the work other teams don’t even have time to start.” Vodde and Larman’s remedy in LeSS is a single product backlog, one Product Owner with real authority, and teams that self-select from the shared ordering. The arithmetic makes the cost plain.
Imagine three teams, each able to ship three items in a sprint, with each team working from its own backlog. Team one has items worth $100, $90, and $80 at the top, followed by $70, $60, and $50. Team two has $30, $20, and $10. Team three has three $10 items. With three owners and three lists, each team ships its own top three: team one delivers $270, team two $60, and team three $30. The organisation delivers $360. Every team is busy, and every team is shipping the best work on its list.
Pool those lists and choose nine items for the whole product. The top nine are $100, $90, $80, $70, $60, $50, $30, $20, and $10. The same nine slots of capacity now deliver $510, with the same people working at the same pace. Pooling drops the three $10 items that team three would have shipped and uses those slots for team one’s stranded $70, $60, and $50. The extra $150 was sitting below a line drawn by the org chart while team three shipped small change because small change was the best work it could see. Goldratt’s sentence describes the prioritisation layer as exactly as it describes the plant floor: a system of local optimums isn’t an optimum system.
I did not want to trust a toy example on its own, so I built the measurement into the delivery-intelligence tool my client teams run against their backlogs. For every story, it forecasts three completion-date ranges from the same points-over-velocity arithmetic, using three widths of pooling, each range running from a P70 to a P95 date rather than a single point. A Team ETA uses one team’s throughput. A Capability ETA uses every team in the capability, while a Value Stream ETA uses the whole value stream. The wider pool ships high-value work sooner for the same reason the pooled backlog beat the three private ones.
The tool also flags the failure directly. When a story’s Team ETA is meaningfully sooner than its Capability ETA, the tool marks it as a local optimum: fast on its own list, but sitting where the most valuable work is not. The mark fires more often than I would like, and every instance is a small, measured version of the $360 that should have been $510. It is a bounded alarm. Where work is genuinely team-local, the Capability and Team ETAs agree and no mark fires, which is what makes the flag worth reading when it does.
Broad interchangeability is closer to the ideal than the usual objection admits. Larman and Vodde’s LeSS deliberately encourages more multi-learning and a higher proportion of feature teams, treating single-specialist teams as a pattern to grow out of. A team that can pull any high-value item is therefore the condition worth building toward. Teams do not have to become identical tomorrow. They keep their skills, context, and sense of a shippable whole, but they self-select from one prioritised list instead of grinding through a private one. Collaboration across a team boundary becomes part of a developer’s job rather than a coordinator’s, and the system begins to reward the multi-learning that makes the next item pullable. In this case, the ordering itself is the constraint. Fragment that ordering into per-team lists and the system manufactures a local optimum at the exact point where it should decide what to build next, the most expensive place to put one.
A representative example
Picture a platform team whose senior architect is the obvious constraint. Every significant design question routes through her, and her calendar is solid for eight weeks. The engineering director responds by hiring a second senior architect to “share the load.”
Throughput falls. After three months, the first architect is spending time coordinating with the second on questions she once answered herself. The team escalates to both of them. Other engineers sense that someone is now responsible for everything and scale back the small, fast decisions they once made on their own. The constraint has been exploited badly. Hiring was the obvious local move and the wrong system move.
The fix is unglamorous. The first architect’s role is renamed, and her decision remit is narrowed to three specific architectural axes where the team needs her critical judgement until they can learn more from her about why she makes the decisions she does. The second architect moves to a different team. For every design question outside those three axes, the other engineers have authority to decide and ship; they bring decisions to the architect after making them.
Throughput recovers within a sprint. The architect’s calendar opens by two days a week, and the team’s confidence in its own decisions returns. The constraint is unchanged (the architect’s judgement on three specific axes), but the system around her now protects the team’s ongoing decision-making instead of interfering with the work only she can do.
In the vocabulary of the five steps, hiring was step four, elevate, run before steps two and three. The working fix uses exploitation and subordination through a policy change, with no new capacity. That is The Goal‘s signature result and the rule worth keeping: elevation is the last resort, and the reflex to elevate first is the reflex the five steps exist to interrupt.
Honour what the hire was trying to do. The engineering director sees a stressed senior architect and asks an obvious, humane question: how do I take work off her plate? Pole A answers by hiring another architect, a defensible act of care for one person. Pole B asks what the system has stopped asking of the rest of the team because she is doing it. Both questions are legitimate. The first adds complexity and cost but cannot repair the system on its own.
The diagnostic move
Use three questions for last Tuesday’s improvement-programme meeting.
- Which pole was I claiming? When we discussed where to invest in improvement, did I name the constraint, or did I list the function-level metrics each leader had agreed to move?
- Which pole did the improvement programme actually run? Look at the resourcing. How much investment went into the constraint, and how much went into improvements that bypass it? Most programmes I see run the second pattern even when their leaders speak the first language.
- Which pole does the system require? Pole A is sound when the work genuinely decomposes into separate product lines or geographies. When resources, attention, queues, and decisions pass through shared bottlenecks, Pole A produces the inefficiency it is trying to solve.
Start where the three answers diverge.
The exercises
The character factory game
Take five minutes with your team. You have three customers (Letters, Numbers, Vowels), and each wants a complete set of 26: the full alphabet, the numbers 1 to 26, or the vowels repeated out to 26. No customer is happy with a partial set; 25 of 26 is worth nothing. Fold a sheet of paper into three columns, one per customer, and use one side per round, a minute each.
Round one: keep every customer moving at once. Work across the columns (A-1-A, B-2-E, C-3-I), writing one character for each customer, round after round, so nobody waits. Stop after a minute. All three sets will be half-built, with no customer served. I have never seen anyone finish a set this way.
Round two: finish one customer, then the next. Write the full alphabet and hand Letters a complete set; write the numbers, then the vowels. Stop after a minute. You will deliver at least one finished set, usually two, and sometimes three. Your hand moved at the same speed in both rounds. The delivered value changed.
This is the subordinate step made physical. Round one treats all three customers as equal claims on the hand and finishes nothing; round two picks one, lets the other two wait, and delivers. The game makes the cost visible: two customers wait while you finish the first. That is exactly the discomfort the five focusing steps ask a leader to hold. Subordination means letting non-constraints wait, and the reflex to keep everyone moving serves nobody.
The lesson concerns how many things the system carries at once. The game produces silence, then an “oh.” Writing a, b, c, d, e is easier than a, 1, A, b, 2, E because every jump between customers asks the mind to reload a different context; real product development pays the same switching tax. A team that keeps four features half-built pays that tax every time it moves between them, so the same people ship less than they would by finishing one and then the next, with no change in effort. The character factory is a minute-long rehearsal of what a quarter of scattered work does to a team.
The game descends from Henrik Kniberg’s Multitasking Name Game; I learned the letters/numbers/Roman-numerals variant from Monica Yap and replaced Roman-numerals with repeating vowels to lower the cognitive load.
Goldratt’s Dice Game
Also consider Dice Game, sometimes called the TOC simulation. Put six stations in a line and give each station a die. Each station rolls and produces its output, which becomes the input to the next. Run twenty rounds. Track total throughput against the average die roll of 3.5.
Total throughput falls below 3.5 in almost every run, and the gap widens with each round. Variability combines with dependent events: a downstream station can pass along only what arrived from upstream, so high rolls are wasted while low rolls leave inventory between stations. Throughput falls as the piles grow. In fifteen minutes, the game makes Goldratt’s claim physical. Ask players to look at where output has piled up before you debrief; those piles are the queues the rest of this book teaches leaders to read. Engineers who have played the game once tend to stop arguing for parallel local-optimisation programmes because the inventory makes the cost hard to miss.
Identify the Brent
In The Phoenix Project, Brent is the engineer every project routes through. Most teams have someone in that role. Name yours out loud. Then ask: what would the next step be if Brent left? The answer reveals where the constraint actually is.
Going upstream
In-text: the argument leans on three sources. Eli Goldratt, The Goal (the canonical novel), gives us the five focusing steps, the claim that a system of local optimums isn’t an optimum system at all, and the step-five inertia warning. Alicia Juarrero, Dynamics in Action, Ch 9 on the three orders of constraint, supplies the claim that constraints are causes. Scott Snook, Friendly Fire, Ch 4, names the fallacy of social redundancy.
Watch. Eli Goldratt, Lectures: Thinking Globally (10 min). Its companion on constraint physics is the Theory of Constraints (TOC) 3 Bottle Oiled Wheels Demonstration (5 min).
On the backlog as local optimum, watch Michael James, Benjamin R. Leffler & Yoko Hinoue, How Misconceptions About the Product Owner Role Harm Your Organization (video, 9 min), for the team-output-owner pattern and the single product backlog as its remedy.
Also touched: Eli Goldratt, The Choice, on the four obstacles to clear thinking, and W. Edwards Deming, Out of the Crisis, on common-cause variation and the funnel experiment.
Craig Larman & Bas Vodde, Large-Scale Scrum, give the single-product-backlog remedy and the structural argument against per-team backlogs. I first met that argument by way of Larman’s CLP/CLE course.
Go deeper: two other traditions make the same operational claim, and both are developed at length elsewhere in the book. Richard Cook, How Complex Systems Fail, Points 16 and 17, treats safety as emergent and created through people’s continuous adaptation (Chapter 15 develops this and its inversion under AI). USMC, MCDP-1 Warfighting, Ch 4, gives the main effort and Schwerpunkt, the same subordination discipline in doctrinal dress. For the systems-archetype reading, see Peter Senge, The Fifth Discipline, especially shifting the burden and the tragedy of the commons.
Subordinating everything to the constraint pays only when that constraint drives the right number. Output and outcome differ. An engineering organisation can raise throughput every quarter while the people paying for its software feel no change. That gap is where a feature factory lives, and chapter 9 asks which number your work is actually judged on.
Leave A Comment