How Microsoft Makes Large Teams Work Like Small Teams

Common sense, industry experience, and some academic research all suggest that, when conducting any complex tasks, small teams of talented people are better than large teams of average or talented people. To develop new products quickly, for example, a recent textbook argues that small teams of no more than ten or so people are most effective.1 One reason may be that the fewer people on a team, the easier it is to have good communication and consistency of ideas among team members. Small teams also can simplify scheduling and work out interdependency difficulties.2

Another factor to consider in determining the optimal size for a particular team is individual team-member productivity. In software development, for example, talented programmers are known to be ten times or more as productive as the least talented members of a team.3 This is no doubt true for other types of research, engineering, and intellectual work, such as creative writing, that we cannot so easily routinize or mechanize. Getting the same amount of raw productivity from a team of ten talented people as opposed to 100 untalented people provides other benefits as well, such as simplifying communication and scheduling problems. The ten-person team would probably produce better results faster, even though managing prima donnas, such as “super-programmers,” can present other challenges (the problem of “too many chiefs and not enough Indians”).4

But, while small teams of talented people may be the most desirable way to develop new products, another issue that managers must consider is the inherent limits of small teams when facing very large products and short deadlines. Small teams even of “super-engineers” may still be unable to design, build, and test a complex product with many components quickly enough to be competitive. As a result, even a very selective firm may end up having to manage teams of hundreds of talented engineers. In the automobile industry, for example, companies require as much as 7 million engineering hours to develop one new product and routinely require 1 to 2 million engineering hours. Even at companies renowned for product development skills, such as Toyota, Honda, and Chrysler, these numbers translate into at least 500 and often more than 1,000 engineers working from three to five years on a single new car product.5 Aircraft manufacturers such as Boeing use teams several times this number of people — several thousands of engineers — to build new commercial airliners.

Many software project managers prefer very small product teams of a dozen or fewer programmers.6 This continues a culture from the early days of programming for both large computers and personal computers, when two or three people could build a new product. Initial versions of Microsoft’s MS-DOS, Word, and Excel from the early 1980s had programming teams of half a dozen to ten or so developers, and consisted of just a few tens of thousands of lines of code. But such small product teams were never practical for large systems, even in the 1960s, when IBM required a thousand people to build the operating system for its System 360 mainframe computers.7 In the 1990s, with more memory-intensive graphical interfaces and various complex functions, even personal computer software teams are huge by historical standards for the PC industry. The first version of Windows NT, introduced in 1993, consisted of around 4.5 million lines of code and had a development team (program managers, who work on product specifications as well as project management, developers, and testers) of about 450 people at the peak. Windows 95, introduced in 1995, consisted of 11 million lines of code and required a similar number of people working approximately three years. A team of about 300 people are building the core components of Microsoft’s Internet Explorer browser, introduced in 1996, and several hundred more people are involved in creating various add-in features, such as Internet mail.8

Of course, since the age of the ancient irrigation systems and the Egyptian pyramids, if not before, engineering managers have broken large-scale systems into separate components or subsystems and into separate subteams that are easier to manage than one large team. Modern companies have made product and task modularization as well as division and automation of labor into a science — whether it be software systems, aircraft, or automobiles. This notion of “divide and conquer” brings up another problem, however: how to integrate the work of many people and many separate components that need to work together smoothly to create a good product. There is also the need to avoid the added confusion and overhead costs, such as time for meetings and communication, that come with coordinating many small teams and constitute a diseconomy of scale.9 (The IBM OS/360 project, for example, spawned what is known as Brooks’s law: “Adding manpower to a late software project makes it later.”10) Exacerbating these difficulties of scheduling and coordination is the need to manage changes effectively, especially if there are time and budget pressures. If the underlying technologies and user needs are evolving very rapidly, product development teams must often invent or innovate in designs as they develop a product and show features to potential users and then respond. This has been the case with software for personal computers, especially for Internet applications.

Project managers and product designers in software and other industries thus need to find ways to divide up products and tasks so that even teams of hundreds of talented people can work and communicate efficiently as well as creatively. In other words, they need to find ways to make large teams work like small teams.

In this article, I discuss how Microsoft has tackled this problem.11 In the first section, I outline the basic concept underlying Microsoft’s approach: allow teams and individuals to be creative and retain the autonomy of small groups, but frequently synchronize and periodically stabilize the design changes or feature innovations that they are continuously making. Next, I discuss two specific strategies and sets of principles that describe how Microsoft makes the synch-and-stabilize style of product development work: (1) focus creativity by evolving features and “fixing” resources, and (2) do everything in parallel with frequent synchronizations. The third section steps back a bit to review how the management of product development and testing processes as well as people can increase the effectiveness of large teams. I conclude with a brief discussion of how these concepts may apply to different types of products and industries.

Frequent Synchronizations and Periodic Stabilizations

In our 1995 book, Microsoft Secrets, my coauthor Richard Selby and I observed Microsoft product development groups during a two-and-a-half-year period, conducted in-depth interviews with thirty-eight key people, and reviewed thousands of pages of confidential project documentation and “post-mortem” reports written since 1986 that discussed what went well, what went poorly, and what projects should do the next time around. We identified a relatively consistent process for product development and decided to label this the synch-and-stabilize approach. The essence is simple: Continually synchronize what people are doing as individuals and as members of teams working in parallel on different features, and periodically stabilize the evolving product features in increments as a project proceeds, rather than once at the end of a project. Microsoft people refer to their techniques variously as the “milestone,” “daily build,” “nightly build,” or “zero-defect” process. The term “build” refers to the act of putting together or “integrating” partially completed or finished pieces of a software product during the development process to see what functions work or what problems exist, usually by “recompiling” and linking the components and then running a simple automated test.

These techniques address the problem of how to deal with the growing size of product development teams. In large development projects, many team members create many components or features that are interdependent but difficult to define accurately in the early stages of the development cycle. In response, Microsoft managers have tried to structure and coordinate what individual engineers and teams do while allowing people enough flexibility to be creative and evolve a product’s details in stages. To save time and produce better features, managers also require developers to test features with customers and refine their designs during the development process.

In various industries, many companies now use prototyping as well as multiple cycles of concurrent design, build, and test activities to control iterations and incremental changes in product development.12 In the computer software community, since the mid-1970s, researchers and managers have talked about “iterative enhancement,” a “spiral model” for iterating among the phases in project development, and “concurrent development” of multiple phases and activities.13 Many firms have been slow to adopt these ideas formally. Nonetheless, the basic idea shared among these approaches is that users’ needs for many types of software are so difficult to understand, and changes in hardware and software technologies are so rapid, that it is unwise to attempt to design a software system completely in advance. Instead, projects should iterate and concurrently manage several design, build, and testing cycles while they move forward to completing a product.

This iterative, incremental, and concurrent-engineering style contrasts to a more sequential or “waterfall” approach to product development. In the waterfall approach, projects attempt to “freeze” a product specification, create a design, build components, and then merge these components together, primarily at the end of the project in one large integration and testing phase