Microsoft Secrets by Michael A. Cusumano: Book Cover

- Table of Contents
  Read an Excerpt
  Read a Sample Chapter

Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People by Michael A. Cusumano, Richard W. Selby, Richard W. Selby (Introduction)

BUY IT NEW

$32.95 Online price
$29.65 Member price

Join Now

Add To List

Usually ships within 24 hours

BUY IT USED

23 used from $1.99

Used Copies Available from our Authorized Sellers.

(Paperback - 1 TOUCHSTO)

Reader Rating: (1 ratings)

See All Detailed Ratings

Publisher: Free Press, The
Pub. Date: December 1998
ISBN-13: 9780684855318
Sales Rank: 269,140
532pp
Edition Description: 1 TOUCHSTO

�

Synopsis

Today, Microsoft commands the high ground of the information superhighway by owning the operating systems and basic applications programs that run on the world's 170 million computers. Beyond the unquestioned genius and vision of Bill Gates, what accounts for Microsofts astounding success?

Drawing on almost two years of on-site observation at Microsoft headquarters, eminent scientists Michael A. Cusumano and Richard W. Selby reveal many of Microsoft's innermost secrets. This inside report, based on forty in-depth interviews by authors who had access to confidential documents and project data, outlines the seven complementary strategies that characterize exactly how Microsoft competes and operates, including the "Brain Trust" of talented employees and exceptional management; "bang for the buck" competitive strategies and clear organizational goals that produce self-critiquing, learning, and improving; a flexible, incremental approach to product development; and a relentless pursuit of future markets.

Cusumano and Selby's masterful analysis successfully uncovers the distinctive way in which Microsoft has combined all of the elements necessary to get to the top of an enormously important industry—and stay there.

Annotation

Today, Microsoft commands the high ground of the information superhighway by owning the operating systems and basic applications programs that run on the world's 170 million computers. Based on nearly two years of on-site observation at Microsoft headquarters, two eminent scientists now reveal many of Microsoft's innermost secrets. 10 line drawings.

More Reviews and Recommendations

Biography

Michael A. Cusumano teaches strategy and technology managment at MIT's Sloan School of Management. He lives in Cambridge, Massachusetts.

Customer Reviews

Reader Rating:
Ratings: 1Reviews: 1

Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Marketsby Anonymous

Reader Rating:
See Detailed Ratings

February 13, 2002: The authors definitely did a fine work by doing excellent research about Microsoft's product development and marketing. This book would prove to be very helpful to those who are coming from a non-technical perspective. It occasionally offers some valuable insights into Microsoft's strategies but it is quite dry for the most part even for a person who has plenty experiences in software development. The Microsoft 'secrets' are not exactly impressive. It would be impossible to know the true secret in a book, otherwise every software company would become a Microsoft. The book is a bit dated, but nevertheless offers the curious reader some insights into the development and marketing of Microsoft's past successful (and unsuccessful) moves.

Table of Contents
Read an Excerpt
Read a Sample Chapter

	Preface to the Paperback Edition
	Preface
	Introduction	1
1	Organizing and Managing the Company: Find "Smart" People Who Know the Technology and the Business	21
2	Managing Creative People and Technical Skills: Organize Small Teams of Overlapping Functional Specialists	73
3	Competing with Products and Standards: Pioneer and Orchestrate Evolving Mass Markets	127
4	Defining Products and Development Processes: Focus Creativity by Evolving Features and "Fixing" Resources	187
5	Developing and Shipping Products: Do Everything in Parallel, with Frequent Synchronizations	261
6	Building a Learning Organization: Improve Through Continuous Self-Critiquing, Feedback, and Sharing	327
7	Attack the Future	399
App. 1	Microsoft Chronology	451
App. 2	Main Microsoft Desktop and Business Applications	457
App. 3	Microsoft Operating Systems	461
App. 4	Applications Division Employee Survey	465
App. 5	Selected Chronology of Microsoft Agreements for the Information Highway	469
	Interviews	473
	Notes	477
	Acknowledgments	493
	Index	499

Read an Excerpt

PREFACE TO THE PAPERBACK EDITION

It gives us great pleasure to write this special preface to the paperback edition of Microsoft Secrets, which we originally published in October 1995. The book has been translated into fourteen foreign languages and has been on best-seller lists around the world, in markets ranging from the United States and Japan to Germany, Brazil, and China. The personal computer software industry moves very quickly, and much has happened to Microsoft in the past three years. The strategies and principles discussed in Microsoft Secrets still appear to be guiding the company forward.

The Internet: The most important change has been the rise of the Internet and the World Wide Web. When we were writing this book, Microsoft was almost totally focused on finishing Windows 95 (which shipped in August 1995), revising Office and some other applications to go with its new operating system, and launching the proprietary online network, Microsoft Network. Not until December 1995 did Bill Gates and other Microsoft executives become truly serious about the Internet, even though they did ship a basic browser, Internet Explorer 1.0, with Windows 95.

Since that time, Microsoft has changed most of its product plans and products to make sure that they took advantage of the Internet's enormous capabilities. Microsoft now has 40 percent of the browser market (compared to 60 percent for Netscape). Microsoft also has a strong and growing position in server software based on Windows NT Plans for Microsoft Network did not work out as expected, although Microsoft has remade much of this system into a Web-based service.

Microsoft has made manystrategic acquisitions in the Internet arena to bolster its technical skills and market positions. These acquisitions include companies such as Vermeer, which created what is now Microsoft FrontPage (a leading program for creating Web pages), as well as Web TV (which allows users to surf the Web while using and watching television). Microsoft also continues to struggle with Sun Microsystems over standards for the Web, primarily involving the Java programming language and the potential of a non-Windows operating system and computing platform. Nonetheless, we can confidently say that Microsoft has demonstrated remarkable speed and agility as it has remade itself into an Internet company, while still remaining the dominant desktop software company. It is also a very strong player in enterprise software for corporations with products such as Windows NT and BackOffice.

Growth and Profits: We have seen no significant slowdown in growth or profitability at Microsoft. We think of the company as a train that continues to push forward. For investors, it does not matter so much when they jump on the train! In mid-1998, the company had approximately 26,000 employees (up from 17,800 in 1995). Sales were running at an annual rate of between $14 billion and $15 billion. Microsoft's expected profits of nearly $4 billion in 1998 also accounted for more than 40 percent of the profits of the ten largest publicly traded software companies. The company's stock price reflected these numbers and continued to rise and double every other year or so. Perhaps most important in driving these numbers was Microsoft's success in moving to the high-margin enterprise market as well as in persuading customers to upgrade their operating systems and applications software. Microsoft Office had about 90 percent of the desktop applications market and had become a standard in corporations. Windows NT and Microsoft BackOffice (which includes servers and database software) were also growing rapidly in market share. These corporate products had higher profit margins than products sold to individuals and guaranteed that Microsoft's profits would probably grow faster than its revenues.

Antitrust: Perhaps the biggest concern about Microsoft was antitrust. The federal government, individual state governments, and governments in Japan and Europe were all concerned that Microsoft was too powerful. We saw these same concerns when we published Microsoft Secrets in 1995. Government scrutiny of Microsoft seemed more intense in 1998, however. The scrutiny was not so much with regard to acquisitions but with Microsoft potentially using its position in operating systems to extend its dominance to other areas, such as Web-based Internet commerce.

The most recent serious debate has involved features or products that Microsoft is bundling into new versions of Windows. The browser that comes with Windows 98, for example, is much more tightly integrated into the operating system than in Windows 95. Microsoft also continued to include the browser at no extra charge (which forced Netscape to make its browser available for free also, even to companies that previously had paid for it). The problem: Microsoft has allegedly pressured computer manufacturers not to load competitors' products, such as Netscape's Navigator/Communicator browser. The browser is no longer a revenue source in itself, but it is critical as a "portal" to the Web. Both Netscape and Microsoft, for example, use their browsers to draw customers to their Web sites, from which point customers can purchase various products and services, such as books, news, and travel reservations. Furthermore, in Windows 98, Microsoft is including the Web TV software "for free" and is encouraging computer manufacturers to include hardware to support this technology. Web TV makes it possible to combine TV advertisements and programming with Internet-based sales.

Not all of Microsoft's initiatives will succeed. The company can misjudge markets, as it did with the Microsoft Network. Microsoft also has more competition in Internet markets than in operating systems or desktop software. But the possibilities are limitless for Internet commerce. And Bill Gates has clearly put Microsoft in a superb position strategically and technically to thrive in this new age of the Internet.

