Goodhart’s Law: Why Your Engineering Metrics Stop Working the Moment You Target Them

TL;DR: Any metric you turn into a target stops being a reliable measure, because people (reasonably) start optimizing for the number instead of the thing it was supposed to represent. This is called Goodhart’s Law, and it quietly wrecks engineering metrics all the time. The fix isn’t to stop measuring — it’s to measure with guardrails, rotate your metrics, and treat every number as a hint, not a verdict.

Here’s a scenario that plays out in engineering orgs constantly. A team lead named Dana runs the “Checkout” team at an online retailer. Leadership wants more visibility into how fast the team ships, so Dana starts tracking story points closed per sprint and puts it on a dashboard everyone can see. For the first month, it works great. The number goes up. Leadership is happy. Then, a few months later, someone finally asks: why does the dashboard keep climbing while customers are filing more bug reports than ever?

The answer is a well-known idea from economics called Goodhart’s Law. It’s usually summarized as: “When a measure becomes a target, it ceases to be a good measure.” In plain terms: the moment you tell people their number matters, some of their effort shifts from doing the real work to making the number look good. That’s not because people are dishonest. It’s because you told them, explicitly or not, that the number is what gets rewarded.

On the Checkout team, “story points closed” quietly turned into a target instead of a measurement. People started splitting big tickets into extra small ones just to rack up point counts. Some engineers picked easy, low-risk tickets over the gnarly ones that actually mattered. The number on the dashboard kept climbing. The actual goal — shipping useful, working software — fell behind.

The loop that makes a good metric go bad: once a number is rewarded, effort shifts toward the number instead of the goal it was meant to represent.

This isn’t an argument against metrics. Teams that fly blind make worse decisions than teams with data. The real skill is knowing how to use a metric without it eating itself. Below are six rules that hold up across most engineering teams, using the Checkout team’s story to show what each one looks like in practice.

Rule 1: Assume every metric you reward will eventually get gamed

Don’t treat gaming as a surprising failure of the metric. Treat it as the default outcome once people know a number is being watched. This isn’t cynicism about your team — it’s just how incentives work. If “story points closed” determines who looks good in the sprint review, someone will find the path of least resistance to a higher number. Planning for this from day one changes how you design the metric in the first place.

Rule 2: Pair every metric with a guardrail metric

A guardrail metric is a second number that would drop if the first one were being gamed. If Dana had paired “story points closed” with something like “bugs found in production per release” or “tickets reopened after being marked done,” the gaming would have shown up fast. The main metric says how much got shipped. The guardrail metric says whether it actually held up. One without the other is an invitation to cut corners.

Rule 3: Prefer metrics closer to the real outcome, even if they’re harder to measure

Story points are a proxy. They estimate effort, not value. A better (if harder to get) metric is something closer to what the business actually cares about — checkout completion rate, page load time, or the number of support tickets tied to the checkout flow. Proxies are tempting because they’re easy to count every sprint. But the closer a metric sits to the real-world outcome you want, the harder it is to fake without actually delivering that outcome.

A rough comparison of two metric types. The easy-to-game, easy-to-measure proxy looks convenient right up until it drifts away from the real goal.

Rule 4: Watch behavior, not just the dashboard

Numbers can look healthy while the underlying behavior quietly rots. If Dana had spent ten minutes a sprint actually reading the tickets being closed — not just counting them — the pattern of split tickets and cherry-picked easy work would have been obvious well before the dashboard gave it away. A metric is a summary. Summaries lose information on purpose. Checking in on the raw work now and then catches what the summary can’t.

What the story-point dashboard didn’t show: once the number became the target, a majority of the team’s effort quietly shifted toward managing the metric instead of the product.

Rule 5: Rotate or retire metrics before they get fully gamed

Every metric has a shelf life. The longer a number sits at the center of attention, the more time people have to learn its blind spots. This doesn’t mean changing what you measure every month — that creates its own chaos. But if a metric has been the star of every planning meeting for a year, it’s worth asking whether it still means what it meant on day one. Swapping in a fresh angle every so often keeps people honest, because the shortcuts they learned for the old metric don’t automatically transfer to the new one.

Rule 6: Use metrics to start a conversation, not to hand down a verdict

The biggest driver of gaming isn’t the metric itself — it’s what happens to people when the number looks bad. If a dip in “story points closed” triggers a stern talking-to, people will protect the number instead of being honest about what’s actually happening. If a dip instead triggers a curious question — “what changed this sprint?” — people have much less reason to hide the truth. Metrics that are safe to discuss stay accurate longer than metrics that are used as judgment.

Dana’s team eventually recovered, not by abandoning metrics, but by changing what got rewarded. They kept story points as a rough planning input, but stopped putting it on a public dashboard. Instead, they started reviewing a small set of outcome-focused numbers together as a team, out loud, every couple of weeks — checkout completion rate, error rates, and how long bugs sat open. None of those numbers were perfect either. But because no single number was the target, no single number was worth gaming.

That’s the real lesson of Goodhart’s Law for engineering teams: the goal was never to find the one metric that can’t be gamed. It’s to build a habit of measuring in ways that make gaming not worth the effort — guardrails, proxies close to reality, regular rotation, and a culture where a bad number gets curiosity instead of punishment.