Anyone with friends or associates working for Microsoft these last few years has heard stories of its bizarre internal employee appraisal system, called stack ranking:   Every group, no matter how wonderful or effective, must include some poor performers – by decree, not for any other reason.   One is reminded of Stalin’s imposition of quotas on the intelligence agencies for finding spies in the USSR in the 1930s.    With this system, it is not sufficient that people achieve their objectives or perform well: to be also rated as performing well, others in the same team must be rated as performing poorly.   There are three extremely negative outcomes of this system:  first, good and even very good performers get rated as performing poorly; second, immense effort is spent by almost everyone in ensuring  that others do badly in the ratings; and third, team spirit dissolves.
The August issue of Vanity Fair has a long profile of Microsoft and its current ills, Microsoft’s Lost Decade, by Kurt Eichenwald, here, which discusses this system in detail.     Here is a description of  the system and its consequences:

At the center of the cultural problems was a management system called “stack ranking.” Every current and former Microsoft employee I interviewed—every one—cited stack ranking as the most destructive process inside of Microsoft, something that drove out untold numbers of employees. The system—also referred to as “the performance model,” “the bell curve,” or just “the employee review”—has, with certain variations over the years, worked like this: every unit was forced to declare a certain percentage of employees as top performers, then good performers, then average, then below average, then poor.
“If you were on a team of 10 people, you walked in the first day knowing that, no matter how good everyone was, two people were going to get a great review, seven were going to get mediocre reviews, and one was going to get a terrible review,” said a former software developer. “It leads to employees focusing on competing with each other rather than competing with other companies.”
Supposing Microsoft had managed to hire technology’s top players into a single unit before they made their names elsewhere—Steve Jobs of Apple, Mark Zuckerberg of Facebook, Larry Page of Google, Larry Ellison of Oracle, and Jeff Bezos of Amazon—regardless of performance, under one of the iterations of stack ranking, two of them would have to be rated as below average, with one deemed disastrous.
For that reason, executives said, a lot of Microsoft superstars did everything they could to avoid working alongside other top-notch developers, out of fear that they would be hurt in the rankings. And the reviews had real-world consequences: those at the top received bonuses and promotions; those at the bottom usually received no cash or were shown the door.
Outcomes from the process were never predictable. Employees in certain divisions were given what were known as M.B.O.’s—management business objectives—which were essentially the expectations for what they would accomplish in a particular year. But even achieving every M.B.O. was no guarantee of receiving a high ranking, since some other employee could exceed the assigned performance. As a result, Microsoft employees not only tried to do a good job but also worked hard to make sure their colleagues did not.
“The behavior this engenders, people do everything they can to stay out of the bottom bucket,” one Microsoft engineer said. “People responsible for features will openly sabotage other people’s efforts. One of the most valuable things I learned was to give the appearance of being courteous while withholding just enough information from colleagues to ensure they didn’t get ahead of me on the rankings.”
Worse, because the reviews came every six months, employees and their supervisors—who were also ranked—focused on their short-term performance, rather than on longer efforts to innovate.
“The six-month reviews forced a lot of bad decision-making,” one software designer said. “People planned their days and their years around the review, rather than around products. You really had to focus on the six-month performance, rather than on doing what was right for the company.”
There was some room for bending the numbers a bit. Each team would be within a larger Microsoft group. The supervisors of the teams could have slightly more of their employees in the higher ranks so long as the full group met the required percentages. So, every six months, all of the supervisors in a single group met for a few days of horse trading.
On the first day, the supervisors—as many as 30—gather in a single conference room. Blinds are drawn; doors are closed. A grid containing possible rankings is put up—sometimes on a whiteboard, sometimes on a poster board tacked to the wall—and everyone breaks out Post-it notes. Names of team members are scribbled on the notes, then each manager takes a turn placing the slips of paper into the grid boxes. Usually, though, the numbers don’t work on the first go-round. That’s when the haggling begins.
“There are some pretty impassioned debates and the Post-it notes end up being shuffled around for days so that we can meet the bell curve,” said one Microsoft manager who has participated in a number of the sessions. “It doesn’t always work out well. I myself have had to give rankings to people that they didn’t deserve because of this forced curve.”
The best way to guarantee a higher ranking, executives said, is to keep in mind the realities of those behind-the-scenes debates—every employee has to impress not only his or her boss but bosses from other teams as well. And that means schmoozing and brown-nosing as many supervisors as possible.
“I was told in almost every review that the political game was always important for my career development,” said Brian Cody, a former Microsoft engineer. “It was always much more on ‘Let’s work on the political game’ than on improving my actual performance.”
Like other employees I interviewed, Cody said that the reality of the corporate culture slowed everything down. “It got to the point where I was second-guessing everything I was doing,” he said. “Whenever I had a question for some other team, instead of going to the developer who had the answer, I would first touch base with that developer’s manager, so that he knew what I was working on. That was the only way to be visible to other managers, which you needed for the review.”
I asked Cody whether his review was ever based on the quality of his work. He paused for a very long time. “It was always much less about how I could become a better engineer and much more about my need to improve my visibility among other managers.”
In the end, the stack-ranking system crippled the ability to innovate at Microsoft, executives said. “I wanted to build a team of people who would work together and whose only focus would be on making great software,” said Bill Hill, the former manager. “But you can’t do that at Microsoft.”

