Retrospective Performance Reviews

First published November 2016

I’m hearing many stories about performance review cycles and the incentives they create, but I’m also getting a very reasonable question: what should we do now? Here’s an immediate suggestion.

---

Thanks to today’s sponsor Unblocked.

When I was a young programmer we were berated for not writing more documentation, but that documentation always turned out to be useless by the time we needed it. That experience was my impetus for writing about communicative code (Smalltalk Best Practice Patterns & Implementation Patterns).

Unblocked meets the same need in the same moment--I have to change this code but what is going on? Unblocked answers this question with less effort on the part of the original programmer & the answers are always up-to-date.

---

Performance review is a lousy planning tool [ed: see also predicted key results in OKRs], because it:

• Requires that you predict the unpredictable

• Attribute all impact to an individual

• Slice impact to fit into six months. Then five. Then four...

What if you and your team used performance review retrospectively? Engineer the way you should engineer together:

• Balance long- and short-term

• Balance features and quality

• Help each other

• Experiment cheaply

• Dig in hard when you find value.

Then, at the end of the cycle you all sit down together and divide up the pie. Y’all know how to engineer.

This only works if everyone on the team does it. One “free rider” will ruin it for everyone. The manager needs to accept the responsibility for keeping the team roped together & telling everyone’s individual story at review time.

Every once in a while this is going to backfire. You won’t have enough impact or as much impact as you’d like. As a way to bet, though, it’s likelier that you will have more stories to tell at the end of the cycle this way than if you divide up a non-existent pie before you start.