Performance without Appraisal

Part I: Pay, Promotion, and Improvement

4 June 2007

Esther Derby
Esther Derby Associates, Inc.

The idea of merit rating is alluring. The sound of the words captivates the imagination: pay for what you get; get what you pay for; motivate people to do their best, for their own good.

The effect is exactly the opposite of what the words promise. Everyone propels himself forward, or tries to, for his own good, on his own life preserver. The organization is the loser.

Merit rating rewards people who do well within the system. It does not reward attempts to improve the system.

W. Edwards Deming in Out of the Crisis

In my previous column, I suggested that ScrumMasters should steer clear of annual performance reviews. Rating and ranking individuals interferes with a ScrumMaster’s responsibilities as a coach in service to the team. In fact, I went further than that: I suggested that managers and the rest of us steer clear of performance reviews, as well.

My suggestion does run counter to widespread practice. But I’m not alone in questioning performance evaluations and rankings.

W. Edwards Deming identified performance appraisal as one of the Seven Deadly Diseases of Management. Deming is clear and concise in stating the negative effects of performance appraisals and merit ratings: “It nourishes short-term performance, annihilates long-term planning, builds fear, demolishes teamwork, nourishes rivalry and politics.” [Deming p. 102]

More recently, Stanford University professors Robert Sutton and Jeffrey Pfeffer combed through data and studies related to widespread management practices. They reference a survey of 200 human resource professionals which reports that forced ranking—a common component of performance appraisal programs—results in “lower productivity, inequity and skepticism, negative effects on employee engagement, reduced collaboration, and damage to morale and mistrust of leadership.” [Pfeffer and Sutton, p. 107] They go on to describe the damage done by merit pay plans.

In short, the evidence supporting the benefits of rating, ranking, and then tying pay to the rating—the stuff of performance evaluations—is thin to none. Deming had it right.

My readers did raise legitimate concerns:

Without performance appraisals….

How do we determine how much to pay people?
How do we know who to promote or fire?
How do people know they need to improve?

Organizations do need answers to these questions. Performance appraisals and pay-for-performance (PFP) aren’t the only way to answer those questions, or even the best way. In this column, I’ll walk through some alternatives to the prevailing practice.

How do we determine how much to pay people?

One reader pointed out, “people get their salaries on an individual basis.” True. Tying annual salary actions to ratings and rankings is just one way to determine what those actions should be. There are other rational and non-capricious ways to adjust individual salaries:

  • Adjust based on the cost of living so that the buying power of salaries keeps pace with economic conditions.
  • Allow all employees to share in the company’s success through profit sharing.
  • Adjust salaries based on the current market rate for skills and roles.

Another reader posed the rhetorical question, “So all certified scrum masters earn the same amount?”

Performance is a function of the person and the environment. Systems thinking and lean production at Toyota tell us that gains in productivity come from inspecting and adapting the system, not from focusing on individual performance. An improvement mindset, thinking for the long term, eliminating waste, respect for people, and removing impediments bring high performance.

Still, there are people who are clearly outstanding performers (both outstandingly good and outstandingly poor), who outperform the limits of the system. Once again, pay increases based on performance ratings is only one way to accomplish the goal of recognizing outstanding individuals.

People—and their jobs—evolve over time. ScrumMaster may start off coaching a team on the basics of Scrum, and over time, take a bigger role working on systemic issues that hinder the team. Or he may develop exceptional coaching skills. If someone is truly performing above others within the same job it may be time to promote him or reclassify his job so that it’s at a higher pay level.

How do we know who to promote or fire?

Other readers asked, “Without yearly ratings, how will we know who to promote?” Looking at how a person has evolved in his job and the level of responsibilities is one way. Another option is to treat promotions as seriously as hiring: create a rigorous internal application process that involves interviews and auditions.

The truth is that many outstanding performers aren’t doing it for the money. They stay for love of their work and are most rewarded by new and challenging assignments.

The reverse question came up, too: “How will we know who to fire?”

It doesn’t take a rating to fire someone. If someone isn’t doing his job, there’s no reason to keep him on the payroll until the annual review cycle comes around. A ScrumMaster will know when someone isn’t doing his job or is making it harder for other people to do their jobs. He can coach the person, or if coaching is not or is no longer an option, work with a functional manager to move the person off the team. (Some teams manage their own team membership, and people who need to go move off the team, without a manager’s involvement.) And, poor performers will hang onto a job even if they aren’t receiving raises. They won’t be improving, though. They’ll be harboring resentment and telling themselves that they really are above average.

