VF, MS, and ranking

The cover article in the August issue of Vanity Fair is Kurt Eichenwald's detailed critique and analysis of Microsoft's problems: Microsoft's Lost Decade: How Microsoft Lost its Mojo.

Eichenwald, who is only 8 days younger than me, has only recently been writing for Vanity Fair, I believe, but he has been one of the nation's top financial journalists for decades, primarily at the New York Times. He is perhaps best known for a dramatic and very controversial investigation of the Internet sex trade about 7 years ago.

The article has been much commented on, including a spirited defense from Ballmer at Forbes.

Eichenwald's article takes Microsoft to task for several sins, most importantly insufficient risk-taking:

a lumbering Microsoft relied mostly on pumping out Old Faithfuls such as Windows, Office, and servers for its financial performance.

Amid a dynamic and ever changing marketplace, Microsoft—which declined to comment for this article—became a high-tech equivalent of a Detroit car-maker, bringing flashier models of the same old thing off of the assembly line even as its competitors upended the world.

It's not entirely unfair, although I think that Eichenwald, who is primarily a financial analyst and not a technology person, gives Microsoft far too little credit for its amazing defense of its Windows and Office franchises. In particular, Microsoft moves slowly for a reason: corporate customers are insanely demanding when it comes to backward compatibility and smooth upgrades. It is astoundingly hard to take software as complex and powerful as the Windows/Office package and evolve and enhance it year-to-year without abandoning or antagonizing your existing customer base.

My wife's company is a perfect example of this. When she joined them nearly a decade ago, they were still running Windows 98 desktops with an ancient Novell file server carrying the shared-office load. Over time, she has brought them along, first to Windows XP, then more recently to Windows 7, and from Office 97, through Office XP and Office 2003, and (soon) to Office 2010.

The amount of painstaking attention to detail, thorough regression testing, detailed documentation, and careful external testing that is required to deliver multi-decade upgrade paths such as these is greatly under-valued by most people outside of the tech industry, in my opinion. Very few companies pay this much attention to upgrade and compatibility, and Microsoft should get a lot more credit than they do for their successes here.

Eichenwald, however, with the benefit of hindsight, sees only the missed opportunities:

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

However, Eichenwald isn't really interested in the product strategy debate, important though it may be. He's far more interested in the tough topic of how you organize a 100,000 employee company so that it is simultaneously efficient and entrepreneurial. In vivid prose, Eichenwald points to a dramatic period around the turn of the century, when the first Internet bubble popped and Bill Gates stepped down:

On December 30, 1999, the face from the computer application frowned. ... Even Microsoft, it turned out, was not immune to the dot-com crash.

Sixteen days later, Bill Gates handed off the C.E.O. reins to Ballmer. ...

A businessman with a background in deal-making, finance, and product marketing had replaced a software-and-technological genius. ...

The music had stopped. The Microsoft Millionaires were now working alongside the Microsoft Minions. One came to work bragging about his new Bentley; the other made do with a Dodge Neon. The days of shoulder-to-shoulder teams fighting to beat the world were over. A financial fissure tore at already strained relationships between the Old Guard and the new blood.

This situation isn't unique to Microsoft, of course. New employees joining Google, Facebook, Apple, or Amazon right now certainly aren't going to be showered with the riches that those who joined a decade ago were. I'm certain that anyone who took the time could easily find just as many sour-grapes tales at these companies right now, as Eichenwald relates from his chats with (mostly former) Microsoft employees.

Of course everybody at the company is happier when everyone is getting rich, but there's no story there. So, to his credit, Eichenwald works to try to unearth some wisdom about what a company faced by such a situation does do to preserve employee motivation as growth necessarily slows.

Eichenwald notes that one thing that occurs as a company grows and ages involves the emergence of a bureaucracy:

Where once creating innovations was both the thrill of the job and the path to riches through stock options, guaranteed financial success could now be achieved only the way it was at stodgy old General Motors or IBM—through promotions.

It's not clear that there's anything unique to Microsoft in this part of the story, but as Eichenwald tells it, it's certainly an unpleasant transition for the company to undergo:

By 2002 the by-product of bureaucracy—brutal corporate politics—had reared its head at Microsoft. And, current and former executives said, each year the intensity and destructiveness of the game playing grew worse as employees struggled to beat out their co-workers for promotions, bonuses, or just survival.

And here's where he turns to ranking.

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.

Again, it's not clear to me that Microsoft's usage of employee ranking was new, different, or unusual; the process as described by Eichenwald seems to match the process that, for example, Computer Associates used back in the early 1990's. We used to call this the "Harvard Business Review effect": some issue of the HBR features an article on some new management practice; the nation's MBA-educated management professionals all read the same article; and six months later every company is trying the same management technique.

I don't know what seminal article initiated the "stack ranking" trend, but nowadays it's everywhere. My friends at various large tech companies tell me that there isn't a major high-tech company out there that doesn't do this, in one form or another.

So, is Microsoft's implementation particularly brutish or demotivational? Here's what Eichenwald has to say about it:

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.

It's certainly true that the objectives game is a poor one. In my experience, a year is nearly an eternity in the high-tech industry, which creates, immediately, a terrible problem for a system like this. Since no high-tech company can possibly plan in detail for a full year in advance, companies only put the vaguest and highest-level goals into their corporate yearly plans. Individual managers, then, have no ability to set reasonable goals for their employees for an entire year. Setting goals for the next three months is possible, but for a year? Fuh-gedda-bout-it!

So, what do those managers do? Well, in my experience, they set out cautiously-worded, generic, nebulous goals such as: "respond to important issues raised during the year", or "address problems exposed by external testing during product launch".

Then, when the year ends, lo-and-behold everyone has achieved their goals!

So the goals become useless for actually evaluating the relative performance of the employees, and the reality of the yearly review becomes as described by Eichenwald:

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.

Ugh. I've seen these scenes. They're a mess, no question.

Eichenwald doesn't offer any solutions to these problems, and I haven't seen much from other commenters, either.

I'm not sure there are any easy solutions. The key is in understanding what motivates an engineer. Money is surely one such thing, but others are harder to reduce to numbers and rankings: working with other great engineers; solving problems that haven't been solved before; having the opportunity to reach a wide audience; building something that will stand the test of time.

Basically, if you're looking to your ranking/review process to motivate your employees, you've already lost the battle, and you've become one of those gigantic boring high-tech companies which exciting engineers flee. Instead, go read Michael Lopp's essays on software industry management and try to understand how software engineering really works.

In the end, I'm pleased that "the mainstream media" are devoting more attention to high tech companies such as Microsoft, but until they spend less time thinking of these companies in simple financial MBA terms, worthy only of being compared to "Detroit car-makers", and more time thinking of these companies as peopled by unique individuals such as described by Lopp, it's hard to see what insights even a great writer such as Eichenwald is going to be able to bring.

But go read the Vanity Fair article yourself; it's entertaining and enjoyable, and if you knew nothing about Microsoft or about the software industry before, you'll surely learn quite a bit.

Just don't think that's all there is to know.