thinking-theory-of-constraints

Compare each stage on utilization, queue length, and throughput. The binding constraint shows near-100% utilization, the longest queue, and the lowest stage rate, and adding input elsewhere does not raise system output.

Identify the constraint with evidence, exploit it without major spend, subordinate all other stages to its rate, elevate capacity only if still short, then recheck because the constraint often moves after improvement.

Avoid it when load is spread evenly with no dominant stage, when the problem is correctness or faults rather than flow rate, or when the bottleneck hops every run due to coupling. Those cases call for systems thinking or debugging instead.

System output is capped by the constraint, so speeding other stages only grows work-in-progress queues before it. Local utilization gains on non-constraints do not change end-to-end rate and often add waste.

Elevate only after exploitation is exhausted—idle time removed, nonessential work dropped, rework reduced. Then invest in capacity such as people, tooling, or sharding, choosing the cheapest adequate option, and remeasure all stages afterward.