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?


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).

Ali A
I agree. A workplace without consequence is a workplace that will soon be in a downward spiral if it isn't already.
Mat Nadrofsky
I mean really really make sure like this guy here [google "will ferrell pierce brosnan boss"]
I do not need to be punished. If I screw up and my coworkers know it, that is already punishment enough. A boss thinking in terms of punishment is a reason to quit the job.
Well, we are all adults. Punishment is a reality of life. The point is that positive and negative incentives should always be balanced.
Ali A
I'm not punished at work. If I was I'd sue the company for bullying and get another job. Everyone makes mistakes sometimes, if someone is making too many they need training not punishment
I completely agree, some need training. But some need punishment. Maybe I am too old-school.
Ali A
I think punishment is the wrong word. Consequences would be better suited. If you are accurately informed of your expectation level and continually under achieve despite appropriate training, consequence needs to be present.
Mat Nadrofsky
If you can slack off all day and for the fifth time blame it on the training you didn't pay attention too, you've got it made don't you? Then you just lower the morale of everyone else around you. You gotta ensure people like this can be dealt with on your team or your team will suffer.
Mat Nadrofsky
I disagree with punishment... if someone isn't getting the job done, make them aware (privately) of the problem. If things don't improve, let them go. Punishment rarely yields good results.
What would be an example of effective punishment in a professional environment?
eg Getting sacked for continual underperformance. We are talking about motivation. So the threat of punishment can be enough incentive. Yes, perhaps "consequence" is a better term. How many people can honestly say they wouldn't get sacked for continual slacking?
Ali A
and yes, always use good people-management skills of talking privately etc etc. that all goes without saying.
Ali A
Threat of punishment is not motivation. In the contrary, it is demotivation.
Let's all sit around, dressed in tie-dye clothes, smoking weed listening to the Beatles. Code? chill out dude!
Ali A
+3  A: 

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.

Only problem with non-concrete reward systems is that without a clear set of "rules", it's really easy for people to think that the system is prone to favoritism. I think individual rewards can rarely work without causing strife.
It is a totally different problem if management likes to play favorites. If they are consciencely trying to be objective then the undefined system can work. Also, we tend to give rewards to teams, not just individuals.
It's a sad statement on the software industry when shipping on time is considered to be "something impressive"...
Dave Sherohman
+50  A: 

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.

100% on the money IMHO.
Mat Nadrofsky
"Wally: I'm gonna write me a minivan" says it all.
Right on the money indeed. In times of refactoring and IoC, I would prefer that my team write LESS code, not MORE! :)
A good motivator is to ask them for what they think would improve things, and then act on their suggestions.
@Kieveli That's not only a good motivator but also the best way to really improve your company. Incremental bottom-up improvement. Japanese call that Gemba Kaizen.
+3  A: 

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.

Mat Nadrofsky
+2  A: 

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.

+9  A: 

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.

Gift cards may be a great idea. Easy to get since stores always want new potential customers. We liked getting them. Even if i had no interest in some particular store, the cards made good tips to give waiters, or trade with someone for something interesting.
Sometimes a sincere "Thank You" means more than a gift card. When you get a gift card or dinner project after project for working insane hours, you start doing the math (if you havent' already) and realise that you net about 2c per hour for all your overtime. Rather remove the reasons for the insane rush every project: Are the deadlines arbritary? Are your teams skills up to date? Do they have a quiet work area where they can be productive. Are they burnt out and unable to function at 100%? Do they have the right equipment?
+8  A: 

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.

+19  A: 

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.

+7  A: 

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....

I don't think working hard means working on weekends or evenings.For the rest, I agree with you :)
Fair enough... working hard can equally mean not doing too much "displacement activity"; surfing slashdot, xkcd, bacefook etc.
...stackoverflow? ;)
+38  A: 

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.

Aaron Digulla
You are so right about sending people home. Overworking often results in less actual work being done, more technical debt, and more overtime work to meet deadlines..
Lars Mæhlum
1000 lines of code a day? You're kidding, right?
Code Trawler
Good points. I would add whiteboards, lots of whiteboards, to the mix.And let people buy as many books as they want, get a nice shelf and put it in a place that anyone can see (or in the "quiet room" that you mentioned so people can take some time off and grab a book to read)
Also, make sure to swap the members in the maintainance team at regular intervals(those fixing old bugs). Fixing bugs all the time is a real demotivator.
Nailer: I agree. I just don't want to add this to my answer in order to keep the size reasonable. There are many more things that could be mentioned but it has to end somewhere :)
Aaron Digulla
Nice info, but what if you don't have any extra rooms for all this stuff? Sadly, even the management of the development team often doesn't control over how much space is available.
Then you can still try the other eight things. When one thing in my list doesn't work, this doesn't mean you have to give up all hope :)
Aaron Digulla
a programmer who is writing 1000 lines of code in a mature project is most likely to make 950 mistakes per day.
Andreas Petersson
@Andreas: Agreed. Just keep in mind that a pupil needs to take in information from the mountain of knowledge one piece at a time. Shoving them under the Waterfall of Truth and ripping their mouth open is not what you want ;)
Aaron Digulla
1000 loc? I remove 5 lines without introducing bugs and call it a good day.
Christopher Mahan
+4  A: 

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.

Michael L
+6  A: 

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.

+1  A: 

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!


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.


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

Peter Tate

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.


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.

Michael Beck
+2  A: 

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.

Dave Sherohman
+1  A: 

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

+2  A: 

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.

JB King
+1  A: 

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