# Goodharts Law

> Anticipate metric gaming and unintended optimization by recognizing that when a measure becomes a target, it ceases to be a good measure

- Skill: `lev-os/goodharts-law` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lev-os/goodharts-law`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lev-os/goodharts-law/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lev-os (https://skillmd.com/u/lev-os)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/lev-os/goodharts-law

---


# Goodhart's Law

**What**: An adage stating "When a measure becomes a target, it ceases to be a good measure." Once people optimize for a metric, they find ways to improve the metric that don't improve (or actively harm) the underlying goal.

**When to use**: When designing KPIs, performance metrics, incentive systems, or any measurement system where human behavior will adapt to the measurement.

**Introduced by**: Charles Goodhart (1975), economist studying monetary policy targets

## Core Mechanism

Metrics are proxies for goals, not the goals themselves. When you incentivize a proxy, intelligent agents find the cheapest path to move the metric—often by exploiting the gap between metric and goal rather than achieving the goal itself.

**Why it happens**: Metrics are simplifications. They capture some aspects of the goal but never all of them. Optimization pressure finds and exploits the gaps.

## When to Apply

**Use Goodhart's Law awareness when:**
- Designing performance metrics or KPIs for teams
- Creating incentive compensation structures
- Setting up A/B testing or optimization frameworks
- Establishing SLAs or quality standards
- Implementing algorithmic ranking or recommendation systems

**High-risk contexts:**
- Systems where metrics are tied to rewards (bonuses, promotions, funding)
- Automated optimization (algorithms, AI models)
- Competitive environments (rankings, leaderboards)
- High-stakes evaluations (hiring, performance reviews)

## Execution Steps

### 1. Distinguish Goal from Measure
Clearly separate what you actually want (goal) from how you're tracking it (metric). The metric is a proxy, not the objective.

### 2. Ask "How Could This Be Gamed?"
Red-team your own metrics. Brainstorm ways to improve the metric while harming the underlying goal. Those exploits will emerge naturally.

### 3. Use Metric Portfolios, Not Single Metrics
Combine multiple metrics that create tension. Gaming one should worsen another. Example: Speed + Quality + Customer Satisfaction vs. just Speed.

### 4. Separate Measurement from Target-Setting
Use metrics for visibility and diagnosis. Reserve target-setting for higher-level goals. "We measure X to understand Y" not "Hit X at all costs."

### 5. Include Counterbalancing Guardrails
For every metric you optimize, add constraints that prevent pathological optimization. Example: "Increase signups" + "Maintain activation rate above Z%."

### 6. Rotate or Evolve Metrics Over Time
Don't optimize the same metric forever. Once behavior has shifted, update the metric to capture new gaps or gaming strategies.

### 7. Inspect for Gaming Regularly
Monitor for warning signs: Metric improves while goal stagnates, clever workarounds emerge, or team behavior shifts in surprising ways.

## Real-World Applications

**Soviet Nail Factory**: Quota by weight → Factory produces fewer, heavier nails. Quota switched to count → Factory produces tiny useless nails. The metric shaped production, not customer need.

**Wells Fargo Account Scandal**: Incentivized account openings → Employees opened millions of fake accounts without customer knowledge to hit targets.

**Software Bug Counts**: Rewarding developers for fixing bugs → Developers split one bug into many tickets or write buggy code to fix later. Bug count goes up, quality doesn't.

**Academic Citations**: Promotion based on citation count → Excessive self-citation, citation rings, salami slicing papers. Citation count up, research quality unchanged.

## Key Indicators

**Signs of Goodhart's Law in action:**
- Metric improving but stakeholders aren't happier
- Creative "interpretations" of how to count metric
- Behavior shifts that technically meet target but feel wrong
- Correlation between metric and goal weakens over time

**Healthy metric systems:**
- Multiple metrics in tension with each other
- Periodic metric review and evolution
- Qualitative assessment supplements quantitative
- Metrics inform discussion, don't dictate decisions

## Common Mistakes

**Single-metric optimization**: Optimizing one number creates blind spots and gaming opportunities.

**Confusing metric with goal**: "Increase test coverage" becomes the goal, forgetting that quality is the goal and coverage is one imperfect proxy.

**Ignoring feedback loops**: Metrics change behavior, which changes what the metric measures, invalidating the original correlation.

**Over-automation**: Algorithmic optimization of metrics without human judgment accelerates gaming and weird outcomes.

## Related Frameworks

**Complementary**: Campbell's Law (same insight from social science), Cobra Effect (perverse incentives), McNamara Fallacy (over-relying on quantification)

**Contrasting**: Management by Objectives (assumes metrics can capture goals accurately), Rational Economic Actor (assumes optimization serves intended purpose)

**Sequential**: Define true goal → Select proxy metrics → Anticipate gaming → Add counterbalances → Monitor for exploitation → Evolve metrics

## Practical Examples

**GitHub Contributions Graph**:
Problem: Commit count becomes hiring signal → People make trivial commits, rewrite history, or auto-commit to look active.
Fix: View commits as one signal among many; inspect code quality, PR discussions, not just activity heatmap.

**Customer Support Response Time**:
Problem: Optimize for "first response < 1 hour" → Agents send "We're looking into it" immediately, then ignore ticket.
Fix: Add metric for "time to resolution" and "customer satisfaction rating" to balance speed with quality.

**Test Coverage Percentage**:
Problem: "Must have 80% coverage" → Developers write tests that execute code but don't assert anything meaningful.
Fix: Use coverage for discovery (where are blind spots?) not targets. Supplement with mutation testing or manual review.

## Red Flags

**Warning signs you're vulnerable:**
- Tying bonuses or promotions to single metrics
- Celebrating metric improvements without checking underlying goal
- Lack of qualitative assessment alongside quantitative
- Metrics haven't changed in years despite gaming opportunities

**Gaming in progress:**
- Metric improves suddenly without process changes
- Clever accounting or definitional tricks
- Behavior that's "technically correct" but feels wrong
- Metric up, but customer/stakeholder complaints also up

## Measurement

**System health checks:**
- Correlation between metric and goal (should be stable; degradation = gaming)
- Diversity of metrics in use (1 = danger, 3-5 = healthy)
- Frequency of metric review/evolution (never = stale, quarterly = adaptive)
- Qualitative vs. quantitative balance in decisions

**Gaming detection:**
- Anomaly detection in metric trajectories
- Behavior pattern changes after metric introduction
- User feedback sentiment vs. metric trends
- Cross-reference metrics with independent goal assessments

## Scoring Criteria

**Practitioner Weight**: 9/10 — Goodhart was a Bank of England economist studying real policy failures; widely observed in business, government, and software

**Clarity & Executability**: 9/10 — Extremely clear one-sentence formulation; actionable guidance (use metric portfolios, anticipate gaming, separate measurement from targets)

**Proven ROI**: 9/10 — Understanding this prevents costly metric gaming, improves incentive design, widely taught in business schools and economics

**Novelty**: 8/10 — Counterintuitive that measurement itself corrupts what's measured; challenges management orthodoxy

**Cross-Domain Applicability**: 10/10 — Applies universally: economics, software, management, education, healthcare, government policy, ML systems

**Total Score**: 45/50 (Tier 1: Canonical)