Implementing performance-based bonuses
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
14
down vote
favorite
I'm trying to create a developer-centric compensation policy. Which is to say it focuses heavily upon transparency, flexibility, and fairness. Many aspects of it are influenced by the Stack Exchange policy, described here.
However, I'm feeling a bit stumped about how to best include performance-based bonuses into the model. I feel this is essentially required since all developers in a given position will start out with the same base salary, and since I want 1) for there to be some incentive to encourage people to put in some extra effort, learn new skills, etc., and 2) for top-performing developers to be able to earn more than the bottom-performing developers when there's a clear and measurable difference between the two.
So there are some pragmatic questions, like:
- What's an appropriate cap on the maximum bonus amount? Currently I'm thinking 10%, but I feel that might be too low?
- What's a good time interval for conducting performance reviews? Currently I'm thinking annual, but maybe quarterly allows better flexibility?
And then there are more conceptual areas of concern, such as what's the best way to set performance objectives? Or if objectives aren't explicitly set, then what becomes the metric used to assess performance?
I'd like to avoid implementing systems that rely heavily on self- or peer-assessments, and other mechanisms that are likely to encourage unhelpful corporate politics (or gaming of the system).
I've worked at companies that used MBO for this, and I suppose it worked acceptably well in terms of not creating negative politics and being difficult to game. However, it was a lot of overhead for both employees and their supervisors (who both had to do a few reports each quarter to set up goals, track progress against them, and then review the progress at the end). Are there comparable strategies around that are more "lightweight" than MBO in terms of overhead?
Note that it's important for the bonus implementation to fit nicely within the rest of the compensation policy. Which is to say it must be developer-centric, transparent, and fair. What approach best fits these requirements?
For reference, you can find my current draft of the complete policy here.
company-culture company-policy compensation bonus
 |Â
show 1 more comment
up vote
14
down vote
favorite
I'm trying to create a developer-centric compensation policy. Which is to say it focuses heavily upon transparency, flexibility, and fairness. Many aspects of it are influenced by the Stack Exchange policy, described here.
However, I'm feeling a bit stumped about how to best include performance-based bonuses into the model. I feel this is essentially required since all developers in a given position will start out with the same base salary, and since I want 1) for there to be some incentive to encourage people to put in some extra effort, learn new skills, etc., and 2) for top-performing developers to be able to earn more than the bottom-performing developers when there's a clear and measurable difference between the two.
So there are some pragmatic questions, like:
- What's an appropriate cap on the maximum bonus amount? Currently I'm thinking 10%, but I feel that might be too low?
- What's a good time interval for conducting performance reviews? Currently I'm thinking annual, but maybe quarterly allows better flexibility?
And then there are more conceptual areas of concern, such as what's the best way to set performance objectives? Or if objectives aren't explicitly set, then what becomes the metric used to assess performance?
I'd like to avoid implementing systems that rely heavily on self- or peer-assessments, and other mechanisms that are likely to encourage unhelpful corporate politics (or gaming of the system).
I've worked at companies that used MBO for this, and I suppose it worked acceptably well in terms of not creating negative politics and being difficult to game. However, it was a lot of overhead for both employees and their supervisors (who both had to do a few reports each quarter to set up goals, track progress against them, and then review the progress at the end). Are there comparable strategies around that are more "lightweight" than MBO in terms of overhead?
Note that it's important for the bonus implementation to fit nicely within the rest of the compensation policy. Which is to say it must be developer-centric, transparent, and fair. What approach best fits these requirements?
For reference, you can find my current draft of the complete policy here.
company-culture company-policy compensation bonus
4
Your two questions seem a bit early to me. You first have to answer how your are going to measure performance. When you have that information, put it in your question as a background for these questions.
– Jan Doggen
May 29 '15 at 8:51
4
Bonuses are never fair, it is not possible for them to be fair. If you use a quantifiable measure, you reward the wrong things becasue the things that really matter are not easily quanltifiable and so you reward the people who write the most lines of code vice the people who solve the hard problems or who can magically troubleshoot anything. Anywhere I have ever worked that uses a "fair" system to give out salary increases (which are far preferable to bonuses) or bonuses ends up rewarding the mediocre because what they do is easier to measure. Don't be that boss. trust and use your judgement.
– HLGEM
May 29 '15 at 13:54
1
Obligatory link to Joel on Software: joelonsoftware.com/articles/fog0000000070.html
– DJClayworth
May 29 '15 at 14:15
4
If there was an even semi-reliable way to do this then every company would be doing it. The problem is that there's no reliable way to do this. For example, whose performance was more clear and objective when one developer wrote 10,000 lines of code but then another developer came along and reduced it to just 5,000 lines of much easier to understand code? The first person did +10,000 SLOC of performance. The second person did -5,000 SLOC. Any objective metrics will have flaws and loopholes like this.
– Dunk
Jun 1 '15 at 16:55
2
MBO doesn't work either. A person's objectives could be clear and well-defined but 2 months later that all changes, then 2 months later it changes again. While technically feasible, the problem is that the overhead in keeping MBO relevant is usually egregious, at least for the most sought after performers because they tend to be the ones being moved around the most to fight the latest fires.
– Dunk
Jun 1 '15 at 16:59
 |Â
