Individual Performance Appraisals, Just Say No!

For some reason, the notion of individual performance reviews comes up a lot. My general feeling is that we should dump them entirely. I’m actually in good company. Almost a third of U.S. companies are dropping individual reviews, including stodgy places like General Electric. (See this HBR article if you can get past their paywall. There are books written on the subject, in fact.)

Let’s look at the issue from an Agile perspective.

One of the key principles of the Agile Manifesto is Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. There are a lot of things implied by that statement, the most obvious one being that the teams are autonomous—in charge of their own work.

Autonomous teams do not have managers in the traditional command/control sense. Management becomes a support role, not a directive one. There is no manager telling the team what to do. (This notion long predates Agile, by the way. It’s central to Lean and TPS.)

So, upper management gives the teams strategic objectives and then lets them figure out how to realize those objectives. Middle managers, if they exist at all, make sure that the teams have whatever they need to get the work done in whatever way the teams decide to work. The more organizational agility you have, the less you need that particular job. Teams in effective organizations don’t need someone to protect them from the organization.

Into that context comes the performance review. The very notion of a performance review is based on command/control thinking.

A “manager” controls the team and doles out things like bonuses and raises as a means of control. It’s basic behaviorist thinking. Dispense rewards to reinforce the behavior you want; withhold them to punish people who don’t exhibit that behavior. That thinking is hardly aligned with autonomous self-managing teams, which is to say that performance reviews are not aligned with Agile, either.

But, how do we determine salaries? How do we reward “top performers?” Let’s dissect that question. First of all, local optimization—improving the performance of one part of a larger system—doesn’t work. That’s a basic principle of the Theory of Constraints (described in The Goal and The Phoenix Project—both are essential reading).

At the team level, what matters is the speed of the entire team. A single “superstar” tends to slow down the team because people end up waiting for that person to finish critical work before they can move forward with their own. The “superstar” is a bottleneck who slows the entire system because the speed of the system cannot exceed the speed of the bottleneck.

What about underperformers? Software shops don’t hire uneducated unmotivated underachievers. “Underperformance” is not inherent. It comes from lack of training and experience. You solve that problem with training and letting “junior” people work on challenging things, not by punishing people with low bonuses or pay cuts. The team itself, of course, is in the best position to know who needs the most help, so individual appraisal is unnecessary.

If someone on the team is more talented than anyone else, the best use of their time by far is for them to help the rest of the team improve by mentoring and teaching. If you reward the entire team rather than individuals, you’re motivating the “top performers” to make the entire team get better. If you don’t do that, you set up a competitive environment where the “top performer” won’t delegate important work because they won’t be a superhero anymore.

So, given all that, shouldn’t people who contribute more be rewarded accordingly? Sure. The question is how to do that. Spotify does it in an interesting way. First, they have a matrix. Numbers on one axis, desired traits on the other (mentors others, learns enthusiastically, produces very high quality code, &c.). Developing that matrix is itself an interesting exercise because it’s both a collaborative and iterative process involving the entire organization. The process is similar to that of a health check.

Periodically, everybody fills out the matrix for themselves, and then submits the matrix to the team for review. The team adjusts the numbers as they see fit. Salary is determined by a simple formula. There’s no gender bias and the like. If everybody gets a top score (and top salary), it’s an incredible win. The minimum salary is what a competitor would pay to hire you away.

I should add that a matrix like this must be developed collaboratively and incrementally with input from everybody from the CEO down to the team members. Do some dry runs, get feedback, adjust. Everybody who is impacted by the evaluation needs to actually contribute and fully understand what improving in every area entails (well in advance of using the matrix the first time). The company has to offer active help if someone wants to improve in some area. I would expect the matrix to evolve over time as the org evolves, and I’d expect variation from team to team. Finally, you have to do this in the context of a psychologically safe organization. Read Amy Edmondson’s two books Teaming and The Fearless Organization. Disaster will ensue if “management” imposes a matrix by fiat.

At the other end of the agility spectrum, the process is less collaborative. Most of the companies mentioned in the HBR article cited in the first paragraph still have managers, but the managers follow a more Lean approach. They interact with the teams constantly, and “reviewing” is an active and continuous process that the managers can put into the context of the whole team, because they often work hands on with the whole team.

I’m less happy with that approach because I still think that a single judge can never be perfect and individual rewards ultimately subvert the effectiveness of the team. However you do it, though, dumping formal appraisals is, to me, a good move.