How to Structure Bonuses for Software Developers? [duplicate]

Question

I am a software developer, and have been asked to define a bonus structure for myself by recommending the metrics that will determine my bonus. I think, once I have defined this bonus structure, there is a decent chance that it will end up applying it to other members of my department. So, for personal and professional reasons, I want to try to get this right :)

I am wondering, what do you guys think are fair and accurate measurements of a software developer's performance? And, if you are a developer or manager of developers, what metrics does your company use to measure developer performance?

Answer 1

First, watch this.

Then, think about how you can create a bonus structure based on the findings of the research in that clip. :)

TL;DW version: Traditional carrot and stick reward structures only work on purely mechanical labour. They don't work for knowledge workers. Really all you can do to motivate knowledge workers is give them interesting work and autonomy.

Answer 2

IME & HO, bonuses do more harm than good. There's no easy way to objectively measure performance, so it often comes down to how well you get along with the person making the decision. It can become very divisive and really hurt the org.

A far better method is to pay everyone well enough that they don't need to worry about money and then cater to their other needs: interesting work, self determination and a good working environment. The occasional "thank-you"-type gift can work if done right: we all (regardless of pay and performance) got iPads for Xmas.

I know that all sounds very socialist, but breeding competition between peers can just distract them from what you actually want them to be focusing on.

Answer 3

Bonus structures tend to work best when they are applied to the entire group, not to individuals. Otherwise, instead of fostering cooperation, you encourage competition, and the developers won't work together to make the best possible software.

That said, you need something for individuals who exceed the call of duty, and a way to prevent slackers, who are rewarded for being in an otherwise well-performing group.

Non-monetary incentives (such as extra days off, catered lunches, day trips or other special activities) can often be more effective than incentive pay.

Incentives must be considered carefully, to avoid unintended consequences. See http://www.joelonsoftware.com/articles/fog0000000070.html

Answer 4

1. Product Milestones: The simple method for measuring success of a product team.

2. Revenue Generated: Another method of measuring success could be to base the success on revenue generated from a product release. Are the developers focusing on the things that lead to profit? (Remember, the purpose of any business is to make a profit.)

Of course, most people are intrinsically motivated, meaning they are motivated by the satisfaction of knowing they did something great and beneficial.

There have of course been studies conducted and blog articles written that suggest that incentive pay is harmful.

a positive review makes them feel like they are doing good work in order to get the positive review... as if they were Pavlovian dogs working for a treat, instead of professionals who actually care about the quality of the work that they do.

I disagree.

So what does that say about the owner of a business whose income derived from the business's profit may fluctuate based on good or poor strategic decision-making?

Business owners aren't incentivized because some manager dictated that as the way he/she will be compensated. Instead, they're incentivized naturally by the capitalist market system. The plain and simple fact is that if the business does well, the business owner is rewarded. If the business does poorly, the business owner is not rewarded.

Does that then mean that clients and customers should be understanding of the business owners predicament and offer some alternative form of reward? Isn't the business owner someone who needs to hear the 'atta-boy' too?

The bottom line, the truth of the matter is that this capitalistic approach has worked for centuries.

I believe that financial rewards, such as profit sharing, are beneficial in terms of getting everyone on the same page in regards to what's important. As long as all parties in the organization have ownership of an area that directly contributes to the profit of the business, then financial rewards can help everyone think more carefully about how their decisions affect the organization.

Again, this only works if you are in control of your destiny. If you, as an employee, cannot make decisions, then this will be harmful to your motivation.

Should financial rewards be the only rewards? I don't think so. I believe the research clearly supports the fact that people are motivated intrinsically and want to feel important, but I also want my developers to be thinking about how their decisions impact the bottom line.

When you're financially motivated, like the owners of the business, you're less likely to spend all your time thinking about how to costly redesign old, ugly legacy systems simply because it bugs you to see if(true) in the code. When there are dollar signs at stake(or laks, euros, etc), then you are more likely to think about how to generate revenue instead of how to spend it.

DISCLAIMER: I have experienced this first-hand as a developer. The financials have made me think about how to make money, and this has helped me think like an entrepreneur.

Answer 5

Do not let them take you into a bonus driven situation where the bonus is based on so-called objective measures.

In all my 25 (almost 26 :-) now) years of being in IT as a developer I have not yet come across a so-called objective measure that cannot be perverted. Lines of code once was the golden measurement, until people began to write incredibly long comments that didn't say a thing. Check-ins got perverted by simply checking in each file separately...

I would have posted the same video @Bobby Tables did if I had seen your question earlier. Have been in situations where bonusses were part of the game. They only tend to make cooperation and getting help from your colleagues harder.

Your management (and you!) should think hard about what you want to stimulate in the development team. And the bonus system should be based around that. Yes, that means very subjective traits and measurements, but despite the draw-backs of subjective evaluations, they are ultimately far more benificial than artificial so-called objective measurements that promote the exact opposite of behaviours that you would like to see.

There should be some kind of worker-evaluation in place based around the qualities that really matter to your job as a developer. The best bonus system I have come across is based around the company's performance for everybody and adjusted up or down based on individual evaluations.

For example: The company's has reached its goals for the year: everybody in principle gets a month salary as a bonus; but the economic outlook is really bas so that is cut in half. Evaluations of all workers are on qualities important to their jobs, scaled from A (way worse than what is expected) to E (way better than what is expected). Worker A receives evaluations averaging a C -> gets him the standard bonus. Worker X receives evaluations averaging a D -> gets her the standard bonus plus 10%. Worker Z receives evaluations averaging a B -> gets him the standard bonus minus 10%.

This seems to work best as evalutions like this can be geared towards behaviours one would like to see, such as co-operation, helping and coaching less experienced workers, leadership, etc. It works best when the evaluations are prepared by someone in a direct leadership position over the worker being evaluated. That can mean the development manager, but also a team leader without further hierarchical say-so.

The evaluator, especially when they are not in daily touch with the evaluated person, should always get input from direct co-workers and other people who deal with that person regularly. Input is best gotten in an informal manner as people not accustomed to evaluating others, usually don't like the idea of feeling responsible for the height another's reward.

Answer 6

Use any hard metrics is bound to fail in my experience because as people realize what that metric is they will start tailoring their work to meet that metric in ways that are counterproductive.

Whatever that metric is, lines of code, bug rate, number of bugs fixed; any objective metric can be gamed.

As an aside, I don't really think bonuses are a good idea. They tend to incentivize bad behavior - just look at wall street.

Answer 7

I think that the metrics should be based on what the purpose of the bonuses are. In other words, what are the goals the company is going for by offering bonuses?

For example, if the code base has a lot of bugs, it might be reasonable to have a metric like, "if the number of bugs found in features that you wrote this quarter is 10% less than the previous quarter, you'll get a bonus."

Answer 8

Simple objective measures are misleading and inaccurate. Complex objective measures are slightly less inaccurate, but even easier to "game" and be misleading.

I suggest some form of voting or polling among the development team. For an off-the-cuff instance, everyone can vote (anonymously) for the top three contributors at management/support level, senior level and junior level (obviously, you can't vote for yourself). The top three in each category get bonuses. It's important the the votes be reported completely anonymously, but each user gets only X votes.

Vary the exact scheme to match your environment. Some possibilities: Everyone gets some bonus; amount varies by polling results (with a minimum award). Fewer or more categories. Add an overall category. Different categories get different numbers of votes. People get different numbers of votes for their category. Etc.