Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Bonus Scheme for Software Developers

Status
Not open for further replies.

RBSTR

Programmer
Nov 10, 2005
71
GB
Hi

I manage a small team of software developers.

We are looking to introduce a bonus scheme.

The team develop commercial projects and also involved in the day to day support of these projects. We are planning to migrate the support role to our dedicated support team over the next year.

I need to come up with some ideas for a bonus scheme - and my current thought is along the lines of a previous scheme I was exposed to.

Developer would receive a percentage of the revenue of the project developed and of the first year's support contract (on the consideration that they would be involved with initial support which would then be migrated to the support team).

Where I am unsure of this plan is of the projects that are worked on by more than one member of the team. I'm thinking maybe make an agreement before hand that Fred would receive x percenatge of the revenue and Joe would receive the remaining y. But then I guess this may need to be revisited during the project lifespan where project dates and tasks may switch.

I also need to ensure team members on an existing bonus scheme are not penalised by this new scheme (maybe cap their bonus on this new scheme so it won't be less than what they got on the old scheme?)

This scheme needs to beneficial to the employee and motivate them suitably. On the other hand I want it to be easy to administer and calculate.

Any suggestions would be appreciated.
 
It sounds a little unfair...unless the developers are also the salespersons.
 
My personal opinion is that the word scheme adequately describes how I would feel about this. My bonus will be based on sales performance that I personally have no control over? What if the company through no fault of the developer decides not to sell the product, then I get no bonus? How about if the prpoduct fails becasue Joe's part of the software is buggy but mine isn't? Why would I want to share my part of the profits with the guy officially assigned who did little to nothing usuable towards the project?

Personally I would be more motivated by being paid a fair to outstanding salary with no bonus hocus pocus nonsense. You only need bonuses if people are being poorly compensated on a day-to-day basis.

"NOTHING is more important in a database than integrity." ESquared
 
I would say if you want to do a bonus determine a set percentage, say 10% of salary, then give specific goals that can be both measured and achieved to the team. Then give them a percentage based on if they meet the goals.

Example.

Fred makes $20,000 per year

Bonus = 2,000

Goals,

Resolve 95% of all support issues
Limit unscheduled down time to 3%
Complete XYZ job related certification
Work 2040 hours

Totals

Support calls for year - 100
Down time - 3%
Completed XYZ
Worked 2040 hours

Fred's Bonus.

Support Calls = 105.3% (5 calls over)
Down time 100%
XYZ 100%
Work 100%

Now each part would be worth 25% of his bonus

Support calls = 526.5
Down Time = 500
XYZ = 500
Work = 500
Total = 2026.5

I know it's kind of convoluted and a little confusing but as long as the goals are kept measurable, achieveable, and specific then most people would be happy with the bonus even if they don't fully understand the process. Obviously the above is a very simple example (and I really hope you pay them more thank 20K :)).


--Dan
Whenever you find yourself on the side of the majority, it is time to pause and reflect.
Mark Twain
 
I completely agree with SQLSister (again!). Please drop the word 'scheme' first and foremost. Next, determine what type of goals there are in the development of your product. If, for example, you'd like the front end built by June 1, the back end built by Sept 1, and have it go into full production by Jan 1 of next year, use those percentages against what you would like to pay out total. Then, the only thing you'll have to do is pay the bonuses on time. You need to make exceptions for people who come in and change the scope of the project (not the developers fault), and for extra bells and whistles that the developers added that makes the product better.

If you view it as a scheme, so will they.
 
I think I would be concerned about possible unintended consequences of whatever bonus sche..., ahem, system you introduce upon overall team performance.

It's all very well having these carefully measured metrics reflecting each person's performance and ensuring that Bob doesn't get penalised for Pete's screw-ups (and vice versa), but you could get each person focussing solely on those tasks which affects their bonus and ignoring anybody else's (or the team's) priorities.

I'd be inclined to put more weight on team goals, say some kind of profit sharing scheme. You want to get everybody focussing on the whole team scoring a success, rather than concentrating too narrowly on their own work area.



-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 
To be fair, in British English, as I understand it, 'scheme' does not quite have the negative connotation that it does on the left side of the pond. 'Plan' might be a better way to say it in America.

Da mihi sis crustum Etruscum cum omnibus in eo.

 
I hear scheme and I think multi-level marketing which = scam
 
Another problem with bonus plans is that they can place importance on things which can be measured, rather than measuring what's important.

There's a lot of intangible stuff which it's difficult to put a number on, but which still have a big impact on your bottom line. That's why I'd look at profit sharing instead.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd
 

Really appreciate everyone's comments. It's given me lots to think about. Keep them coming.

Thanks for your comment Flapeyre. I am UK based. I've been scratching my head a little about my use of the word 'scheme' and the reaction it brought. Let me say 'plan' from this point on...
 
Another comment. Why a bonus plan? Just give em more money on their weekly, monthyly, bi-weekly checks.