Product Development Process: To build new Internet and enterprise products, Microsoft has continued to use the same principles and organization for product development that we talked about in Microsoft Secrets. The company has made some minor changes, however, that we feel are important to note. For example, in Internet groups that want to move especially fast from ideas to final products, Microsoft developers sometimes take the lead in proposing features and writing up outlines of specifications. This leaves Microsoft program managers to work mainly on managing project schedules, writing up test cases with testers, or building relationships with outside partners and customers. Product managers, in this scenario, play less of a role and mainly work with customers or prepare for the sales efforts. Microsoft also continues to try to hire one tester for every developer, although this practice now varies more than in the past. We have seen some Internet groups that had more testers than developers, in order to speed up the process of stabilizing the product and getting it to market. Some other groups had fewer testers than developers and relied more on the release of frequent beta versions to get feedback on the quality of the product.

Impact of Microsoft Secrets: It is appropriate to close this preface with a few words on the impact of Microsoft Secrets as a book. We think the book has become popular because there is great interest in Microsoft, and our study has revealed at a very deep level how Microsoft works. We are told that the book has nearly become a "bible" to many software companies and nonsoftware companies, providing hints about how to manage highly creative people in dynamic markets.

We now know that Microsoft Secrets has become essential reading at a wide range of organizations. These include computer companies such as Sun Microsystems and IBM, software companies such as Netscape and Baan, financial companies such as Fidelity Investments and Swiss Bank, communications companies such as Ericsson and US West/Media One, and even NASA (the National Aeronautics and Space Administration). Many managers in these companies have been attracted to the alternative approach to product development that we called the "synchronize-and-stabilize" process. This process moves away from rigid, sequential approaches to product development. It allows engineers to make a lot of changes in their designs until late in a project, while still keeping individuals synchronized and the evolving product more or less stabilized. The synchronize-and-stabilize process enabled Microsoft to add, for example, Internet features (including the browser in Windows 95 and the ability to create HTML pages in Word) very late in projects that had not included these features in their original designs. The process is the essence of speed and flexibility, which is important not only in software but in many industries.

We would also like to say that studying Microsoft over a period of several years has been one of the most interesting and rewarding experiences in our professional lives. We are extremely grateful to the Microsoft people who made this book possible. We also expect that Microsoft Secrets will continue to be a basic reference on Microsoft and high-tech company management for many years to come.

Michael A. Cusumano

Cambridge, Massachusetts

Richard W. Selby

Newport Beach, California

June 1998

PREFACE

This study started in March 1993 as part of a project at MIT to compare the management of product development at PC software firms with that of older companies making software products for mainframes and minicomputers. During this initial research, it became clear why Microsoft was able to remain on top in its industry while most contemporaries from its founding years in the 1970s disappeared: Microsoft has had remarkably effective ideas on how to compete and market products in a rapidly expanding and evolving industry. Microsoft people have also created an approach for product development and team management—we call it the synch-and-stabilize process—that superbly supports its culture and business strategy. This process has enabled the company to build an increasing variety of complex software products and features for the mass market and corporate customers.

In writing this book, we cannot overemphasize the unique opportunity we have had to probe broadly and freely inside Microsoft. We reviewed published articles and books to analyze the public record on the company's history, strategy, and range of activities and products. But most of the book is based on unusually candid interviews (all tape-recorded and transcribed into several thousand pages) as well as our analysis of several thousand pages of confidential internal documents and project data. We interviewed thirty-eight Microsoft employees in depth; typical sessions lasted two hours, and we interviewed many people twice. These formal interviews took place at Microsoft (either its headquarters in Redmond, Washington, or its offices in nearby Bellevue) between March 1993 and September 1994. Telephone and e-mail correspondence as well as additional meetings with Microsoft people to receive their feedback on the manuscript continued through July 1995.

We spread our interviews across different categories of people (Bill Gates and other top executives, middle managers, senior and junior software developers, program managers, testers, product managers, recruiters, and product support staff) and across different product areas (Word, Excel, Office, Mail, Windows NT, MSDOS, Windows 95, advanced consumer products, and research). Among the highly-sensitive documents we asked for and received were key memos on the development process and written "post-mortems" on major projects between 1987 and 1994. The post-mortems were particularly valuable sources of quantitative data on quality, scheduling, and project management as well as the evolution of Microsoft's practices for product specification, software development, testing, and user education (documentation for users). We also received samples of product specifications at different stages, as well as training materials for product design and implementation, documentation on tools (special software programs used to write other software), test plans, customer problem reports, and an internal employee survey.

We agreed with Microsoft to avoid specific discussions on features or schedules for unannounced products, and to let Microsoft people review the manuscript before publication and suggest changes. But we retained the right to publish whatever we felt was appropriate about the strategies, processes, methodologies, or organizational structures used at Microsoft. For this reason, Microsoft exerted no editorial control over the content of this book (except for suggestions on how we treated some sensitive issues and confidential data), nor did we receive any financial support from Microsoft (although we did use an office during our visits). The result is a study about the company written by two outsiders but told primarily through its own people and documents. We recognize that competitors or people openly critical of Microsoft might want to put a somewhat different slant on the material that we have analyzed. Nonetheless, we have tried our best to present an accurate picture of how this firm operates.

We have tried to summarize the "best practices" used in Microsoft. We acknowledge that there are variations across groups. Microsoft does not always manage small projects (like Macintosh versions of its products) or operating systems upgrades (like Windows 95) as well as it manages highly strategic applications that are major revenue generators (like the Windows versions of Excel, Word, and Office) or new technology platforms (like Windows NT). Nor do managers try to control projects engaged in first-time invention as closely as they do more mature products or products targeted for the mass market. We discuss why operating systems such as Windows NT and Windows 95 are particularly difficult to build, test, and deliver on a predictable schedule.

Why did Microsoft agree to reveal many of its innermost secrets? One reason is that Microsoft managers seem driven to critique themselves. They want to identify and spread knowledge about "best practices" in product development as well as in organization and management more generally. They were not afraid of being analyzed. To the contrary, this book seemed to them like another post-mortem report, but with an added twist: We were an outside party attempting to be objective, and we reviewed key projects and the entire company over numerous years, not just one project.

The second reason why we think we received cooperation is that Microsoft has had a lot of pressure from customers to improve its ability to deliver reliable products in a predictable time frame. Though still far from perfect, company people are proud of the improvements they have made—especially in quality control—and want to communicate them to customers. They also felt confident that talking publicly was less a risk for them than a competitive advantage, even if Microsoft had to divulge some proprietary information.

Microsoft people have been deeply affected by increasing demands for higher reliability in their products, and they have realized that satisfying customer concerns now requires not only a better public image but also a better development process. As part of their shift to using PCs and workstations, many large firms build or buy "mission critical" software systems that today depend heavily on such Microsoft products as Windows, Office (including Word and Excel), and Windows NT. A famous internal memo from 1989 on "zero-defect code" pointed out that a defect or "bug" in a spreadsheet or word-processing program could cost a customer enormous sums of money. (This is a lesson that the Intel Corporation, with a calculation error in its Pentium microprocessor, now understands.) Indeed, PC hardware producers such as IBM, Compaq, and Dell, which bundle Microsoft software with their products, have been particularly critical of Microsoft on some occasions. These hardware producers, as well as applications developers and retail software stores, all gear up in the expectation of new products, especially operating systems. When Microsoft ships a product late or, worse, ships a "buggy" product that it has to recall, the result can be a technical, public relations, and financial disaster for an entire industry and user community.

Neither we nor Microsoft people claim that its problems are over and that no more Microsoft products will ever be late or have defects. No software producer can make these claims. PC software product's are extraordinarily complex to build. They are also getting larger and more intricate every year, while PC software companies often put unrealistic pressure on themselves to deliver new products and replace existing products in short periods of time. Microsoft has made, and continues to make, laudable improvements in its process for product development and in its ability to organize and share what its people know as a company. Microsoft managers have also rethought conventional practices in software development and made critical departures that go beyond existing good practices in many other firms. Microsoft people often cited the desire to let people know about these advances in their responses to the question "Why let us write this book?"

