# Theory of Constraints ## The Idea in Brief Every system has exactly one bottleneck that limits its output. Fix that one, and everything improves. Fix anything else, and nothing changes. The discipline is resisting the urge to optimise everywhere at once—which feels productive but wastes effort on non-constraints. --- ## Key Concepts ### The Constraint Is the System A chain is only as strong as its weakest link. Strengthening any other link is pointless until you fix the weakest one. Most organisations spread improvement effort across dozens of initiatives simultaneously, which guarantees that the actual bottleneck stays bottlenecked. The constraint can be physical (machine capacity, a slow approval process) or policy-based (a rule that seemed sensible once but now blocks flow). Policy constraints are often harder to see and harder to change. ### The Five Focusing Steps Goldratt's method is almost embarrassingly simple: **Identify** — Find the bottleneck. Where does work pile up? What's everyone waiting on? **Exploit** — Maximise what you can get from the constraint without major investment. Don't let it sit idle. Prioritise its workload. Remove anything that wastes its time. **Subordinate** — Align everything else to support the constraint. Other processes should run at the pace the constraint can handle, not faster. Overproducing elsewhere just creates inventory and confusion. **Elevate** — If exploiting isn't enough, invest to increase the constraint's capacity. Buy more, hire more, redesign. **Repeat** — Once you've fixed this constraint, a new one will emerge. The work is never done. ### Why Local Optimisation Fails When each department optimises for itself, the system as a whole suffers. A fast sales team overwhelms a slow fulfilment team. A rapid engineering pace outstrips a slow approval process. The gains evaporate in the handoffs. System performance is set by the constraint. Everything else is noise. --- ## Implications **In operations:** Stop trying to improve everything at once. Find the bottleneck. Focus there. Measure progress by system throughput, not local efficiency. **In product development:** The constraint is often not engineering. It's decision-making, or requirements clarity, or deployment. Speeding up code without addressing the real bottleneck just creates idle inventory (finished work waiting for approval). **In your own work:** What's the one thing that, if faster, would unlock everything else? That's your constraint. Work on that, even if other things feel more urgent. --- ## Sources - [[The Haystack Syndrome]] — Goldratt on information management; the constraint is often not having the right data, but having too much - [[The Choice]] — TOC as a thinking process, not just a manufacturing technique - [[The Fifth Discipline]] — Systems thinking complements TOC; constraints are leverage points - [[The Logical Thinking Process]] — Dettmer's systematic method for applying TOC through logic trees --- ## See in Notes - [Hidden Bottleneck](https://www.anishpatel.co/hidden-bottleneck/) — The constraint isn't execution speed, it's decision speed. Externalise the logic. - [Capacity and Flow](https://www.anishpatel.co/capacity-and-flow/) — Flow as system property: WIP discipline, finishing bias, and variety reduction - [Marginal Gains, Marginal Returns](https://www.anishpatel.co/marginal-gains-marginal-returns/) — Why the 1% everywhere philosophy fails in serial systems