Back when I first left college and got a job, I worked for Hewlett-Packard. HP was a great place to learn engineering, to become a good manager. HP was a large, slow moving company however, so for many people, the next step was to go and apply those skills elsewhere. In my case, the faster company was Microsoft. I worked there from 1987 to 1998. Those of you who are familiar with what was happening in the software business and the stock market will know this was a very good time to be at Microsoft. I am eternally grateful.
One of the things that I learned at HP was Total Quality Control (TQC, as it was termed back then). Now, these days, TQC has been replaced by a myriad of ISO number sequences, but I think the basic tenets hold: measure lots of stuff, understand your processes, fix them.
One of the things that most struck me about TQC, something that has stayed with me in the 20+ years since I left HP, was an anecdote from a Japanese automobile company executive. At the time, American car quality was very poor. The Japanese executive commented that their American counterparts had only taken the first step towards TQC: they were looking for and counting defects in the cars exiting the production line. The second step, he explained, was to look at your processes and find out why defects were occurring. If door panels were misaligned, you needed to look at your door assembly process and figure out why the misalignment was occurring. The third step, he went on, was to understand what was wrong with your “meta-processes”. What were you doing that resulted in a poor door assembly process. This “upstream” analysis of corporate process and culture, he explained, was crucial to TQC.
When I got to Microsoft, I was thrilled to be working at a faster company. My first week there, my manager took me aside and told me to stop waiting for consensus. If I thought something needed to be done, I should go and do it and apologize later for any mistakes along the way. Microsoft spent very little time thinking about TQC, scheduling methodology, management techniques, etc.
The company was extremely decentralized. The Excel team cared only about Excel. The Word team, only about Word. I remember “midnight requisitioning” where we would go to an adjacent building and steal some other groups’ office chairs (only to have them restolen by some other group on some other night). Each business was run by a general manager responsible for, maybe, 100-200 people and $100-200M worth of revenue. The technical and marketing managers were all aware of their group’s P&L and were all doing everything they could to beat their competition (back when Microsoft had competition: Lotus, WordPerfect, etc.).
My first year at Microsoft, I spent in the Systems group. I was working on the Windows 1.0 SDK and then on OS/2 Presentation Manager. The latter project, of course, was part of the JDA (Joint Development Agreement) with IBM.
Everyone hated working with IBM. They were slow. They were bureaucratic. They had hundreds of developers writing software that was bloated and buggy. Our developers would rewrite code in half the time and half the memory. IBM was also weird. They insisted on their own terminology (remember DASDs instead of hard disks? PELs instead of pixels?). They wanted to change the cartesian origin of the graphics canvas (in spite of the typical layout of display memory). Microsoft engineers rejoiced when the JDA fell apart. The company focused on making Windows successful and the rest is history.
Fast forward 20 years. Replace IBM with Microsoft and the same story could be told. It is Microsoft that has gotten big and slow. It is Microsoft that is having trouble executing on its strategies. It is Microsoft that ignores industry standards and insists that others follow its directions.
This is not to say that there is nothing good happening at Microsoft. I still have many friends working there and some are working on genuinely interesting things. Last week, I met with some folk in the System Center group who really seem to understand the importance of supporting non-Microsoft systems. It is altogether conceivable that Microsoft will continue to deliver on quarter after quarter of increased sales and revenue.
And yet, I think there’s something fundamentally wrong at 1 Microsoft Way. Although the company can survive in the short-term, I believe that its basic flaws will ultimately require a major restructuring of the company and its business. IBM has successfully converted itself into a service company (although its mainframe business is booming!). Microsoft may need to perform a similarly radical redefinition.
In my next few posts, I’ll go more into what I think is wrong in Redmond and what they need to do to fix it. Here’s a hint: it has something to do with TQC and listening to Japanese auto executives.