Perverse Incentives: When the Reward Backfires

A support team got a new rule one quarter: whoever resolved the most tickets each month took home a bonus. It was a reasonable instinct. A team that closes tickets fast is a team that helps customers quickly, so the count really did track something good. Within a month the leaderboard was topped by the people replying "Please try restarting and reopen this ticket if the problem continues," then marking the ticket resolved. A reopened ticket counted as a fresh one, so the fastest route to the bonus was to never actually solve anything. Resolved-per-day climbed to a record. Customers were more stuck than before, and the people genuinely fixing hard problems, slowly, sat at the bottom of the board.

Nobody in that story was a villain. Each person did the rational thing given the reward in front of them, and the sum of those rational moves was a system working against its own purpose. That failure has a name, and it is the umbrella term that two more famous laws sit underneath. It is the perverse incentive: a reward structure that reliably produces the opposite of what it was meant to encourage. Knowing it by name changes the question you ask when a metric goes strange, from "who is cheating?" to the sharper and more useful "what is the cheapest way to earn this reward, and is that the thing I actually wanted?"

What is a perverse incentive?

A perverse incentive is an incentive structure with an undesirable result, specifically one where the reward motivates behavior that works against the goal the reward was supposed to serve. The textbook origin is the cobra effect. Under British rule in Delhi, the government put a bounty on dead cobras to reduce their numbers; enterprising locals started breeding cobras to collect the bounty, and when the scheme was scrapped they released the now-worthless snakes, leaving the city with more cobras than it started with. That story is told in full as the opening example of how a chain of locally sensible choices produces an outcome nobody chose, and it is the single clearest picture of the pattern: the incentive did not just fail, it inverted.

The key is in the word "cheapest." People respond to the reward actually on offer, not the one you intended, and they take the least costly route to it. When the cheapest route to the reward happens to be the real work, the incentive behaves. When a cheaper route exists that skips the work, the incentive goes perverse, because the reward is now paying for the shortcut. This is why a perverse incentive is not a rare freak event but the default failure mode of any reward attached to a proxy, and it is worth writing down what each reward is actually a proxy for before you wire a consequence to it, because that is the detail everyone forgets within a quarter.

Why a reward on a proxy inverts

Almost every incentive is aimed at a proxy rather than the thing you truly care about, because the thing you care about is usually hard to measure directly. You cannot easily reward "helped the customer," so you reward "closed the ticket." You cannot easily reward "wrote valuable software," so you reward "shipped the feature" or "hit the velocity target." The proxy stands in for the goal, and as long as moving the proxy means doing the real work, everything holds together. The trouble starts the moment a cheaper way to move the proxy appears.

The diagram is the whole mechanism on one page. Both paths arrive at the same place, which is the reward being paid, because both of them move the proxy. The difference is cost. Doing the real work moves the proxy and also improves the goal, but it is expensive. Gaming the proxy moves the proxy just as well, earns the identical reward, and is far cheaper, so a rational person with a target to hit takes the top path. The result is that the reported number improves while the thing you wanted gets worse, not despite the incentive but because of it. The reward is functioning exactly as designed; it was simply designed to pay for the proxy, and the proxy had a back door.

This is the same force by which any behavior a system can actually observe quietly becomes a behavior people build toward, whether or not you meant to ask for it. Expose a measurable proxy and attach a reward, and you have not just created a target; you have created a search for the lowest-effort way to hit it. The more precisely you specify and enforce the proxy, the more sharply that search converges on the shortcut.

Perverse incentives in software and knowledge work

Modern teams run almost entirely on proxies, and most of the ones that go bad do so in the perverse-incentive shape. Here are the rewards that most reliably backfire, the shortcut they end up paying for, and the goal that quietly suffers while the number looks fine.

