Inertia and Constraint Moves
also Don't let inertia become the constraint · Check if the constraint moved
The warning that once you raise the limit at one bottleneck, the constraint shifts elsewhere, so you must re-identify it rather than keep running on policies that no longer fit.
This is the fifth of the five focusing steps: after you have optimized and, where needed, added capacity to elevate the constraint, check whether the constraint has moved. If a different link is now the weakest link, you must loop back through the steps and re-focus on the new one rather than keep applying the rules built around the old bottleneck.
Goldratt’s explicit warning is against inertia — letting yesterday’s solution harden into permanent policy. Rules made to protect a former constraint can become the very thing that limits the system once the constraint has shifted. So the inertia trap is not the original constraint at all; it is the obsolete habit of subordinating everything to a link that no longer constrains throughput.
CF frames this as a case of treating improvement as a process of ongoing improvement that is inherently self-correcting. There is always a weakest link somewhere; solving one bottleneck exposes the next, so the work never finishes. Clinging to a past fix is itself an error to watch for — a refusal of error correction dressed up as a settled answer.
The step also cautions restraint: a system should have a known, reasonably stable constraint planned around, not one that thrashes between links. You re-run the steps when a genuine improvement has moved the limit, not on every fluctuation. The discipline is to keep checking, treat your current policies as tentative, and discard them when the real constraint relocates.