In the mid-1990s I was hired as an executive (director level) into IBM. My group was a services group chartered with developing solutions using object technology for IBM’s clients. During my tenure, we grew to have about 150 people in the group. IBM insisted that we hire the best object technologists we could find and we were empowered to do some unconventional (for IBM) HR gymnastics to make it happen. The price for the best object technologists was high so we had to put engineers into IBM pay bands typically reserved for senior managers. In this respect we were unlike any other group at IBM at the time.
Okay, now jump forward to the end of the fiscal year—performance review time! I received very specific instructions from IBM HR. I was to rank each of my direct reports on a scale of one, two, and three. If an employee received a one she was stellar and IBM wanted to make sure she got a good bonus. If an employee received a two she was doing the job expected of her and would receive the median bonus. And, if she received a three, she was to be shown the door. Fired. Sacked…
When I read those instructions, I thought to myself, “OK, I can do that.” What bothered me was the next part of the instructions: a certain percentage of my people had to be ranked a one, a two, or a three! And 10% of the people needed to be ranked a three!
Remember, IBM had tasked me with hiring the best possible people in the industry and paying them outrageous sums of money to employ them. I thought to myself, if I have anyone who is a three in this group they ought to fire me!
The process that IBM was asking my group to follow is called stacked ranking. It has been very popular at larger companies—GE (through their CEO emeritus Jack Welch), for example, has been a huge proponent of this approach.
Stacked Ranking in an Agile Environment
A few years ago I was teaching a class for a large company that used stacked ranking. As you know, applying agile effectively requires considerable collaboration among the people doing the work. Time and again during this class whenever I would make a point that emphasized the importance of collaboration in being successful, the people in the class would balk and say that the type of collaboration I was discussing just wasn’t possible in their environment. The reason given every time was stacked ranking.
Stacked ranking leads to employees focusing on competing with each other rather than competing with other companies, leaving no motivation to work together to create a great agile team. If we are on a team of 10 people, then all of us know that from day one, no matter how good we are as a team or how great each of us might be individually, two of us are going to get a great review, seven are going to get an average review, and one is going to get a horrible review. So what really matters to individuals on that team? Don’t be one of those people in the bottom rank. Its like the old joke that I don’t have to be faster than the bear, I just need to be faster than you!
Not only did people at this company not collaborate, they were essentially incentivized not to collaborate. This issue of stacked ranking was an impediment to the students in my class. They couldn’t figure out how to make agile work in an environment that enforced stacked ranking.
I agree with them! I don’t know how to make agile, an inherently collaborative process, work in an environment that promotes a dog-eat-dog world of fierce internal competition among members of the same team!
My only solace was that six months after the class completed, there was an article in a prestigious business magazine proclaiming that stacked ranking at the company where I taught had been abolished. Sadly by that time stacked ranking had taken its toll. The company had become uncompetitive in most of its markets and excellent employees had already moved on to other companies.
Does your company use stacked ranking? If so, please leave a comment below about how it is helping or hindering your ability to do great agile!