Every engineering leader wants a number that tells them how the team is doing. The trouble is a law named after economist Charles Goodhart: when a measure becomes a target, it ceases to be a good measure. The moment you reward a metric, people optimize for the number instead of the thing it was supposed to represent, and the metric goes hollow.
Key Takeaways
- Goodhart's Law: when a measure becomes a target, it ceases to be a good measure (Goodhart's Law).
- Reward velocity and estimates inflate; reward lines of code and people write more code than needed (Goodhart in software).
- Any single metric elevated to a goal gets gamed, at the expense of the real outcome.
- Use metrics for insight, balance several, and pair them with judgment.
The Law
Charles Goodhart's observation, sharpened into the popular form "when a measure becomes a target, it ceases to be a good measure," is one of the most useful and most ignored ideas in management (Goodhart's Law). A metric works as a signal precisely because people aren't trying to move it directly. Start rewarding it, and behavior bends toward the number. People are clever; they'll hit the target you set, even when hitting it defeats the purpose you set it for.
How It Breaks Engineering Metrics
Software is full of metrics that curdle the instant they become targets (Goodhart in software engineering). Reward velocity and teams inflate estimates and split tasks to pump the number, turning a rough planning aid into a gamed vanity metric, which we covered in why story points mislead. Target lines of code and developers write twenty lines where one would do, keep code that should be deleted, and treat a refactor that removes code as "negative productivity." Mandate test coverage and people write assertions that assert nothing to hit it, exactly the failure in does test coverage predict quality. Reward tickets closed and work gets sliced into trivial tickets or closed prematurely. Each metric is genuinely useful as a signal, and misleading the moment it's the goal.
| Metric as a signal | Same metric as a target |
|---|---|
| Velocity: rough capacity feel | Inflated estimates, gamed |
| LOC: activity indicator | Bloated code, no deletion |
| Coverage: finds untested code | Hollow tests that assert nothing |
A Concrete Version
A VP wants engineers "more productive," so they start tracking and rewarding tickets closed per person. Within a month, the numbers look great and the software doesn't. Engineers split real work into many tiny tickets, close ambiguous ones early, and avoid the big, important, hard-to-ticket work because it tanks their count. The metric went up; the actual output went down. Nobody cheated, exactly; they did what the target rewarded.
What to Do Instead
There's no perfect metric that escapes Goodhart's Law, because any single target gets gamed. The defenses are practical. Use metrics for insight and conversation rather than as individual performance targets. Balance several metrics so gaming one shows up in another (DORA's four keys work partly because speed and stability check each other). And keep humans in the loop, pairing every number with the qualitative judgment of someone who understands the work. The goal is to measure for learning rather than for reward.
What This Means for Teams
Goodhart's Law is a caution against the seductive dashboard, and a reason we're skeptical of hiring or evaluating engineers by a single proxy, whether that's pedigree, a LeetCode score, or a velocity chart. Real signal comes from looking at the work with judgment, which is what our vetting is built to do. Numbers inform the decision; they don't get to be the decision. See available engineers.
Frequently Asked Questions
What is Goodhart's Law?
The principle, from economist Charles Goodhart, that when a measure becomes a target it ceases to be a good measure. Once you reward a metric, people optimize the number instead of the outcome it stood for.
How does Goodhart's Law apply to engineering?
Common metrics break when they become targets: rewarding velocity inflates estimates, targeting lines of code bloats it, and mandating coverage produces hollow tests. Each is useful as a signal but gets gamed as a goal.
How do I avoid gaming my metrics?
Use metrics for insight rather than individual rewards, balance several so gaming one shows up in another, and pair every number with human judgment about the actual work.
Are engineering metrics useless then?
No. They're valuable for learning and conversation. The danger is elevating a single metric to a target, which is when people optimize it at the expense of the real goal.
The Bottom Line
When a measure becomes a target, it stops measuring anything real, and engineering metrics are especially easy to game. Velocity, lines of code, coverage, and tickets closed all break the moment you reward them. Use numbers to learn, balance several, keep judgment in the loop, and never let a single metric become the goal.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
