Goodhart's Law
When a measure becomes a target, it ceases to be a good measure.
To an executive
Once a number becomes a target, people find ways to hit it that do not deliver what it stood for. Reports can look healthy while the real result slips.
To an engineer
Treat metrics such as coverage or migration counts as proxies. Pair each with an outcome measure, and watch for teams hitting the number the cheapest way.
The idea
The economist Charles Goodhart observed, in the context of monetary policy, that a statistical relationship tends to break down once it is used as a target for control. The anthropologist Marilyn Strathern later gave the idea its well-known form while writing about audit culture in British universities: when a measure becomes a target, it ceases to be a good measure.
The reason is simple. A metric is useful because it moves with something you care about. Once people are rewarded for moving the metric, they find ways to move it that do not move the thing it stood for.
Architecture metrics are especially vulnerable: services migrated, APIs published, test coverage, percentage of workloads in the cloud, number of decisions recorded.
Why it works
Metrics are proxies. Test coverage stands in for confidence in the code; migration counts stand in for modernisation. A proxy and its outcome only move together while nobody is pushing on the proxy alone.
People are good at hitting targets. Give a capable team a number and they will reach it, often by the cheapest route, which is rarely the route you intended.
Gaming hides the signal. Once a metric is being managed, it stops warning you when things are going wrong, because it looks fine.
Where it applies
- Transformation programmes measured by counts, such as applications migrated or services created.
- Engineering metrics like test coverage, velocity or deployment frequency used as team targets.
- Architecture governance, where compliance scores can be met on paper.
- Vendor and outsourcing contracts with SLAs that can be satisfied while users suffer.
How to apply
- Start from the outcome. Write down what you actually want to improve before choosing a metric.
- Ask how it could be gamed. For each proposed target, describe the cheapest way to hit it without helping.
- Pair metrics that balance each other, such as deployment frequency with change failure rate, or migration count with cost per transaction.
- Use metrics to start conversations, not to rank teams. Look behind the number regularly.
- Retire and replace metrics once they stop reflecting intent.
Example scenario
A cloud programme set a target of "percentage of applications migrated". Teams lifted and shifted the easiest applications first, reported strong progress for a year, and the programme hit most of its target while infrastructure costs rose and delivery speed did not change.
The architecture team proposed replacing the single target with a small set of outcome measures: cost per transaction, deployment frequency and change failure rate for each migrated application. Teams started refactoring the applications that would benefit most, even though the raw migration count grew more slowly.
Questions to ask
- What behaviour will this target encourage, including behaviour we don't want?
- How could a team hit this number without improving anything?
- Which outcome are we really trying to improve, and how will we see it?
When not to use it
- Measures that are not targets. Metrics used purely for observation, with no reward attached, are less exposed to gaming.
- Direct measures of the outcome itself. When the metric is the thing you want, such as customer-reported outages, pushing on it is fine.
How it misleads you
Refusing to measure anything. Without numbers, decisions fall back on opinion and loudness. Use metrics as signals and conversation starters, not as targets on their own, and keep checking that they still track the outcome.
In the wild
Further reading
Last reviewed · Suggest an improvement