When Metrics Backfire
The Cobra Effect is named after a famous anecdote from British colonial India:
- Problem: Too many venomous cobras in Delhi.
- Solution: The government offered a cash bounty for every dead cobra brought in.
- Unintended consequence: Enterprising citizens started breeding cobras in their homes to kill them and collect the bounty money.
- Outcome: When the government discovered the scheme and canceled the bounty, the breeders released their now-worthless snakes into the wild, tripling the original cobra population.
The government created a reinforcing loop (more cobras killed → more money → incentive to produce more cobras) when they intended to create a balancing loop (bounty → fewer cobras → problem solved). The intervention changed the goal of the system's actors from "avoid cobras" to "maximize cobra-derived income."
The Lesson:
This is a specific instance of Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure." When you attach a reward (or punishment) to a metric, people will optimize for the metric, often destroying the goal the metric was supposed to represent.
Engineering Examples:
| Metric (Target) | Intended Goal | Cobra Effect |
|---|---|---|
| "Close tickets faster" | Improve customer satisfaction | Engineers close tickets without fixing root causes; reopen rate skyrockets |
| "Increase code coverage to 90%" | Improve code quality | Engineers write tests like expect(true).toBe(true) to hit the number |
| "Reduce mean time to recovery (MTTR)" | Improve reliability | Teams mark incidents as "resolved" prematurely, before the actual fix is verified |
| "Increase deployment frequency" | Ship value faster | Teams deploy no-op changes (whitespace, comment edits) to inflate the metric |
| "Reduce number of production incidents" | Improve stability | Teams reclassify incidents as "expected behavior" or raise the severity threshold |
How to Defend Against It:
1. Pair metrics: Never use a single metric. Pair "deployment frequency" with "change failure rate." Pair "tickets closed" with "reopen rate." Pair "code coverage" with "mutation testing score."
2. Measure outcomes, not outputs: Instead of "number of deployments" (output), measure "time from code commit to value delivered to user" (outcome).
3. Rotate metrics: Change what you measure periodically so that gaming strategies cannot calcify.
If asked "How do you measure engineering team productivity?", resist the urge to name a single metric. Instead, describe the Cobra Effect and explain that you use balanced metric sets (like the DORA metrics: deployment frequency, lead time, change failure rate, and MTTR) specifically because they are designed to counterbalance each other. Optimizing one at the expense of another immediately shows up in the dashboard.
Key Point: The Cobra Effect is not about people being malicious. It is about rational actors responding to incentive structures. If your system rewards the wrong behavior, you will get the wrong behavior — reliably and at scale. The fix is never "hire better people." The fix is "design better feedback loops."