When performance is stable with no bottleneck, stop optimizing and move effort to a different system

Why This Is a Rule

Goldratt's Theory of Constraints establishes that optimizing a non-bottleneck subsystem produces zero system-level improvement. If your writing process takes 2 hours and your publishing process takes 10 minutes, optimizing publishing speed from 10 minutes to 5 produces negligible total improvement. The constraint is writing — but after the writing process is optimized and running well, the constraint has moved somewhere else.

The pathology this rule prevents is over-optimization: continuing to refine a system that's already performing satisfactorily because the optimization process itself feels productive. The programmer who keeps refactoring clean code, the writer who endlessly polishes a functional draft, the manager who restructures an efficient team — all are optimizing past the point of diminishing returns because optimization feels like progress even when it isn't.

The diagnostic trigger is specific: stable performance (not declining) + satisfactory results (meeting requirements) + no identifiable bottleneck (you can't point to a specific thing that's slow or broken). When all three conditions hold, continued optimization produces effort without commensurate improvement. Move your attention to the system that actually has a bottleneck.

When This Fires

• When you've been optimizing a process and results have plateaued but you want to keep tweaking
• During resource allocation decisions about where to invest improvement effort
• When someone asks "how can we make X even better?" but X is already performing well
• During quarterly reviews when deciding which systems need attention

Common Failure Mode

Optimizing what's measurable rather than what's constrained. Your note-taking system produces clean, well-formatted notes in 10 minutes — so you optimize the template, tweak the formatting, add automation. Meanwhile, your review process (where notes get integrated) hasn't happened in months. The measurable, optimizable system gets attention because improvement is visible; the constrained, broken system gets ignored because fixing it is harder.

The Protocol

(1) Before starting an optimization cycle, check three conditions: Is performance stable (not declining)? Is it satisfactory (meeting requirements)? Is there an identifiable bottleneck? (2) If all three → stop. The system doesn't need optimization. (3) If performance is declining or unsatisfactory → optimize the bottleneck. (4) If there's no bottleneck but performance is unsatisfactory → the constraint may be structural, requiring redesign rather than optimization. (5) Redirect freed-up optimization effort to the system with the most obvious bottleneck — that's where the same effort produces the most improvement.