The constraint that throttles the system
Theory of Constraints (ToC) states that any process has one weakest link, and the system's throughput is limited by that single constraint. In a manufacturing line, it might be the slowest machine. In a software team, it might be code review capacity or infrastructure deployment time. In sales, it might be territory coverage or qualification bandwidth. The constraint is not always obvious because the organization has learned to work around it unconsciously.
Improvements to non-bottleneck steps produce zero impact on overall throughput. If a team processes customer onboarding in 4 steps and step 2 is the constraint, optimizing steps 1, 3, and 4 has no effect. The team still processes customers at the step-2 rate. This is why local optimization often fails: teams improve what they can see, not what limits the system.
The cycle of continuous improvement
Identifying the constraint requires data: measure cycle time for each step, find the step where work queues up or where cycle time is highest. Once identified, focus all improvement effort on breaking that constraint. Add capacity, parallelize work, reduce decision latency, automate the step. When the constraint breaks, throughput jumps. Immediately a new constraint emerges, and the cycle repeats.
This is why organizations that practice TOC achieve consistent improvement without heroics. Each cycle targets the true system limiter, not local pet projects. A team that runs this discipline quarterly will find themselves continuously clearing fresh obstacles and asking different questions each quarter: first it was deployment speed, now it is QA bandwidth, next it will be product design review capacity. The constraint moves, but the system improves.