Local Optimisation Hurts
Every team hit its target. Why did the whole thing get slower?
The idea
Improving one part of a system in isolation often makes the whole worse by shifting work elsewhere.
In the real world
A team hits its own throughput target by pushing rework downstream.
Going deeper
A local metric with no accounting for downstream cost will be met by exporting work rather than by improving the whole. This is what measurement does, and it is not a failure of the people being measured.
Development doubling its release rate while QA and support drown is the canonical case: the target was hit exactly as specified, and total delivered value fell. The error is upstream in the metric design. Asking who absorbs the cost when this number improves usually identifies the problem before it is deployed.
Where it stops applying
End-to-end metrics are slow, noisy and hard to attribute, which is why local ones exist. The practical answer is usually a local metric paired with a guardrail on what it can damage.
Why it matters
It explains how every department can hit its numbers while the organisation performs badly.
Try this today
For one team metric, ask who absorbs the cost when it improves.
Test yourself
Development doubles its release rate and hits target. Support and QA are overwhelmed and total delivered value falls. Was development wrong?
Show the answer
They optimised what they were measured on, which is what measurement does. The error is upstream: a local metric with no accounting for the cost imposed downstream will reliably be met by exporting work rather than by improving the whole.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.