Can Performance Bonuses Be Agile?
Prefer to watch this as a video? Click here.
It’s funny isn’t it, the performance bonus. It feels like a present, like your employer being kind and giving you a gift, all mixed up with a recognition that you’re doing a good job. Hell, even the word bonus comes from the latin word ‘bonum’ meaning ‘good thing’. (It’s interesting to note that in Latin the word bonum is a word that doesn’t have a gender, but the word bonus is masculine). Anyway…
It’s hard then to see a bonus as anything other than a good thing. It gives you money or possessions, it recognises that you personally have been doing good work, and the word itself is the very epitome of a good thing. Which is funny really, when you think the multi-billion pound PPI miselling scandal was caused by a culture of bonuses, and to some degree the global financial crash too.
However, for the purposes of agile, I actually think bonuses are a really bad thing. Let me explain…
First, if you think about it, the whole idea of a bonus is a bit odd. Getting paid to do your work, that makes sense. But being given what feels like free money on top of your pay is nearly always about power and control. Think about it. If someone came up to you in the street and said ‘I think you’re great, do you want some free money?’ you’d be pretty suspicious. Yet when your employer does this, you don’t seem to think it’s suspicious at all. Bonus schemes are generally tax efficient ways of controlling those who work for you and keeping them from leaving the business, especially the sort of bonus where you’re told what your performance rating is, then a few months later told how much bonus that means for you, then a few months after that you’re actually paid the bonus. Sometimes portions of one annual bonus are only paid out over a few years, clearly keeping the person in their job with the promise of money, and completely in the power of their employer.
I tend to think anything that is set up to create unequal power relationships between people are generally a threat to agility. However, we should realise that within this idea of bonus, there are different types of bonuses, each with their own types of problems.
The first, and I think worst kind, are bonus schemes that are run based on the opinions of more senior people about how you’ve performed. As much as companies create frameworks for performance measurement, these sorts of schemes are nearly always down to personal opinion. This has two really toxic effects. First, it makes people do the sort of work they know will win them attention and praise from senior people. If agile is about delivering value to the business, then there’s a potential tension here. Of course, you could say that the senior people’s opinions and the value to the business should be identical, but they’re clearly not. Every human has personal biases, opinions and ways of seeing the world that are different from their employer. Opinion based bonuses promote the power of personal opinion over data, which is something marketers need to move away from now the digital world has arrived.
I also think that opinion based bonuses create hierarchies that harm agility as well. If agile is about trusting the team to do the work well, then allowing senior people to give out bonuses based on their opinions is sending a message that they don’t really trust the people they’re employing. Technically, if you wanted to run an opinion based bonus scheme in an agile environment, then you should trust each person to decide themselves how much bonus they should be awarded. If that idea seems ridiculous to you, you need to ask how much you really trust your team.
Then there are the metric based bonuses. You see these in sales environments a lot, and they have the advantage over opinion based bonuses that they’re based on hard facts. If you tell a sales person that they’ll get a bonus of 10% of the value of the thing they sell, basically a commission, then you can’t really dispute the fact that they sold that thing and how much they sold it for.
Or can you? I’ve worked on this kind of bonus scheme, and it really can be toxic. First, as a sales person it drives you to sell things to customers that they don’t need, just to up your bonus, which clearly runs counter to the idea of customer collaboration in the agile manifesto. Second, it also drives you to sell things regardless of the impact on the team. As a young, fresh faced and stupid software salesman, I used to go out and promise more to the client than they were paying for, then come back and let the rest of the team work out how to deliver it for the price I’d quoted. Looking back I’m not proud of it, but it made sense for me in the bonus scheme I was on.
Third, not only does it harm team cohesion with those in your wider organisation, it also harms cohesion with those around you. In that same job, there was another chap selling stuff like me, and it sometimes became ridiculous how much we’d rush to answer the phone when it rang, as if it was a new customer enquiring about a purchase, then the person that answered the phone would likely get the sale. We also had no incentive to help each other out with selling, as we’d just be spending our time helping their bonus.
In this job, we did try to deal with these problems by making the bonus a collective, team thing, based on hard numbers rather than personal opinions, and calculated through profit. Basically, I had to sell a project for a price at which I knew we could make a profit, and the team had to deliver it within the budget in order to make profit. Once the project had been delivered, then a percentage of the profit was split equally between the team. This made for much happier inter-team relations, but it still ran counter to a fundamental principle of agile; that the start of a project is the time when you know the least about the time and cost involved in delivering the project. But if time and cost are fixed up front, and everyone’s trying to minimise the time spent in order to keep the cost low and maximise the profit to be shared out, then the only thing that can flex is the quality, and that’s not prioritising customer collaboration.
So then, could a bonus scheme ever be of benefit to an agile environment? Well, possibly, but I think there are two important factors in it. The first is obviously the one I mentioned before. If you trust your team, and if you’re going to have a bonus scheme, then you should let the team members, either individually or collectively, decide how much bonus they should be awarded. This is probably quite a leap of faith for all but the most hardened agile practitioner, so I’d like to suggest a second route.
If you must have a bonus scheme, whether it’s based on opinion, or data, or whatever, keep it meaningful, but keep it really small. Back in the early days of the sales job I’ve been mentioning in this video, I was getting paid what is now the minimum wage. We were young, we were a start up, and we all recognised we were doing this for love more than money. That first christmas, the director announced that the company was buying everyone a christmas present, our choice of either an ipod or a PSP. I chose the ipod, and I was over the moon with it. It only cost a couple of hundred pounds at most, but it was hugely useful to me, and as I’d had a hand in choosing it, I felt to some degree trusted to be involved in my bonus. On top of this, on a human level it felt like a genuine present, a heart felt thank you for all my hard work. I was probably happier and more motivated by that iPod than I was by any of the four figure cash bonuses I went on to earn in that job.
So, my concluding thought is this. Bonuses are generally a really bad idea in agile environments. They cause people to put themselves before others, and can really damage team cohesion. So if you are going to have them, keep them small, keep them cheap and keep them personal. Perhaps the best bonus you can give someone is a heartfelt thank you for doing a great job, and even more freedom to do the work the way they think it should be done.
The best bonus you can give someone is trust.