Are programmer incentives a good idea?

Question

I would like my programming team to be more productive and it has been suggested that the way to achieve this is to provide incentives to make them work harder and / or longer.

Does anyone else work in an environment where bonuses are offered for completed work? And if so, does it help?

It's been suggested that an Xbox or Wii could be bought for the team, or the team could get extra holidays or a cash bonus. Would these actually motivate people and make them more productive? Should we only reward the people working on a successful project or the whole team?

Can anyone suggest a better approach to motivation and productivity?

Answer 1

Always balance the "stick" and the "carrot".

So yes, give them the Wii, and let everyone play, but make sure you punish people properly at the same time (if they deserve it).

Answer 2

We use incentives at our workplace, and I think they are very effective. Only we don't dangle it in front of them, or even mention it is a possibility. Simply wait till they pull off something impressive (like ship on time) and give it to them.

I think the biggest thing is you can't make the reward system something concrete, if people know all the rules they can game the system. Which isn't going to produce better software.

Most importantly, treat the programmers like first class citizens (you may be doing this already). Give them the latest and greatest hardware (A new mac book pro goes further than at $5000 bonus, IMHO). And encourage a good environment.

Answer 3

I think bonuses can work but usually do more harm than good.

If you give someone a bonus when the rest of the team doesn't agree the loss of motivation in the rest of the team is much worse than the increase in motivation for the person getting the bonus.

Bonus systems can be gamed. If you give people a bonus for LOC's people write more LOC's to implement the same feature. If you give people a bonus for more bugs solved people write more bugs so they can solve them, if you give people a bonus for features implemented they implement more features instead of reducing technical debt.

I think just paying people well. Making sure they have a good environment to work in with smart co workers and interesting work and making sure they have the opportunity to have pride in their work is a far better motivator than a bonus.

edit I didn't read the question completely and only answered the bonus part. I think having a place to "hang out" with the team playing console games is a good idea. This partly depends on the team. I've worked at places where most people had children and only worked from 9 to 5 so hanging out after work was not an option for them. But in general this can get a team more motivated.

Another idea I like but haven't seen in practice are team incentives. Celebrate team accomplishments. Make sure this doesn't turn too competitive between teams though, a little competition is good but too much competition can make people lose sight of what's good for the company instead of what's good for the team.

Answer 4

This is a can of worms in my opinion. What are the team dynamics currently like?

The reason I say this, is if you start giving them a Wii just for getting their job done, you've really just rewarded them for what was already expected. Working longer hours or putting in the effort to get a job done should be driven by something other than getting a Wii.

I'd look at the team. Do you have anyone that is a downer on the rest of them? Do you praise them when they complete tasks? What is the feedback loop like with management at your place of work? A lot of these things can make a difference and impact productivity.

Giving them a Wii might solve the problem for a single project, but if you want a winning team that gets things done and is proud of it, that isn't the way to go.

Have a look at The Five Dysfunctions of a Team by Patrick Lencioni. Great reading and will offer some key insight into how to fix this problem once and for all.

Answer 5

Buying the console can help motivate until the team starts to game (no pun intended) the system to look more productive to start playing sooner.

A good motivation for developers is remove all the roadblocks that are getting in their way.

Answer 6

First, it's a dangerous thing to suggest that a reward might be granted, if it never materializes. I worked in one company that talked about various incentives like this several times, but most of what was talked about never appeared.

A team "toy" like an Xbox, Wii, foosball table, etc. has a downside: management will negatively view any time spent using it.

I've seen cash bonuses work pretty well - gift cards, etc. They have to be tied to something specific, and I'd also suggest that it shouldn't be an expectation. The point of a bonus is that it's a bonus. If they expect to get it anyway, it's just standard compensation.

Flex time, vacation time, etc. is also an available alternative. If we'd worked late into the evening, my manager would often tell us not to show up the next day until noon, for example, or take a 3-day weekend after a milestone release.

Answer 7

If the environment is bad, if the communication among developers and between them and the management is bad, there's no money or prize that can make them more motivated; actually, the opposite could happen, people could start communicating even less because now they are eyeing the prize, and they won't help the "competition"; Besides that, people will always find ways to "game" the system and reach whatever is the goal so they can win the prize.

I don't think money can solve motivation problems, as long as the developers are paid fairly.

Now, a party for everyone if the product is released on time, or when some other milestone is reached (e.g a certain percentage of code coverage is achieved, the number of bugs is reduced to some magic number in the bug tracking system), that's cool. The key is to involve the whole team, not single out people.

Give prizes to more specific achievements such as when someone gets a hard certification is also nice.

Answer 8

