The Man-Month Myth & How to Manage Large Teams

This article is an excerpt from the Shortform book guide to "The Mythical Man-Month" by Frederick Brooks. Shortform has the world's best summaries and analyses of books you should be reading.

Like this article? Sign up for a free trial here.

What is the man-month myth? How can you best manage large, complex teams?

Fred Brooks originally wrote The Mythical Man-Month as a management guide for the burgeoning software industry. However, managers from diverse fields began adopting his strategies, turning his work into a business classic.

Read on to learn about the man-month myth and how to manage large teams, according to Brooks’s advice.

What Is The Man-Month Myth?

In The Mythical Man-Month, Frederick P. Brooks offers a guide to managing large teams and completing complicated projects. The book explains the man-month myth and covers strategies for streamlining your process so that you can keep your staff working together smoothly and finish your most daunting projects on time.

Large teams inherently introduce a lot of complexity by multiplying the possibilities for miscommunication exponentially. The higher the number of workers, the more opportunities they have to misunderstand each other. Brooks demonstrates this relationship with the formula: n(n-1)/2. Here, n equals the number of employees. They can each communicate with n-1 other employees (because they won’t communicate with themselves). Each miscommunication involves two people, so you then divide the figure by two. When graphed, this formula displays an exponential growth curve. While five employees can miscommunicate 10 times, 100 employees can miscommunicate 4,950 times. Therefore, Brooks argues, many strategies that succeed with small teams won’t scale up to larger teams.

(Shortform note: Brooks’s ideas about the relationship between workers and productivity ran counter to a lot of assumptions about management at the time. Many managers used a unit of measurement called a “man-month” that allegedly represented the amount of work a worker could get done in a month. This led some to believe you could speed up any project simply by adding more workers. However, in Brooks’s thinking, productivity has less to do with the quantity of workers, and more to do with the quality of processes. Therefore, Brooks declares the “man-month” a myth with the title of his book: The Mythical Man-Month.)

In this section, we’ll discuss two strategies for managing teams and solving the problems of complexity: reducing the need for communication and documenting processes.

Strategy #1: Reduce the Need for Communication

Brooks’s first strategy for reducing errors is to cut down on the need for employees to communicate with each other. The fewer employees involved in a decision, the less discussion there needs to be about it. In this section, we’ll cover Brooks’s three core tactics for reducing the need for communication: specializing roles, limiting the number of designers, and letting skilled workers take the lead.

Technique #1: Specialize Roles

Brooks advises you to narrow and distinguish your employees’ roles within the company. This allows employees to carry out their individualized tasks without the need for collaboration or joint decision-making—reducing the need to communicate and with it, the potential for miscommunication.

For example, at IBM Brooks gave his programmers full responsibility over their programs until they were submitted for testing. Then the testing managers would have full responsibility. This reduced the need for collaboration because the project was out of the programmers’ hands once it reached the tester. To make this system work, Brooks separated his staff into a wide range of specialized roles, including tool makers, schedule keepers, and manual updaters.

(Shortform note: While Brooks highlights the benefits of role specialization in reducing the need for communication, economic theory demonstrates that role specialization also leads to greater company efficiency. When each employee specializes in one task, they can devote more time and energy to mastering and performing that skill. Therefore, the more specialized your company’s roles become, the more proficient your employees can become at each stage of production. This also gives an enormous advantage to large companies and even large economies with more workers: The more employees you have, the more tasks can be split up into separate specializations.)

Technique #2: Limit the Number of Designers

Brooks also reduced the complexity of his programs by limiting the number of people who designed them. Rather than following the logic of the man-month myth, he explains that programs designed by large committees tend to have more functions, but are less coordinated, more complex, and more error-prone than programs designed by only a few people. Brooks argues that the costs of the extra functions outweigh their benefits.

To limit the number of people giving input on the design, Brooks calls for a strict separation of designers from programmers. This ran counter to management practices common at the time he was writing, when the programming team helped design the software. Instead, Brooks advocates a process similar to building construction, in which the architects and construction crews are on separate teams. This reduces the complexity created by extra people introducing new ideas.

He concedes that designers and programmers still need to communicate a little to keep designers within practical limitations of money and memory. Therefore, at IBM, he allowed programmers to give input but left the ultimate decision-making authority to designers.

When Might You Want More People Making a Decision?