It's good for our corporate customers to know more about development because they do a lot of development. In aggregate, they have a lot more developers than the commercial software industry does. And so we want to remind them that we have some good ideas, and share those ideas with them. Maybe they'll buy more PCs. (Bill Gates, chairman and CEO)
We have a philosophy that ideas and vision are important, but execution is the thing that distinguishes companies. By and large, we're [a] pretty open book. We tell a lot of people a lot of the things that we do....In the ability to emulate and execute on our ideas, we think we've got an advantage in terms of the people and in terms of what we're doing. So there's not a proprietariness issue. And to some extent, it's probably ego driven. It's nice to have you guys write a book and tell us how good we are, or tell us where we're screwed up, and we can at least go work on that....To some extent, you guys help us with spreading the word on our best practices. (Mike Maples, former senior executive vice president)
My philosophy is that I've seen groups here have to go through a transformation. They have to go through phases and those phases take time....[Competitors] have to go through the same transformations and phases, and it will take them years in some cases. In that time, we've also gone through years, and we're advancing and improving at a quicker rate than they have been. So we're not worried about exposing things that compromise our competitiveness....And if they try to duplicate us, we'll know the failings of that system we have in place today by the time they reach this point. (Dave Moore, director of development)
This is the first book that Bill's talked to anybody for, ever, that I know of....My opinion is that no book in the world is going to be able to capture how we actually do it....It's not going to be a manual. You're not going to be able to go out and hire all the same people. That's the whole craft-versus-engineering thing. Even in engineering, you can't build a bridge by reading a bunch of books, no matter how many books about building bridges you've read. (Steven Sinofsky, former technical assistant to Bill Gates and current group program manager, Office Product Unit)

We would like to make two additional comments to readers. First, we have targeted some of our discussions for people familiar with PC software products (Chapter 3) as well as software development (Chapters 4 and 5). Readers more interested in the overall picture of how Microsoft operates as a company might want to read these chapters selectively and focus on the broader themes behind Microsoft's approach to organizing, competing, and developing new products.

Second, on all the dimensions of division and group-level organization, people management, and software development management, there are differences among the various Microsoft product units. Statements that we make about the Excel group, for example, do not necessarily apply to the Windows 95 group. Differences are particularly large between the applications as opposed to the systems and languages divisions. Many differences reflect variations in the products these groups build or in the customers they serve; others stem from separate histories, preferences of managers, and additional factors that have little to do with technology and markets. We highlight key differences among the groups throughout this book. Nonetheless, compared to other companies, Microsoft groups are far more similar than they are dissimilar. What we try to describe, then, are strategies and "best practices" that most people within and outside the company would recognize.

Read a Sample Chapter

Chapter 1 Organizing and Managing the Company

Find "Smart" People Who Know the Technology and the Business

To organize and manage the company, Microsoft follows a strategy that we describe as find smart people who know the technology and the business. We break down our discussion of this strategy into four principles:

* Hire a CEO with a deep understanding of both the technology and the business.
* Organize flexibly around and across product markets and business functions.
* Hire the smartest managers you can find -- people with a deep understanding of the technology and the business.
* Hire the smartest employees you can find -- people with a deep understanding of the technology and the business.

These principles, in theory, are not unusual or unique to Microsoft. In practice, however, they have had a profound impact on both the firm and the industry. Few companies have chief executives who know their underlying technology and how to translate this knowledge into a multibillion-dollar business as well as Bill Gates. Many companies organize around product markets and business functions in ways similar to Microsoft, but many companies have difficulty simultaneously maintaining a strong product and market focus as well as a strong set of basic functional skills. For a company in a rapidly evolving and expanding industry, Microsoft has done an excellent job of organizing to match and sometimes lead the market. It has also acquired and nurtured the technical functions needed to build a huge and constantly expanding portfolio of products.

Many firms hire or promote people based solely on their managerial skills, not necessarily on how well they can combine their technical knowledge with an understanding of business and strategy. Microsoft puts knowledge of the technology and how to make money with this knowledge first in choosing managers. While this results in a shortage of middle managers with good people management skills, it has served Microsoft well in the highly technical world of developing computer software. At the same time, through new hires and acquisitions, Microsoft continually broadens its existing skill base such as by adding new groups for consumer software and information-highway products and services.

Microsoft is also particularly rigorous in how it screens people, especially software developers, hiring only 2 or 3 percent of all applicants. Moreover, as with managers, Microsoft looks specifically for people with a deep knowledge of the technology and a very clear sense of how to use this knowledge to ship products for the company.

In many respects, Microsoft's product unit managers operate like the Roman centurions of two thousand years ago. They are sufficiently competent that they do not need a lot of direction and can respond quickly to new opportunities and threats. Their organizations have most of the resources they need to operate independently; the centurions go off on their own and report back only occasionally. But they roam within certain limits, and the leader can rest assured that these centurions -- and their troops -- are fighting for the good of the whole organization. The record speaks for itself: Although not every customer is happy, Microsoft clearly has a leader, a top management team, and an army of employees who deeply understand both the technology and the business of PC software. They also know how to win.

PRINCIPLE Hire a CEO with a deep understanding of both the technology and the business.

Much of a successful company's performance stems from the technical and business acumen, as well as the leadership and managerial abilities, of its chief executive officer. Bill Gates of Microsoft may be the shrewdest entrepreneur and the most underrated manager in American industry today. His talents appear both in a technical understanding of software and computers and in his ability to create and maintain an enormously profitable business. He acquired a reputation years ago as a cantankerous personality who often criticized (and even yelled at) his employees, but Gates has matured along with his company. He continues to guide the selection of new products and businesses, as well as the features that go into key products. Now, however, he relies heavily on several dozen senior executives and technical leaders, and has instituted formal and informal mechanisms to help him direct the Microsoft machinery.

Gates the Person: William Henry Gates was born in 1955 in Seattle, Washington, the middle child in a well-to-do family. (Neither parent was a technologist; his father was a lawyer, and his mother was a teacher.) By all accounts, Gates the child was similar to Gates the adult: His biographers describe him as a "high energy kid" who liked to rock back and forth in his chair, just as he did during our interview. A former teacher described him as "a nerd before the term was invented." His childhood interests included -- but obviously did not end with -- games such as Risk, where players compete for global domination.

Gates's first exposure to computers came during 1968-1969, in his second year at the private Lakeside School. The school had a primitive teletype machine and access to a computer through a time-sharing hook-up. He learned the BASIC programming language and then teamed up with a tenth-grade electronics expert named Paul Allen to learn more about programming. When Gates was fourteen, he and Allen made money by writing and testing computer programs. The duo then established their first company, named Traf-O-Data, in 1972 and sold a small computer that recorded and analyzed motor vehicle traffic data.

In 1973 Gates enrolled at Harvard University. The following year, Allen, who had gone on to study computer science at the University of Washington, left college and took a job with Honeywell in the Boston area. It has often been described how Allen saw an issue of Popular Electronics in 1974 that advertised the new Altair microcomputer kit from MITS Computer, and how he and Gates wrote a version of BASIC using Harvard's computing facilities. Gates left college in 1975 to concentrate full-time on developing programming languages for the Altair (and then for other personal computers), relocating with Allen to Albuquerque, New Mexico, to be next to MITS Computer's office. They formed Microsoft during 1975 as a 60-40 partnership in favor of Gates, reflecting his larger role in developing Microsoft BASIC, the company's first product. (See Appendix 1 for an abbreviated chronology of Microsoft's history.)

Several characteristics stand out in stories about the young Gates. He was intelligent and ambitious, as were his friends. He was able to concentrate intensely on and master what interested him; most notably, computers and how to program them for practical purposes. Perhaps most important, Gates envisioned a world with computers not merely tracking traffic data but sitting on every desktop -- and running his software. This was a great combination of skills and ambitions to have at the dawning of the PC era.

Observers from outside and Microsoft employees paint similar pictures of Gates. They describe him as a visionary with a maniacal drive to succeed, accumulate great power, and make money by taking advantage of his technical knowledge and understanding of industry dynamics. Microsoft the company emerges as an extension of Gates' unique personality and skills.

Gates is a visionary. Very early in the history of the PC, he evolved a strikingly clear concept of where the industry was headed, and he has pursued that vision -- despite many tactical setbacks -- unwaveringly, relentlessly, and ruthlessly.
This guy [Gates] is awesomely bright. But he's unique in a sense that he's the only really bright person I've ever met who was 100 percent bottom-line oriented -- how do you make a buck? Not in a mercenary way. It's just like that's what's good in life, right? If you make money, clearly that's good. It's like he's this huge computing machine that knows how to make money. (Jim Conner, program manager, Office Product Unit)
He's a maniac. Bill knows more about the product than any of us. And you go into the meetings and you come out just sweating because, if there is any flaw, he will land on it immediately and pick it to bits. He is just unbelievable. (Dave Maritz, former test manager, Windows/MS-DOS)
IBM thought they had Gates by the balls. He's just a hacker, they thought. A harmless nerd. What they actually had by the balls was an organism which has been bred for the accumulation of great power and maximum profit, the child of a lawyer, who knew the language of contracts, and who just ripped those IBM guys apart.

Gates the Manager: During an interview, we asked Gates to describe the main precepts behind how Microsoft has managed product development. His list impressed us and included elements we had already observed. Below are Gates's key principles for managing product development -- which we will come back to later -- with brief quotations from our interview to illustrate his points:

* Smart people and small teams: "We started using the very best practices, which was just hiring great people and having small teams....The biggest advantage we have is that good developers like to work with good developers."
* A development process that allows large teams to work like small teams: "Then we had to have larger teams...and then we had to formalize a lot of things. We went into the whole approach of milestones and driving the zero defects at those milestones, and the way we did the project estimations. Those are all things that deal with the size of the project teams."
* Product architectures that reduce interdependencies among teams: "Good architecture can reduce the amount of interdependency within even a development group here."
* Nearly all new product development done on one site: "Our all being, with very minor exceptions, here on one site, so that whatever interdependencies exist you can go see that person face to face...[is] a major advantage."
* People working on the same machines they build products for: "Our development system and our target system are the same. Some people don't do it that way."
* A single main development language: "People can argue about which is the best development language, but we have one."
* Large capital investments to support people: "Our willingness to spend money to buy tools for people. Our giving people an office of their own."
* Internal use of their own engineering tools: "We have control over our tools because we use our own tools....On balance, we have had a massive benefit by using our own tools."
* More than one person who understands the product details: "We don't have large bodies of code where just one person has looked at the code and everybody else goes, 'Oh my God, the prima donna is the only one who can change this code.'"
* Managers who both create the product and make the technical decisions: "We don't have non-technical management trying to make technical trade-offs."
* Quick decision making on technical-versus-business trade-offs: "[We have] an ability to get technical-business trade-offs made with high speed. If there's some question about it, either the business [product] unit manager will decide very quickly, or if somebody wants to send e-mail to me to get me involved in the decision, that'll happen very quickly."
* An enormous feedback loop from customers: "Most people don't get millions of people giving them feedback about their software products....We have this whole group of over [two] thousand people in the U.S. alone that takes phone calls about our products and logs everything that's done. So we have a better feedback loop, including the market."
* Deliberate efforts to learn from past projects: "We do good postmortems after the projects and look at what were the source of the bugs, how could the design generate less bugs, [and] how could the tools generate less bugs?"

As Microsoft has grown, Gates has faced new problems. He has to study constantly to stay on top of a fast-moving company and industry, and to remain knowledgeable about Microsoft's expanding arsenal of products (as well as those of competitors). He has to decide every day what to control and what to delegate. To be sure, Gates has able help, although he and other Microsoft managers resist creating large staffs for anything. Gates has only one personal administrative assistant and one technical assistant, hired during the past few years. The technical assistant is generally a young program manager or software developer who holds the job for a year or two. The assistant reviews product ideas and specifications, takes notes in meetings, follows competitors and trade shows, and helps Gates keep track of different projects.

Microsoft executives have introduced fairly conventional management systems, but Gates remains closely involved. He presides over program reviews and planning sessions in April and October of every year that set the schedule for rolling out new products and establishing budgets. The October reviews center on three-year product plans; each division explains the products it is planning to deliver and any interdependencies with other products. After completing the October review, Microsoft's marketing staff (called product managers) create a sales forecast based on the divisions' product plans. Detailed budget planning then begins, and managers look at the sales versus budget estimates to determine how these compare with the profit objectives for the company. Based on this analysis, Gates and other top executives determine the employee head count they want for the fiscal year beginning in July. Gates not only takes an active role in all the significant review and planning sessions but gives direct advice to the key product units.

In general, Gates concentrates on defining strategic new products (or new versions of products) and keeping a check on development schedules, mainly through product status reports and electronic mail from project team members and managers. He receives short status reports from projects every month -- these used to be biweekly -- and actually reads them. He attends quarterly program reviews for many projects. He writes occasional strategic memos, perhaps four or five times a year. (One he was writing while we visited, his assistant told us, outlined "some of the big technical challenges we face and who's going to own particular solutions, and what solutions are the right ones from a strategic point of view.") Once or twice a year, he goes on "think weeks." During these times, he isolates himself and thinks about a particular problem: for example, how to improve customer support, how to get groups to cooperate more, or what a product should look like five years in the future. Gates also tries to "get the biggest bang for the buck" from the time he spends: "The products that comprise 80 percent of our revenue I choose to understand very, very deeply." This means that he spends most of his time following such key applications as Office and its Word and Excel components, as well as Windows. He also closely follows new high-growth areas, such as multimedia and on-line information services and products.

Project Status Reports: Each software product has a corresponding project status report. Project teams send these each month to Gates and other top executives as well as the managers of all related projects. They are a key mechanism for communicating between projects and top management. Gates usually responds to the relevant managers or developers directly by electronic mail, then uses the information he gathers for the formal program reviews. These reports also communicate target schedules, which project members set themselves. As Gates explained:

I get all the status reports. Right now there might be a hundred active projects....[The status reports] contain the schedule, including milestone dates, and any change in the spec, and any comments about "Hey, we can't hire enough people," or "Geez, if this OLE [Object Linking and Embedding] 2 Mac release isn't done, we're just going to have to totally slip."...They know [their report] goes up to all the people who manage all the other groups that they have dependencies with. So if they want to raise an issue, that's a great way to raise it. And if they don't raise it in the status report and then two months later they say something, that's a breakdown in communication....The internal group is totally copied on those things, so it's sort of the consensus of the group.

The status reports are brief and have a standard format. Gates can read most of them quickly and still spot potential project delays or changes he does not want, although some projects and issues get more attention than others: "I read every one of those things....It's not that hard to read a hundred status reports....If it's an obscure mail gateway product, and if it hasn't slipped a whole bunch, then I just hit delete. The thing is very succinct....It's like two screens full....There's a line for each date, like milestone dates, spec-by dates, code complete dates...and then there's a column for the original date, the last date, and what they're reporting this time." Gates especially looks for schedule slips, cutting too many product features, or the need to change a specification:

In any reporting period, there'll only be about ten to fifteen of them that catch my eye....[because of comments like] "Several features were cut." Well, is there anything left? Give me a clue. Or "You know you just slipped the schedule." Not much of a comment; people really have to address size and speed requirements. Or when a competitor comes into the market with a new version, they have to really say in their status report are they choosing to stay with the spec as it is, or are they going to change the spec and go with the new schedule? It's a really major thing to get that straight....The thing that jumps out right away is, are they changing the date this time?...And so, as you read the development commentary, the program management commentary, the testing commentary, marketing commentary, which are usually only about three or four sentences each, sometimes there's a lot going on. Then you know you have that context in mind. It's easy then just to shoot off a piece of mail and say, "Come on, I thought I asked to get drag-and-drop into this thing, and I don't see it in the status report." And "Don't we need this thing? Didn't we promise this thing to HP? And what about the RISC version? You don't mention that."...[But] I'm not the only sanity checkpoint on these things. There's quite a few other people.

Program Reviews: Microsoft holds program review meetings for each project every three months or so. These meetings, lasting about two hours, are usually attended by Gates as well as other senior executives. Project teams send one or two key people from each functional area: program management (the group responsible for writing down product specifications), software development (the people who write the computer code), software testing (the people who test the code), product management (the people in charge of product planning and marketing), and user education (the group that prepares product documentation). Gates told us that he focuses on the same types of issues he looks for in the status reports:

You want to know is the project under control. That's fundamental. And you want to know if people are anticipating...major problems. If they're adding something that could potentially slow the product down, you say to them, "Prove to me it's not going to be ten times slower."...If something is taking longer to get done than they expected, was it because they just didn't understand the design?...You have to ask enough questions to really understand: Are we on top of what we're doing? And you have to listen for ideas that have come up during the project that might be worth changing the spec to accommodate....Can [they] take something and push it to a higher level of generality? What's their relationship with all the other groups?
...I believe in code sharing across the groups. I've imposed on them the necessity to get this thing from this group and that thing from that group, and those groups don't work for them. If they want to point out to me some dependency that is creating massive bugs or it's massively slow or they may never get that piece from that group in time, it's important to bring that out in the discussion....
If the marketplace environment has changed and we're asking them to change the spec, it's important they hear from me about that. There's [also] a need to set a tone in terms of telling them they're doing super well or not doing super well, once you have the data. Sometimes you have that before you go into a meeting, because the amount of e-mail that's generated about projects is rather massive.