--Dan
Whenever you find yourself on the side of the majority, it is time to pause and reflect.
Mark Twain
 
The best advice I have ever recieved around bonuses was "always plan to pay out at minimum what you are offering as a bonus"

Meaning... make it achievable. Your plan should definitely be based on metrics that your team has control over, which sounds like would NOT be sales. Collaborate with your team to set the goals for these metrics. They should be achievable, but still take some work to achieve. This way it is a great moral boost when they achieve their goals (and their bonus); a win-win all around. If someone does not achieve their goals, the converstaion is not about not getting the bonus, but rather about this individuals performance and whether they belong on this team.

Hope this helps,
Matt
 
Bonuses are a demotivator. I've seen people work ridiculously hard to achieve a bonus once and then find out that after taxes, etc it was only a hundred dollars or so. You can bet they didn't put out the extra effort ever again. I've also seen people furious because the boss got a huge bonus for the work they did (in spite of him not because of his leadership) and they only got a 2% pay raise. Again a huge demotivator. I once watched my boss receive a big national award (this was a government job) and every single thing they said he was responsible for I did (not even anyone else on the team did these things, I did every single one). Yet somehow I didn't get any awards. Not such a good motivator, I can tell you.

I like Matt's advice though. Budget to pay out to everyone. If you don't then you get into denying someone a bonus because it is someone else's turn because he got denied last year. Again big demotivator. Or you end up paying everyone but an amount so smal that no one cares.

"NOTHING is more important in a database than integrity." ESquared
 
Bandenjamin (Programmer) 21 Mar 08 10:57
I would say if you want to do a bonus determine a set percentage, say 10% of salary, then give specific goals that can be both measured and achieved to the team. Then give them a percentage based on if they meet the goals.

I think that if one is to implement a bonusing system, this is the way to go about it. It is the way the last few companies I have worked for have done it. Beginning of the year (or near to) we are give a list or goals and deadlines for projects or learning new tasks/technology/efficiencies - how well we meet those targets & deadlines determines our eligibilty. The one varying factor between my current employer and the previous is that my previous had preset percentages for our maximum bonus based on salary grade - nice to know in advance the most you will get, but a little demotivating when the higher up the grid you went, the higher the percentage got as well. My current employer takes a percentage of corporate income at yearend and sets a blanket percentage across all salary ranges - a methodology I personally fine far more fair.

The "SMART" method for setting goals is a common practice within the two corporations:
Specific
Measurable
Atainable
Realistic
Timely

Hope this helps. :)

Mike
______________________________________________________________
[banghead] "It Seems All My Problems Exist Between Keyboard and Chair"
 
Really, I'd prefer a dual bonus system. One that insures that big profits equate to bigger bonuses but one that also gives a bonus based on individual effort. Effectively a bonus plus profit sharing. The bonus should be based on individual effort and should effectively be part of the salary - the part that makes the yearly wage attractive but not so that without it people are getting below industry standard wages. 10% is a descent value for bonus and should be achievable and flexible based on changing business needs. It is terribly unfair to penalize an employee for not achieving some item on a checklist because they knocked themselves out taking care of other things that came up throughout the year.

Sharing profits creates a motivation to do things and contribute beyond the individuals regular measurable responsibilities.

Anyhow.. those are my thoughts on the matter
 
Since this thread has reactivated, my 1p worth:

SQLsister is right, and more.

Any bonus plan that pays out to 10% of the workforce will demotivate 90% of the workforce; and worse: it will probably demotivate each individual in the 90% more than it motivates each individual in the 10%.

The fundamental problem is that mostly, those in the 90% will compare themselves to the 10%, and find ways in which their output and abilities are equal to the 10%, so they will feel ill-treated.

Meanwhile, the people who get the bonus spend it, and the next year don't have a bonus, and notice the hole in their wallet, so their happiness is short-lived.

The only situations that avoid this are ones where there is really only one output, and pay is by straightforward "piece-work". If you are assembling Grooks, and the rate is One Saturnian Dollar per Grook, no one has any problems because it's clear that the chap who assembled 327 Grooks should get 327 Saturnian Dollars this (Saturnian) Month. Even here, resentment will brew unless all Grooks are scrupulously equal.
 
I once worked for a small company where bonuses were paid out based upon reviews by coworkers. Unfortunately, as the only IT guy and programmer, not only did my coworkers not really understand what it was that I did, but my mistakes were highly visible while my successes often went unnoticed. They noticed that several of my deadlines had slipped while not realizing that the causes behind this were complete specification changes, desktop support issues, and emergency customer support tasks (all of which were beyond my control). In the end, I was one of two people who did not receive a bonus. I put in my notice shortly after that.
 
I agree that bonuses are probably not a good idea. Why not just take whatever amount you would bonus the employee and roll it into their next raise? Then they'll see, by the size of their raise, that they're appreciated. At the same time, I think its less likely they'll continue to expect every raise to be as big.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top