The through-line is that in every row the reward is attached to something cheaper to fake than to earn, so the reward buys the fake. Notice that none of these is a case of bad people; each is a case of a good reward pointed at a convenient proxy with an obvious shortcut. The A/B-testing row is a telling one, because it is exactly where experienced product teams get caught: once "number of experiments" becomes the thing leadership counts, you get a pipeline full of underpowered tests that generate activity and no knowledge, which is the opposite of why you set up experimentation in the first place.

Perverse incentive vs Goodhart's law vs Campbell's law

These three terms get used as if they were interchangeable, and they are closely related, but it is worth keeping them straight because each names a different slice of the same problem. The perverse incentive is the umbrella: any reward whose result runs counter to its intent. The two laws are sharper statements about measurement sitting underneath it.

In practice, Goodhart's law gives you the crisp one-liner, that a measure under pressure to be a target stops measuring what it did, and Campbell's law adds that the higher the stakes, the faster that happens and the more the real work rots underneath. The perverse incentive is the broader category both belong to, and the cobra effect is its most extreme instance, where the reward does not merely decouple from the goal but actively drives the goal backward. When you are diagnosing a reward gone wrong, "perverse incentive" is the right opening diagnosis, and Goodhart and Campbell are the finer tools for explaining the mechanism and the scale.

How to design an incentive that does not backfire

A perverse incentive is not an argument against rewarding people. It is an argument against pointing a reward at a convenient proxy and then walking away. Most of the fix is cheap and comes down to closing the back doors the shortcut would use. These are the questions to run any reward through before you attach a real consequence to it.

The pattern underneath the table is that a reward backfires when it has an easy shortcut and no independent view of the real thing and high enough stakes to make the shortcut worth taking. Remove any one of those and the perversion loses most of its grip. The cheapest lever is usually the pairing: for every number you reward, name a second number that gets worse when the first is gamed, and watch them together. Before you rip out an incentive that has already gone bad, though, it is worth finding out why it was put there in the first place, because the behavior it was fighting often comes straight back the moment the reward is gone.

The incentive whose reason got lost

Here is where a one-off bad quarter hardens into a permanent trap. Every incentive was introduced once, by someone, to solve a specific problem. The ticket-count bonus was added because support used to sit on tickets for days. The coverage gate was set because an untested release once took down production. At the moment it is created, everyone understands that the number is a stand-in and roughly how much weight it can bear. Then the person who set it moves on, the original pain fades, and what remains is the reward with its stakes still attached and its original reasoning quietly decayed away.

New people inherit "we hit our coverage target" or "we lead the resolved-per-day board" with no memory that the target was only ever a proxy, so they optimize it with a clear conscience, shortcut and all. The fix is specific and cheap: when you attach a reward to a number, write down what it is a proxy for, what the cheapest way to game it would be, and what paired signal would tell you it had started to backfire. That note belongs in the same durable record as the decisions it came from, next to the reasoning, so the next person inherits the intent along with the metric. Try Scribelet free and keep the purpose and the failure conditions behind each incentive, not just the number, where the people who inherit your scorecards will actually find them. A reward whose reason is written down can be retired the day it starts paying for the wrong thing; a reward whose reason has decayed becomes a target nobody dares question.

Reading perverse incentives correctly

The tempting overreaction is to conclude that incentives are hopeless and to stop rewarding anything, which is the wrong lesson and an expensive one. People respond to incentives whether or not you design them, and an organization with no deliberate rewards still has plenty of accidental ones. The point of understanding perverse incentives is not to abandon rewards but to design them with the shortcut in mind, so the cheapest way to earn the reward is the thing you actually wanted.

So the standing question a perverse incentive hands you is not "are people gaming this?" but "what is the cheapest way to earn this reward, and is that the behavior I meant to buy?" Reward outcomes rather than convenient proxies, pair every number with a counter-number, keep the stakes proportional to how gameable the metric is, and keep an independent view of the real result. Try Scribelet free and let it hold the reasoning behind each incentive your team runs on, so the rewards keep pointing at the work instead of quietly paying for its opposite.