show 1 more comment
up vote
14
down vote
favorite
up vote
14
down vote
favorite
I'm trying to create a developer-centric compensation policy. Which is to say it focuses heavily upon transparency, flexibility, and fairness. Many aspects of it are influenced by the Stack Exchange policy, described here.
However, I'm feeling a bit stumped about how to best include performance-based bonuses into the model. I feel this is essentially required since all developers in a given position will start out with the same base salary, and since I want 1) for there to be some incentive to encourage people to put in some extra effort, learn new skills, etc., and 2) for top-performing developers to be able to earn more than the bottom-performing developers when there's a clear and measurable difference between the two.
So there are some pragmatic questions, like:
- What's an appropriate cap on the maximum bonus amount? Currently I'm thinking 10%, but I feel that might be too low?
- What's a good time interval for conducting performance reviews? Currently I'm thinking annual, but maybe quarterly allows better flexibility?
And then there are more conceptual areas of concern, such as what's the best way to set performance objectives? Or if objectives aren't explicitly set, then what becomes the metric used to assess performance?
I'd like to avoid implementing systems that rely heavily on self- or peer-assessments, and other mechanisms that are likely to encourage unhelpful corporate politics (or gaming of the system).
I've worked at companies that used MBO for this, and I suppose it worked acceptably well in terms of not creating negative politics and being difficult to game. However, it was a lot of overhead for both employees and their supervisors (who both had to do a few reports each quarter to set up goals, track progress against them, and then review the progress at the end). Are there comparable strategies around that are more "lightweight" than MBO in terms of overhead?
Note that it's important for the bonus implementation to fit nicely within the rest of the compensation policy. Which is to say it must be developer-centric, transparent, and fair. What approach best fits these requirements?
For reference, you can find my current draft of the complete policy here.
company-culture company-policy compensation bonus
I'm trying to create a developer-centric compensation policy. Which is to say it focuses heavily upon transparency, flexibility, and fairness. Many aspects of it are influenced by the Stack Exchange policy, described here.
However, I'm feeling a bit stumped about how to best include performance-based bonuses into the model. I feel this is essentially required since all developers in a given position will start out with the same base salary, and since I want 1) for there to be some incentive to encourage people to put in some extra effort, learn new skills, etc., and 2) for top-performing developers to be able to earn more than the bottom-performing developers when there's a clear and measurable difference between the two.
So there are some pragmatic questions, like:
- What's an appropriate cap on the maximum bonus amount? Currently I'm thinking 10%, but I feel that might be too low?
- What's a good time interval for conducting performance reviews? Currently I'm thinking annual, but maybe quarterly allows better flexibility?
And then there are more conceptual areas of concern, such as what's the best way to set performance objectives? Or if objectives aren't explicitly set, then what becomes the metric used to assess performance?
I'd like to avoid implementing systems that rely heavily on self- or peer-assessments, and other mechanisms that are likely to encourage unhelpful corporate politics (or gaming of the system).
I've worked at companies that used MBO for this, and I suppose it worked acceptably well in terms of not creating negative politics and being difficult to game. However, it was a lot of overhead for both employees and their supervisors (who both had to do a few reports each quarter to set up goals, track progress against them, and then review the progress at the end). Are there comparable strategies around that are more "lightweight" than MBO in terms of overhead?
Note that it's important for the bonus implementation to fit nicely within the rest of the compensation policy. Which is to say it must be developer-centric, transparent, and fair. What approach best fits these requirements?
For reference, you can find my current draft of the complete policy here.
company-culture company-policy compensation bonus
edited Jun 30 '15 at 7:08
asked May 29 '15 at 6:59
aroth
8,29812646
8,29812646
4
Your two questions seem a bit early to me. You first have to answer how your are going to measure performance. When you have that information, put it in your question as a background for these questions.
– Jan Doggen
May 29 '15 at 8:51
4
Bonuses are never fair, it is not possible for them to be fair. If you use a quantifiable measure, you reward the wrong things becasue the things that really matter are not easily quanltifiable and so you reward the people who write the most lines of code vice the people who solve the hard problems or who can magically troubleshoot anything. Anywhere I have ever worked that uses a "fair" system to give out salary increases (which are far preferable to bonuses) or bonuses ends up rewarding the mediocre because what they do is easier to measure. Don't be that boss. trust and use your judgement.
– HLGEM
May 29 '15 at 13:54
1
Obligatory link to Joel on Software: joelonsoftware.com/articles/fog0000000070.html
– DJClayworth
May 29 '15 at 14:15
4
If there was an even semi-reliable way to do this then every company would be doing it. The problem is that there's no reliable way to do this. For example, whose performance was more clear and objective when one developer wrote 10,000 lines of code but then another developer came along and reduced it to just 5,000 lines of much easier to understand code? The first person did +10,000 SLOC of performance. The second person did -5,000 SLOC. Any objective metrics will have flaws and loopholes like this.
– Dunk
Jun 1 '15 at 16:55
2
MBO doesn't work either. A person's objectives could be clear and well-defined but 2 months later that all changes, then 2 months later it changes again. While technically feasible, the problem is that the overhead in keeping MBO relevant is usually egregious, at least for the most sought after performers because they tend to be the ones being moved around the most to fight the latest fires.
– Dunk
Jun 1 '15 at 16:59
 |Â
