How Microsoft Makes Large Teams Work Like Small Teams
Topics
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.
References
1. P.G. Smith and D.G. Reinertsen, Developing Products in Half the Time (New York: Van Nostrand Reinhold, 1991), p. 119.
2. See F.P. Brooks, The Mythical Man-Month (Reading, Massachusetts: Addison-Wesley, 1975); and B.W. Boehm, Software Engineering Economics (Englewood Cliffs, New Jersey: Prentice Hall, 1981).
3. T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams (New York: Doreset House, 1987), p. 45. See also: Brooks (1975), p. 30.
4. This appeared to be a common problem at AT&T’s Bell Labs, for example. See: M.A. Cusumano, Japan’s Software Factories (New York: Oxford University Press, 1991), p. 72.
5. For data on engineering hours involved in automobile product development, see: K.B. Clark and T. Fujimoto, Product Development Performance (Boston: Harvard Business School Press, 1991); and K. Nobeoka and M.A. Cusumano, “Multiproject Strategy, Design Transfer, and Project Performance: A Survey of Automobile Development Projects in the U.S. and Japan,” IEEE Transactions on Engineering Management, volume 42, November 1995, pp. 397–409.
6. See various discussions in Brooks (1975) and DeMarco and Lister (1987).
7. Brooks (1975), p. 31.
8. E-mail correspondence with D. Moore, director of development, Microsoft Corporation, 5 February 1997.
9. R.D. Banker and C.F. Kemerer, “Scale Economies in New Software Development,” IEEE Transactions on Software Development, volume SE-15, number 10, 1989, pp. 416–429.
10. Brooks (1975), p. 25.
11. This discussion is based on material adapted from: M.A. Cusumano and R.W. Selby, Microsoft Secrets: How the World’s Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People (New York: Simon & Schuster/Free Press, 1995).
12. For examples, see: S.C. Wheelright and K.B. Clark, Revolutionizing Product Development (New York, Free Press, 1992).
13. See V.R. Basili and A.J. Turner, “Iterative Enhancement: A Practical Technique for Software Development,” IEEE Transactions on Software Engineering, volume SE-1, December 1975, pp. 390–396; B.W. Boehm, “A Spiral Model of Software Development and Enhancement,” IEEE Computer, May 1988, pp. 61–72; and M. Aoyama, “Concurrent-Development Process Model,” IEEE Software, July 1993, pp. 48–55.
14. See W.W. Royce, “Managing the Development of Large Software Systems,” Proceedings of IEEE WESCON, August 1970, pp. 1–9.
15. See Wheelwright and Clark (1992). See also, for example: G.L. Urban and J.R. Hauser, Design and Marketing of New Products (Englewood Cliffs, New Jersey: Prentice Hall, 1993); and K. Ulrich and S. Eppinger, Product Design and Development (New York: McGraw-Hill, 1995).
16. For a discussion of the evolution of development process techniques and organization at Microsoft, see: Cusumano and Selby (1995), pp. 35–46.
17. See M. Iansiti, Technology Integration (Boston: Harvard Business School Press, 1997).
18. See M.A. Cusumano, The Japanese Automobile Industry: Technology and Management at Nissan and Toyota (Cambridge, Massachusetts: Harvard University Press, 1985).
19. One exception to this is a new master’s degree program at MIT in system design management, run jointly by the schools of engineering and management, precisely to address this weakness in education.
20. C. Peters, “Shipping Software,” Tech Talk Seminar Video, 1990.
21. Interview with Chris Peters, vice president, Office Product Unit, Microsoft Corporation, 12 April 1993.
22. Peters video (1990).
23. Interview with Dave Thompson, development manager, Corporate and Network Systems, Microsoft Corporation, 15 April 1993.
24. Interview with Bill Gates, chairman and CEO, Microsoft Corporation, 3 August 1993.
25. Interview with Mike Maples, former executive vice president, Microsoft Corporation, 16 April 1993.
26. Peters interview (1993).
27. See the translator’s afterword to Maikurosofuto shiikuretto (Tokyo: Nihon Keizai Shimbunsha, 1996), volume 2, pp. 305–306.