And, according to Eichenwald, Microsoft had an early lead in e-reader technology that was lost due to the company’s cultural bias in favour of the Windows look-and-feel:

The spark of inspiration for the device had come from a 1979 work of science fiction, The Hitchhiker’s Guide to the Galaxy, by Douglas Adams. The novel put forth the idea that a single book could hold all knowledge in the galaxy. An e-book, the Microsoft developers believed, would bring Adams’s vision to life. By 1998 a prototype of the revolutionary tool was ready to go. Thrilled with its success and anticipating accolades, the technology group sent the device to Bill Gates—who promptly gave it a thumbs-down. The e-book wasn’t right for Microsoft, he declared.
“He didn’t like the user interface, because it didn’t look like Windows,” one programmer involved in the project recalled. But Windows would have been completely wrong for an e-book, team members agreed. The point was to have a book, and a book alone, appear on the full screen. Real books didn’t have images from Microsoft Windows floating around; putting them into an electronic version would do nothing but undermine the consumer experience.
The group working on the initiative was removed from a reporting line to Gates and folded into the major-product group dedicated to software for Office, the other mammoth Microsoft moneymaker besides Windows. Immediately, the technology unit was reclassified from one charged with dreaming up and producing new ideas to one required to report profits and losses right away.
“Our entire plan had to be moved forward three to four years from 2003–04, and we had to ship a product in 1999,” said Steve Stone, a founder of the technology group. “We couldn’t be focused anymore on developing technology that was effective for consumers. Instead, all of a sudden we had to look at this and say, ‘How are we going to use this to make money?’ And it was impossible.”
Rushing the product to market cost Microsoft dearly. The software had been designed to run on a pad with touch-screen technology, a feature later popularized with the iPhone. Instead, the company pushed out Microsoft Reader, to run on the Microsoft Pocket PC, a small, phone-size device, and, soon after, on Windows. The plan to give consumers something light and simple that would allow them to read on a book-size screen was terminated.
The death of the e-book effort was not simply the consequence of a desire for immediate profits, according to a former official in the Office division. The real problem for his colleagues was that a simple touch-screen device was seen as a laughable distraction from the tried-and-true ways of dealing with data. “Office is designed to inputting with a keyboard, not a stylus or a finger,” the official said. “There were all kinds of personal prejudices at work.”
Indeed, executives said, Microsoft failed repeatedly to jump on emerging technologies because of the company’s fealty to Windows and Office. “Windows was the god—everything had to work with Windows,” said Stone. “Ideas about mobile computing with a user experience that was cleaner than with a P.C. were deemed unimportant by a few powerful people in that division, and they managed to kill the effort.”
This prejudice permeated the company, leaving it unable to move quickly when faced with challenges from new competitors. “Every little thing you want to write has to build off of Windows or other existing products,” one software engineer said. “It can be very confusing, because a lot of the time the problems you’re trying to solve aren’t the ones that you have with your product, but because you have to go through the mental exercise of how this framework works. It just slows you down.”