Management Myth #5: We Must Have an Objective Ranking System

Submitted by Johanna Rothman on Tue, 2012-06-12 09:00

“It’s time for our annual management meeting to rank everyone in engineering,” Don, the VP started to explain to his three directors.

“Hold on a minute,” interrupted Dave, the development director. “We didn’t do this last year, because we explained we can’t be objective and it makes no sense. We thought we eliminated this nonsense.”

“Well, Dina, the new HR VP, believes in it. We have to fit everyone in engineering to a 20%-70%-10% curve.”

Dave looked as if he would have a coronary.

Jim, the QA director, asked, “Why? What does she want out of this?”

“She thinks she can do a better salary fit to the salary norms if we do this,” Don said.

“What if we help her understand our job descriptions instead? Would that help her? We don’t hire to her curve—we hire way above her curve. And, because we don’t hire for technical skill but for cultural fit and for the ability to teach and learn, she is not going to get what she wants with her curve. You know, the problem is that she doesn’t fit the culture here.”

Sharon, the project and release management director piped up, “I have an idea. Dina needs to see our projects. She doesn’t understand what our cross-functional teams look like—the agile and the not-yet-agile ones. Dina doesn’t understand that software is a design activity and it’s a team sport. She thinks we can pick one person and reward that person. I’ll volunteer to show her around for a day or two and explain what she is seeing. I bet Dina has no idea what servant leadership means.”

Over the next couple of days, Sharon escorted Dina around the engineering organization. Sharon explained how their projects worked: that all the teams were cross functional and that team members depended on one another. Sharon and Dina spent time in team problem solving meetings, where Dina could see how team members interacted.

After one team meeting, Dina asked for a replay of who was whom. “So, who was the first person writing at the board? That was the project manager, right?”

“No, that was the architect first,” Sharon replied. “Then one of the testers took over.”

“A tester? But that person was arguing with the architect. They stood toe to toe, drawing pictures.”

“Yeah,” Sharon laughed. “Wasn’t that great? I liked it when the chess timer went off and they had to agree to try a prototype instead of discussing it anymore. That’s one of that team’s working agreements.”

“But the tester was fighting with the architect,” Dina began.

“Dina, this is why we can’t stack-rank anyone,” Sharon interrupted. “We work very hard to make sure everyone knows that we want them to collaborate. We, as a management team, trust them to make the right decisions for the product. The project teams have feedback built into everything they do, so they know how to trust themselves. If we do this crazy stack-rank thing, we will destroy everything we have built. We will lose everyone’s trust. We will lose the transparency we’ve built. We will lose their expertise. All the good people will leave.

“You are asking us to do something that doesn’t fit into any software development culture. Software is a collaborative design effort. If you want to maintain collaboration, you don’t pit one person against the others, which is what stack-ranking does. It doesn’t make sense to do this.”

Dina agreed and decided she could do salary norms another way.

Ranking Systems Destroy Collaboration at All Levels
Ranking systems have never made sense to me. The first time I participated in one, we attempted to rank all eighty-five people in an engineering group. We were trying to rank developers against testers against writers against architects against performance engineers against sysadmins. By the time we were done, the management team had created a ranked list, but it was not objective. No sirree. We had horse-traded, used our influence, negotiated, and angered each other. It was ugly. Our VP was satisfied, but he was the only one who was.

As a management team, we stopped being able to collaborate that day. Our VP asked us to play a zero-sum game, where one of us would win (him) and the rest of us would lose. We didn’t trust each other anymore. We damaged our relationships as a management team that day, some beyond repair. I left that company soon after.

Here’s why ranking systems make no sense: People contribute to the best of their abilities. If they aren’t contributing, it may not be their fault. If you think ranking systems are useful, first ask yourself these questions:

Are people receiving adequate and timely feedback about what to continue or change?

Do people have the knowledge to do their jobs?

Does the organizational system, the environment, allow them to contribute to the best of their abilities?

If you can’t answer yes to all of these questions, there is no point in having a ranking system. And, if you can answer yes to these questions, you don’t need a ranking system. If people can’t contribute, it’s part of the manager’s role to help them out of the organization, a topic for another myth.

Consider Alternatives to a Ranking System
So what can you do instead of a ranking system? You can make sure people have feedback, so they know what to continue doing in their jobs or what they need to change to perform better. Sometimes, people don’t know that what they are doing isn’t quite right and you can provide them the knowledge to perform their jobs better or arrange for training. Sometimes, people need to talk to others who perform similar jobs or roles. In that case, your management job is to facilitate communities of practice.