Hire the right people. Treat them well because you value them -- which may include buying a Wii for the team room or snacks or dinner out periodically. Pay them well because they deserve it. Make them go home after 40 hours at the office if necessary. Reward the team for good work, not individuals. If some individuals deserve it and others don't or some feel they deserve more than others, then you've hired the wrong people. Except if the team says, "Give it to Jane, she really came through on this project," then you've really got the right people.

Answer 9

IMHO, the best way to get people to work hard (even weekends/evenings etc) is to give them interesting projects to work on. As engineers most of us enjoy getting involved in challenging projects. Look at the amount of free time people will devote to open source projects that they're interested in for example.

Easier said than done of course....

Answer 10

You say "to make them work harder and longer" ... let's see.

The average programmer writes, say, 1000 lines of code per day and puts a constant amount of bugs in that code which is usually around 7.

If you make this guy work four hours per day, he will write 400 lines of code and make 10 bugs because he's bored, feels unappreciated or because he's thinking about his other job all the time or how to pay his bills.

If you make this guy work 10 hours per day, he will write 1200 lines of code on the first seven days with 20 bugs every day and after that, he'll write 500 lines of code and make 50 mistakes because he's worn out.

So, yes, you can make them work harder and longer ... if your ultimate goal is to ruin the result.

If you want them to be more productive, you can try these:

• Give them the right tools: Fast PC with enough RAM, two screens (one for the web browser and the other for the IDE).
• You make sure that they take their breaks. One trick to achieve this is to give them free drinks. One short break per two hours guaranteed. And there is no way any developer can drink soda for more than $100 per month, so it's cheap, too.
• You send them home after eight hours. Kill the power if you have to.
• Assign a different member of the team to pick of the phone every day. He takes all the calls and dispatches them.
• One stand up meeting every day for 15 minutes so people can sync.
• Set up an empty room nearby for discussions so other aren't interrupted
• Add green to their rooms: Buy some plants.
• It's okay to ask them to work overtime for a few days, max. a week.
• Give them a budget to buy software and books so they can get their work done in time [Thanks geek_in_belgium]

[EDIT] I made the number above up, obviously :) They are just there to give you the idea. Some real numbers can be found here: How Many Lines Of Code Should A Programmer Expect To Write In A Day. Of course, lines per day means nothing if you don't mention the language or the experience of the programmer.

Answer 11

The main problem I see with short term cash incentives is that the employee develops a diminished respect for his/her typical renumeration. In my experience the best way to motivate employees is to be up front with them from the start, and also have some real interest in the employees medium to long term future.

All employers are able to hire and pay developers, but very few go that extra mile and invest time in training and maintaining the developer as an investment.

I think if any cash incentive is offerred it should be on an annual basis, perhaps a 13th cheque, this way the developer can continue to work for standard renumeration for the rest of the year without despising his/her standard rate.

Answer 12

If you budget a 100.000$ profit and got 140.000$, then take x% (10%) of the money that was over the budget and give back to the group to use together, maybe to buy stuff, travel to other countrys to attend konferences, have a big kick off or other things.

Individual bonuses are unfair, because some have to work on internal system that do not generates money, some work on projects that not will generate money in a couple of years and some work on support, testing and so on. Its harder than you think to get a working bonus system that is not unfair against someone.

I prefer to work at places that have group bonuses, you feel more like a team then, and work together to the goals.

You should not have a bonus to get people to do their work. The bonus should kick in when the company does better than expected, not to stop it doing worse.

Answer 13

One great motivator for the team: Let them feel they own what they are working on. Make it "their" project. Assemble teams that work on specific projects and give them a share of the income earned by those projects, as their bonus.

I can feel this is the best way of motivating team members, and when I found Google was doing something like this, I thought they stole my idea!

Answer 14

It is good idea to make them think that they deserve benefits which are offered. So it is not paying in advance or opposite, promise to pay if ... which never becomes reality. There should be provided method to improve and motivation in form of incentive. If team will believe they deserve more they will tell you what they want and what they are ready to do to get it.

Answer 15

Of course incentives work, they just might not work the way you want them to!

The trick is deciding what reinforcers to use. What is a reinforcer? It is an incentive that produces a desired behavior. How do you know if your "incentive" is a reinforcer? You measure! Of course measuring is hard. As others have pointed out the easiest things to measure aren't always the most useful. Also, as other have already pointed out, any kind of measurement can (and, over time, probably will) be gamed. That doesn't mean shouldn't measure. You must use your brain to interpret the results, measure more than one thing, and continually try to improve your measurements and methods. There's a whole branch of psychology that deals with this called Applied Behavior Analysis. Unlike other branches of psychology (as espoused by Freud, Maslow, etc.) ABA deals with externally observable changes in behavior rather than attempting to determine the inner workings of the brain (feelings, wants, needs). I like to make the analogy with software development processes. Most branches of Psychology are analogous to defined software methodologies processes (Waterfall at the extreme) which are prescriptive and attempt to model development as a series of well-defined steps to follow to produce the desired result at the end. ABA is analogous to an agile approach (e.g. Scrum) which uses an empirical model by looking at the end result (working software, desired behavior) and modifying the inputs (requirements, working environment, incentives).

How do you know what to use as an incentive? There's lots of great incentives, but whether they work or not depends on the organization, the team, and the individual.
- choose the behavior you want to change (overtime, lines of code - caveat: I don't think these are very good choices, but they are easy to measure and serve the purpose of this example) - baseline the behavior (use historical data if you have it) - offer your incentive - observe changes in the behavior - watch for unintended side effects

Answer 16

Like many things in the world, we can learn a lot from Dilbert.

Wally - "This afternoon, I'm going to code me a minivan!"

Nuf' said.

Answer 17

I don't know about giving them a Wii or something. That doesn't seem like it would be very productive. Maybe taking the team out for drinks or something once they've reached a milestone or managed to solve a particularly difficult problem would be a better solution?

Small things that the team can enjoy to celebrate the fact that they're awesome. To me, getting a Wii seems less like a treat and more like an excuse to go and sit on the couch and play games.

Answer 18

Why do you hire programmers? Seriously, why? Think about it for a minute.

If your answer is "to write code", then think about it some more. I don't know what your reason is, but I'm pretty sure that's not it. Writing code is merely a means to an end.

Are they there to create internal systems that keep your company running? Or did you hire them to produce a product for sale to customers? Or for some other reason entirely?

Once you know why you have hired your programmers, then develop an incentive system which rewards them for accomplishing that purpose. If they do internal support systems, reward them based on the reduced cost of operations in the departments they support. If they're developing products, reward them based on those products' sales.

Don't reward them based on lines of code written or function points implemented, because that's not what you hired them to do.

Answer 19

There is a lot of research that rewards turn off creativity or performance.

Answer 20

Bonuses can backfire if they become expected, IMO. I work and have worked at places that have what they call performance-based rewards which means if the company does X, then we get bonus Y and sometimes some of that bonus comes through and sometimes not. At one of my dot-coms, it was a rather nice bonus system they had that you could get up to 15% of your annual salary as a bonus where half was based on personal performance and the other half on the company's performance. I thought it was a rather neat system. Both places that had bonuses used a 4 point grading scale though there was a little difference between them as in one place a 2.0 was considered acceptable but at another place it was 3.0 that was considered acceptable so it can vary.

For myself, there are a few different ways a company can get more out of me:

1. Team/friendship building. If I'm working with a group that I feel has my back, that will likely get me to give my all. Granted this isn't exactly an easy thing to create out of thin air, but if it is built then it can be hard to tear it down, IMHO. This also includes my boss being that sort of like a friend that takes care of me in a sense. I remember one company having a bowling party after a big project was done that was a rather nice time and something that I wouldn't mind having every so often.

2. Understand what matters to me. Do I get flexibility if I need it? Will people come in on the weekend to make a big deadline? Is there a sense that the team is the big focus and not just our individual derrieres? If someone brings in a treat, is it something someone knows I really like? Some of this is like the first one though a bit more explicit in terms of what is offered; something that I can see a, "Yes, you have listened to what I like and are acknowledging that." If you know I'm a hockey fan and I find a puck on my cube, that may bring a smile to my face and make me want to give some more possibly. Also in this is to see how well different people can handle different roles, e.g. how good of a tester am I compared to Bob or which of us is a better BA? The comparison here is more about letting people use their strengths rather than forcing them to work on their weaknesses, using a Marcus Buckingham understanding of strength as there is a subtle difference in his compared to conventional wisdom, IMO. Another way to view this is that if one is in a great evironment then they can do so much more than in a sucky environment. Do I have good tools and know how to use them?

3. Show me that my core values are upheld where I work, and not just lip service. This is kind of tricky as it does require instances where various virtues can be shown as well as what hierarchy is there,e.g. does the company value loyalty over honesty? I think this falls back under the previous ones but it is worth singling out this way I think as if someone goes to work where a company is sucking out their soul, there is only so much a person can take. That probably sounds scarier than it is in most cases, I'd think.

Answer 21

The way to make ppl work harder and longer is to allow them to work on what they really enjoy.