The Bad News
There is no way to directly measure a team’s impact on the business.
The most effective use of bonuses is for sales people. The more they sell, the bigger the bonus, right? But even this isn’t direct. The amount they sell might be due more to the health of the economy and what rival companies are doing. Or technological change or a dozen other factors.
The measurement problem, in statistical terms, is “confounding factors”.
The Good News
I lied, for dev teams there is a way to beat confounding factors – our old friend AB testing.
Before we look at how this applies to bonuses, let’s look at a few more reasons why it’s important. Particularly for bonuses based on big (3 month) milestones.
More Bad News
1. Big milestones are too vague. We see it a lot on the Metro dev team. Our target is to deliver reader comments, or a TV product, or registation. We “deliver” it but it’s sub-standard. It doesn’t work properly. And we spend ages trying to patch it up.
Of course, we should reduce scope not quality. And we should be more iterative. But these take time to establish. Our bonuses get in the way by promoting persistent short-termism.
2. Big milestones are an obstacle to business agility. Typically, within a month, a new backlog item emerges that would deliver more value than our target. We spend most of our time NOT working on the most important things. Fail. It’s why scrum has 2 week sprints.
3. Developer motivation is debased from “doing it for the love of it” to “doing it for the money”. (It may be hard for non-geeks to grok “doing it for the love it”, but if you observe any good dev team you’ll realise it’s true).
4. Bonuses dont make sense. If targets are set at the right level they should only be achieved 50% of the time (if you never fail then you’re not challenging yourself). Targets are relative to previous achievements.
5. Burnout. One reason for a drop in dev productivity is burnout. And the biggest reason for burnout is… big milestones and big bonuses.
6. Bonuses mean a conflict of interests (if different teams have different targets).
Quick recap
For dev teams, traditional bonuses are obstacles to quality, prioritisation and productivity in general. They are too simplistic. They create more problems than they solve.
The easy answer is to ditch bonuses. But maybe there is a way to make them work…
A Better Way? Lots of small bonuses
Avoid big milestones. Give a small bonus for each successful 2 week sprint.
A Better Way? Stake a claim
Rather than being given a fixed target up-front, team’s could work on whatever is most important with a view to later staking a claim for their bonus.
For example, “In the last 3 months the team delivered features X and Y. X was AB tested and increased the number of tweets by 5%. Users using feature Y spend 20% longer on the site. Adding further business value was prevented by strategic work imposed by Z”.
This would empower teams to take ownership and make decisions backed up with real data.
It would make targets and bonuses more adaptable. (The business might suddenly decide to target urbanites instead of the masses, for example). The metrics could be reviewed at regular intervals (e.g every month)
Of course, for every feature the business proposes they should have expectations such as, “We expect social login to increase sign-ups by 20%”. This helps with prioritisation. Expectations can often be validated with small experiments.
A Better Way? Make an enemy
Performance metrics can be a bit dry. It might be more fun if targets were to out-perform competitors (such as the evil MailOnline).
“Localised variation”
Different teams could trial different approaches.
What do you think? Leave a comment below.
