How Incentives Backfire

It’s an axiom these days that “if it matters, measure it.” That is, if you have an objective, collect data that can show whether you are meeting that objective. Usually we do that by creating some measurement from that data that can tell us if we’re making progress towards our objective. Creating a good measurement can be hard, but I will only talk about that a little bit at the end of this post. Instead, I will focus on how incentives backfire when you put too much emphasis on the measurement and it becomes the objective. That means that I am going to focus on Rule 41 - Treat incentives, especially monetary ones, very carefully. Warning: Dramatic oversimplification ahead.

A pseudohistorical and poorly conceived story about money

Money is a great example of the measure becoming the objective.

Before money, our hunter-gatherer forebears had an objective: survive. To survive, they needed to avoid dying of exposure, disease, predation, accident, starvation, or any of a million other things. For simplicity’s sake, let’s focus on the exposure and starvation.

To avoid dying of exposure or starvation, our forebears needed to have enough basic necessities: food, water, shelter, firewood. They could look at their supplies and figure out if they would live another day. If not, they knew they had work to do. That left them with this:

Objective : survive another day
KPIs¹ : amount of each basic necessity
Activities : build shelter; obtain food, water, & firewood

Pretty simple, right? When people started developing the notion of trade, it got complicated because they wouldn’t necessarily have the right thing at the right time to trade for something else or they wouldn’t want to exchange it all right now.

What happened when someone wants to buy a hut for five bushels of berries? The seller can’t eat 5 bushels of berries fast enough, some will go to waste. It’s also inconvenient to move berries around when you’re trading a manufactured good like flint knives over long distances. Sooner or later, people figured out they needed an abstraction to make trade practical. That abstraction turned out to be something resembling money. Once money is in the picture, they could change their activities:

Objective : survive another day
KPIs : amount of each basic necessity
Activities : obtain money; buy necessities

What then? With the continued growth of agriculture and settlements, they could build secure places to store grain and other necessities. Not only could they simplify some complexities of trade, they could now just look at how many coins were jingling in their coin purse and determine if they could survive. That now left them with this:

Objective : survive another year
KPIs : money in the coin purse to buy necessities
Activities : obtain money

Technology is advancing, our now late stone age forebears are thinking about luxuries. They’re not just surviving, they’re thriving. They also are able to plan for famines, wars, and other large scale events.

Objective : thrive
KPIs : amount of money in the bank to buy necessities & luxuries and survive rainy days
Activities : obtain money

Sooner or later, our brain starts deceiving us. We’re so accustomed to measuring the KPI, that we tend to forget the reason for that KPI. We only want that KPI to keep going up because our parents, their parents, etc. all taught us to build up that bank account. We sort of know there’s a connection to surviving and thriving, but we tend to lose sight of it. Our objective has dramatically switched. The thing that was once a means to an end is now the end itself:

Objective : obtain money and assets
KPIs : rate money is obtained; how fast we can increase that rate
Activities : grow money and other assets

I’ll stop that line of reasoning there. We could keep going and work our way through the growth of materialism and throw a real pity party about how much modern culture stinks, but that means pretty much everyone reading this (and the guy writing it) stinks too. That’s not fun. Let’s go down another path.

The messages we hear about “pursue your passion” and “if you’re doing what you love, you’ll never work a day in your life” (that can be taken several ways!) still are messages about making money. Those motivational quotes can be be paraphrased as: “figure out how to monetize the other things you like to do, because a large part of your life will be focused on earning money.” It’s not because money somehow makes the music/painting/writing/whatever better, it’s because we’re programmed to make money. It’s what we’ve heard all of our lives. This almost universal objective helps us start to apply Rule 53:

Rule 53 - If you want to understand why someone is acting the way that they are, seek to understand their motivation.

What that means for incentives

Now that we’ve established that most people will look at the money they earn as an objective, let’s look at how most organizations incentivize employees. Drum roll please: with money!

I bet you saw that coming.

Even if we love what we do, I’m pretty sure most of us would do a lot less of it (or do it different ways) if we didn’t want the money. The organizations we work for know it because those organizations are made up of people doing exactly the same thing. Thus, we end up with incentive systems that makes it all about the money. Do the things you are supposed to do, you get paid and sometimes even get rewarded with a bonus or promotion. At a basic level, that’s fine. It’s when we fail to realize that both incentives and compensation are programming the employee to act a certain way and not act other, beneficial, ways that we have a problem.

Let’s use software development as an example. The organization wants its developers to be productive, so shortsighted managers think to themselves “Aha! I’ll measure each developer’s productivity and we’ll base performance ratings on that.” Then they start thinking about how to do that measurement. Next thing you know, the developers are being measured on some aspect of how much work they get done. The problem appears when “work done” starts to become specific.

