Theory of Constraints

The throughput of a whole system is governed by one binding constraint - its rate-limiting step - so improving anything other than that constraint does almost nothing for the system as a whole. The default improvement instinct is the opposite: make every part faster, cheaper, more utilized. This skill refuses that reflex. It treats local efficiency at a non-constraint as waste, because a non-bottleneck working harder just piles inventory in front of the bottleneck, and it concentrates effort on the one step that caps the flow while subordinating (not optimizing) everything else. The single question it forces is whether one step limits the throughput of the whole, and whether effort is aimed there or scattered. The output is a constraint-intervention plan - the named binding step plus its exploit, subordinate, and elevate decisions - not a discussion. This is the Five Focusing Steps reduced to its working core; it is deliberately scoped to the bare bottleneck move, not the full Goldratt operational systems (Drum-Buffer-Rope, Critical Chain, Throughput Accounting).

When to Use

• A system has a clear flow - a pipeline, a funnel, a queue, an approval chain, a production line - that work items pass through, and its output is capped by one step.
• Improvement effort is being spread evenly across all steps, or aimed at the loudest, most-complained-about step, instead of at the step that actually caps throughput.
• Adding resources is not lifting output ("we keep adding salespeople but revenue is flat"), which suggests the constraint is elsewhere.
• There is appetite to wring more from the limiting step before spending to add capacity.

When NOT to Use

• No single binding constraint, or an unstable or non-flow problem. This method assumes one dominant, reasonably stable bottleneck governs the system. With several co-equal limiters, a constraint that shifts faster than you can act on it, or no flow at all (a one-off decision, a design question, a values trade-off), forcing a single-constraint frame manufactures a rate-limiter that is not really binding and aims effort at the wrong place. Say so and stop.
• Coverage or "have we considered every part?" questions go to think-issue-tree. Exhaustive decomposition (every category of cause or option, nothing left out) is the inverse move; coverage is this method's failure mode, not its goal.
• Recurring or deep-structural-cause questions go to think-iceberg-model. "Why does this keep recurring, and where structurally do we intervene?" is leverage by causal depth (event to pattern to structure to mental model), which a bottleneck analysis does not provide.
• Accumulation-trajectory ("is the stock rising or falling?") questions go to think-stocks-and-flows-reasoning. Whether a quantity is accumulating up or down is a net-flow reading, a different error from locating a rate-limiter.
• Treat the identified constraint as a hypothesis to test, never as found. A wrongly named bottleneck - the loudest step rather than the binding one - sends the whole exploit / subordinate / elevate sequence at the wrong target. The method does not itself prove which step is binding; the capacity-versus-demand test does.
• Do not subordinate healthy parts to a step that was never the true limiter. "Subordinate everything to the constraint" is correct only when one constraint really governs. Applied where it does not, it starves working parts of the system to feed a step that was never the rate-limiter.