Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People

Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People

3.0 1
by Michael A. Cusumano, Richard W. Selby
Michael Cusumano and Richard Selby spent nearly two years on-site at Microsoft headquarters. The result is this objective and analytical look at how Microsoft organizes, competes, develops new products, and tries to learn and improve as an organization. As timely a topic today as when it was first published.


Michael Cusumano and Richard Selby spent nearly two years on-site at Microsoft headquarters. The result is this objective and analytical look at how Microsoft organizes, competes, develops new products, and tries to learn and improve as an organization. As timely a topic today as when it was first published.

Editorial Reviews

David Rouse
Now that Bill Gates has been declared the richest man in the world and his company produces the software that drives most of the world's personal computers, fascination and interest in the man and in Microsoft, his company, are at an all-time high. There are already at least three books profiling Gates and Microsoft. Another, "I Sing the Body Electronic" by Fred Moody , follows the development of Microsoft's new multimedia Explorapedia and focuses on the company's project-team approach to product development. Gates' own much-anticipated, much-delayed (much like several of the company's software releases) "The Road Ahead" is also now due in the fall. With that in mind, Simon and Schuster and the Free Press have rushed the release of this book by several months. Gates has a penchant for showcasing his company, inviting outsiders to sit in, watch, report on, and even critique and participate in operations. As he did with Moody, Gates allowed Cusumano, who teaches the management of technology at MIT, and Selby, who teaches information and computer science at the University of CaliforniaIrvine, access to Microsoft's headquarters. There they were able to see confidential documents and project data as well as conduct in-depth interviews. The result is the most thorough profile of one of the most important companies today. Most corporate "biographies" seek either to glorify or vilify their subjects. Cusumano and Selby, however, take an instructive, objective, and analytical look at "how Microsoft organizes, competes, develops new products, and tries to learn and improve as an organization."
From the Publisher
Peter Senge MIT Center For Organizational Learning, author of The Fifth Discipline Microsoft Secrets is a fascinating book about a fascinating company. What is surprising are the insights the authors developed into the interaction of culture, strategy, and process.

George Fisher Chairman, President, and CEO, Eastman Kodak Company Bill Gates is to computer software what George Eastman was to photography. Microsoft Secrets tells us how this dynamic company and its leader organize, compete, and win.

Product Details

Free Press
Publication date:
Product dimensions:
6.57(w) x 9.57(h) x 1.67(d)

Read an Excerpt

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 systems people to come around slowly as they gain more experience:

People in systems still feel that "we will sell no wine before its time," and so their approach to developing software is completely different....I think you have to have lived through three or four project cycles, to have gone through the pain of a badly managed process several times....And if you think about the people who are working in systems, their cycles are...twice as long as they are in apps. The guys who are coming off NT are the guys who are coming to me now going, "I cannot take this one more time!" And of the guys who are in Chicago [Windows 95], I'm convinced there will be a certain percentage who will come to me when that thing ships and go, "I cannot take this."...That's a fundamental difference. I also think the difference is that the people who are in charge of those projects are people who have succeeded. Windows 3.1 was arguably a fairly successful project, and these are people who have succeeded at creating software in the old-fashioned way. And it is not broken, as far as they're concerned, so why are you trying to fix it?

New Markets and Technologies: Microsoft does not only make operating systems and applications programs, even though these areas generate most of the company's current revenues and profits. The fastest-growing markets are new consumer products and on-line systems. These divisions have yet another culture, more concerned with mixing "leading-edge" science and technology with everyday consumer habits. Group vice president Nathan Myhrvold, who has been head of advanced technologies in Microsoft, described his three charters in a recent interview: (1) Help Bill Gates set technology strategy for the company, such as making decisions on what technologies to license, buy, or develop; (2) create products for the future; and (3) conduct research, focusing on areas of computer science that support Microsoft's product groups and Gates's vision for extending the personal computer.

In a broader sense, Myhrvold saw his role as preparing Microsoft for "paradigm shifts," such as that which seems to be occurring in digital information:

A classic problem is that companies have one product that they do really well with, but they never move beyond that. What's distinguished Microsoft is that we're not afraid of making paradigm shifts, largely because our senior management is very technical. We understand the technology, which at the end of the day is really what drives the industry. You have to be very smart in business, but no amount of smarts will protect you from a technological revolution. It can overthrow you in a minute.

The advanced consumer systems division, now part of the Platforms Group, has been particularly important. In cooperation with the research, broadband applications, and on-line systems areas, the advanced consumer systems division develops and markets multimedia products for the home and the information highway; these include interactive TV and the Microsoft Network. It also works on futuristic products. The division has a similar functional structure to other product units (i.e., people have assignments in program management, development, testing, and product planning). Job responsibilities are less distinct among the functions, however, to promote innovation and exploration of new ideas.

Rick Rashid, a former Carnegie-Mellon professor of computer science, runs research, including interactive TV studies. His group has about two hundred and fifty scientists and an annual budget of at least $150 million. Its work targets new technologies five to ten years from commercialization but also includes projects with shorter-term potential. Researchers are studying programming productivity tools; applications of artificial intelligence to operating systems and user interfaces; computer-based decision making; speech processing and understanding; supercomputer design; video-on-demand server technology; and different approaches to mixing video, audio, and text to create interactive TV, multimedia products, and pocket information systems (such as a "wallet PC"). Rashid explained that Gates feels Microsoft is now big enough to afford to have a research group and fund it lavishly. Gates and others also believe that Microsoft must generate more of its own technologies:

Basically, Bill wants to see an organization that pushes specific areas of research....We want those groups to be world-class and to be as good as or better -- preferably better -- than any of their competitors in their particular research arenas. Bill views this as a long-term commitment. It's something that Microsoft is able to do because it has reached a certain point in time and a certain size. It's also increasingly important because the company has to be able to develop its own ideas and its own technology to really prosper in the future. Besides, it never hurts having smart people around.

The research division has already contributed significantly to the new on-line service, new operating systems such as Windows 95 and Windows NT, and new user interfaces that provide "intelligent" assistance and make Windows easier to use for novice consumers. Myhrvold and Rashid are both confident that Microsoft will eventually produce whole new generations of technologies and products. They hope their research division will also outdo previous central labs at leading companies. Xerox's Palo Alto Research Center (PARC), for example, pioneered but did not successfully commercialize the personal computer and graphical user interface. IBM also has had difficulty commercializing computer technologies its researchers invented, such as reduced instruction-set computing (RISC).

Rashid explained why they are so confident: "The problem with Xerox PARC was not a problem with PARC. It wasn't that they were doing anything wrong; they were doing just exactly the right things. The problem was that they were working in a copier company....And I think that's really the lesson that you get from all these things, that the research has impact in the areas that it's performed if the company is operating in those areas. Then it can take advantage of that research." Myhrvold added that unlike in these other companies, Microsoft ties its research directly to the heart of the company -- to the CEO and to strategy: "Another problem with older labs is that they suffer from the ivory tower syndrome; they're completely separated from everyone else. I report directly to Bill Gates. Bill's very involved with our group's strategy, [and] I'm involved with the strategy we do elsewhere in the company." (Gates has been reported to spend as much as a third of his time working with Myhrvold on futuristic product ideas.)

PRINCIPLE Hire the smartest managers you can find -- people with a deep understanding of the technology and the business.

The senior Microsoft managers we have already talked about (Bill Gates, Mike Maples, Steve Ballmer, Nathan Myhrvold, Paul Maritz, Pete Higgins, Chris Peters, Rick Rashid, and others) may have their weaknesses, but they are clearly very able in ways important to Microsoft. In fact, Gates and other managers frequently boast that they hire only smart people -- managers, as well as developers, testers, and others. But what does being "smart" mean? To Bill Gates, this means being able to understand and probe complex things quickly and creatively, as he explained in a 1994 interview: "There's a certain sharpness, an ability to absorb new facts. To walk into a situation, have something explained to you and immediately say, 'Well, what about this?' To ask an insightful question. To absorb it in real time. A capability to remember. To relate to domains that may not seem connected at first. A certain creativity that allows people to be effective." Gates himself exhibits these qualities and looks for them in potential Microsoft managers and employees.

As Microsoft has grown, Gates has personally interviewed hundreds of programmers, managers, and technical experts who complement and challenge his own skills and knowledge. From this group, he has cultivated a relatively small corps of senior people that serves as an informal brain trust to assist him in making decisions and overseeing critical projects or initiatives. Gates, though, has a tendency to promote programming experts into senior management at very young ages. Combined with very rapid growth, this has left Microsoft short of managers in the middle ranks who understand not merely the technology and the business but also the human side of management.

The Brain Trust: The core of Microsoft's brain trust consists of around a dozen people. They run the key product areas and new initiatives as well as constitute an informal oversight group to critique what everybody else is doing. There are also senior technical people working in the projects who are part of a broader network; although many of these people are Microsoft veterans from the founding years, a growing number have come from competitors or are experts in new technical domains that go far beyond the PC. Dave Moore, who does not consider himself a member of the inner circle ("I'm more modest than that"), described it as a group of people not listed anywhere but widely recognized for their exceptional knowledge and experience: "It's fairly informal. The one thing I would say that makes you part of the brain trust is your ladder level. Every developer has a ladder rating....Each of the functional disciplines -- development, testing, program management, user ed -- they each are on their own ladder levels."

People associated with the Microsoft brain trust include the company's most senior executives as well as top developers and program managers. Among the executive staff, there is executive vice president Steve Ballmer (age thirty-nine), a classmate of Gates at Harvard who studied management at Stanford for a year before joining Microsoft in 1980. He may not be the right person to manage the systems divisions today, but he goes where the challenges are -- successfully taking over Windows development when this project was mired in delays during the mid-1980s, and recently taking over sales and customer support as these areas have become more critical. There is group vice president Nathan Myhrvold (age thirty-six), a Princeton University Ph.D. in physics who studied with Nobel Prize winner Stephen Hawking and joined Microsoft in 1986 when Gates acquired Myhrvold's software company. Myhrvold has been leading the way into corporate networks, multimedia, telecommunications, and on-line services.

Group vice president Pete Higgins (age thirty-seven) came to Microsoft in 1983 after obtaining a Stanford MBA. He formerly headed the desktop applications division and now, with Myhrvold, manages the new Applications and Content Group. Group vice president Paul Maritz (age forty), a Microsoft veteran since 1986, specializes in long-term product strategy and oversees the development of Microsoft's operating systems as well as other key consumer technologies. We should add to this group newcomer Robert Herbold (age fifty-three), a Ph.D. in computer science from Case-Western Reserve University who worked in Procter & Gamble for twenty-six years, most recently as a senior vice president in charge of management systems, market research and advertising, and technology acquisitions. He joined Microsoft in 1994 and brings a deep expertise in consumer marketing, important to Gates because consumer products are Microsoft's fastest growing area.

Several other senior executives fall into the brain trust category. Senior vice president Brad Silverberg (age forty-one), manager of the personal operating systems division, came to Microsoft in 1990 from Borland, and headed the Windows 3.1 and Windows 95 projects. Roger Heinen (age forty-three), senior vice president in charge of the developer and database systems division, entered Microsoft in 1993 after heading Macintosh software development at Apple and working at Digital Equipment Corporation before that. James Allchin (age forty-three), vice president and head of the business systems division, leads the Cairo (Windows NT 4.0) project. He came to Microsoft in 1991 from Banyan Systems. Senior vice president Craig Mundie (age forty-six), responsible for advanced consumer systems, joined Microsoft in 1992 after managing a super-computer company, Alliant Computer Systems. Jonathan Lazarus (age forty-four), vice president of strategic relations, is a marketing specialist who joined Microsoft in 1986. Vice president Chris Peters (age thirty-six) heads the Office product unit, which has generated nearly half of Microsoft's sales and profits.

Vice president Rick Rashid (age forty-three), head of research, joined Microsoft in 1991 after being a well-known professor of computer science at Carnegie-Mellon University. Rashid is the chief architect of Mach, a UNIX-based operating system that served as one of the models for Windows NT. Darryl Rubin (age forty-one), vice president for software strategy, is an expert in network technologies and a Microsoft employee since 1986. Although his influence has diminished as new people have come on board, another member of this select group has been Charles Simonyi (age forty-eight), a Stanford Ph.D. in computer science who designed graphical applications for Xerox PARC, including the famous Bravo word processor. He left Xerox for Microsoft in 1981, and for much of the next decade directed Microsoft's entry into applications, beginning with Multiplan, Word, and Excel.

Some members of this group are clearly on a faster track than others. Silverberg had this to say about one youthful colleague: "Chris Peters is the guy who understands the development process the best, who has had the most success, who has the development process most people in the company want to emulate. He's the guy we think we can learn the most from." Like other top managers in Microsoft, Peters has a solid technical background, but he also has broader than usual experiences in the company, having worked in systems, applications, and general management. He has both bachelor's and master's degrees in electrical engineering from the University of Washington, where he specialized in software engineering. After coming to Microsoft in 1981, he worked as a programmer on MS-DOS 2.0, the Microsoft Mouse 1.0, PC Word 1.0, and Windows 1.0. For five years, he was the development manager for Excel. After the successful shipment of Excel 3.0 just eleven days late (as a result of using the new development process), Peters became general manager of the Word product unit -- a business that generated several hundred millions dollars in revenues for Microsoft. In 1993 Peters received the title of vice president when he took charge of the new Office product unit, now the key to Microsoft's applications strategy for desktop PCs.

Another essential member of the brain trust has been Mike Maples (age fifty-three), who served as executive vice president between 1988 and 1995. He is now an advisor to the company on such matters as mergers and recruiting. Maples is important because he gently but steadily nudged Microsoft further down the path of greater structure and less chaos in product development. He was not a developer, but he had the background to be one, with a college degree in electrical engineering from the University of Oklahoma as well as an MBA. He also seemed to know how to manage creative technical people who do not like a lot of managers above them. Maples left IBM because of the potential he saw in Microsoft as well as his disappointment with IBM. Within Microsoft, he tried to help Bill Gates avoid the pitfalls of large, bureaucratic organizations by emphasizing four general precepts that worked well in IBM. Maples recalled that the first was to introduce in Microsoft a full set of personnel management practices, covering hiring, training, compensation, and career paths:

One of several things that IBM did really well, and that I think we continually improve on, is personnel management and management practices -- the whole idea of having a level of consistency in terms of the way you measure, monitor, and reward people. Nobody likes to be "formula-ized" into a review system or a management system or an increase system. But...what ends up happening is [people] playing favorites and trying to keep everything in their heads. We were a size where that was starting to break down; it had probably started to break down a lot worse than we had even recognized at the time. So [we started] the whole idea of moving people between groups, and of having some guidelines and a philosophy of how people progress in pay and a definition of levels. Dave [Moore] has spent a lot of time working on what it means to be a D 10 developer and an 11, and what it takes to get promoted, and how...we ingrain that in everybody's mindset so that when we move people across projects there are not huge disparities in pay, in expectations, or whatever.

A second precept, which remains a Microsoft weakness, was to nurture middle managers: "The other thing we spent more time on was management development -- retreats, managers' meetings. A lot of time they're a waste of time, but everybody gets together and talks, and you have that opportunity to talk about common problems." A third was to continue cultivating functional expertise, such as in development and testing, but to make sure people move around and receive broad experiences. Maples wanted to avoid the narrow mindsets and departmental rivalries and turf battles that have plagued IBM and many other large organizations:

The other thing that has happened is that people are much broader now, and it's not the developers against the testers. Anytime you have a functional organization you always have these boundaries, and there gets to be quite a lot of animosity. In fact, it gets to be so bad that some people can never cross them; they have to change jobs or leave. I think we have a lot less of "the testers are bums and the developers are good," or "the developers are bums and the marketing guys are good." Each team is much more cohesive. We still do have a system that is slightly biased toward developers in terms of levels and pay, and prestige. You walk a little taller if you're a Microsoft developer than if you are anything else in Microsoft. And I guess that's the way it ought to be; that's our culture. We're a technically driven company, and most of the senior people in Microsoft are technically grown people.

Maples in particular tried to avoid the type of culture that prevailed at IBM, where there were many internal conflicts, and groups would hide "bad news" from management or the quality assurance people. Bill Gates does not like to hear bad news either, and some Microsoft managers have been reluctant to admit errors or slips in schedules, but Gates can be even nastier in meetings when he discovers problems that no one told him about. Maples liked frequent, frank communications aimed at constructive mutual criticism and learning how to do things better. Despite his more confrontational style, Gates has similar values: He wants openness, especially if there are serious problems in a product under development. He wants people to think about what is good for Microsoft, and not just for their own project or their own careers. And neither Gates nor Maples liked to see people repeat the same mistakes. Maples compared the atmosphere in IBM to what he has seen in Microsoft:

[At IBM] there were quality assurance people, not nearly as many people as we have here, and it was much more of an audit function. The development organization did some testing, and then there were the quality assurance guys, who were always telling them that they're screwed up. We don't have the kind of adversarial roles that IBM had. IBM had a conflict management system on purpose: If you let people represent their specific interest, then you'll get all the facts on the table and make better decisions. To some extent, that's certainly a valid management idea. We don't do that; we try to get better consensus and have people think broadly what's good for the whole. When I was in development at IBM, you just learned how to hide stuff from them....And you'd go to the very last minute before you'd bring bad news....You'd end up with some really bad tragedies. Things just go against you, or you don't have the experience to bear the risk right. And then all of a sudden the project that everybody thought was going great just totally bombs. We're much more "all cards up," very flat communication. I'll get an e-mail from one of the Word developers that'll say this thing is going screwy down here or whatever, and that's not thought of as being anti-Microsoft to communicate.

Maples's fourth precept was that a software company should define a process for product development: "If you're in IBM, you realize there is value and there are problems with process. The idea of having a process is important. The idea of having one that works for the particular organization or the particular unit is important." Maples recalled that, following the 1989 retreat, he and other senior people decided "each team could define their own process, as long as they know what it is and they follow it." He wanted to see evidence of a repeatable development process, but would not try to define standards for all of Microsoft to follow. Key people in each of the business units then went off and tried to write down how they could best develop and test software. Over about a year and a half, a consensus started to emerge: "People still feel they have some degree of freedom in terms of how they run their projects. But I'd say that there are really a couple of basic ways that we do things, and these have permeated throughout the organization -- a few basic principles, and that's pretty much what has driven it." Maples listed his common principles; as with Gates's list, we include them in our later discussions:

1. Let people do their own schedules.
2. Build in buffer time for the unforeseen delays that always occur.
3. Assume change will happen, so don't waste time trying to write a complete specification up front.
4. Manage by milestones, starting with the most difficult things first.
5. Focus on customer problems, not technologies or processes.
6. Move people around, to mix the good and the bad.

Technically Competent Managers: Gates and other early executives in the company have made a special effort to populate Microsoft with technically competent managers, especially but not exclusively in the development organization. Rick Rashid, when still a neutral observer and accustomed to dealing with bright computer science students at Carnegie-Mellon University, recalled being struck by the senior people he met: "One of the things that I was very impressed with when I first visited Microsoft was the level of expertise and competence that you find basically all the way through the management hierarchy. It's just not that common in the computer industry to find strongly technical people in key management positions throughout the company." Dave Thompson, who had bachelor's and master's degrees from Cornell University and worked in DEC and Concord Communications for thirteen years before joining Microsoft in 1990 to head the Window NT network design group, echoed this sentiment: "I believe that one of the strengths of Microsoft is the fact that its managers are very technical, even at the most senior levels....I believe that managers should be as technical as possible. Leads -- that is, first-level line managers -- absolutely should write code, should be able to fix problems in the stuff that their people develop."

It is common practice for managers in all the functions to continue doing their functional jobs after becoming senior managers. Even development managers of large groups such as Word and Windows NT still spend one-third to one-half of their time writing code. The rationale is that managers need to remain directly involved in the technology in order to make the right decisions and solve problems that occur in their groups. Lou Perazzoli, software engineering manager on the Windows NT 3.0 project, spends about half his time coding. He makes managers under him do the same:

I have these rules in my group that I try to follow. Number one is everybody who works for me actually has code responsibilities, so nobody just manages people....I find that people who manage people lose sight of what the goal is and they don't appreciate the problems and issues...and they don't act on them quickly enough. Yet when you have code that you are doing, you tend to act on issues in a much more timely fashion, and you tend to be more concerned about how things are going....I probably spend 50 percent of my time looking at problems and writing code.

Managers in the applications area, such as Chris Peters (speaking when he was the general manager of the Word unit), have similar values:

At Microsoft...the functional managers still spend a great deal of their time doing whatever they do. In other words, the development manager of a group of 60 developers will still spend a fair amount of his time programming....In larger organizations...they keep pushing down the level where people are actually doing the work. Pretty soon you get a development manager who decides that he's way too important to program, and pretty soon the feature team leads all decide that they're way too important to program. Pretty soon, the programmers are way too busy to program....I have 270-some people working for me, and I'm the first layer in the organization that actually doesn't have to do any work, although I did write one feature in the new version.

Weaknesses in Middle Management: One consequence of promoting successful technical people into the management ranks, and encouraging them to continue working in their technical areas, is that managers may not spend enough time being or becoming good managers of other people. A common disdain for formal training and promotion systems, and for staffs and written procedures -- all of which can support the management process -- has not helped the situation in Microsoft. The key problem, in Dave Maritz's view, is Microsoft's habit of choosing managers for their technical ability, not for their managerial ability:

Management at this firm sucks....I had promotions when I didn't know I had a promotion; I suddenly saw a salary increase, and it happened. There have been times when I haven't even had a review because my manager has been scared of me. There is a problem at Microsoft at the middle management level....Salary increments and bonuses and the one-on-one process is lacking, in my opinion. The managers are picked because of their technical ability, because they've all worked up through the ranks after being hired in as developers. And the best developers become the [top] managers.

Maritz agreed with others in the company that technical managers need to have superb technical skills, otherwise Microsoft people will not respect them. But he also argued that managers need to be more than just excellent programmers -- they should exhibit qualities of leadership and charisma, which Maritz said he encountered too infrequently among Microsoft's middle management corps:

To be a manager or a leader -- in essence, a manager is a leader -- you have to have one of two essential things; if you've got both, then you are just set for life. One is you have to be technically as competent if not better than your peers or the people you're going to manage. Two [is] charisma, and generally the managers at Microsoft are not the charisma types. I regard myself as a charisma type, not a technical type; I am unusual at Microsoft in that respect. At the first line level of management, you'll see a lot of non-charisma types....those that bump up to the second level will be the ones that have both the charisma and the technical abilities....and so it goes, higher and higher up the levels. When you get to about the third and fourth line up, you generally have people who can manage people well, in addition to managing the technical concepts well.

Maples admitted that he learned about this problem shortly after he joined the company, and he maintained that he (with Dave Moore and others) worked hard to improve the situation. But Microsoft grew so quickly that Gates and Maples had to put very young people in positions of great responsibility, and Microsoft's senior executives continue to promote people with technical backgrounds and successful records in technical achievement. Richard Barth acknowledged that finding suitable middle managers is "the biggest challenge" in the company:

No question that we do not have a good set of middle managers. The Chris Peters of the organization are great managers, and that's another one of Mike's agendas -- to create more managers....But our biggest challenge is finding the appropriate set of middle managers....They don't just happen....One of the things we have discovered over the last couple of years is that you've got to value and cultivate management skills....The culture of Microsoft has been if you yell loud and push hard, you were a manager. And again, just in the last year, I've seen that change....In the past, if you were somebody who could really get things done, you were a manager. That's no longer enough.

PRINCIPLE Hire the smartest employees you can find -- people with a deep understanding of the technology and the business.

As we discuss in the next chapter, to find people with good technical abilities and a desire to make money using those abilities to build and sell software, Microsoft has instituted a hiring process that rigorously screens candidates. In particular, recruiters look for people who fit into each functional specialty and who can work together well in small teams. Managers generally try to find young people who can adapt to Microsoft ways. They also look for people with the ability to act and learn on their own as well as make good decisions quickly, without a lot of formal training and written rules or guidelines. But there are both positives and negatives to bringing together so many bright and independent-minded people.

The Benefits of Smart People: Below the product groups and functional managers, Microsoft has approximately 5,000 software developers and test engineers. In a field where the best software programmers may write ten to twenty times more code in the same time as the least productive members of the same team, attracting talented people is a great advantage. It means that the apparent resources available to managers with a high percentage of talented people are far greater than simply the number of bodies they command. (We can think of a contrast to many companies building software systems in the United States, Europe, and Japan, who do not screen software developers so rigorously. Many companies also hire people of various backgrounds and minimal experience with computers, then train them in-house to write software. It is difficult for these people to perform well and be "smart" in a complex technology when they have such limited experience and training.)

In fact, every Microsoft manager that we talked to about this subject emphasized the value of having a highly selective pool of people. Mike Maples noted that "the quality of the people is an unmeasurable benefit. Not everybody has the luxury we have of getting MIT's best and Stanford's best." Rick Rashid agreed: "There are more good smart software developers here than I've seen anyplace else in the world, concentrated in one place." So did Dave Thompson: "The...big difference between us and other companies is the people that we hire. Our whole system is predicated on the fact that our people are very fast and smart....It makes you feel like you have a much larger set of resources to work with. You feel like you have flexibility when you have people that can fix things in hours instead of days." As Bill Gates boasted:

We benefit from having the smartest people actually get involved not just in the design and ideas but actually the code itself. They know the code extremely well, and large areas of the code. It's good to have one person who can think through any kind of design change, particularly when you're late in the process and you're trying to be very careful. They can review anything that goes on. They've got a very strong model in their head for what...side effects that change might have....We have the benefit that people don't like to have bad developers around. It's just enough of a drag on them that they'll find a way to convince people it's a bad match to be in here if you're not a really top-notch developer.

In addition to providing an abundance of sheer technical skills, smart people can make even a large company seem relatively non-bureaucratic and flexible -- more like a small company. Chris Peters held this view, emphasizing the value of people who can work and solve problems on their own: "This is not a company where there's a bunch of stupid people running around, and then some manager writes down a bunch of stuff in order to control stupid people. It's a company where there's a lot of smart people running around all trying to do the right thing....I've seen stupid companies where they just hire bodies and attempt to make up for their hiring of lots of bodies by putting in lots of rules. I guess it may partly fix the problem, but the root cause of the problem was not lack of rules. It was hiring people that needed lots of rules to do their job."

Given the type of people that Microsoft screens for, it is not surprising that the company culture emphasizes technical competence and shipping products rather than adhering to rules and regulations, respecting formal titles, or cultivating skills in political infighting. Dave Moore commented on this: "Titles aren't important in the company. What's always been important is shipping products -- how many products have you shipped?" Brad Silverberg added that authority and responsibility tend to move toward those people who demonstrate the most competence: "Another key point about Microsoft development is that the balance of power within each group is more a reflection of the individuals and the strengths and capabilities of those individuals than any cookie-cutter approach....We're flexible. If I hired a development manager who was a super, super great product guy, who knew how to make features, balance of power can go over there. I'm certainly not religious about it. I just adapt to the strengths of the people I have."

If a conflict emerges between individuals or groups, such as over which components to share, Gates often steps in as the final arbiter. John Fine, formerly a director of program management and currently group program manager for Excel, offered this view of Microsoft's culture and the role of Bill Gates:

Things get done around here in many ways, from the most informal ear whisperings to the most formal orders....Rules don't count....Politics does not reign supreme here. So it is certainly not unthinkable for, say, the business unit manager of one piece of software to talk to the business unit manager of another piece and say, "You know, maybe our software should be inside of your software," or something like that. That is not a political gaffe; it's just another tactic in order to get the job done of benefiting the industry the most, therefore making the most money. But because those decisions are very costly in opportunity and have such a huge potential for negative effects if they're wrong, of course, they'll end up with Bill. In that way, the traditional management tree is used.

The Negatives of Smart People: The negative side of hiring people who do not want or need rules to work is that these people often have to learn by painful trial and error. It was our impression, for example, that Microsoft developers and testers (with some exceptions) were not so well read in the software-engineering literature and often reinvented the wheel, belatedly discovering good practices for software development other companies had recognized as important years ago. (These include doing more careful design reviews and code inspections as well as paying more attention to architecture and designs, sharing components, and having better quantitative metrics and historical data for project management.)

It is also difficult for senior managers -- including Bill Gates -- to tell these "smart" people what to do. They do not always like to cooperate and compromise, or share what they create and learn. As we discuss in Chapter 6, Microsoft has made some progress on this dimension, but there is much more that the company can do. Mike Maples gave one example of the problems he saw when he first joined Microsoft:

There weren't many people who had experience in project management; things were just done loosely. The Microsoft people and the Microsoft culture was such that you had very smart people. They don't want to be told what to do, but they're willing to be allowed to discover what to do -- and so you figure out the approach to let people discover what's a better way. "You've got to have this process, and this is the way you're going to do it," and so forth, would never work. But facilitating people sitting down and talking about it and working it out [does]....That's a reasonable, good modern management style, if you've got capable people. You don't want too much of an authoritarian management....I think we have a unique process that works better here than it would in most [companies]....But it is tailored to the fact that we have very, very smart people who are very, very motivated.

As Microsoft has grown, it has introduced a number of policies to prevent groups from having to continually reinvent solutions to the same problems, but these generally remain as guidelines or principles rather than rigid rules. Brad Silverberg commented on this transition within the company: "Back in the early days you didn't really need rules, but the practices have adapted to fit the new needs. But I think the culture is very strong, firmly entrenched -- decentralization, keeping things as flexible as possible but not too flexible. There are some rigid points, but each group adapts to the rules a little differently....Dave Moore or Mike Maples doesn't come to me and say, 'You are going to run your development organization this way.' It wouldn't work." In the next chapter we discuss how Microsoft defines job categories, as well as how it organizes and cultivates creative technical specialists.

Copyright © 1995 by Michael A. Cusumano and Richard W. Selby

Meet the Author

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

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews