"Stack ranking" as it has been reported to be used at Microsoft, is multiple things conflated together. Some of these things are, by themselves, not necessaril

"Stack ranking" as it has been reported to be used at Microsoft, is multiple things conflated together. Some of these things are, by themselves, not necessarily bad. The problem is that people hear the words "stack ranking", and immediately jump to "eeeeevil" and "that's what killed Microsoft", and "Google does stack ranking, it must be doomed / I'd never want to work there", which is sloppy thinking. Let's taking what people are calling "stack ranking" apart. The first aspect of stack ranking, is simply forcing people to make decisions about what things/object/people are more important/better/etc. than others. This can be a valuable technique. For example, there is a very useful testing instrument I took a while back that took a list of twenty values, e.g., "justice", "loyalty", "honesty", "security", "family", etc., and asked me to force rank sets of five of these values in order of which I thought were most important to least important (i.e., DNI Clapper would rank "honesty" below that of "loyalty" and "security"; others might make different choices --- there were no right answers). By taking twenty or thirty of these different subsets, ranked in the order of which I thought were most valuable, a computer program would allow me to see which values I considered most important, and which I considered least important. This was a valuable thing, and so the technique of doing forced ranking is and of itself a useful thing. The second technique is that of trying to normalize employee performance review ratings across departments --- whether using a bell curve, or some other technique. Again, in isolation, this isn't necessarily a bad thing. Some managers might grade their employees more harshly, and some might be soft touches. Within a departmental level, it may be easier for a manager to argue that his team were all stars, but how do you deal with the question of an entire department using a harsher or more lenient grading system? One of the simplest things to do is to use a bell curve --- which may or may not be fair, especially if the company says (and all companies will claim this) that they hire the "best and brightest". The final component is what do you actually do with this normalized ranking number? If you really believe that everyone you've hired are the "best and the brightest", then firing the lowest scoring 5% is insane. If however you don't have confidence in your hiring mechanisms, such that some duds make it past your hiring screens, then firing the lowest 5% may make a lot of sense; you want to get rid of them before they do (more) damage. (BTW, this is is why I believe a hiring system which tries extremely hard to avoid hiring duds, at the expense of sometimes failing to hire qualified individuals, is extremely important; it has its downsides, but it's very much a necessary evil, because the alternatives are far worse.) What about using this number as an input to compensation? Here, using a normalized bell curve may make more sense. Certainly if you only have fixed pot of money to use for salary increases and equity refreshes, you want to make sure that your top performances get rewarded. What about promotions? For junior engineers, if they are growing in their job, presumably they should get promoted as they demonstrate that they are getting better at programming and understanding the company's systems and development environment. Using the performance rating would certainly be one metric, but evaluating that person's proficiency and results should probably be just as important, if not more so. The point is that just doing a "stack rank", whether as an input to the performance review mechanism (i.e., asking other employees to stack rank their peers, and then having some algorithm to merge those inputs together, and taking into account controversial rankings where multiple colleagues had differing opinions about whether person A was more or less effective than person B) or whether managers are forced to stack rank all of the employees in their department, is not necessarily a bad thing. The problem comes from what do you _do_ with the stack ranking after you've generated it. It's that which can drive a company's culture, either positively or negatively. So my suggestion to Microsoft employees (other than to consider a career at Google :-), is to not rail against stack ranking per se, but to point out some of the negative effects of some of the things are done with the stack rank after it has been generated. Perhaps, if your HR people are at all competent, they might be more amenable to your suggestions. Or, maybe you'd be better off considering another company altogether, in which case my first suggestion still stands. :-)