All tools

Goodhart's Law

New
Systems Thinking

Understand why metrics stop working when they become targets

Goodhart's Law states: "When a measure becomes a target, it ceases to be a good measure." Originally formulated by economist Charles Goodhart in 1975, the concept explains why organizations often optimize for metrics at the expense of the outcomes those metrics were supposed to represent. Once people know they're being measured on something, they change their behavior to hit the number — often in ways that undermine the original goal.

How to use it

  1. Identify your metrics — What KPIs, OKRs, or measurements is your team or organization targeting?
  2. Ask "What behavior does this incentivize?" — Think critically about how people might game or optimize for this metric in unintended ways.
  3. Look for perverse incentives:
  • Are people optimizing the metric while undermining the real goal?
  • Has the metric become disconnected from the outcome you actually care about?
  • Are there ways to hit the target that violate the spirit of the goal?
  1. Design better measurement systems:
  • Use paired metrics — Balance each metric with a counter-metric (e.g., pair "speed" with "quality")
  • Measure outcomes, not outputs — Track customer satisfaction, not tickets closed
  • Rotate metrics — Change what you measure periodically to prevent gaming
  • Use qualitative checks — Complement quantitative metrics with qualitative assessments
  1. Build a culture of intent — Help people understand the why behind metrics so they optimize for the goal, not just the number.

Example

Common Goodhart's Law examples:
  • Lines of code as productivity metric → Developers write unnecessarily verbose code, avoid refactoring, and resist deleting dead code.
  • Number of bugs fixed as quality metric → QA reports trivial issues as bugs. Developers write sloppy code knowing they'll get credit for fixing the resulting bugs.
  • Average handle time in support → Agents rush customers off calls and close tickets prematurely, hurting customer satisfaction.
  • Story points completed per sprint → Teams inflate their estimates so they can "complete" more points.
Better approach for developer productivity:

Instead of lines of code → measure deployment frequency, lead time for changes, change failure rate, and time to restore service (DORA metrics) — paired with customer satisfaction.

Takeaway

Goodhart's Law reminds you that metrics are proxies for what you actually care about, not the thing itself. Always ask what behavior a metric incentivizes, use paired metrics to prevent gaming, and never lose sight of the real goal behind the numbers.

Put this tool to practice

Apply the Goodhart's Lawto your own situation. Start with a real problem you're facing and work through the steps above.

Explore more tools

Sources

Related tools