In addition to debunking the man-month myth, Brooks’s strategy of limiting the number of people making decisions stands in contrast to the popular management strategy of seeking diverse perspectives during decision-making. Andrew Grove (Only the Paranoid Survive) advocates this strategy, maintaining that business leaders need to get as many perspectives as they can on an issue to cut down on their blindspots. However, this isn’t to say there’s a best way to make decisions—Brooks and Grove sought to solve different problems:

– Grove’s largest problem was uncertainty. Responsible for high-level strategic decision-making, he spent three years making one large decision when the entire future of the company was at stake. Therefore, he solicited as many perspectives as he could to lower the odds of getting this decision wrong.

– Brooks’s largest problem was complexity. Managing the daily operations of a programming team, he had to make hundreds of little decisions every day and didn’t have time to discuss all of them in depth.

In deciding which approach is best for your business, consider which is a greater threat to your company, uncertainty or complexity. If the costs of getting one choice wrong are very high, try soliciting many different points of view to reduce the odds of getting it wrong. If the costs of getting choices wrong are diffused across hundreds of little decisions, try the Brooks approach of narrowing decision-making authority.

Technique #3: Let Skilled Workers Take the Lead

Brooks’s third technique for debunking the man-month and improving productivity by reducing communication is organizing programming teams so that they are led by a single master programmer, who makes most of the decisions but also does most of the work while other programmers take on a supportive role as assistants. This stands in contrast to a collaborative approach of shared responsibilities as well as a traditional hierarchical team that divides management from labor. Brooks makes two arguments in favor of his approach.

First, Brooks contends that programmers vary widely in skill level. Therefore, you will get the best results by identifying the most skilled programmers to do the heavy lifting and having the rest support them. Second, this will also reduce the number of people who need to coordinate with each other. If each team functions under the decision-making of one mind, then you only need to worry about errors of poor coordination between team leaders, rather than between all of the programmers on the staff.

(Shortform note: In the 1960s, major computer companies like IBM often promoted skilled programmers into management, where they no longer programmed. (Brooks himself began his career as a programmer before moving into management.) This was likely based on the idea that management was a “higher” position, and therefore appropriate to a company’s best employees, though these promotions often took workers away from the tasks they did best. Since then, the strategy Brooks advocates has become widely adopted. In later editions of The Mythical Man-Month, Brooks praises 1980s tech startup culture for creating roles focused on programming for their most skilled programmers.)

Strategy #2: Coordinate Understanding Through Documentation

In addition to debunking the man-month and reducing the need for communication, Brooks argues that you can better coordinate your employees’ work by creating standardized instruction manuals. If every programmer on the team can consult a manual with precise, agreed-upon definitions and protocols, you reduce the risk of programmers diverging. This also creates an easier way to settle disputes between employees about protocols, as they will be able to find clear answers to their questions of procedure.

Brooks advised managers at IBM to create a written record of all their managerial decisions, large and small. These decisions could then be copied into manuals and become protocols to inform future decision-making across the company. While some considered his manuals excessive, Brooks emphasized they weren’t intended to be read cover to cover. Rather, he advised employees to treat manuals like an encyclopedia or a dictionary—a reference to be consulted as needed.

How Brooks’s Thinking Changed With New Technology

Later in life, Brooks changed his mind about the need for everyone in the company to have an encyclopedic instruction manual. He revised his thinking after the widespread adoption of high-level programming languages.

A high-level programming language is designed to be user-friendly to programmers and bundles combinations of instructions into simple commands. For example, let’s say a programmer wants to find the largest value in a data set. A modern programmer using Python doesn’t have to know the math their computer does behind the scenes—they simply have to remember the command: “max().” The set of instructions to carry out that function have been pre-programmed into the coding language.

However, in the 1960s, IBM programmers were working with a low-level coding language, designed to meet the needs of the machine rather than those of the programmer. These languages typically lack easy-to-remember commands and require programmers to write one instruction at a time, rather than bundling sets of instructions. To find the largest value in a data set, a programmer not only needs to understand the math required to do so, but they also need to tell the computer how to do it one step at a time.

Besides making things easier, high-level programming languages also create standardization. Every programmer using Python’s “max()” command will call up a function with the same set of instructions as every other programmer. Brooks’s programmers, writing their instructions one at a time, could all come up with slightly different functions, which is why they relied on granular instruction manuals to standardize their work.

The Man-Month Myth & How to Manage Large Teams