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


An objective ranking system is unnecessary when trying to determine an employee's value, and it can even be detrimental to collaboration on teams. Providing feedback, facilitating knowledge building, and allowing them to contribute are three key ways to help your employees excel in their roles.

“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.


About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.