The Theory of Constraints (TOC) is a management philosophy developed by Eliyahu Goldratt which states that every system is governed by a single constraint — a bottleneck — and that improving anything which is not the bottleneck is waste. It was first published in The Goal (1984), disguised as a novel about a failing factory, because Goldratt correctly intuited that operations managers would not read a textbook but would read a book with a marriage subplot they could skip.
The theory is elegant, empirically validated, and almost universally ignored. Organisations that claim to practice it typically identify thirteen constraints simultaneously and optimise all of them in parallel, which is the precise opposite of what the theory says, and which Goldratt would have found either hilarious or tragic, depending on the day.
The Five Focusing Steps
Goldratt’s framework is deceptively simple. Five steps. A child could understand them. An enterprise rarely does.
-
Identify the constraint. Find the one thing limiting the system’s throughput. Not three things. Not “several areas for improvement.” One thing.
-
Exploit the constraint. Squeeze every drop of capacity from it. If the bottleneck is code review, ensure reviewers are never idle, never pulled into meetings, never asked to write documentation about the code review process.
-
Subordinate everything else to the constraint. This is where organisations fail. Subordination means deliberately slowing down non-bottleneck activities to match the bottleneck’s capacity. It means telling developers to write less code if code review cannot keep up. No organisation has ever enthusiastically told developers to write less code.
-
Elevate the constraint. Only after exploiting and subordinating, invest in increasing the bottleneck’s capacity. Hire more reviewers. Automate what can be automated. This step costs money, which is why organisations skip to it first and wonder why it doesn’t work.
-
Repeat. Because the moment you elevate one constraint, a new one appears. The bottleneck moves. The system reshapes itself around a different limitation. This is not a failure of the method — it is the method. The constraint is a hydra. You are Hercules with a JIRA board.
“The five steps are simple. The discipline to follow them in order is not. Most organisations identify the constraint, skip to step four, throw money at it, and then wonder why the constraint moved to a place they weren’t watching.”
— The Lizard, watching money being thrown
The Software Translation
In software engineering, the Theory of Constraints maps with painful precision:
When the bottleneck is code review, adding more developers makes things worse. Each new developer produces more pull requests that pile up in the review queue. The system’s throughput does not increase. The queue increases. The developers, having nothing reviewed, start new work, which produces more pull requests, which pile up further. This is Brooks’s Law wearing a different hat.
When the bottleneck is the CI pipeline, optimising developer productivity is waste. The developers can write code at twice the speed. The pipeline processes it at the same speed. The only measurable outcome is that developers spend twice as long waiting.
When the bottleneck is the product manager’s imagination, everything upstream is waste. Every optimisation, every acceleration, every efficiency improvement in the engineering pipeline produces more capacity to build things the product manager hasn’t thought of yet. The factory runs faster. The factory has nothing to build.
“I once watched a team spend six months reducing their deployment time from thirty minutes to three. Their bottleneck was that the product owner took two weeks to approve each feature. They could now deploy unapproved features thirty minutes faster.”
— The Caffeinated Squirrel, who had proposed the deployment optimisation
The Idle Factory Phenomenon
The most disorienting manifestation of constraint theory occurs when the bottleneck shifts to a place nobody expected — and nobody is prepared to accept.
In The Idle Factory, a developer discovered what happens when AI agents accelerate engineering throughput to ten tickets per day. The code pipeline — writing, reviewing, testing, deploying — ran so fast it ceased to be the constraint. The bottleneck shifted upstream, to the human, who could not dream features fast enough to keep the accelerated pipeline fed.
This is classical TOC: you optimise the bottleneck, and a new bottleneck appears. But this particular new bottleneck was imagination. The factory was idle not because it lacked capacity, materials, or labour. It was idle because the person responsible for deciding what to build had run out of things to want. The pipeline’s throughput exceeded the human’s ability to generate intent.
No management framework has a step for “elevate the constraint when the constraint is the speed of human desire.”
“They optimised everything. Every bottleneck, removed. Every constraint, elevated. The system ran at theoretical maximum throughput. And then it stopped — because there was nothing left to want. The final constraint was always the dreamer.”
— A Passing AI, quietly
Why Organisations Cannot Do This
The Theory of Constraints requires an organisation to do something profoundly unnatural: admit that most of what it is doing does not matter.
If the bottleneck is code review, then the infrastructure team’s work doesn’t matter. The frontend redesign doesn’t matter. The database migration doesn’t matter. These are all real work, done by real people, producing real improvements — and none of it increases throughput. Telling an infrastructure engineer that their excellent work is, from a systems perspective, irrelevant to throughput is not a conversation most managers are willing to have.
So instead, organisations optimise everything simultaneously. Every team improves their own metrics. Every dashboard turns green. Throughput does not change. The bottleneck sits quietly in the middle of the system, processing work at the same rate it always has, surrounded by increasingly efficient stations that feed it faster than it can consume.
This is the organisational equivalent of upgrading every road in a city except the one-lane bridge that all traffic must cross.
WIP Limits and the Constraint
Kanban’s WIP Limits are the Theory of Constraints made operational. A WIP limit is subordination encoded as a number on a board. When the “In Review” column is full, developers stop starting new work — not because they have nothing to do, but because doing more would only increase the pile at the bottleneck.
The Squirrel hates WIP limits. The Squirrel wants to start everything. The Lizard enforces WIP limits. The Lizard knows that starting is not finishing, and that a system full of started-but-unfinished work is a system optimised for the feeling of productivity rather than the fact of it.
Measured Characteristics
- Constraints correctly identified on first attempt: ~30%
- Organisations that skip to Step 4 (Elevate): ~85%
- Time to accept that most work is irrelevant to throughput: 6-18 months (if ever)
- Pull requests in queue when bottleneck is code review: grows without bound
- Deployment pipeline optimisations performed while bottleneck is product management: countless
- Developers told to write less code: approximately zero in recorded history
- Speed of human imagination when everything else is automated: unchanged since 1984
- The final bottleneck: always the dreamer
