Joe’s Blog

Slate recently posted an article about incentives in the fruit picking industry and how they can increase productivity. Naturally there is a big difference between fruit and scripting, but it begs the question: can we do more in the tech industry to link income to productivity? I think we can.

A hard problem to solve

In most organizations the developers are some of the highest paid employees. They get paid well because their skills are scarce and hard to reacquire. This leads to entrenched “senior” developers who produce little, but “know” (and therefore get paid) a whole lot. It also shifts the emphasis to stability and away from being quick, nimble, and adaptive. Over time this turns your development teams into an occupying force rather than a fighting force.

How can we shake things up?

Code Cookoff

Last spring our tech team (from my day job) engaged in a week long experiment to see how quickly we could clear out old code. We called it a Cash Code Cookoff.

The economics were pretty simple:

1. Delete commented out code: $5
2. Delete unused files/functionality: $10
3. Re-write a bad section of code into a good one: $25
4. Roll out a bug that someone else catches: -$20
5. Track over 75 items as a team and everyone gets an extra: $100

We’re a small team in a small company. Two years of scramble coding had left us with a lot of dead wood to clear out. The whole project cost less than $1000 and reduced the file size of our code base by nearly 90%.

Being productive

The combination of the team goal, the encouragement from the business side, the payout, and the novelty of the program helped make the Code Cookoff hugely productive.

In an interesting twist, the guy who got the most done and therefore received the highest payout was our newest developer. Besides being really aggressive he took the idea seriously from the start and was immediately able to see how his effort contributed to his paycheck. It didn’t hurt that I let him wonder through my obese code base to make deletes

Watching the money grow

When you are already valuable to the company there is little reason to move quickly with dev projects. But with a pay incentive this hierarchy turns on its ear and twice the work means twice the reward. While salary information is normally kept secret, work incentives are public. Employees are free to compare themselves with each other and to compete. They also have the satisfaction of being rewarded with each completed item.

You want team members thinking

“I could always do more today”

and not

“I’ve done enough for today”.

Quality as a business aim

In many companies it is difficult for the business folks to see developers as are much more than glorified copywriters. The difference being that they can’t read what we write and so they don’t care about code quality. They care about the next feature, bug fix, color change, etc. But not quality.

The Code Cookoff gave business incentives and overt permission to focus on quality. It let developers scratch that long neglected itch and go back into their code to make things better, cleaner, smarter, and slicker.

It also penalized developers for bugs in a very public way, increasing awareness of how changes impact the customers.

Base it on headcount?

The Code Cookoff was a wonderful success, but could it scale beyond a week? Let me suggest an idea: base it on headcount.

In this system you could offer an individual incentive for each item and a team incentive for each item. Complete an item and you get paid $20. At the end of the period everyone gets $10 for every item the team completed successfully. This encourages collaboration as every item completed matters to each team member.
To make it interesting, you should tie the individual rate to number of team members. Unable to keep up with the work? A new hire means that the individual rate for everyone falls by 50%. But you can make up for it by getting significantly more done as a team.

Example

Consider the following chart:

So from the business side there would be a sweet spot where increased productivity would “pay for itself” by delaying the need to hire additional developers. Likewise developers would be rewarded for their efforts and would be more apt to keep an eye on each other to make sure “stuff was getting done.” Increased productivity at the team level would offset the drop in the individual rate over time because the team as a whole gets more productive.

A key aspect would need to be manager oversight to make sure payable “items” involved work and not just answering an email or support question.

Thoughts?

What do you think? How would you incentives your tech workers? What holes can you poke in this approach?

* Update:

As Dan pointed out, Joel Spolsky lambasted the whole idea of pay incentives in his own blog post. He makes some good points although I’m not sure I agree with the whole argument. In a small company where your dev team is your operations team it could easily make sense to reward people for driving their area of the product forward. Its hard to tell if that reward should just be your salary or some other kind of incentive to increase productivity/focus.