show 1 more comment
4
Your two questions seem a bit early to me. You first have to answer how your are going to measure performance. When you have that information, put it in your question as a background for these questions.
– Jan Doggen
May 29 '15 at 8:51
4
Bonuses are never fair, it is not possible for them to be fair. If you use a quantifiable measure, you reward the wrong things becasue the things that really matter are not easily quanltifiable and so you reward the people who write the most lines of code vice the people who solve the hard problems or who can magically troubleshoot anything. Anywhere I have ever worked that uses a "fair" system to give out salary increases (which are far preferable to bonuses) or bonuses ends up rewarding the mediocre because what they do is easier to measure. Don't be that boss. trust and use your judgement.
– HLGEM
May 29 '15 at 13:54
1
Obligatory link to Joel on Software: joelonsoftware.com/articles/fog0000000070.html
– DJClayworth
May 29 '15 at 14:15
4
If there was an even semi-reliable way to do this then every company would be doing it. The problem is that there's no reliable way to do this. For example, whose performance was more clear and objective when one developer wrote 10,000 lines of code but then another developer came along and reduced it to just 5,000 lines of much easier to understand code? The first person did +10,000 SLOC of performance. The second person did -5,000 SLOC. Any objective metrics will have flaws and loopholes like this.
– Dunk
Jun 1 '15 at 16:55
2
MBO doesn't work either. A person's objectives could be clear and well-defined but 2 months later that all changes, then 2 months later it changes again. While technically feasible, the problem is that the overhead in keeping MBO relevant is usually egregious, at least for the most sought after performers because they tend to be the ones being moved around the most to fight the latest fires.
– Dunk
Jun 1 '15 at 16:59
4
4
Your two questions seem a bit early to me. You first have to answer how your are going to measure performance. When you have that information, put it in your question as a background for these questions.
– Jan Doggen
May 29 '15 at 8:51
Your two questions seem a bit early to me. You first have to answer how your are going to measure performance. When you have that information, put it in your question as a background for these questions.
– Jan Doggen
May 29 '15 at 8:51
4
4
Bonuses are never fair, it is not possible for them to be fair. If you use a quantifiable measure, you reward the wrong things becasue the things that really matter are not easily quanltifiable and so you reward the people who write the most lines of code vice the people who solve the hard problems or who can magically troubleshoot anything. Anywhere I have ever worked that uses a "fair" system to give out salary increases (which are far preferable to bonuses) or bonuses ends up rewarding the mediocre because what they do is easier to measure. Don't be that boss. trust and use your judgement.
– HLGEM
May 29 '15 at 13:54
Bonuses are never fair, it is not possible for them to be fair. If you use a quantifiable measure, you reward the wrong things becasue the things that really matter are not easily quanltifiable and so you reward the people who write the most lines of code vice the people who solve the hard problems or who can magically troubleshoot anything. Anywhere I have ever worked that uses a "fair" system to give out salary increases (which are far preferable to bonuses) or bonuses ends up rewarding the mediocre because what they do is easier to measure. Don't be that boss. trust and use your judgement.
– HLGEM
May 29 '15 at 13:54
1
1
Obligatory link to Joel on Software: joelonsoftware.com/articles/fog0000000070.html
– DJClayworth
May 29 '15 at 14:15
Obligatory link to Joel on Software: joelonsoftware.com/articles/fog0000000070.html
– DJClayworth
May 29 '15 at 14:15
4
4
If there was an even semi-reliable way to do this then every company would be doing it. The problem is that there's no reliable way to do this. For example, whose performance was more clear and objective when one developer wrote 10,000 lines of code but then another developer came along and reduced it to just 5,000 lines of much easier to understand code? The first person did +10,000 SLOC of performance. The second person did -5,000 SLOC. Any objective metrics will have flaws and loopholes like this.
– Dunk
Jun 1 '15 at 16:55
If there was an even semi-reliable way to do this then every company would be doing it. The problem is that there's no reliable way to do this. For example, whose performance was more clear and objective when one developer wrote 10,000 lines of code but then another developer came along and reduced it to just 5,000 lines of much easier to understand code? The first person did +10,000 SLOC of performance. The second person did -5,000 SLOC. Any objective metrics will have flaws and loopholes like this.
– Dunk
Jun 1 '15 at 16:55
2
2
MBO doesn't work either. A person's objectives could be clear and well-defined but 2 months later that all changes, then 2 months later it changes again. While technically feasible, the problem is that the overhead in keeping MBO relevant is usually egregious, at least for the most sought after performers because they tend to be the ones being moved around the most to fight the latest fires.
– Dunk
Jun 1 '15 at 16:59
MBO doesn't work either. A person's objectives could be clear and well-defined but 2 months later that all changes, then 2 months later it changes again. While technically feasible, the problem is that the overhead in keeping MBO relevant is usually egregious, at least for the most sought after performers because they tend to be the ones being moved around the most to fight the latest fires.
– Dunk
Jun 1 '15 at 16:59
 |Â
