Bottleneck Theory
Why improving the constraint matters—and everything else doesn't.
1The Theory of Constraints
In the 1980s, Eli Goldratt developed the Theory of Constraints (TOC). The core insight is simple but profound:
Every system has a constraint—one step that limits the throughput of the whole.
Think of a highway: if one stretch is congested, the whole highway slows down. Widening the clear stretches doesn't help. You have to fix the congested stretch.
The same applies to value streams. If code review is the bottleneck, making development faster just creates a bigger pile at code review. If testing is the constraint, hiring more developers just means more work waiting for QA.
The system can only move as fast as its slowest constraint.
This has powerful implications for improvement: improving anything that's not the constraint is theater. It may feel productive but has no effect on overall throughput.
The Focusing Power
TOC tells you exactly where to focus: the constraint. Ignore everything else until the constraint is broken. Then find the new constraint and repeat. This prevents the common trap of optimizing everywhere without results.
2Finding the Constraint
How do you find the constraint? Look for where inventory (work) piles up.
The constraint has a pile of work waiting in front of it. If code review always has a backlog, code review is likely the constraint. If testing has weeks of work queued, testing is likely the constraint.
Other signs of constraints:
- High utilization: The constraint is maxed out
- Constant pressure: People in the constraint stage are always rushed
- Downstream starvation: Stages after the constraint are waiting for work
- Upstream frustration: "We're done, why isn't it moving?"
Common software constraints:
- Code review (too few reviewers, large PRs)
- Testing (manual QA, limited test coverage)
- Deployment (complex releases, limited deploy windows)
- Architecture decisions (waiting for the architect)
- Product decisions (waiting for the product owner)
Note: the constraint often isn't a "productive" stage. It might be a decision-maker. It might be an approval process. It might be a shared resource.
A team measures and finds work piling up at deployment. Only one person knows how to deploy. They have time for one deploy per week. Everything else waits. Solution: automate deployment and spread the knowledge. Throughput doubles.
Management sees developers 'underutilized' (90% vs. 100%) and assigns more work. Developers speed up. But deployment is the constraint—it's still once per week. Lead time doesn't improve. Inventory in front of deployment grows.
3Exploiting and Elevating Constraints
TOC prescribes a five-step process:
1. Identify the constraint: Find where work piles up.
2. Exploit the constraint: Maximize throughput through the constraint without adding resources. If code review is the constraint, prioritize reviews over new development. Make sure reviewers aren't distracted. Reduce PR size so reviews go faster.
3. Subordinate everything else: Non-constraints should serve the constraint. If QA is the constraint, don't push more work into QA—pace development to match QA capacity.
4. Elevate the constraint: If exploitation and subordination aren't enough, add capacity to the constraint. Cross-train more reviewers. Automate testing. Hire more of the constrained skill.
5. Repeat: Once you break one constraint, another emerges. The constraint moves. Find it and repeat.
This is iterative, continuous improvement. You're always focused on the current constraint, not scattered across all stages.
The drum-buffer-rope metaphor: The constraint is the "drum" that sets the pace. Work ahead of the constraint is the "buffer." The "rope" pulls work into the system at the pace the constraint can handle—no faster.
The Wandering Constraint
When you break a constraint, another stage becomes the new constraint. This is normal. But if the constraint wanders randomly (sometimes dev, sometimes QA, sometimes deploy), your system is unstable. Stabilize first, then optimize.
- Every system has a constraint that limits overall throughput
- Improving non-constraints doesn't help the system
- Find the constraint by looking where work piles up
- Exploit the constraint before adding capacity
- When you break one constraint, another emerges—repeat