A team is measured on "bugs closed." Within a month, the bug count is at an all-time low. The team has not stopped having bugs. The team has stopped logging bugs that look hard to close. They reclassify ambiguous reports as "feature requests." They split large bugs into many small tickets, each closeable in an afternoon. The dashboard looks healthy. The product is not.
This is Goodhart's Law (L9): when a measure becomes a target, it ceases to be a good measure. The law is one of sixteen in Framework 9 of The Engineer's Map, and it threatens every other engineering measurement you put in place.
What Goodhart Actually Says
Optimising for a metric produces behaviour that improves the metric without improving the underlying objective. The metric was originally chosen because it correlated with the thing that mattered. Once the metric becomes the target, the path of least resistance is to improve the metric directly — usually through gaming, reclassification, or selective measurement — rather than the underlying outcome.
The pattern is universal. A team measured on "bugs closed" closes bugs without fixing the underlying problems. A team measured on "features shipped" ships small, low-complexity features to maximise count. A team measured on "code coverage" writes tests that hit code paths without verifying behaviour. A model measured on "user engagement" learns to maximise engagement, not user satisfaction.
The metric stops measuring the objective it was chosen to track. The dashboard says progress. The product does not advance.
Why It Is True
The mechanism is human behaviour responding to incentives. Once a metric becomes the basis for evaluation — performance reviews, OKRs, leadership presentations, promotion criteria — engineers and teams optimise for it. They are not being dishonest. They are being rational under the incentive structure they have been given.
The original metric's value was its correlation with the underlying objective. That correlation was approximate. When the metric is treated as the target, every gap in the correlation becomes an exploit. Engineers find the cheapest way to improve the metric. The cheapest way is rarely the path that improves the underlying outcome.
This is AT9 (Speed vs Quality) in disguise. Quick wins on the metric come at the cost of slow, real improvements to the system.
The Engineering Mitigations
Choose metrics whose only natural path to improvement is to improve the underlying objective. Retention is hard to game. Number of commits is easy to game. Measure the outcome, not the activity.
A Goodhart-resistant metric for a search product is query reformulation rate — the percentage of searches where the user modifies their query and searches again within the same session. The only way to reduce reformulation is to return better results. The metric cannot be artificially suppressed without degrading the search experience in ways that show up immediately in other metrics. The incentive gradient points toward real improvement.
A Goodhart-resistant metric for a payments product is the successful-transaction-to-dispute ratio. A team measured on transaction volume alone will approve marginal transactions that generate disputes. A team measured on dispute rate alone will reject legitimate transactions to keep the denominator clean. The ratio forces both sides of the equation to improve together. Both numerator and denominator are anchored to real outcomes.
A Goodhart-resistant alternative to "daily active users" for a SaaS product is weekly core-action users — users who performed at least one action central to the product's value proposition (creating a document, sending an invoice, deploying a build) within the last seven days. The metric cannot be inflated by notification-driven opens because opens without core actions do not count.
The pattern in all three: the metric is rooted in the outcome the system is supposed to produce, not in proxies that happen to correlate with the outcome under normal conditions.
Why This Threatens Every Engineering Process
Any time you measure compliance with a law or a process, Goodhart predicts the measurement will be gamed.
- "Our architecture review checklist has 12 items." Result: 12 items are checked. The review becomes a checkbox exercise.
- "We require 80% test coverage." Result: lines are covered by tests that don't assert behaviour.
- "Our incidents are closed within 24 hours." Result: incidents are closed prematurely and reopened later under new ticket numbers.
- "We track code review approvals per engineer." Result: rubber-stamp approvals proliferate.
The engineering response: measure outcomes, not compliance. Not "did the review happen?" but "did the post-launch incident rate change after introducing the review?" Not "is coverage above 80%?" but "did the escape defect rate drop after the coverage requirement?"
The harder version: when you cannot directly measure the outcome, accept that your proxy will eventually be gamed. Build the feedback loop that lets you detect when the metric has drifted from the outcome — and replace the metric when it does.
Goodhart in AI Systems
The law is especially sharp in machine-learned systems because optimisation against the metric is automated and continuous. A recommendation model trained to maximise click-through learns to recommend clickbait — content that earns clicks but degrades user satisfaction. A content-moderation model trained on labeled examples learns to match label patterns rather than detect the underlying harm. A language model trained to maximise human-rater preference learns to be agreeable rather than correct.
The pattern repeats: the metric was chosen because it correlated with the objective. The model was trained to optimise the metric. The model found the cheapest path to the metric, which routes around the objective.
The engineering response in ML systems is the same as in human-team systems: pick metrics anchored to outcomes you actually want, instrument the gap between metric and outcome, and be ready to replace the metric when the gap widens.
Detecting Goodhart in Production
The signal is a metric that improves while the underlying outcome does not. Some concrete forms:
- Bug closure rate up; user-reported issue volume flat or rising.
- Deployment frequency up; lead time to user-visible improvement unchanged.
- Code coverage up; escape defect rate unchanged.
- DAU up; retention down.
- NPS up among power users; churn up among casual users.
When you see this pattern, the metric is no longer a useful proxy. The team is optimising for what is measured, which has detached from what was wanted. The mitigation is not to push harder on the metric. The mitigation is to find a Goodhart-resistant replacement.
The Law That Constrains the Other Laws
Goodhart sits inside Framework 9 of The Engineer's Map alongside the other engineering laws — Amdahl, Brooks, Conway, Gall, Hyrum, Pareto, and the rest. It is the law that constrains all the others. Any time you measure compliance with another law, you risk converting it into a target and gaming the measurement.
The discipline is to measure outcomes. The system either works better or it does not. Everything else is bookkeeping.
Goodhart's Law is named in The Engineer's Map — Framework 9 (Book 0, Chapter 13) and applied at depth in Book 7, Chapter 3 — Product Metrics. The book7 chapter covers the full HEART instrumentation pipeline for a SaaS at 100K MAU, dashboard target/alert thresholds for each dimension, the Facebook 7-friends activation discovery method, and the reflection exercises for auditing your current metric stack against Goodhart corruption.