Question
Why can a solution that looks correct at the point of intervention make the wider system worse?
Current position
Because the visible problem is often an effect of relationships across a system. A change can improve one metric while shifting cost, delay, risk or work to another part of the system.
Observation
A process can be locally efficient and globally inefficient. A team may reduce its own processing time by pushing incomplete work downstream. A product may increase applications while increasing operational load or worsening the quality of the applicant pool. The first metric improves, but the whole system may not.
Hypothesis
When an intervention targets a visible symptom without modelling dependencies and feedback, its benefits are likely to be incomplete or unstable. The risk increases when teams optimise separate metrics, information arrives late, or consequences appear outside the measured boundary.
Model
A useful diagnostic loop is: define the outcome → map the boundary → identify dependencies and incentives → predict second-order effects → intervene → measure the whole-system result → revise the model.
Example
Imagine a digital application flow with a high drop-off rate. Removing a step may increase completion. But if that step collected information needed for eligibility or fulfilment, the apparent gain may create more manual review, errors or later abandonment. The right question is not simply “Did completion increase?” but “Did the end-to-end system produce a better outcome at an acceptable cost and risk?”
Limitations
This is a diagnostic heuristic, not a universal law. Some problems are genuinely local; some interventions have predictable direct effects. Systems maps are models, not complete copies of reality. Their usefulness depends on evidence, scope and revision.
Implication
Before changing a component, state the outcome to optimise, the boundary of the system, the metrics that could move, and the guardrails that must not deteriorate. Then check the consequences after the change.
Open question
How can a team choose a system boundary that is broad enough to capture important side effects without making every decision impossibly complex?