Suboptimization: When Local Improvements Harm the Whole System
“If we can only improve what we can see and we can only see a subset of the overall flow of work, all our effort could be wasted in comparison to addressing the weakest link in the chain of activities. If our visibility is limited to a subset of the work process, we will direct improvement efforts there. But if we fail to address the real constraint, our targeted improvements won’t matter at best and could make things worse.”
”Suboptimization occurs when you make an improvement to one part of a system while ignoring the effects of that change on the other components. A seemingly important improvement could cause the overall work system to perform more poorly. For example, if one department successfully improves turnaround time, but the faster output merely causes a larger queue and/or more work for the downstream department, the improvement may have a negative impact on the performance of the overall system"
"The inclination to jump into the weeds and design micro-level improvements before the entire work system—the macro picture—is fully understood, is a key contributor to suboptimization.”
Have you seen this in the wild? An infrastructure team automated deployments to reduce rollout time from weeks to days, but didn’t update the monitoring and rollback systems accordingly, or introduce alerts, resulting in critical bugs staying in production longer before being detected and corrected, negatively impacting the customer, and creating unplanned work for the team.
The production problems are not a reason not to automate deployments. Manual deployments are slower, more error prone, leading to bigger batches, which makes errors harder to fix, leading to more unplanned work for the team and ultimately worse customer outcomes.