Suboptimization: When Local Improvements Harm the Whole System

“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"

"Value stream maps provide an effective means to establish a strategic direction for making improvement. 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.”

Value Stream Mapping by Karen Martin and Mike Osterling.

I’ve seen this happen multiple times, for example: an infrastructure team automates deployments to reduce rollout time from weeks to days, but doesn’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 an unplanned investment, and can be a positive outcome, if the team learns from it, continues investing in monitoring, alerting, and making the automated deployments more robust. It’s not a reason not to automate deployments. Manual deployments are more error prone, slower, leading to bigger batches, which lead to more errors which are harder to fix, more unplanned work for the team and ultimately worse customer outcomes.