Goodhart’s Law in software development

Every metric that becomes a target looses its value as a metric. The specific phrase “when a measure becomes a target, it ceases to be a good measure” is known as Goodhart’s Law. It originates from British economist Charles Goodhart, and the exact modern phrasing was popularized by anthropologist Marilyn Strathern.

Core Ideas of Goodhart’s Law

• Gaming the System: People change their behavior to optimize for the specific KPI / number / benchmark / outcome instead of the actual goal.
• Loss of Reliability: The data no longer reflects real success or quality, since it is biased by the game.
• Unintended Consequences: Chasing the metric can actively damage the broader purpose. It is an infinity game problem.
• Change is constant – how different KPI optimizations are intersecting one another. Correlation between i.ex cycle time / lead time / number of bugs / happines of developers and etc…

A Practical Way to Think About It

Treat metrics as signals, not goals. Use them to start conversations, not to close them. Combine quantitative KPIs with qualitative checks (code reviews, incident deep-dives, customer feedback) so no single number can be gamed without being noticed.

Goodhart’s Law exmaples in Business

• Call centers: When agents are measured on average call duration, they rush calls or transfer customers to keep times low, hurting resolution quality and satisfaction.
• Sales teams: Hitting quarterly revenue targets can lead to heavy discounting, pushing deals into the next quarter, or booking low-quality customers who churn quickly.
• Software support: Counting “tickets closed” encourages quick, shallow fixes or re-categorizing issues instead of solving root causes.
• Content/SEO: Optimizing purely for pageviews or time-on-page leads to clickbait headlines and bloated articles that rank well but don’t help users.

Goodhart’s Law exmaples in Education

• Standardized testing: Schools judged by test scores narrow curricula to tested subjects, teach test-taking tricks, and sometimes even manipulate who sits the exam.
• University rankings: Institutions optimize for ranking metrics (e.g., research output, selectivity) in ways that don’t necessarily improve teaching quality or student learning.
• Graduation rates: Pressure to raise graduation rates can lead to grade inflation, easier courses, or pushing struggling students through without real mastery.

How to design metrics ?

• Use multiple, balanced metrics: Speed, quality, and outcome measures (e.g., cycle time + incident rate + customer satisfaction) so gaming one is direclty impacting another. Design for correlation.
• Make metrics diagnostic, not punitive: KPIs should be tools for learning and improvement, not as the sole basis for rewards or punishment.
• Qualitative checks: Pair numbers with regular reviews, audits, and feedback understand when, how and why metrics fluctuate.
• Randomize trials: Make it harder for people to optimize and game the algorithm. As Gandalf said “Keep it hidden, keep it safe.”.
• Measure outcomes, not just outputs: Focus on business or user outcomes (retention, NPS, feature adoption, incident impact) rather than activity counts (tickets closed, stories delivered).

Summary

Measuring simple KPIs is easy but gaming of those is also easy. However even if people optimize for one, this has impact on something else. It is a zero sum game. It is up to You to identify how You can minimize on some and maximize on others. 100% of time for pure development and zero bugs is a goal, but it might make overall 100% as less task done with more care. This will be gamed for zero bugs, but lower the veocity.

When will You decide that some value is “good enough”. What is the end game ? Or if developers achieve Your godly 100% You will try to push them more…. ? 🙂