Implementing performance-based bonuses

Question

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.

Answer 1

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.]

Answer 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.

Answer 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.