Only optimize the constraint — verify that improving a loop component would increase total system throughput before investing effort

Why This Is a Rule

Goldratt's Theory of Constraints (TOC) establishes that in any system, only one component is the constraint — the bottleneck that limits total throughput. Improving any non-constraint component produces zero system-level improvement because the constraint still limits the whole system. This is the same principle as When performance is stable with no bottleneck, stop optimizing and move effort to a different system (stop optimizing stable non-bottleneck systems) applied specifically to feedback loops.

In a feedback loop, the constraint is the node that limits how fast or effectively the loop cycles. In a "write → publish → get feedback → improve → write" loop, the constraint might be publishing speed (you write faster than you publish), feedback quality (you publish but get no useful feedback), or improvement integration (you get feedback but don't integrate it). Optimizing writing speed when publishing is the constraint produces more unpublished material without increasing the loop's throughput.

The diagnostic is simple: "If I doubled the capacity of this component, would the loop produce more output?" If yes → it's the constraint. If no → something else is limiting the system, and your optimization effort would be wasted here.

When This Fires

• Before investing effort in improving any component of a feedback loop
• When loop optimization isn't producing system-level improvement — you're probably optimizing a non-constraint
• When deciding which of several possible improvements to prioritize in a loop
• Complements Strengthen virtuous loops through one lever at a time: reduce friction, increase gain, or shorten cycle time (strengthen reinforcing loops) with the diagnostic for where to apply the intervention

Common Failure Mode

Optimizing the easiest component rather than the constraint: "Let's improve our data collection because that's straightforward." If data collection isn't the constraint (maybe it's analysis speed or decision implementation), improving it produces better data that piles up waiting for analysis. You've invested in a non-constraint while the actual bottleneck remains unchanged.

The Protocol

(1) Map the feedback loop: identify each component and the flow between them. (2) For each component, ask: "If I doubled this component's capacity, would the loop cycle faster or produce better output?" (3) The component where doubling capacity would most increase system throughput is the constraint. (4) Optimize only that component. Use the three levers from Strengthen virtuous loops through one lever at a time: reduce friction, increase gain, or shorten cycle time (reduce friction, increase gain, shorten cycle time) applied to the constraint specifically. (5) After improving the constraint, re-assess: the constraint has likely moved to a different component. Repeat the diagnostic. (6) The constraint moves with each improvement. This is expected — it means the system is improving. Follow the constraint.