Back in the day, managers looked at the number of lines of code a developer produced over a given time period to see how productive they were. The developers very rapidly figured out that all they had to do was crank out code. They didn’t try to optimize the code, make it readable, test the code before sending it out the door, or doing any of a number of other things that would have made it good code. In fact, they made the code worse because they copy and pasted code or reinvented the same wheels over and over again. The did it the bad way just so they could bump up their line count. After all, the amount of code is the thing their boss told them to focus on.

When this happens, even the developers who aren’t inclined to cheat still avoid those tasks that don’t benefit them. They often won’t try to solve the big problems in the system because they’ll be “less productive”. They just keep solving the small ones. After all, they can really crank through those.

For another take on this, read Tanya Reilly’s great post on Being Glue. She shows us that when you reward the team for focusing solely on delivering new application features, you end up hurting those who realize there is other work that still needs to be done and do it. Everyone suffers in the end as the organization gets passed by its competitors who figured this out already.

This same thing manifests in other jobs. I worked for a help desk early in my career. We were measured on how many calls we took in a shift and how long they lasted. If a customer called back later because we didn’t solve their problem the first time, we didn’t get penalized for that. So what happened? Some techs would try to get the customer off the phone quickly. The good techs would give them a list of things to try and tell the customer to call back if needed (and hope someone else got the call). There was one tech who just cared about having good numbers so he could get promoted to another department. If it wasn’t a simple problem, he’d tell them “rebooting will solve it for you,” and get the call over with. That’s exactly the kind of customer service we all have come to hate! The incentives were clearly messed up.

That leaves us with the full form of Rule 41:

Rule 41 - Treat incentives, especially monetary ones, very carefully. They often backfire and always limit people to operating inside the box.

What can we do?

There’s no silver bullet, but there are a few things you can do when you’re setting up incentives.

Rule 41 is my paraphrase of a quote from Mary Poppendieck’s “Unjust Deserts” article (2004):

Treat monetary rewards like explosives because they will have a powerful impact whether you intend it or not

Riffing on that article, we can come up with a few things to do:

Avoid overly simplistic objectives and KPIs.

It’s really easy to grow this quarter’s net profits by firing all non-revenue generating employees. What about next quarter?
Make sure incentives reflect the overall goal of the organization and project.

If we are building software, are we measuring developers on producing code or helping to ship features? Are we actually incentivizing the team to avoid getting work done?
Make sure measurements reflect actual output and quality, not just one aspect of a persons job.

Are we just measuring lines of code or call duration?
Never incentivize competition. Always be aware of the many ways people will find to compete, or at least act only in their own interest.

Some people find it easier to rise above others by pushing them over. Why does it matter that someone is better than someone else if both are doing great work?
Actively foster teamwork and cooperation (This gets to Rule 6 - Cooperation is a powerful force).

A common mistake in software development is rewarding quality assurance based on the number of bugs found. This annihilates the teamwork between the QA group and everyone else. This is part of what I’ll talk about when I discuss Rule 45 - The Quality Assurance team’s job is to validate the solution fits the need, not to find bugs.
Analyze the people who are upstream and downstream in the workflow.

Make sure the incentives you use to motivate the employee serve the needs of the upstream and downstream people too.
Constantly reassess your measurements.

What was good yesterday may not be good today. The measurements may not reflect the needs of the organization or the organization may start turning the old measurements into the new objectives.
Make sure your incentives properly reward the quiet contributors too.

Was the rockstar developer really a rockstar or did they just pick the high visibility task? Did someone else do all the glue-work (seriously, read Being Glue) that let the rockstar get the visible task done?

Conclusion

Ok, this was a long one. Hopefully you got a taste of one of my most deeply-held beliefs about working: despite most of us only showing up for the job because we get paid, many of us do still want to do a good job. Make sure the incentive structure your organization uses supports that and good things will happen.

I started out just with a non-rule blog post in mind to explore that central idea of the evolution of the KPI into the objective. As I was writing, I realized it could dovetail into a start to the incentive discussion. I expect I’ll have more to say on the topic as I evolve the discussion on Jim’s Rules.

A note on the artwork: The image “Climbing a Treasure Pile” was created by Jim Leonardo with much AI tweaking using NightCafe. See my other experiments at https://creator.nightcafe.studio/my-creations.

“KPI” = Key Performance Indicator. These are the really important things you measure to see if you’re meeting your goal. Other measures can help, but they aren’t “key”. A lot of organizations miss the “key” and track everything they can measure. ↩