As with identifying outstanding good performers, consider the environment, as well as individual skills. Ask whether someone is truly underperforming, or whether the system is limiting his performance.

I spoke with a new agile coach recently who was beginning to doubt he was in the right role. “I just can’t get this group moving in the right direction,” he said. “Maybe I should go back to being a developer.”

When he described the situation to me in detail, I began to wonder if any new coach could move this group in the right direction. The project has several stakeholders who disagree about the direction of product. The team is split into three factions, which swirl around a long standing conflict between two team members. One member of the team is skeptical of agile methods and baits the coach at every opportunity. When he’s not baiting the coach, he’s working to bring other team members to his point of view. The new coach is struggling in his job. The person who is supposed to mentor him is missing in action. I don’t think firing him—or giving him a low rating—is the answer.

It would be more fruitful (and more difficult) to look at the system that assigned a brand new coach to this project and failed to provide support.

How do people know they need to improve?

How will people know they need to improve if they don’t have an annual review? The answer to this question is simple (though not easy): their ScrumMaster will tell them.

A letter or number rating or ranking is an evaluation. It may tell someone he needs to improve, but it doesn’t tell him what specifically he needs to do differently. In order to improve, people need clear behavioral descriptions and they need to understand the impact of behavior or results. Some managers provide specific examples along with the letter or number evaluation grade. However, most humans resist labels, so they may be busy with the emotional response to the rating, and not ready to fully listen as the manger gives examples.

Scrum runs on frequent feedback loops. That includes feedback to people on their work interactions and work results. Feedback on an annual cycle is worse than useless and is totally out of congruence with agile methods.

When organizations adopt Scrum, sooner or later they bump up against the problems caused by asking people to work collaboratively and then measuring and rewarding them for individual effort. But Scrum is all about making issues visible, so we can inspect and adapt. The time has come look at the evidence about pay and appraisal systems. We may want to succumb to the allure of the “merit pay” words, but performance appraisals are a barrier to delivering valuable software; it’s time for them to go.

Further Reading
  1. Out of the Crisis. W. Edwards Deming
  2. Hard Facts, Dangerous Half-truths and Total Nonsense: Profiting from Evidence-based Management. Jeffrey Pfeffer & Robert I. Sutton
  3. "Real-time Feedback"
  4. "How to Talk About Work Performance: A Feedback Primer"
  5. "Peer to Peer Feedback"
  6. "What Every Manager Should Know About Feedback" 
  7. What Did You Say? The Art of Giving and Receiving Feedback. Charles Seashore, Edith Seashore and Gerald M. Weinberg

Article Rating

Current rating: 5 (2 ratings)

Comments

Trevor Sterritt, CSM, 8/21/2007 11:46:57 PM
I'm a software development manager with direct reports, and I also serve as the Scrum Master on the projects that my team is responsible for. I consider performance management one of my primary responsibilities. I would boil my philosophy for performance management down to the following:

- managers should be having performance discussions with their employees all year long. Waiting until the end of the year or even mid-year prevents the development of high performing teams.

- performance ratings are not as important as the performance discussion itself. Too much emphasis on the rating adds noise to the value of the feedback message.

- top performers get the bulk of the raise/bonus pool, and I want everyone on the team to know that I approach pay decisions this way. It helps me to keep my best people motivated, encourage people that are struggling but are still valuable to the team, and send tough messages when I need to.

Alan Atlas, CST,CSC,CSP,CSM,CSPO, 8/31/2007 11:31:52 AM
I'm also a SW Dev Manager who was a Scrum Master. I agree with a lot of what you say, Esther, although I don't find the pay practices you mention compelling from the standpoint of recruiting and retaining the really good performers. As a Scrum Master/Dev Manager, I did two things to try to make everything sensible while at the same time enabling performance management:
1. I gave the entire team the same yearly goals. At review time, each person wrote up what they did to contribute to meeting those goals. By doing this, I was trying to focus on the team's success without having to have HR change the performance review process.
2. Frequent 360-degree feedback. I firmly believe that the team is the best source of judgments on the performance of team members (including the Scrum Master). As the manager, I collected and homogenized the feedback, then met with each individual to go over with them what the team felt about their performance. This seemed to work well for me and my team, and yes, I did get skewered several times. I think the team really felt that they were collectively managing each other's performance.

It wasn't perfect, but it actually wasn't too bad.

You must Login or Signup to comment.