show 1 more comment
3 Answers
3
active
oldest
votes
up vote
17
down vote
accepted
What's an appropriate cap on the maximum bonus amount? Currently I'm
thinking 10%, but I feel that might be too low?
I feel that the range of 10% to 15% is often enough to change behavior - which is what you are after with bonus systems.
In some contexts, 15% might not be enough. But for many US companies these days, in this economy, it seems sufficient. You won't really know for sure until after you have implemented your system for a few years, and you have analyzed the feedback/metrics you are capturing.
What's a good time interval for conducting performance reviews?
Currently I'm thinking annual, but maybe quarterly allows better
flexibility?
I recommend that formal performance reviews be conducted annually, if they must be done at all.
Unless you have an extremely simple-to-administer system, quarterly is too frequent, involving too much overhead and not letting longer-duration projects have any impact.
One note of warning. Before you embark on implementing these bonuses where they didn't exist before, I always strongly suggest that folks read and understand "Measuring and Managing Performance in Organizations" by Robert D. Austin.
Austin points out the dysfunction that you may very well trigger, as folks strive to maximize their bonuses, to the detriment of the company/system as a whole.
I'd like to avoid implementing systems that rely heavily on self- or
peer-assessments, and other mechanisms that are likely to encourage
unhelpful corporate politics (or gaming of the system).
I'm not a believer in performance-based bonuses for knowledge workers, although I've usually worked in companies where they existed. I can honestly say that I've never seen them achieve the "transparency, flexibility, and fairness" you are seeking.
In my opinion, all performance-based bonus systems can and will be "gamed", and lead to at least some level of dysfunction. I've personally encountered many scenarios where I was forced to choose between what was the "right" thing to do in a particular situation (i.e., best for the company and/or client) and what was the thing that would provide the highest bonus for me. I hate being put in that position and being forced to choose.
I believe that good managers in knowledge-worker departments know which members of their teams are the best performers, and are perfectly capable of rewarding those members appropriately. I don't think taking the decision out of their hands really works, no matter how hard you try to come up with the "perfect metrics" on which the bonuses are based.
[Note: Since you indicate that you are the head of Software Development and IT, you may be wise to consult with HR before moving forward with your plan. When different departments within a company have very different goals/measurements/bonus systems, there can be a big disconnect between groups and it can generate a lot of friction and dysfunction. In many companies you wouldn't be free to implement such a bonus system without prior HR approval.]
1
Excellent points and references.
– user8365
May 29 '15 at 13:34
8
Spot on. Managers are supposed to be paid more to use their judgement and objective systems almost always reward the mediocre (becasue they do better on the stuff that is easy to measure) or the people who game the system. Any manager who doesn't know who his best people are without a system is not paying attention through the year.
– HLGEM
May 29 '15 at 13:58
So the subtext in the comments (and certainly also, here) seems to be that it might be better to not bother with the bonus idea at all? That's a possibility. And to add a bit more detail, there is no HR department; this is a small company that's just about to start its first hiring run. So whatever gets established is likely to set the tone of the organization's culture for years to come, hence the importance of getting it right.
– aroth
May 30 '15 at 10:48
@aroth: small companies have an advantage in that it is FAR easier to change things when it becomes apparent it's not working. If this is your first round of hiring, then I suspect you're going to be changing a lot of things over the next 2 years.
– NotMe
Jun 30 '15 at 18:14
suggest improvements |Â
up vote
3
down vote
I used to be a strong believer in performance-based rewards. After having seen them malfunction drastically several times in my career, I can no longer say that, at least on any level above the most local and with a manager who is actively enough involved in his own department's work that he knows the answer without needing gameable/broken/just-plain-stupid metrics.
If you don't know how your people rank, and can't reward that fairly, without a formalism you aren't doing your job as manager. If you can't justify your rankings to the rest of the department, ditto.
Comparison across departments progressively loses more and more information as it goes up the chain, and becomes unfair, especially to those who hate bragging about themselves and hence don't self-market as effectively... and/or who are working for managers who don't have the skills or inclination to advocate for their people.
It's a fine theory. It just doesn't work for any but the smallest organizations, or those like manufacturing where there really are uncontestable concrete metrics for productivity. And even there that fails to recognize the ones who make everyone else's job easier.
Possibly impractical alternative: If you want to recognize/award bonuses, you might do so for particular achievements when someone goes significantly above and beyond what's expected at their level. Remember to scale that to their title/pay-grade/band/whatever your company calls it, so the less experienced folks also get recognized when they done good. If someone's getting these at all frequently, it's time to raise their base pay and base expectations. I dunno if that really works, but it's a thought.
suggest improvements |Â
up vote
2
down vote
Here is the problem with having a system, especially a transparent and open system, for bonuses: it will be gamed. People just cannot resist working to the metrics and making decisions that bring them more personal money, regardless of the impact on the company. The larger the bonuses, the stronger the incentive to do the wrong thing sometimes. Companies generally respond by making the system more complicated, which will further disconnect "striving to help the company" from "striving to earn a large bonus" and introduce an adversary element into the system as well.
Here is the problem with having bonuses that are entirely subjective, especially if the amounts are not public knowledge: many people will think management is being unfair and giving money to people they like better. This can lead to discontent and even losing your best people (who will find it easier to get other jobs.)
In short, you almost certainly cannot motivate developers to do the right thing by offering them extra money to do so.
In my firm we are small enough that we just make a decision and give it to people as a true bonus - we had a good year this year, you helped a lot, here is some extra money for you. I don't think anyone ever counted on it, budgeted for it, or would have been mad if they didn't get it. If you're too large to do that, and you don't work in an industry that has a "bonus culture", I would stay away from bonuses entirely and give performance-based raises, which are well understood and can be offset by "your risk taking cost us money" in a way that bonus systems rarely can.
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
17
down vote
accepted
What's an appropriate cap on the maximum bonus amount? Currently I'm
thinking 10%, but I feel that might be too low?
I feel that the range of 10% to 15% is often enough to change behavior - which is what you are after with bonus systems.
In some contexts, 15% might not be enough. But for many US companies these days, in this economy, it seems sufficient. You won't really know for sure until after you have implemented your system for a few years, and you have analyzed the feedback/metrics you are capturing.
What's a good time interval for conducting performance reviews?
Currently I'm thinking annual, but maybe quarterly allows better
flexibility?
I recommend that formal performance reviews be conducted annually, if they must be done at all.
Unless you have an extremely simple-to-administer system, quarterly is too frequent, involving too much overhead and not letting longer-duration projects have any impact.
One note of warning. Before you embark on implementing these bonuses where they didn't exist before, I always strongly suggest that folks read and understand "Measuring and Managing Performance in Organizations" by Robert D. Austin.
Austin points out the dysfunction that you may very well trigger, as folks strive to maximize their bonuses, to the detriment of the company/system as a whole.
I'd like to avoid implementing systems that rely heavily on self- or
peer-assessments, and other mechanisms that are likely to encourage
unhelpful corporate politics (or gaming of the system).
I'm not a believer in performance-based bonuses for knowledge workers, although I've usually worked in companies where they existed. I can honestly say that I've never seen them achieve the "transparency, flexibility, and fairness" you are seeking.
In my opinion, all performance-based bonus systems can and will be "gamed", and lead to at least some level of dysfunction. I've personally encountered many scenarios where I was forced to choose between what was the "right" thing to do in a particular situation (i.e., best for the company and/or client) and what was the thing that would provide the highest bonus for me. I hate being put in that position and being forced to choose.
I believe that good managers in knowledge-worker departments know which members of their teams are the best performers, and are perfectly capable of rewarding those members appropriately. I don't think taking the decision out of their hands really works, no matter how hard you try to come up with the "perfect metrics" on which the bonuses are based.
[Note: Since you indicate that you are the head of Software Development and IT, you may be wise to consult with HR before moving forward with your plan. When different departments within a company have very different goals/measurements/bonus systems, there can be a big disconnect between groups and it can generate a lot of friction and dysfunction. In many companies you wouldn't be free to implement such a bonus system without prior HR approval.]
1
Excellent points and references.
– user8365
May 29 '15 at 13:34
8
Spot on. Managers are supposed to be paid more to use their judgement and objective systems almost always reward the mediocre (becasue they do better on the stuff that is easy to measure) or the people who game the system. Any manager who doesn't know who his best people are without a system is not paying attention through the year.
– HLGEM
May 29 '15 at 13:58
So the subtext in the comments (and certainly also, here) seems to be that it might be better to not bother with the bonus idea at all? That's a possibility. And to add a bit more detail, there is no HR department; this is a small company that's just about to start its first hiring run. So whatever gets established is likely to set the tone of the organization's culture for years to come, hence the importance of getting it right.
– aroth
May 30 '15 at 10:48
@aroth: small companies have an advantage in that it is FAR easier to change things when it becomes apparent it's not working. If this is your first round of hiring, then I suspect you're going to be changing a lot of things over the next 2 years.
– NotMe
Jun 30 '15 at 18:14
suggest improvements |Â
up vote
17
down vote
accepted
What's an appropriate cap on the maximum bonus amount? Currently I'm
thinking 10%, but I feel that might be too low?
I feel that the range of 10% to 15% is often enough to change behavior - which is what you are after with bonus systems.
In some contexts, 15% might not be enough. But for many US companies these days, in this economy, it seems sufficient. You won't really know for sure until after you have implemented your system for a few years, and you have analyzed the feedback/metrics you are capturing.
What's a good time interval for conducting performance reviews?
Currently I'm thinking annual, but maybe quarterly allows better
flexibility?
I recommend that formal performance reviews be conducted annually, if they must be done at all.
Unless you have an extremely simple-to-administer system, quarterly is too frequent, involving too much overhead and not letting longer-duration projects have any impact.
One note of warning. Before you embark on implementing these bonuses where they didn't exist before, I always strongly suggest that folks read and understand "Measuring and Managing Performance in Organizations" by Robert D. Austin.
Austin points out the dysfunction that you may very well trigger, as folks strive to maximize their bonuses, to the detriment of the company/system as a whole.
I'd like to avoid implementing systems that rely heavily on self- or
peer-assessments, and other mechanisms that are likely to encourage
unhelpful corporate politics (or gaming of the system).
I'm not a believer in performance-based bonuses for knowledge workers, although I've usually worked in companies where they existed. I can honestly say that I've never seen them achieve the "transparency, flexibility, and fairness" you are seeking.
In my opinion, all performance-based bonus systems can and will be "gamed", and lead to at least some level of dysfunction. I've personally encountered many scenarios where I was forced to choose between what was the "right" thing to do in a particular situation (i.e., best for the company and/or client) and what was the thing that would provide the highest bonus for me. I hate being put in that position and being forced to choose.
I believe that good managers in knowledge-worker departments know which members of their teams are the best performers, and are perfectly capable of rewarding those members appropriately. I don't think taking the decision out of their hands really works, no matter how hard you try to come up with the "perfect metrics" on which the bonuses are based.
[Note: Since you indicate that you are the head of Software Development and IT, you may be wise to consult with HR before moving forward with your plan. When different departments within a company have very different goals/measurements/bonus systems, there can be a big disconnect between groups and it can generate a lot of friction and dysfunction. In many companies you wouldn't be free to implement such a bonus system without prior HR approval.]
1
Excellent points and references.
– user8365
May 29 '15 at 13:34
8
Spot on. Managers are supposed to be paid more to use their judgement and objective systems almost always reward the mediocre (becasue they do better on the stuff that is easy to measure) or the people who game the system. Any manager who doesn't know who his best people are without a system is not paying attention through the year.
– HLGEM
May 29 '15 at 13:58
So the subtext in the comments (and certainly also, here) seems to be that it might be better to not bother with the bonus idea at all? That's a possibility. And to add a bit more detail, there is no HR department; this is a small company that's just about to start its first hiring run. So whatever gets established is likely to set the tone of the organization's culture for years to come, hence the importance of getting it right.
– aroth
May 30 '15 at 10:48
@aroth: small companies have an advantage in that it is FAR easier to change things when it becomes apparent it's not working. If this is your first round of hiring, then I suspect you're going to be changing a lot of things over the next 2 years.
– NotMe
Jun 30 '15 at 18:14
suggest improvements |Â
up vote
17
down vote
accepted
up vote
17
down vote
accepted
What's an appropriate cap on the maximum bonus amount? Currently I'm
thinking 10%, but I feel that might be too low?
I feel that the range of 10% to 15% is often enough to change behavior - which is what you are after with bonus systems.
In some contexts, 15% might not be enough. But for many US companies these days, in this economy, it seems sufficient. You won't really know for sure until after you have implemented your system for a few years, and you have analyzed the feedback/metrics you are capturing.
What's a good time interval for conducting performance reviews?
Currently I'm thinking annual, but maybe quarterly allows better
flexibility?
I recommend that formal performance reviews be conducted annually, if they must be done at all.
Unless you have an extremely simple-to-administer system, quarterly is too frequent, involving too much overhead and not letting longer-duration projects have any impact.
One note of warning. Before you embark on implementing these bonuses where they didn't exist before, I always strongly suggest that folks read and understand "Measuring and Managing Performance in Organizations" by Robert D. Austin.
Austin points out the dysfunction that you may very well trigger, as folks strive to maximize their bonuses, to the detriment of the company/system as a whole.
I'd like to avoid implementing systems that rely heavily on self- or
peer-assessments, and other mechanisms that are likely to encourage
unhelpful corporate politics (or gaming of the system).
I'm not a believer in performance-based bonuses for knowledge workers, although I've usually worked in companies where they existed. I can honestly say that I've never seen them achieve the "transparency, flexibility, and fairness" you are seeking.
In my opinion, all performance-based bonus systems can and will be "gamed", and lead to at least some level of dysfunction. I've personally encountered many scenarios where I was forced to choose between what was the "right" thing to do in a particular situation (i.e., best for the company and/or client) and what was the thing that would provide the highest bonus for me. I hate being put in that position and being forced to choose.
I believe that good managers in knowledge-worker departments know which members of their teams are the best performers, and are perfectly capable of rewarding those members appropriately. I don't think taking the decision out of their hands really works, no matter how hard you try to come up with the "perfect metrics" on which the bonuses are based.
[Note: Since you indicate that you are the head of Software Development and IT, you may be wise to consult with HR before moving forward with your plan. When different departments within a company have very different goals/measurements/bonus systems, there can be a big disconnect between groups and it can generate a lot of friction and dysfunction. In many companies you wouldn't be free to implement such a bonus system without prior HR approval.]
What's an appropriate cap on the maximum bonus amount? Currently I'm
thinking 10%, but I feel that might be too low?
I feel that the range of 10% to 15% is often enough to change behavior - which is what you are after with bonus systems.
In some contexts, 15% might not be enough. But for many US companies these days, in this economy, it seems sufficient. You won't really know for sure until after you have implemented your system for a few years, and you have analyzed the feedback/metrics you are capturing.
What's a good time interval for conducting performance reviews?
Currently I'm thinking annual, but maybe quarterly allows better
flexibility?
I recommend that formal performance reviews be conducted annually, if they must be done at all.
Unless you have an extremely simple-to-administer system, quarterly is too frequent, involving too much overhead and not letting longer-duration projects have any impact.
One note of warning. Before you embark on implementing these bonuses where they didn't exist before, I always strongly suggest that folks read and understand "Measuring and Managing Performance in Organizations" by Robert D. Austin.
Austin points out the dysfunction that you may very well trigger, as folks strive to maximize their bonuses, to the detriment of the company/system as a whole.
I'd like to avoid implementing systems that rely heavily on self- or
peer-assessments, and other mechanisms that are likely to encourage
unhelpful corporate politics (or gaming of the system).
I'm not a believer in performance-based bonuses for knowledge workers, although I've usually worked in companies where they existed. I can honestly say that I've never seen them achieve the "transparency, flexibility, and fairness" you are seeking.
In my opinion, all performance-based bonus systems can and will be "gamed", and lead to at least some level of dysfunction. I've personally encountered many scenarios where I was forced to choose between what was the "right" thing to do in a particular situation (i.e., best for the company and/or client) and what was the thing that would provide the highest bonus for me. I hate being put in that position and being forced to choose.
I believe that good managers in knowledge-worker departments know which members of their teams are the best performers, and are perfectly capable of rewarding those members appropriately. I don't think taking the decision out of their hands really works, no matter how hard you try to come up with the "perfect metrics" on which the bonuses are based.
[Note: Since you indicate that you are the head of Software Development and IT, you may be wise to consult with HR before moving forward with your plan. When different departments within a company have very different goals/measurements/bonus systems, there can be a big disconnect between groups and it can generate a lot of friction and dysfunction. In many companies you wouldn't be free to implement such a bonus system without prior HR approval.]
edited Jun 30 '15 at 10:40
answered May 29 '15 at 11:49


Joe Strazzere
223k106656922
223k106656922
1
Excellent points and references.
– user8365
May 29 '15 at 13:34
8
Spot on. Managers are supposed to be paid more to use their judgement and objective systems almost always reward the mediocre (becasue they do better on the stuff that is easy to measure) or the people who game the system. Any manager who doesn't know who his best people are without a system is not paying attention through the year.
– HLGEM
May 29 '15 at 13:58
So the subtext in the comments (and certainly also, here) seems to be that it might be better to not bother with the bonus idea at all? That's a possibility. And to add a bit more detail, there is no HR department; this is a small company that's just about to start its first hiring run. So whatever gets established is likely to set the tone of the organization's culture for years to come, hence the importance of getting it right.
– aroth
May 30 '15 at 10:48
@aroth: small companies have an advantage in that it is FAR easier to change things when it becomes apparent it's not working. If this is your first round of hiring, then I suspect you're going to be changing a lot of things over the next 2 years.
– NotMe
Jun 30 '15 at 18:14
suggest improvements |Â
1
Excellent points and references.
– user8365
May 29 '15 at 13:34
8
Spot on. Managers are supposed to be paid more to use their judgement and objective systems almost always reward the mediocre (becasue they do better on the stuff that is easy to measure) or the people who game the system. Any manager who doesn't know who his best people are without a system is not paying attention through the year.
– HLGEM
May 29 '15 at 13:58
So the subtext in the comments (and certainly also, here) seems to be that it might be better to not bother with the bonus idea at all? That's a possibility. And to add a bit more detail, there is no HR department; this is a small company that's just about to start its first hiring run. So whatever gets established is likely to set the tone of the organization's culture for years to come, hence the importance of getting it right.
– aroth
May 30 '15 at 10:48
@aroth: small companies have an advantage in that it is FAR easier to change things when it becomes apparent it's not working. If this is your first round of hiring, then I suspect you're going to be changing a lot of things over the next 2 years.
– NotMe
Jun 30 '15 at 18:14
1
1
Excellent points and references.
– user8365
May 29 '15 at 13:34
Excellent points and references.
– user8365
May 29 '15 at 13:34
8
8
Spot on. Managers are supposed to be paid more to use their judgement and objective systems almost always reward the mediocre (becasue they do better on the stuff that is easy to measure) or the people who game the system. Any manager who doesn't know who his best people are without a system is not paying attention through the year.
– HLGEM
May 29 '15 at 13:58
Spot on. Managers are supposed to be paid more to use their judgement and objective systems almost always reward the mediocre (becasue they do better on the stuff that is easy to measure) or the people who game the system. Any manager who doesn't know who his best people are without a system is not paying attention through the year.
– HLGEM
May 29 '15 at 13:58
So the subtext in the comments (and certainly also, here) seems to be that it might be better to not bother with the bonus idea at all? That's a possibility. And to add a bit more detail, there is no HR department; this is a small company that's just about to start its first hiring run. So whatever gets established is likely to set the tone of the organization's culture for years to come, hence the importance of getting it right.
– aroth
May 30 '15 at 10:48
So the subtext in the comments (and certainly also, here) seems to be that it might be better to not bother with the bonus idea at all? That's a possibility. And to add a bit more detail, there is no HR department; this is a small company that's just about to start its first hiring run. So whatever gets established is likely to set the tone of the organization's culture for years to come, hence the importance of getting it right.
– aroth
May 30 '15 at 10:48
@aroth: small companies have an advantage in that it is FAR easier to change things when it becomes apparent it's not working. If this is your first round of hiring, then I suspect you're going to be changing a lot of things over the next 2 years.
– NotMe
Jun 30 '15 at 18:14
@aroth: small companies have an advantage in that it is FAR easier to change things when it becomes apparent it's not working. If this is your first round of hiring, then I suspect you're going to be changing a lot of things over the next 2 years.
– NotMe
Jun 30 '15 at 18:14
suggest improvements |Â
up vote
3
down vote
I used to be a strong believer in performance-based rewards. After having seen them malfunction drastically several times in my career, I can no longer say that, at least on any level above the most local and with a manager who is actively enough involved in his own department's work that he knows the answer without needing gameable/broken/just-plain-stupid metrics.
If you don't know how your people rank, and can't reward that fairly, without a formalism you aren't doing your job as manager. If you can't justify your rankings to the rest of the department, ditto.
Comparison across departments progressively loses more and more information as it goes up the chain, and becomes unfair, especially to those who hate bragging about themselves and hence don't self-market as effectively... and/or who are working for managers who don't have the skills or inclination to advocate for their people.
It's a fine theory. It just doesn't work for any but the smallest organizations, or those like manufacturing where there really are uncontestable concrete metrics for productivity. And even there that fails to recognize the ones who make everyone else's job easier.
Possibly impractical alternative: If you want to recognize/award bonuses, you might do so for particular achievements when someone goes significantly above and beyond what's expected at their level. Remember to scale that to their title/pay-grade/band/whatever your company calls it, so the less experienced folks also get recognized when they done good. If someone's getting these at all frequently, it's time to raise their base pay and base expectations. I dunno if that really works, but it's a thought.
suggest improvements |Â
up vote
3
down vote
I used to be a strong believer in performance-based rewards. After having seen them malfunction drastically several times in my career, I can no longer say that, at least on any level above the most local and with a manager who is actively enough involved in his own department's work that he knows the answer without needing gameable/broken/just-plain-stupid metrics.
If you don't know how your people rank, and can't reward that fairly, without a formalism you aren't doing your job as manager. If you can't justify your rankings to the rest of the department, ditto.
Comparison across departments progressively loses more and more information as it goes up the chain, and becomes unfair, especially to those who hate bragging about themselves and hence don't self-market as effectively... and/or who are working for managers who don't have the skills or inclination to advocate for their people.
It's a fine theory. It just doesn't work for any but the smallest organizations, or those like manufacturing where there really are uncontestable concrete metrics for productivity. And even there that fails to recognize the ones who make everyone else's job easier.
Possibly impractical alternative: If you want to recognize/award bonuses, you might do so for particular achievements when someone goes significantly above and beyond what's expected at their level. Remember to scale that to their title/pay-grade/band/whatever your company calls it, so the less experienced folks also get recognized when they done good. If someone's getting these at all frequently, it's time to raise their base pay and base expectations. I dunno if that really works, but it's a thought.
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
I used to be a strong believer in performance-based rewards. After having seen them malfunction drastically several times in my career, I can no longer say that, at least on any level above the most local and with a manager who is actively enough involved in his own department's work that he knows the answer without needing gameable/broken/just-plain-stupid metrics.
If you don't know how your people rank, and can't reward that fairly, without a formalism you aren't doing your job as manager. If you can't justify your rankings to the rest of the department, ditto.
Comparison across departments progressively loses more and more information as it goes up the chain, and becomes unfair, especially to those who hate bragging about themselves and hence don't self-market as effectively... and/or who are working for managers who don't have the skills or inclination to advocate for their people.
It's a fine theory. It just doesn't work for any but the smallest organizations, or those like manufacturing where there really are uncontestable concrete metrics for productivity. And even there that fails to recognize the ones who make everyone else's job easier.
Possibly impractical alternative: If you want to recognize/award bonuses, you might do so for particular achievements when someone goes significantly above and beyond what's expected at their level. Remember to scale that to their title/pay-grade/band/whatever your company calls it, so the less experienced folks also get recognized when they done good. If someone's getting these at all frequently, it's time to raise their base pay and base expectations. I dunno if that really works, but it's a thought.
I used to be a strong believer in performance-based rewards. After having seen them malfunction drastically several times in my career, I can no longer say that, at least on any level above the most local and with a manager who is actively enough involved in his own department's work that he knows the answer without needing gameable/broken/just-plain-stupid metrics.
If you don't know how your people rank, and can't reward that fairly, without a formalism you aren't doing your job as manager. If you can't justify your rankings to the rest of the department, ditto.
Comparison across departments progressively loses more and more information as it goes up the chain, and becomes unfair, especially to those who hate bragging about themselves and hence don't self-market as effectively... and/or who are working for managers who don't have the skills or inclination to advocate for their people.
It's a fine theory. It just doesn't work for any but the smallest organizations, or those like manufacturing where there really are uncontestable concrete metrics for productivity. And even there that fails to recognize the ones who make everyone else's job easier.
Possibly impractical alternative: If you want to recognize/award bonuses, you might do so for particular achievements when someone goes significantly above and beyond what's expected at their level. Remember to scale that to their title/pay-grade/band/whatever your company calls it, so the less experienced folks also get recognized when they done good. If someone's getting these at all frequently, it's time to raise their base pay and base expectations. I dunno if that really works, but it's a thought.
edited Jul 1 '15 at 4:33
answered Jun 30 '15 at 13:40
keshlam
41.5k1267144
41.5k1267144
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
Here is the problem with having a system, especially a transparent and open system, for bonuses: it will be gamed. People just cannot resist working to the metrics and making decisions that bring them more personal money, regardless of the impact on the company. The larger the bonuses, the stronger the incentive to do the wrong thing sometimes. Companies generally respond by making the system more complicated, which will further disconnect "striving to help the company" from "striving to earn a large bonus" and introduce an adversary element into the system as well.
Here is the problem with having bonuses that are entirely subjective, especially if the amounts are not public knowledge: many people will think management is being unfair and giving money to people they like better. This can lead to discontent and even losing your best people (who will find it easier to get other jobs.)
In short, you almost certainly cannot motivate developers to do the right thing by offering them extra money to do so.
In my firm we are small enough that we just make a decision and give it to people as a true bonus - we had a good year this year, you helped a lot, here is some extra money for you. I don't think anyone ever counted on it, budgeted for it, or would have been mad if they didn't get it. If you're too large to do that, and you don't work in an industry that has a "bonus culture", I would stay away from bonuses entirely and give performance-based raises, which are well understood and can be offset by "your risk taking cost us money" in a way that bonus systems rarely can.
suggest improvements |Â
up vote
2
down vote
Here is the problem with having a system, especially a transparent and open system, for bonuses: it will be gamed. People just cannot resist working to the metrics and making decisions that bring them more personal money, regardless of the impact on the company. The larger the bonuses, the stronger the incentive to do the wrong thing sometimes. Companies generally respond by making the system more complicated, which will further disconnect "striving to help the company" from "striving to earn a large bonus" and introduce an adversary element into the system as well.
Here is the problem with having bonuses that are entirely subjective, especially if the amounts are not public knowledge: many people will think management is being unfair and giving money to people they like better. This can lead to discontent and even losing your best people (who will find it easier to get other jobs.)
In short, you almost certainly cannot motivate developers to do the right thing by offering them extra money to do so.
In my firm we are small enough that we just make a decision and give it to people as a true bonus - we had a good year this year, you helped a lot, here is some extra money for you. I don't think anyone ever counted on it, budgeted for it, or would have been mad if they didn't get it. If you're too large to do that, and you don't work in an industry that has a "bonus culture", I would stay away from bonuses entirely and give performance-based raises, which are well understood and can be offset by "your risk taking cost us money" in a way that bonus systems rarely can.
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
Here is the problem with having a system, especially a transparent and open system, for bonuses: it will be gamed. People just cannot resist working to the metrics and making decisions that bring them more personal money, regardless of the impact on the company. The larger the bonuses, the stronger the incentive to do the wrong thing sometimes. Companies generally respond by making the system more complicated, which will further disconnect "striving to help the company" from "striving to earn a large bonus" and introduce an adversary element into the system as well.
Here is the problem with having bonuses that are entirely subjective, especially if the amounts are not public knowledge: many people will think management is being unfair and giving money to people they like better. This can lead to discontent and even losing your best people (who will find it easier to get other jobs.)
In short, you almost certainly cannot motivate developers to do the right thing by offering them extra money to do so.
In my firm we are small enough that we just make a decision and give it to people as a true bonus - we had a good year this year, you helped a lot, here is some extra money for you. I don't think anyone ever counted on it, budgeted for it, or would have been mad if they didn't get it. If you're too large to do that, and you don't work in an industry that has a "bonus culture", I would stay away from bonuses entirely and give performance-based raises, which are well understood and can be offset by "your risk taking cost us money" in a way that bonus systems rarely can.
Here is the problem with having a system, especially a transparent and open system, for bonuses: it will be gamed. People just cannot resist working to the metrics and making decisions that bring them more personal money, regardless of the impact on the company. The larger the bonuses, the stronger the incentive to do the wrong thing sometimes. Companies generally respond by making the system more complicated, which will further disconnect "striving to help the company" from "striving to earn a large bonus" and introduce an adversary element into the system as well.
Here is the problem with having bonuses that are entirely subjective, especially if the amounts are not public knowledge: many people will think management is being unfair and giving money to people they like better. This can lead to discontent and even losing your best people (who will find it easier to get other jobs.)
In short, you almost certainly cannot motivate developers to do the right thing by offering them extra money to do so.
In my firm we are small enough that we just make a decision and give it to people as a true bonus - we had a good year this year, you helped a lot, here is some extra money for you. I don't think anyone ever counted on it, budgeted for it, or would have been mad if they didn't get it. If you're too large to do that, and you don't work in an industry that has a "bonus culture", I would stay away from bonuses entirely and give performance-based raises, which are well understood and can be offset by "your risk taking cost us money" in a way that bonus systems rarely can.
answered Jun 30 '15 at 13:17
Kate Gregory
105k40230332
105k40230332
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f47348%2fimplementing-performance-based-bonuses%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
4
Your two questions seem a bit early to me. You first have to answer how your are going to measure performance. When you have that information, put it in your question as a background for these questions.
– Jan Doggen
May 29 '15 at 8:51
4
Bonuses are never fair, it is not possible for them to be fair. If you use a quantifiable measure, you reward the wrong things becasue the things that really matter are not easily quanltifiable and so you reward the people who write the most lines of code vice the people who solve the hard problems or who can magically troubleshoot anything. Anywhere I have ever worked that uses a "fair" system to give out salary increases (which are far preferable to bonuses) or bonuses ends up rewarding the mediocre because what they do is easier to measure. Don't be that boss. trust and use your judgement.
– HLGEM
May 29 '15 at 13:54
1
Obligatory link to Joel on Software: joelonsoftware.com/articles/fog0000000070.html
– DJClayworth
May 29 '15 at 14:15
4
If there was an even semi-reliable way to do this then every company would be doing it. The problem is that there's no reliable way to do this. For example, whose performance was more clear and objective when one developer wrote 10,000 lines of code but then another developer came along and reduced it to just 5,000 lines of much easier to understand code? The first person did +10,000 SLOC of performance. The second person did -5,000 SLOC. Any objective metrics will have flaws and loopholes like this.
– Dunk
Jun 1 '15 at 16:55
2
MBO doesn't work either. A person's objectives could be clear and well-defined but 2 months later that all changes, then 2 months later it changes again. While technically feasible, the problem is that the overhead in keeping MBO relevant is usually egregious, at least for the most sought after performers because they tend to be the ones being moved around the most to fight the latest fires.
– Dunk
Jun 1 '15 at 16:59