Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People
528
Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People
528Paperback
-
PICK UP IN STORECheck Availability at Nearby Stores
Available within 2 business hours
Related collections and offers
Overview
Drawing on almost two years of on-site observation at Microsoft headquarters, eminent scientists Michael A. Cusumano and Richard W. Selby reveal many of Microsoft's innermost secrets. This inside report, based on forty in-depth interviews by authors who had access to confidential documents and project data, outlines the seven complementary strategies that characterize exactly how Microsoft competes and operates, including the "Brain Trust" of talented employees and exceptional management; "bang for the buck" competitive strategies and clear organizational goals that produce self-critiquing, learning, and improving; a flexible, incremental approach to product development; and a relentless pursuit of future markets.
Cusumano and Selby's masterful analysis successfully uncovers the distinctive way in which Microsoft has combined all of the elements necessary to get to the top of an enormously important industry — and stay there.
Product Details
| ISBN-13: | 9780684855318 |
|---|---|
| Publisher: | Free Press |
| Publication date: | 12/04/1998 |
| Pages: | 528 |
| Product dimensions: | 5.50(w) x 8.50(h) x 1.30(d) |
About the Author
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 impac
Table of Contents
ContentsPreface to the Paperback Edition
Preface
Introduction
- Organizing and Managing the Company
Find "Smart" People Who Know the Technology and the Business - Managing Creative People and Technical Skills
Organize Small Teams of Overlapping Functional Specialists - Competing with Products and Standards
Pioneer and Orchestrate Evolving Mass Markets - Defining Products and Development Processes
Focus Creativity by Evolving Features and "Fixing" Resources - Developing and Shipping Products
Do Everything in Parallel, with Frequent Synchronizations - Building a Learning Organization
Improve Through Continuous Self-Critiquing, Feedback, and Sharing - Attack the Future!
Appendixes
- Microsoft Chronology
- Main Microsoft Desktop and Business Applications
- Microsoft Operating Systems
- Applications Division Employee Survey
- Selected Chronology of Microsoft Agreements for the Information Highway
Interviews
Notes
Acknowledgments
Index