Performance Reviews

I had an interesting conversation last night about that old bugbear, the annual performance review. No matter how many well-meaning attempts have been made with SMART targets or peer review systems, every annual review I've had or given during my professional career has gone something like this:

• Here are a bunch of objectives that ceased to be relevant within weeks of being set.
• Here's some peer feedback which is almost certainly about something which happened six months ago.
• Neither of these things matter because all the departmental managers have been given an average review score to target, so you're all getting 75%.

This is weird. It's one of those hangovers from the days of managerialism, an odd piece of theatre that we keep up because everybody does it, and none of us want to be the kid who yells out, "but he isn't wearing anything at all!"

What's odd is we've figured out that if we're building software, building a big set of idealised requirements up front, then bunkering down for a year and releasing at the end doesn't work. Instead we spend a couple of weeks building a small piece of it, get feedback quickly, then change direction (or not) based on that feedback. So why do we run our personal development, something even more important than a few software artefacts, on this discredited process?

There is an answer. But to explain it, let me talk about the Utopian vision - what would good look like?

Good is where we follow that same iterative process for improving ourselves. Start with a retrospective on how things are - what's going well, what's going badly, what do you want to change? Then pick a small, achievable goal that you can work on over a couple of weeks. Be the person who fixes the next broken build, start using the streams library, be more polite when you disagree with other team members. At the end, review the goal. Did you achieve it? Did you learn anything else along the way? What were the challenges? That then feeds forward into your retrospective and you go back over the loop.

You know what else good looks like? A really big commitment from people managers: one to spend time with their team members. Not necessarily a lot of time, but a consistent rhythm of time. This is not an easy commitment to make. What happens is you say you're going to make it, but one week there's an interview, then next week a meeting you can't move, then one of you is on holiday, then the other, then you're just flat out busy and by that point you've skipped so many catch-up sessions everyone involved assumes they don't happen or need to happen anyway.

Hence the temptation to stick with the annual review cycle, because you get these two or four weeks where everyone is setting targets and having review meetings, in which "team time" is suddenly the most important thing you do. This is much the same as all those waterfall approaches which know "releasing software" is the most important thing to do during the release window, but don't make the leap that maybe "releasing software" is always important and you should do it all the time. If you're a leader, "team time" is massively important. It's a scaling thing: in 5 or 10 minutes you can make someone's entire week more productive. Do that across an entire team and you've added a hell of a lot more value than you would have making up the numbers for another hour-long meeting.

Not only that, but you're giving yourself half a chance to fail fast and fail small. Teams fall apart when they don't get regular time from their leaders. Negative behaviours grow unchecked and spread between team members. If you're leaving months between performance discussions, what could have been "you're getting discouraged easily of late, what can we do?" becomes "this team hasn't met a sprint goal since January".

Of course, I've missed the one big reason firms still stick to the big old annual review process: salaries and bonuses.

The reason is that not only do I think this is a pretty flimsy excuse, I think it drives a lot of the negative behaviours we see in performance reviews. You know what the most common, the most persistent review comment I've had right from my days as a junior developer? The one I've even become part of the problem by saying myself? "I can't give you a 5 here because it'd put you into a salary band we don't have budget for". You take people who've done a great job and tell them, "stop being good, it's causing me a problem." This review/salary pollution gets even worse when you add 360 feedback into the cycle, and not in the direction you'd expect - people hold back on giving useful negative feedback because they don't want to cost their workmates a raise.

I don't want to get into the whole murky world of compensation and intrinsic vs. extrinsic motivation here, but I would recommend reading the Netflix presentations on the matter. At the least, be open with people about what you pay them and why, and don't let it pollute your discussion about whether they're doing a good job or not.

Anyway, that was my conversation. If you're a leader, have a think about how you manage performance and growth in your team. Do you commit your time? Are your team members allowed to fail fast, learn and grow? Are you measuring and changing behaviour on a cycle of weeks, or years? Or does your process look more like the one which delivers failed software projects?