Incentives and the Related Dangers

Incentives are just as dangerous as they are powerful. I have the running theory that most incentives can actually do the exact opposite of the intended goal when executed wrong.

Let’s start with an example to illustrate. You’re in charge of a small company that picks up garbage after events like street fairs and parades. However, you just got an angry call from your customer (the city) that your company has been doing an increasingly poor job and they are threatening to cut your contract.

You can fire and hire people, but ultimately, you or some new manager will need to fix the culture of the team. Aside from the obvious choice of talking to your staff about goals and values, let’s assume that incentivizing performance ends up being the option you go with. It’s time to play with fire.

What are some obvious ways to incentivize good cleaning efforts? There are many, but I’ll focus on a really obvious one for this post: Tie bonuses to volume/weight of trash picked up.

Is this a bad incentive? Not necessarily. But if executed poorly, it can be disastrous.

Which is more important to pick up? The pile of 50 napkins or the four empty soda bottles? Under this solution, people would be incentivized to ignore napkins, cigarettes, and plastic bags while encouraged to chase after bottles (bonus points for liquid content) and discarded food. In fact, once employees start realizing this, they might even start picking up rocks and dirt instead of actually cleaning — in effect making the situation worse.

The situation above is universal across all industries. In software, the oft-cited “Dilbert” situation is when performance gets tied to lines of code written. The point is, any system introduced that attempts to incentivize a certain type of behavior can cause employees to focus on the wrong thing. If you tell your staff that closing bug tickets is tied to bonuses, your entire team will focus on that metric like a laser. This will be good at first until you realize that everybody is spam-fixing the “misspelled text” bug tickets and nobody is bothering with the REAL problems.

Why Being Hard to Replace is Bad

I read something I’ve always followed without realizing exactly why:

Don’t be irreplaceable; if you can’t be replaced, you can’t be promoted.

I once worked with two programmers who told me they purposely wrote convoluted code. When I asked why they would do that, they replied, “Job security.” I always wondered why that company let its employees do that despite the impending likelihood that they would eventually quit and leave their mess for someone else to clean up.

Ever since then, I’ve always advocated for strict adherence to coding standards and frequent code ownership swapping. I’d like to add to the advice:

Nobody will choose to promote an individual who screws the company over – on purpose – on a daily basis.

I thought that was a neat tip to share on a Friday. 🙂