People Need Feedback to Know What to Continue or Change
People need feedback. They need feedback primarily from their teammates in an agile organization. If you haven’t transitioned to agile and you, the manager, are assigning work, your team members need feedback. They need to know how they are doing, and a ranking system doesn’t tell them that. If their contributions aren’t adequate, they need to know. If their contributions are outstanding, they need to know that, too. Whatever your team members’ contributions are, they need to know. So, your team needs feedback.

If your team members aren’t receiving feedback from their peers or you, is it because no one knows how to provide feedback? That’s a common problem. Here’s a peer-to-peer model of feedback from Behind Closed Doors: Secrets of Great Management :

Create an opening to deliver the feedback.
Describe the behavior or result in a way the person can hear.
State the impact using “I” language.
Make a request for changed (or continued in the case of reinforcing feedback) behavior.

Here’s how this can occur during a workday. Let’s say you have someone, Tim, with bad breath and it’s affecting how other people want to work with that person. You’ve noticed it today, and it’s affecting you. You decide to provide Tim with feedback right now.

“Tim, do you have a minute to talk?”

“Sure, what about?”

“Let’s get a conference room where we can talk in private.” The two of you walk into a conference room.

“Tim, I’ve noticed that when we sit together side by side to work on the stories for this product, I can smell your breath. I’m a little embarrassed to tell you this, but I thought you’d want to know. The reason I’m telling you is that I’m finding it difficult to work with you. I wanted to get this out in the open. Is there something we can do?”

Notice that you didn’t blame Tim for his breath. You didn’t tell him not to eat garlic. You did tell him that you were having trouble working with him. You asked him for a change.

Most people, when they receive feedback like this, are a little embarrassed, too. They almost always thank the person who provides the feedback, and they often ask for more data. “I had no idea. Does this happen all the time?”

“Well, I just noticed it today.”

“Oh, maybe if I chew some gum that will help. Will you tell me if it happens again?”

“Sure, no problem. How would you like me to tell you?”

Now you have a solution and way to address the problem in the future. You weren’t comfortable, but you both lived through the feedback.

Direct feedback is best. If you leave a bottle of mouthwash on someone’s desk, that person will not understand the problem.

People Need Knowledge
Sometimes, people don’t know that they need training to change what they are doing. You can provide feedback and ask if they need training.

It’s the same problem and solution if someone breaks the build. “Lisa, you broke the build three times this week, on Monday at 2pm, Tuesday at 4pm, and Wednesday at 10am. When you break the build, it slows everyone down. What can we do about this?”

“Oh, is that a problem?”

“Yes, it is. We have an agreement here that we are not allowed to break the build. First you build on your machine, make sure everything works, and then you can check in. Did you know that?”

“No, I didn’t.”

“Ooh. I wonder what else you don’t know. Let’s review a couple more things.”

Maybe Lisa knew and she forgot. Maybe no one ever explained these team norms. But now she knows. Now she can be successful. You might need to provide other training as your systems evolve.

Managers Create a System that Allows People to Contribute
One of the biggest things you can do as a manager is to make sure that people can contribute. That means that the technical staff are not multitasking on multiple projects. If you and your peers manage the project portfolio, the technical staff can manage the technical work. That’s part of creating an environment in which people can work.

You might also have to create communities of practice. Managers are not the only people who have expertise—in fact, managers often don’t have the expertise any longer if they are doing a good job managing. But people need to be able to discuss their technical concerns with others in the organization. So, you can create and enable communities of practice.

In a community of practice, you help people with similar jobs or interests get together, then you step back and watch the magic happen. You might organize time for an open space, arrange lunch-and-learns, or plan more formal coaching and mentoring. On a project or a program, you might have to be more formal to make sure that the architects or testers or business analysts share information, risks, and progress on a regular basis. Whatever the reason for your communities of practice, your role as a manager is to facilitate the initiation of them.

Don’t Use a Ranking System as a Substitute for Management
Do you want to know how people are doing? Provide feedback often, from peers and from managers. Do you want to make sure their salaries are equitable? Don’t rank them. Instead, have one-on-ones and make sure you, as a manager, know what they are doing and what their value is to the organization. Especially don’t use a ranking system to force people into a curve. If you’ve been hiring, paying attention to cultural fit, and providing feedback and training, you don’t have people in the bottom 10 percent.

There is no evidence that ranking systems help. There is significant evidence that ranking systems hurt. Don’t use them—unless you want to destroy collaboration in your organization.

Read more of Johanna's management myth columns here: