Should you give developer(s) bounty/bonus for his/her result?

Question

How would you profit the work of a software developer? I would also say team, but I speak partly about single developer and partly about the whole. I have seven years in the developing scene, with mostly all projects for internal usage of the companies itself.

I haven't still seen this kind of profit/bonus/wager-strategy for a developer's work, where I worked myself. With that say I think there are more developers out there who meet same situation, not to make the question localized.

If the development process is tied to some sort of salary or an application that sells per distribution, profit can be more natural to implement, or already have implemented. Profit-sharing of the business-win in overall is not a discussion of this (even if it fits, I refer to profits specific for the specific worker/work).

I understand that we can't talk values in terms of money, but at least how to measure a value of a work, i.e. dignity and complexity of work.

I think about a developer who has a generally high morality for work. She dies before dead-lines, doesn't leave unsolved threads (at least not willingly), is highly willing to learn for better result, etc. This does not automatically mean that she works efficiently and right on spot all the time. Just a side note for an employer's thought about a bonus program.

And ok! Who wants a robot? But I think a bounty or profit for finished work will gain

• More accurate threads (because she knows she doesn't get them back if they got status Complete.

• Developer knows where the wallet can be helped, behind an extra work on a project.

If the project manager is too busy for continuous following the status of projects, the developer can feel responsibility for follow-up. Also there are up to the developer really finish the threads/points because he/she don't want them back!

Answer 1

From the perspective of a Project Manager...

It is certainly the job of the PM to negotiate a "project reward structure" with stakeholders/sponsors. I have never seen/heard of this done for an individual, but only for the "whole team" and involves things like improving on the committed: delivery schedule, project cost, product quality, market/customer acceptance, etc. The "maximum bonus" ranges from 2% to 15%

Once negotiated, there are many options for dividing it amongst the team. Typical are:

• Each person gets the same %age bonus based on their salary over the duration they were active on the project
• People are ranked/prioritized based on either objective or subjective scale and the bonus is given only to the "top x% of the project team" in some sliding scale

If you (as a programmer) are slaving away on the project, the one piece of advice I would strongly recommend is that you ensure the work is both noticed and also providing a definite benefit. I have personally witnessed some individuals slaving away over what they perceived as high value activities, but they weren't part of the plan and weren't asked for. This type of "extra work" may appear to be beneficial to the person doing the work, but it might fight against the direction of the PM.

Also, like others have said, irrespective of any bonus or personal reward, be sure you are comfortable with your base salary. Expecting a bonus to make you feel validated or valued may lead to disappointment.

Answer 2

I'm not 100% sure I'm reading the question correctly, so please let me know if I'm missing the mark here.

If the basic question is how to you structure bonuses and other incentives for software engineers, there are a few options:

• Give them equity in the company, that way if they contribute to the company's success they get a piece.
• For more contract and engineering services companies, you can tie productivity to revenue and so giving the engineers some reward based on revenue is an option.
• Finally, you can set goals or objectives as bonus requirements. For example: Complete your piece of the project on time for your annual bonus of 15% of salary. Assuming a well managed group, I've seen this work well.

If your asking if you should, all I can say is that many companies do.

Answer 3

There should be a baseline agreement between the developer and the employer on what work will be completed at what level of pay.

The pay will generally be higher for more experienced/higher quality work. However, the end of a project is a bad place to try and get more money if you feel you were underpaid.

You can't expect extra pay if you went above and beyond the agreement. If your employer doesn't recognize the extra effort you put in, keep that in mind next time they come to you with a job.

Though, part of the problem could be in the communication between you and your employer. The employer may not know that you went beyond what was expected. This is often the case where either communication was not consistent throughout the project or if your employer is not familiar with software development.

Answer 4

I know my answer won't be complete enough, but I've seen some companies in Brazil rewarding the developers by the tasks they conclude. Think about a bug tracker not only with bugs, but also with tasks, and the project manager can assign "values" for these tasks. It doesn't matter if the value is money or points that can be traded by money or something else.

If you set tasks with values, the developers will be more motivated to complete them, since they're going to receive a bonus for it. Complex tasks wil reward more, and less complex will reward less.

Answering the question in a fast way: yes, I think you should give developers a bounty for his/her result. Even if it's not money. The sense of rewarding is something really valuable.

Answer 5

Let's reverse the question and ask Why would PM give a bonus for a work? I am not sure what is your suggested reason for doing it, so let's consider some commonly used reasons:

• To motivate employees. Well, lack of money can be a very good demotivator. Adding more money doesn't bring motivation, it rather removes demotivation (final effect is similiar), but it works only to a certain point (where employee feels comfortable with base salary). Above that money doesn't motivate or does it very very poorly. Of course many people are subjected to wishful thinking that more money => more motivation, inc. productivity, better quality etc. It's wishful because we would like to receive more money for better motivation, more work or better quality. The reality is different and bonuses/rewards go to the better politics, better sellers, better negotiators. If one wants to mess with motivation, she should know another point of view.
• To bond employees with the company. The concept is: you work on the project - you receive a bonus, so you will more likely to work with us next time. It looks nice, but it's a monster with no legs. In the long term employees will much likely to choose better/nicer work environment with better motivation and cooperation. They can be easily bought by higher rewards of the competing company. And last, but not least it does not consider status of the project and indolence of the developers.
• To achieve the goals. I am not a fan of "selling" the goals. A healthy team shares the goals and tries hard to achieve them. PM shouldn't expect them to work over hours because it affects the long term productivity. But ok, there are moments when I can understand it. PM didn't notice some patterns early enough and she needs to deal with it. She needs to pay for every extra time or set a reward for achieving a goal. Maybe she promised something at the moment of better mood. It's maybe not the best choice but it works from time to time.
• Because she can. In this case, a bonus is not meant to influence the motivation, it is not a salary for work, and it is not a tool that helps achieving the goals. Not something that is "payed instead" or "payed for". It is a bonus - it is payed despite the other factors and it express the company's financial situation or particular happiness with project outcome. Like a gift.

Edit: To answer @Jonas question in comment:

I didn't even touch the motivation-subject because it is vast.

The motivation system can be connected with financial rewards (generally speaking - something company must pay for) but it should not play a major role as it doesn't have such influence on a employee's motivation. Design of such financial rewards in most cases will strongly depend on developer role in the organization.

For example: if developer is heavily involved with relations with customers (gathers requirements, provides support, install upgrades and makes customizations) and the overall image of the company depend mostly on developer's actions then a share of profits seems as a reasonable reward. But if developer is involved only in back-office actions and she works mostly in a team (like in Scrum) then the most suitable would probably be a reward based on the team performance or on the extraordinary teamwork events.

If one 'feels' a financial part should play more important role in a motivation system, then one probably needs to think about how comfortable she feels about her base salary.