Steven Sinofsky, Gates's technical assistant in 1993 and 1994 (and now group program manager for Office), downplayed the drama of the program reviews, claiming that senior executives usually know about problems beforehand and hold preliminary meetings with the projects: "It's just a chance to make sure they have their act together. And often they'll do them for Mike Maples or for Steve Ballmer previously or one of the senior VPs, and then they'll do them for Bill as well. It's not an ambush." But Gates does try to mix up his questions. He spends some time on obvious things and also probes more deeply: "I'll always surprise people with maybe half my questions, but about half the questions are fairly clear. I can remind people of which benchmarks really count. I can remind people of which system configurations really count." In some cases, he sends in some help:

At my level, what do I really control? I have some very senior developers that I could shift over onto a project and have them help review the algorithms [mathematical or procedural recipes to accomplish particular tasks through computer code], review the code or just pitch in. So if a project really appears to be broken, then you want an independent review of the code. Very early in the company I'd say, "Hey, give me the source code. I'll take it home." I can't do that now. So I take somebody, a D 14 or a D 15 [the top technical ranks in the company] and say, "Go dig into this thing and let me know," or, "Help them out in terms of getting more personnel assigned." They're always going to have a recommendation in terms of what features ought to be cut...because they understand all the dependencies and how the pieces fit together.

Gates admitted, however, that he finds it difficult to cancel projects in trouble:

We don't have that many we cancel, but sometimes things will shift in the marketplace and we'll cancel. That's a combined technical-business decision. The most famous one was the database we were doing. The first Windows database was inadequate....You could say we started over. Some people would say we only rewrote 80 percent of the thing, but it was fairly radical. And Word for Windows was a classic; if you want to take a project that was late, that's our most famous late thing.

In reviewing specifications, Gates concentrates on a few key themes. He wants to know how "exciting" a new product is, as well as how it fits with other Microsoft products. Increasingly he also asks about quality, mainly defined in terms of bug levels. These three issues drive Gate's recommendation on whether a product is good enough to ship. Another rising concern is making sure that groups cooperate and share common components, and that products slated to work together or share code are coordinated and on schedule. Managing such interdependencies is no trivial matter for Microsoft's previously independent product groups, and it is likely to become a greater problem because many Microsoft products may now come out every year (for example, Windows 95 and Office 95); delays beyond the control of any one project could force embarrassing changes in product names.

Gates prefers to set broad directions and then leave the product groups to solve these types of problems on their own. But he continues to astonish people with his ability to grasp the technical details of what the groups are doing. This has happened with products outside his personal area of expertise (like Windows NT), but more commonly with products he understands from personal experience (like BASIC, Word, and Excel). Mike Conte, formerly a product and program manager on Excel -- and now with Office -- recalled how the busy Gates took minutes to find a weakness in a new feature. The Excel team, which knew about the flaw but had not yet told Gates, had taken a month to find the problem:

We did a thing called subminimal recalc[ulation] in Excel 3.0. Minimal recalc says you only recalculate dependencies; minimal recalc only recalcs the cells that were affected by the change you made, instead of recalcing the whole sheet. That was a big innovation for speed in recalc. For Excel 3.0, we did subminimal recalc, which said even in some cases you can skip the dependencies if the intermediate results haven't changed....And so we're talking about this to Bill, and...[he] says, "What about this case, this case, and this case?" And Chris Peters, who was our development manager at the time, said, "Well, funny you mention those. After a month of thinking about this problem, those are the three cases we came up with. We were not optimal." So he's pretty good at following the technical stuff.

Preparing for an encounter with Gates can be intimidating even to seasoned employees and executives. Chris Peters, now vice president of the Office Product Unit, gave this advice to his colleagues in his now-famous 1990 video entitled "Shipping Software":

You should keep Bill very informed about what you're doing and why; you should never hide anything from Bill, because he's so good at knowing everything. But you should be firm, and you should yell back. The only recommendation I can bring or give you guys is to bring your very, very, very best developers with you to the meeting so they can quote things off the top of their head and they can just bury him with facts....Don't ever be unprepared. But say no. Bill respects no. Bill understands shipping on time. I think the thing that we finally said is...it will be useful for Microsoft to know what it takes to ship a product on time, so please let us not do this feature. I think we ended up doing that feature actually, but that's why he's Bill Gates.

Control Over New Product Development: To the question of what are the first things he let go of versus those he has insisted on controlling, Gates responded as follows:

Well, [at] first, I wouldn't let anybody write any code. I went in and took every statement that anybody else had written in BASIC and rewrote it myself, just because I didn't like the way they coded. That product had a certain craftsmanship thing. I was very reluctant to let anybody get involved in it. But then we had products like FORTRAN and COBOL, where all I did was make sure that we were designing to the right spec and review the basic algorithms....I have not delegated the general idea of products to develop. I don't come in and say, "Well, I didn't know there's a whole new product group here. Nobody told me about that." That is a good decision for a CEO of a software company to keep in his hands. That's about the only one that I really control nowadays.

