Principle · Operations
Theory of Constraints.
Source: Eliyahu M. Goldratt, The Goal: A Process of Ongoing Improvement (1984), North River Press.
The Principle
Every system has a constraint. The throughput of the entire system is set by the slowest step, not the average step. Improvements to any non-constraint step do not increase throughput. They produce more work-in-progress that piles up at the constraint. The Theory of Constraints says: find the constraint, exploit it, subordinate everything else to it, then elevate it. After it is no longer the constraint, find the next one. Repeat forever.
The five focusing steps: (1) Identify the constraint. (2) Decide how to exploit it. Make sure the constraint is never idle and never wasted on work that does not need to pass through it. (3) Subordinate everything else to that decision. Other steps run at the pace the constraint can absorb, even if they could run faster. (4) Elevate the constraint. Add capacity, automate, redesign. (5) If the constraint moves, do not let inertia keep your attention on the old one. Go back to step one.
The counter-intuitive part is the discipline of slowing non-constraints down. Most teams optimize whatever step they can see, which produces local efficiency and global slowness. A factory floor full of busy machines and growing piles of inventory is the classic symptom. The constraint, not the average, is the only number that matters.
Why It Matters Here
Operations is where the constraint actually lives. Sales can promise more, marketing can generate more demand, product can imagine more, but throughput is set by the operational step that cannot keep up. The COO's job is to know which step that is, name it out loud, and protect the team from the temptation to optimize anything else. Without this principle, operations becomes a long list of "improvements" that look productive and produce no additional throughput.
Signals (When to Apply)
- Work-in-progress is piling up in front of one step in a workflow
- The team is busy everywhere but throughput is not increasing
- Different team members are recommending different fixes, and each one is fixing a different step
- An automation or new tool is being proposed for a step that is not the bottleneck
- The same delay shows up in delivery week after week, regardless of how hard the team works
How to Apply
- Identify the constraint by looking at where work piles up. The bottleneck is the step with a queue in front of it. The queue is the signal, not the rumor or the loudest complainer.
- Exploit it before elevating it. Make sure the constraint never sits idle. If it is a person, protect their time from anything that is not the constrained work. If it is a tool or step, schedule it for maximum utilization.
- Subordinate the rest of the system. Other steps run at the pace the constraint can keep up with. Faster work upstream creates inventory, not throughput. Slower work downstream creates idle constraint, which is worse.
- Elevate only after exploit is fully done. Adding capacity to a constraint that is already not fully used is wasted spend. Make the existing constraint produce its theoretical maximum first.
- Re-check after every elevation. The constraint moves. The team's reflex is to keep working on the old one because that is what they know how to do. Discipline yourself to look again.
Examples
Applied well
A consulting firm has a six-week delivery cycle. The COO traces every project and notices that proposals get written in two days, kickoffs happen the next week, and then projects sit for three weeks waiting for the senior consultant to do the deep analysis step. That step is the constraint. The fix is not to hire more salespeople or generate more leads. It is to protect the senior consultant's calendar from anything that is not deep analysis, and to start documenting the analysis pattern so a junior can do the first pass. Throughput goes from four projects per quarter to six within two cycles.
Misapplied
The same firm hires two more salespeople because the founder believes the bottleneck is "not enough leads." Lead volume doubles. Proposals double. The senior consultant is now buried under twice as many waiting projects. Delivery time goes from six weeks to ten. Customer satisfaction drops. Revenue per quarter does not change because the constraint did not move. The non-constraint got faster. The constraint got worse.
When to Break It
- In businesses where the constraint is so obvious it does not need formal identification, and the team can fix it without ceremony. Use the discipline lightly when the answer is already clear.
- During strategic shifts where the entire system is being redesigned. The current constraint may be irrelevant in the new design. Build the new system first, then find its constraint.
- When the constraint is external (a market, a regulator, a supplier you cannot replace). Fixing internal steps will not help. Recognize external constraints and design around them.
Further Reading
- Eliyahu Goldratt, The Goal (1984). The novel that introduces the theory.
- Eliyahu Goldratt, It's Not Luck (1994). The follow-up applied to broader business problems.
- Eliyahu Goldratt, Critical Chain (1997). Theory of Constraints applied to project management.
- Gene Kim, Kevin Behr, George Spafford, The Phoenix Project (2013). The same theory applied to IT and software delivery.