When performance is stable with no bottleneck, stop…
When measurement data shows stable satisfactory performance with no identifiable bottleneck, redirect optimization effort to a different system rather than continuing to optimize the current one.
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.