A key role that Gates plays is to view the entire product portfolio of the company in light of the future directions he sees, including likely competitor moves. Then he makes the hard decisions: the technology-versus-business trade-offs. One example is how Gates, for five years, pushed for Excel and other groups to adopt Visual Basic as a common "macro language." (Macros are special commands that, at the user's discretion, combine many functions into one or two keystrokes. Using a standard macro language allows users to customize various Microsoft products all in the same manner.) Gates has also pushed groups to adopt Object Linking and Embedding (OLE) standards so that they can more easily share components.

Gates also works closely with key projects. He helps define current products as well as chart future directions. As Ed Fries, development manager for Word, recalled:

We interact with Bill a lot, especially in the early stages of a product when we're going over the spec and we're trying to decide what features we're going to put into the product....Bill was here a few weeks ago and we walked him around and showed him all the stuff that we're doing in Word. He was on a "think week" last week, and during that week he probably sent ten pieces of mail to Chris [Peters] that said, "Oh, here's something I don't like about this version of Word. And here's something you should be thinking about in the future to make spelling better for all our products. Or Word and Help, and how can those things be combined into one type of thing." So Bill does a lot to define our future direction with the product, and he also does some quick criticism of where we are now....He always represents where he thinks things are going to be five years from now. We're trying to balance going in that direction with meeting the needs the users have today that we think we're not meeting. So we try to come up with a compromise of making that happen....That's always the conflict.

With the fiercely independent culture of Microsoft managers and developers, however, it is rare that Gates tries to mandate anything; according to Sinofsky, the "numbers of those things are so small that they all have a reputation of their own." Along with pushing groups to adopt Visual Basic and OLE, some key additions to products that Gates has demanded include an outlining feature in Excel, tables and drag-and-drop in Word, and custom controls in Visual Basic (called VBXs). Gates also once insisted that program managers and developers use Visual Basic for writing prototypes and special software programs; some groups successfully resisted when they found the language inappropriate for technical reasons. And executive vice president Steve Ballmer, with Gate's agreement, once mandated that Microsoft groups use a pre-ship version of Windows NT as their operating system, rather than Windows or OS/2. In addition, Gates told Microsoft's commercial tools group (which makes language compilers, among other things) to add features to support Microsoft's internal software developers, rather than just serve outside customers. Occasionally, Gates halts projects mired in delays and bugs, such as the Omega database product for Windows (which later evolved into Access). He has also consolidated projects working on multiple versions of the same type of function, such as text-processing code in Word, Excel, and Mail.

People argue with Gates and his suggestions fairly often; as Chris Peters observed, this is necessary to gain his respect. But people must have clear technical grounds and data to support their positions. Arguments based on personal or emotional reasons, or internal politics, have little impact on Gates or other key managers. Gates in particular seems to need a new intellectual "model" -- a comprehensive argument that views the world differently -- in order to change his mind. As Steven Sinofsky explained: "You can't repeat your argument over and over again if his model keeps refuting your argument. You need to find a new model that disproves his."

PRINCIPLE Organize flexibly around and across product markets and business functions.

Bill Gates insisted to us that Microsoft's "dominant organizational theme is by products." We find this to be largely true, but Microsoft also pays a lot of attention to (albeit overlapping) technical or functional specialties. People in these jobs work in multifunctional teams organized by product, with some mechanisms to integrate across the product groups. Furthermore, in addition to divisions and product groups, Microsoft has two other organizational structures. One is formal, consisting of the management hierarchy. The second is informal; this consists of a loosely defined "brain trust" of executives and a network of technical people and managers who work on special assignments or projects, often at the suggestion of Bill Gates or other senior executives.

Organizational and Process Evolution: Microsoft adopted its current organizational structure and process for product development in stages and through trial and error. During the early 1980s, it created an End User Group to develop applications programs. This allowed the systems and applications groups to evolve independently. The company struggled, however, to improve functional expertise, especially in testing. It also had to overcome problems stemming from a lack of focus in the product groups, and relatively poor mechanisms for quality control and project management. As in many other companies, several turning points and key actors defined this evolution (Table 1.1).

The first turning point was a decision in 1984 to set up testing groups separate from development. This provided an independent check on the work of developers. The second, occurring about the same time, was when program management began to emerge as a function distinct from product management and software development. Third was a series of late and buggy products during the mid-1980s, which led to a growing consensus in the company that Microsoft had to become much more serious about quality control and project management. Microsoft groups now began documenting their experiences in projects through written postmortems, reflecting the belief that people could do a much better job at "learning from mistakes." Fourth was the arrival of Mike Maples in 1988 from IBM and his decision to create smaller business units; these added more focus to the operating groups and made them easier to manage.

The fifth key event was a 1989 retreat where top managers and developers grappled with how to reduce defects, and proposed solutions that helped Microsoft teams become more systematic in software development and quality control. One was the idea of breaking up a project into subprojects or milestones, which Publisher 1.0 did successfully in 1988. Another was to do daily builds of products, which several groups had done but without enforcing the goal of zero defects. These critical ideas would become the essence of the synch-and-stabilize process. Excel 3.0 (developed in 1989 and 1990) was the first Microsoft project that was large in size and a major revenue generator to use the new techniques, and it shipped only eleven days late.

A sixth key event was the 1992 establishment of the four-person Office of the President and the centralization of all product development responsibilities under Maples. These moves brought more structure to the operating systems groups, whose schedules remain difficult to predict. Seventh was a 1993 reorganization that centralized most product managers in marketing groups for the individual divisions, except for a few product planners who remained with the product development groups. Microsoft also renamed the business units "product units" to reflect this change, and it created the Office Product Unit. These changes have more clearly separated marketing from product planning and development, and they have facilitated sharing of common components across Microsoft's key applications products.

The split of Microsoft into systems and applications divisions came under former Microsoft president Jon Shirley, an MIT dropout and Tandy Corporation (Radio Shack) executive whom Gates recruited in 1983. Gates had assumed developers should report to developers, not general managers -- and that all development should report to him, since he was the top developer in the company. Gates also tried to control other key areas such as marketing, an approach that quickly became obsolete as Microsoft grew beyond a handful of products. Shirley concluded that Gates had overstretched himself and that a reorganization was necessary. For example, Gates had a habit of pulling developers from one team and putting them on another, and making large changes in specifications with no prior warning or planning for such contingencies. Shirley felt the CEO should define products at a high level of abstraction and set strategic directions for the development organization, rather than be bogged down in the details of each project. Gates agreed to the reorganization and to limit himself to overseeing applications, and he put Steve Ballmer in charge of systems. Gates gave this account of the changes:

Before Mike Maples came in...all development worked for me, because there was this theory that developers should never have to work for somebody who couldn't write thousands of lines of code a day; it was just an insult to them. So all development management was purely developers, and at almost every step of the chain there was a developer who had written more code, basically. Then I broke it into systems and app[lication]s and I put Steve in charge [of systems]. Well, Steve is nontechnical. But he's fairly mathematical, and he has good personality. People trusted his ability when it came to a technical decision to turn to the right developers that, even though they weren't managers, were people that [everyone] had broad respect for. So we got by then.

Microsoft decided in 1984 to separate testing from development after bugs in different products prompted complaints from hardware manufacturers who bundled Microsoft's operating systems with their PCs. (Microsoft refers to these companies as original equipment manufacturers, or OEMs.) For example, the version of BASIC that Microsoft shipped with the IBM PC in 1981 gave the wrong answer when the user divided ". 1" and other numbers by 10. After this incident, IBM insisted that Microsoft improve its processes for software development and quality control. Microsoft had other nonpublicized problems in the early 1980s as well, such as a bug in its FORTRAN product (a technical programming language) that corrupted data. Individual customers also began complaining about quality problems in Microsoft's applications products, which they could buy in retail stores.

Senior managers finally saw the need to introduce better internal testing and quality control practices. There was resistance to this idea, since most programmers and even some senior managers (such as Ballmer) insisted that developers could test their own products, assisted on occasion by high school students, secretaries, and some outside contractors. Microsoft did make a special effort by hiring the Arthur Andersen consulting firm to test its new version of the Multiplan spreadsheet for the Macintosh before it shipped in January 1984. But an outside company usually cannot test a complex software product adequately. A serious data-destroying bug forced Microsoft to ship an update to Mac Multiplan's twenty thousand buyers at the cost of $10 each -- $200,000 total.

Microsoft managers concluded that they could not meet higher quality standards without setting up an independent testing group, following the lead of IBM and other companies with longer and more successful histories of software development. Dave Moore, Microsoft's director of development, recalled this realization: "We knew that we couldn't stand alone with development doing their own testing. We needed a separate group that would build the test, run the test, give some feedback to development. That was a turning point." Microsoft did not copy such IBM techniques as making large groups of people review all software items -- from specifications documents to code and test plans -- or requiring executives to "sign off" at the various development stages. These bureaucratic practices are common in software production for mainframe computers and defense applications, but they are still rare in the PC world. Nor did Microsoft start monitoring in detail how developers and testers spend their time, as IBM and a few other companies (including Japanese software factories) do. Instead, Microsoft people selected what seemed to be good techniques, such as a separate testing group and automated tests, and code reviews for new people or critical components. Then they promoted these not as IBM practices ("That's not the way to get it used in Microsoft," noted Moore) but as methods that worked.

But, Moore added, "We did it wrong." After Microsoft expanded the new testing groups between 1984 and 1986, developers "got lazy," thinking they could "throw code over the wall to testing." They forgot that developers find more of their own bugs than testers do, and that only developers can prevent errors from happening in the first place. Meanwhile, Microsoft shipped the next big disaster in company annals. Word 3.0 for the Macintosh, delivered in February 1987 after having been promised for July 1986, had approximately seven hundred bugs -- several of which destroyed data or "crashed" the program. Microsoft had to ship a free upgrade to customers within two months of the original release, costing more than $1 million.

By now, it had become apparent even to skeptics within the company that Microsoft was having enormous difficulties managing product development, and that groups would have to become more systematic to satisfy customers. Gates himself took over the applications division, but several key projects remained in chaos. None of the new applications for Windows, except for Excel, were progressing. A database program (dubbed the Omega project, which evolved into Access) and a project management application for Windows were in serious trouble.

The Opus project, later renamed Word for Windows, caused staffers to coin the now-famous phrase "infinite defects." This describes a situation where testers are finding bugs faster than developers can fix them, and each fix leads to yet another bug; under these conditions, predicting the schedule and eventual ship date becomes impossible. This sometimes occurred at Microsoft when summer interns wrote code and then went back to college without testing their work fully, and when developers moved from one feature or project to another, also without fully testing their work. During the "late and large" integration and testing periods that Microsoft used to attempt, developers had to return to old code whose details they had largely forgotten or whose authors had disappeared. In rewriting much of the code to fix the innumerable bugs, the developers tended to add as many new errors as they repaired. Roger Sherman, Microsoft's director of testing, recalled this dark period in Microsoft's history:

People got the message that they actually could screw up....It's like driving a race car: They hit the wall, and now they know where the wall is....[P]eople learned that they couldn't just throw code together, no matter how imaginative or how creative. They had to look at some things, external factors, and they had to have code that was testable and testing resources were not infinite....They had to work on stable code. So from the negative experience of Omega and Opus, people learned something that pushed them into this milestone process. I think the lessons were probably learned better in Access than they were in Word. The bug databases were so large they couldn't keep them on a single server. There were so many active bugs that the test team really didn't have any work to do: "Why bother? Development has two years' worth of work backlog to catch up with us already." So they spent all their time automating and developing automation tools. Finally, somebody said these ship dates are totally unrealistic, the project is a mess, we're never going to be able to ship this on time. And that probably means that the whole definition of the product...is bogus as well. And so they had to go back and take small portions of the product and stabilize them....They cut a lot of the product away and got back to a point where they had a stable code base and were able to proceed.

Rather than let more projects spin out of control, Gates decided to go outside the company for more management expertise. In July 1988, he brought in Mike Maples, who had been with IBM for 23 years and headed software strategy and business evaluation. He was also a central figure in the development of OS/2 and Presentation Manager, an early graphical interface product for the IBM PC. Ironically, Microsoft people often criticized IBM for hiring too many programmers who were not very skilled developers (a practice they referred to disparagingly as "masses of asses programming"), and using a development process that was too sequential and compartmentalized. Microsoft managers also believed that IBM required thousands of people to do what Microsoft could achieve with just a few hundred top-notch developers. But Maples seemed uniquely talented, and Gates wanted to see more processes in place to make sure Microsoft built and delivered its products and controlled their quality more effectively. A key 1989 memo summarizing discussions from the May retreat (which Dave Moore organized) galvanized the product groups to take corrective actions. The memo shown, titled "Zero-defects code" and written by Chris Mason, a development manager in the Word group, reflected the state of affairs and the new process Microsoft would adopt.

Over in the systems area, Microsoft was also having severe troubles with Windows. As Gates's biographers observed after Microsoft shipped the third version of Windows in 1990, the product was still far from perfect: "Once again, Microsoft's testers had not weeded out all the problems. There were problems installing the program on certain machines, troubles with networks, difficulties with the pointing device called a 'mouse,' data destruction with certain third-party disk management software -- along with the usual collection of glitches and documentation errors....The running gag in the industry was that Microsoft products were in beta test until version 3."

Gates and many other Microsoft people had additional worries. Stock options had become a critical source of compensation in the company, and delayed products more than occasionally brought the price of Microsoft's stock crashing down. Delays and recalls also confused and frustrated customers, both on the OEM and retail sides. There was even a shareholder suit due to Microsoft's failure to ship Word -- which then accounted for 20 percent of sales -- that the company settled in 1990 for $1.5 million. (The suit charged that Microsoft managers concealed their knowledge of the delay.) As for the database project, it was supposedly three months from being finished when Mike Maples arrived in 1988; a year and a half later, he and Gates canceled it.

These continuing problems in both the applications and systems divisions created a receptive environment for Maples to suggest changes. In particular, he wanted smaller groups that worked in projects targeting specific leading competitors and products, such as WordPerfect, Lotus 1-2-3, and Harvard Graphics. He also wanted each of these groups to define and then refine their processes for software development, testing, and project management. After discussing the matter with Gates, Maples broke down the applications division into five business units: Office, Analysis (Excel), Graphics (PowerPoint), Data Access, and Entry (Works). These now became independent profit centers -- with self-contained resources for program management, development, testing, marketing (product management and product planning), and user education -- very much patterned after the highly successful independent business unit that IBM used to launch its original PC in 1981. Maples, who got his introduction to Gates and Microsoft while working for this IBM unit, recalled his influence on Microsoft's reorganization:

It was really funny. When I first came, I went to what we called resource planning meetings. The head of development, the head of marketing, the head of program management, and the head of test[ing] would be there, and they'd go over a project. Every week every project would move; some of them that were out eighteen months would move [their target date for completion] three days. And then they'd say, "Okay, we need more testers on this project," so we'd rip some testers off something and put them on another project. And then the next week we'd have another resource planning meeting and the one we took them off of was in trouble, so we'd move them. It was constant moving people around; people never owned projects. Then we built this whole idea of the business units. Conceptually, you lose the efficiency of moving people around. The testing group for Word stays the testing group for Word, even when there isn't anything to test. [But] it turns out that knowing what the continuity is in your resource pool allows you to plan. And that also did quite a bit in growing a lot of management people [by] giving people a lot broader responsibility. It brought a great deal of focus to customers, and sets of competitors. By and large, Microsoft is broadly organized that way now in terms of small business units.

Microsoft maintained this same basic organizational structure, with some refinements. In 1992, Gates moved Steve Ballmer from head of the systems division to head of the Sales and Support Group. He also created an expanded Worldwide Products Group, with Mike Maples overseeing product development for both applications and systems areas. This change gave Maples a chance to rein in the operating systems groups until he retired in 1995, at which time Microsoft once again separated responsibilities for applications and operating systems. In 1993, Microsoft also centralized marketing and created the Office Product Unit. In addition, Microsoft appointed directors for the key functional areas: development, testing, program management, and user education; since 1994, this staff group reports to an overall director of product development. The directors do not oversee projects or have well-defined responsibilities, although they help groups identify and share best practices. Gates reflected on the pluses and minuses of the new organization:

It's a trade-off; all organizational things are a trade-off. It optimizes for the esprit de corps of the product: What are we trying to do with this product? What trade-offs do we need to make with this product? Did we ship a product, did it win the review? And so it breaks down the idea of specialization.
There're two big drawbacks to the product organization: One is that, with any skill area, it's not as obvious that best practices -- interviewing practices, new tools, new approaches -- get shared as well. And if you take the extreme group, like a group that has one tester, how are they supposed to review that tester and tell him, "Hey, you didn't read the latest book on testing." And so we lay over a very small group of people that are supposed to make sure testing knows all the new things going on. But it's just a very small part. And second, it makes it hard to share code. But it's far, far better to do it that way. If we had tried over the last eight years not to use business units to do our stuff, this thing would break down.

A clear benefit of Microsoft's organization is that it provides the freedom for groups to operate as relatively small development centers totally dedicated to shipping products to particular markets. As Chris Peters explained:

The business units, although we pretend that they're mini-companies, are really pure product development centers....There is no sales or finance -- all that stuff is removed from it. Everybody in a business unit has exactly the same...job description, and that is to ship products. Your job is not to write code, your job is not to test, your job is not to write specs. Your job is to ship products....You're trying not to write code. If we could make all this money by not writing code, we'd do it.

Stimulated in particular by the 1989 retreat, Microsoft managers also now insist that developers and testers stay in their groups for more than one product cycle. They want developers to make more effort to "get it right the first time" and to "build in quality." Microsoft's strategy for doing this is to use the daily-build and multiple-milestone techniques -- the essence of the synch-and-stabilize process we describe in Chapters 4 and 5.

Current Management Structure and Organization: Microsoft's current management hierarchy, below the board of directors, begins with the "communal" leadership first instituted in 1992: the Office of the President. After a July 1995 reorganization following the retirement of Mike Maples, this includes, in addition to Bill Gates as Microsoft's chairman and chief executive officer, five senior managers who direct Microsoft's four operating groups: Group vice presidents Nathan Myhrvold (formerly head of advanced technology) and Pete Higgins (formerly head of desktop applications) jointly preside over the new Applications and Content Group. Group vice president Paul Maritz (formerly responsible for product and technology strategy) heads the new Platforms Group. These two groups build Microsoft's products and conduct research and development. Executive vice president Steve Ballmer is in charge of the Sales and Support Group, while Robert Herbold is head of the Operations Group and also serves as chief operating officer. Reporting to these group executives are division vice presidents and general managers. Below them are product unit managers, followed by functional team managers and then team leads in the product groups.

As seen in Figure 1.1, the Applications and Content Group has four divisions: desktop applications, consumer on-line systems, and research. The Platforms Group also has four divisions: personal operating systems, business systems, developer and database systems, and advanced consumer systems. Most of these divisions contain their own marketing departments staffed by product planners and share a centralized usability lab (staffed by thirty to thirty-five people) to test features and product prototypes. The Sales and Support Group has separate divisions for worldwide OEM sales (primarily to AST, DEC, Dell, Compaq, Fujitsu, Gateway, IBM, NEC, Olivetti, Packard Bell, Toshiba, Unisys, and Zenith), product support services (abbreviated as PSS), international operations (mainly Asia), advanced technology sales, strategic enterprise systems (special sales and consulting to large firms), North American sales, and European sales. The Operations Group includes finance, diskette production, manuals and book publishing (Microsoft Press), information systems, and human resource management.

Within the Platforms Group, the personal operating systems division produces Windows and MS-DOS. The business systems division produces Windows NT and Object Linking and Embedding (OLE), with a separate product unit for workgroup applications (electronic mail and PC server systems). The developer and database systems division builds programming languages such as Visual Basic, programming support tools, and database products such as Access and FoxPro. The advanced consumer systems division contains groups for interactive TV systems and broadband communications and multimedia technologies. Within the Applications and Content Group, the desktop applications division contains the Office product unit. This supervises the Word and Excel product units and works closely with the Graphics product unit (PowerPoint) to make sure that these three products function together properly in the Office applications suite. The division also builds Project, a popular project-management tool. The consumer division includes the "Microsoft Home" product groups, which build the Money home-finance product as well as multimedia applications for home entertainment and education, and a combination word processor, spreadsheet and database product for novices called Works. The on-line systems division develops and manages the new Microsoft Network. Research explores new product and programming technologies, and works closely with various product groups. (See Appendixes 2 and 3 for descriptions of Microsoft's main applications products and operating systems.)

The example of the desktop applications division in Figure 1.2 illustrates how Microsoft organizes the product units and functional specialties. Divisions contain more than one product unit. Each product unit generally has five functional teams run by a separate manager: program management, development, testing, product planning (product managers assigned to the product groups), and user education. Microsoft breaks down these teams into areas related to the products they build. For example, before the formation of the Office product unit, developers in the Excel unit had five small teams: recalc/functions, charting, printing/formatting, add-ins (special software programs, often imported from outside, such as for statistical analysis or spell-checking), and macros/conversions. Some product units combine their teams for user education, which prepare manuals and on-line documentation (such as "Help" functions). In the desktop applications division, the Office product unit's user education team prepares manuals for Word, Excel, and PowerPoint. Also, the development groups generally include small teams that work with overseas subsidiaries to prepare non-English product versions, and product management groups have international managers that coordinate foreign marketing. Microsoft K.K., a Japanese subsidiary that creates Japanese, Chinese, and Korean versions of desktop applications, reports directly to the division manager.

Table 1.2 breaks down Microsoft's seventeen thousand employees by functions. About thirty percent (5,100) work overseas in thirty-six foreign subsidiaries responsible for sales, product support, and some adaptation work into local languages. (Overseas accounts for nearly 70 percent of Microsoft's retail sales. See Table 2 in the Introduction.) Of the 13,300 employees in the United States, there are approximately 1,850 software developers, 1,850 software test engineers, and 400 program managers and product planners. Some 2,100 people work in customer support; 4,000 in sales, marketing, and consulting; 600 in user education; 2,200 in operations and administration; and 300 in research.

The bigger product units such as Office, Windows NT, and Windows each have between three and four hundred people, and several other product units have two hundred or more people. Groups building operating systems tend to have more developers and testers than applications groups; the latter need more people in product planning and program management, since their features are more directly visible and marketed to non-technical customers. Overall, these numbers represent enormous increases over the past decade. Groups such as Excel, Word, and MS-DOS/Windows had ten or fewer developers in the early 1980s and only a few dozen total employees. Other divisions have seen similar increases. The product support services staff has grown from a couple of dozen people in the early 1980s to a couple of thousand today, and it has become an invaluable source of feedback to the product development groups (see Chapter 6). Microsoft's highly effective sales and marketing force has also grown from a handful of people a decade ago to approximately three thousand. This number includes hundreds of consultants that help corporations install databases and network systems.

Sales and marketing (including advertising) are Microsoft's largest expenses, equal to about 30 percent of 1994 revenues. Operating costs (including product support) consumed about 15 percent of 1994 revenues, research and development (treated as a current expense) 13 percent, and general administrative costs 3 percent. This left Microsoft with about 37 percent of its revenues as profits before taxes (see Table 1, p.3). Rapid rises in R&D, sales and marketing, and product support expenses, however, have prompted Gates, Maples, and other senior managers to seek ways to reduce these costs -- such as through more systematic engineering practices, better coordination among the product groups, and improved product quality and ease of use (to cut down on the need for customer support). Rising interdependencies among the product groups -- as well as the growth in product size and complexity, and the need to always maintain compatibility with previous versions of a product -- remain difficult problems to manage. At times, these problems have tarnished Microsoft's efforts to deliver reliable products on a more predictable schedule. As we discuss later, delays in shipping Office 4.0 and Windows 95 are typical of the difficulties Microsoft has been struggling to overcome.

Old Rivalries -- Systems Versus Applications: The most significant aspect of the 1992 change in the top management structure is that it formally unified responsibility for the systems and applications divisions (as in the days when projects reported directly to Gates). This move placed both divisions under Mike Maples. It was important to bring these two divisions closer together because of their long-standing rivalries and growing strategic interdependence. Understanding in depth how Windows products work is essential to writing good applications; influencing the evolution of Windows and technologies such as OLE is equally important to writing good applications; and new systems products like Windows NT will never take hold in the marketplace if applications builders -- led by Microsof t -- do not write applications. The problem is that, historically, Microsoft's systems and applications divisions have never gotten along very well. Systems people (especially the group that has built Windows 3.1 and Windows 95) have also tended to be less organized and less systematic than their counterparts in applications, even though systems products are usually more difficult to build and test.

Maples succeeded in getting the applications groups to become more systematic and quality oriented, and he tried to do the same with the systems groups while these were under his direction until 1995. Managers such as Dave Cutler (who joined Microsoft from DEC) had similar values, but Maples did not succeed completely. He acknowledged to us that his focus on customer problems and process was more suitable for applications than for systems software for two basic reasons. First, operating systems have to run on many different kinds of unique hardware. To test the various kinds of hardware requires "very long, extensive large-volume betas" (tests of preliminary product versions at customer sites) so that users can try many different combinations of machine and application configurations. Progress for this kind of testing is difficult to predict. Second, Maples observed that operating systems projects are generally much larger in terms of people, and they have components that interact with many different products. These make project management much more cumbersome: "One of the things that can make apps efficient is that they can have a small team, communicate well, and have fewer dependencies. Systems has lots more dependencies, bigger teams. It is a different process. I would say, not as a value judgment but as just kind of a fact, that the apps guys are more process driven...than the systems guys."

As a result, there is usually what some people have described as a greater level of chaos in the systems division, including the high-profile Windows 95 project. Windows NT is somewhat of an exception, as Maples noted: "In systems, we have very different processes. Dave Cutler in the NT group is very, very regimented. They have a workbook and write everything down....a very strict, strong type of process, whereas in Windows and DOS it's much more of a gunslinger process. You know, 'Let's kind of start coding and see how it works out.'" But Maples believed that all the systems groups needed to show more concern with controlling defects and improving accuracy in predicting when they would finish.

Various managers with experience on both sides of the fence confirmed this view of systems as more problematic than applications, although this distinction is changing slowly. Chris Peters, who worked as a developer on MS-DOS 2.0 and Windows 1.0 (as well as on various versions of Excel and Word) before becoming vice president of Office, emphasized the lack of control in specifications and project management: "Systems, you'll find, is far less organized than the apps group....I don't think they have proper specs....They'll say, yes, we use milestones, but you'll say, 'How many milestones total in the project?' and they won't be able to tell you." Richard Barth, a senior product manager for Windows NT, agreed: "When I first came in 1990 there really was a pretty vast gulf between applications and systems in the way they were managed. In fact, from the systems side, we often looked at the applications side and thought of them as much better managed, that the development process was much more under control there."

One of the reasons for the different culture in the systems division has been the management style of Steve Ballmer. For years, he preferred a relatively unstructured environment, with no separate testing function and lots of freedom for program managers and developers to innovate and make changes in the product late in the development cycle. Dave Maritz, formerly head of testing for MS-DOS and Windows (and now retired from Microsoft), had this to say about Ballmer, his former boss: "He's very sharp, but it's very hard to work under Steve because he was so random....He's not a structured type of guy. That's why he was moved out of controlling systems." Mike Conte, senior program manager in the Office group, suggested another reason for the different culture in systems:

I think that one of the shifts they're still making is away from an OEM-focus perspective to an end-user-focus perspective....It's partly history and culture. Steve Ballmer was very much the leader of that division. He's not somebody who is structured or bureaucratic, and it just didn't evolve over there. Also, it's because they tend to be more technical. The developers tend to have more of a say. And developers, without structure, are reasonably irrational: Left to their own devices, they will do things which may not make sense for marketing reasons or supportability or anything else. So they haven't yet got straightened out. The applications division used to be kind of Wild West, too. Then Mike Maples had a real positive effect on rationalizing a lot of things. They haven't yet had that effect. This is an apps guy's perspective, so you've got to take it with a grain of salt. But he [Ballmer] can still rattle people's cages all over the company if he wants to. So he still has an effect over systems, and he has Bill's ear....And Mike is...a very long-game player. He's not the type of guy to go up there and say, "Okay, scorch the earth. We're going to do it my way." He's much more subtle than that. I think his plan is to gradually change things over there.

Various Microsoft people echoed these sentiments and added to the picture of how systems differed from applications. There is even a geographical explanation: The applications groups are located in the more modern northern part of the Microsoft campus, with a road separating "the big fancy brown buildings and the southern suburbs down here," as Dave Maritz described the setting. (Despite the relatively greater affluence of the applications division, however, Gates maintains his office with the systems people.) The different technical natures of the products play a major role as well, but this too is changing as user interfaces and features become more important in operating systems. Chris Williams, the director of product development, expected