14

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:

  1. What's an appropriate cap on the maximum bonus amount? Currently I'm thinking 10%, but I feel that might be too low?
  2. 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.

  • 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
17

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
3

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.

2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.