An Alternative to the Annual Review

DZone 's Guide to

An Alternative to the Annual Review

Time to take a new look at an old idea. Do you agree with this suggestion of how annual performance reviews should be conducted?

· Agile Zone ·
Free Resource

Well, it's that time again — time for the yearly performance evaluation. The ritual starts with gathering feedback, proceeds to assigning rating/ranking, and drags on through doling out a raise.

Do you enjoy annual performance reviews? Thought not.

This year I think we should all skip it.


Here's why:

For most teams, each person's achievement is all intertwined with the other members of the team. Trying to pull out individual performance on project goals is futile. Emphasizing or rating individual performance undermines collaboration.

Individual skills are only part of the performance equation. The quality of management and the environment for success are major factors in individual performance. But most rating and ranking schemes ignore those factors.

Ranking people with different skills sets against each other makes no sense. Yeah, I know lots of companies do it, but the fact that lots of companies do it does not make it a good idea.

Rating on the bell curve is ranking in a different dress. The bell curve isn't particularly useful in a small population — like the size of a typical workgroup.

Rating and ranking engender competition, not collaboration.

Most people believe they are above average performers. Disabusing them of this notion does not improve morale, nor does it spur people on to greater efforts. Quite the opposite.

And if everyone is doing their job reasonably well (and if managers are doing their jobs, they are, or they've moved on...) does it help to tell them they're at the bottom of the heap? I think not.

Performance reviews aim for objectivity, but in almost all cases, they are, in fact, subjective.

Year-end is a lousy time to tell people how they're doing. It's too late — why waste weeks (or months) of inadequate performance? The best time to let people know how they are doing is in the present, as close to the event as feasible.

Here's what to do instead:

Have a conversation with each person in your group about how the year has gone. Discuss questions like these:

  • What were the major events of the year?
  • What have been the major accomplishments?
  • What new skills have you acquired?
  • What have been your struggles?
  • What contributed to those situations?
  • What insights do you have, looking back on the year?
  • What are you most proud of?
  • How does this inform us going into next year?
  • What do you want to do better?
  • Are there new areas you want to explore?
  • What skills or capabilties will you develop?
  • How can we build developing those capabilities into daily work?
  • How will we tell you're making progress?

Do not discuss a letter or number rating or ranking. Just talk.

Have a separate conversation about salary increases.

Find out what the salary ranges are for the people in your group. Most companies determine salary rates based on the market. They look at how much people in various jobs are paid within their industry and region, then determine where within the range they will aim to pay — say within 20% of the midpoint salary. Then they have a progression, usually with smaller percent raises as the person reaches the top of the range. From this perspective, salary increases are intended to keep salaries pegged to the market and provide reasonable progression as people become more skilled in their jobs. Use what ever pool you have to keep people aligned within the market rates; don't try to use the pool for "pay for performance." The aim is to pay people fairly, not to entice people with monetary rewards (which doesn't usually work anyway).

Start the new year by meeting regularly (weekly or at very least, every other week) with each person on the team. Talk about the person and the work. Coach and provide feedback. Talk about the goals you set in your year-end conversation.

This article was originally published in 2004.

agile, developers, interview, leadership, management, managers, performance review, questions

Published at DZone with permission of Esther Derby , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}