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.
Looking for practical advice for managing complexity? How can you improve performance for large teams and complex projects?
The Mythical Man-Month by Frederick P. Brooks offers guidance to managers leading large teams, especially teams coordinating detail-oriented projects with lots of moving parts. Its advice centers on managing and reducing complexity.
Read on to learn Brooks’s groundbreaking strategies for managing complexity at IBM in the 1960s.
Managing Complexity at IBM in the 1960s
In The Mythical Man-Month, Frederick P. Brooks offers a guide to managing large teams and completing complicated projects. The book covers strategies for managing complexity so that you can keep your staff working together smoothly and finish your most daunting projects on time.
Brooks led the division of IBM that programmed computer operating systems in the 1960s, when computer programming was far less developed than it is now. He 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.
While much of Brooks’s advice for streamlining projects applies broadly across industries, understanding the specific logistical challenges he sought to overcome at IBM in the 1960s will ground our understanding of his strategies. He notes three challenges in particular: coordination between IBM components, limited feedback and testing resources, and coordination between programmers.
Challenge #1: High Level of Coordination With Other IBM Components
Brooks’s operating systems needed to work perfectly in tandem with multiple pieces of software and hardware. This is because an operating system manages a computer’s memory and works as a “go-between” with the computer’s hardware and software. Therefore, Brooks also had to coordinate his efforts with the teams that made IBM’s hardware and software.
Challenge #2: Limited Feedback and Testing Resources
Brooks explains that, because computers were rare and expensive, his programmers weren’t able to work on their own individual computers. Therefore, all of their code was written by hand and tested on just a few computers—a tedious process that often created significant testing backlogs. This made testing much more time-consuming and errors more difficult to catch. Working without immediate feedback, programmers would have no way of knowing if they had made an error earlier in the process that could compromise their subsequent work.
Challenge #3: High Need for Coordination Between Programmers
Standardization is crucial in software development because all the parts must work together seamlessly for the program to run. This created a challenge at IBM when working in large teams, because each programmer was working independently on their own software components.
This challenge was further compounded by the fact that, in the 1960s, computer companies custom-made all of their hardware and software in-house. This meant that they couldn’t rely on standardized coding languages to streamline the process. Instead, they relied on detailed company instruction manuals for each component, as well as managers tightly coordinating programmers’ efforts to ensure that all the components from all the programmers would fit together.
The Difference Between Fundamental and Incidental Complexity
While technological advances have eliminated many of the specific logistical problems Brooks faced, he warns that the problem of complexity can never be completely solved. To understand why, we first need to explore Brooks’s distinction between two types of complexity: fundamental and incidental.
- Fundamental complexity: Creating a functioning software program is an inherently complex endeavor. No matter how advanced technology becomes, Brooks argues that creating an elegant, high-functioning program will always require a high level of conceptual thinking and coordination.
- Incidental complexity: Incidental complexity is caused by the logistical challenges of translating your programming concept into an actual program. This could include limitations in memory, challenges in coordinating with other programs, or limited functions in the programming language.
Brooks argues that advances in technology are able to resolve incidental complexity, but they are unable to resolve fundamental complexity. Creating software still requires high-level conceptual thinking and coordination.
(Shortform note: History has partially borne out Brooks’s assertion that technological advances can solve incidental complexity but not fundamental complexity. Over the years, as many of the logistical hurdles of early computer programming have been resolved, programs have become much more complex and still require high-level conceptual thinking to design. Solving incidental complexity has simply allowed us to create fundamentally complex programs at a greater scale. For example, the OS360, Brooks’s signature operating system, used only 400kb of memory, roughly one-tenth the size of an average 4mb song on iTunes. In comparison, the largest storage drive for managing big data is currently 100tb, about 250 million times larger.)
No Single Solution to the Problem of Complexity
Brooks argues that, while complexity cannot be completely solved, project complexity can be managed and reduced. The rest of our article will focus on Brooks’s strategies for managing and reducing complexity in your projects.
Technique #1: Specialize Roles
To manage complex teams, 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: Don’t Add More Employees to a Late Project
Brooks argues that once a project becomes late, it’s a mistake to add more employees in the hopes of speeding it up. Many managers are tempted by this pitfall, hoping that extra labor will speed up the project. Brooks asserts this will only add further delays. In fact, he calls this principle “Brooks’s Law”: Adding more workers to a late project will make it even later. He provides two reasons why.
All of those new employees need to be onboarded and incorporated into the existing workflow, which will add time and effort. Furthermore, the additional employees will add more complexity. Recall that as you increase the number of employees working together, the opportunities for miscommunication increase exponentially. This complexity increases the likelihood of errors, meaning more time spent testing, debugging, and correcting.
(Shortform note: Brooks focuses on how new employees will require training and add complexity to a project. However, adding a significant number of new employees can also slow down a project because your team will have to take time building relationships. Management experts have found that teams do their best work when their members trust and rely on each other. These relationships take time to cultivate. Therefore, a team with a significant number of new workers needs time—and perhaps some intentional team-building—before it functions effectively.)
Technique #3: Don’t Build Something You Can Buy
Brooks’s last piece of advice for overcoming the challenges of managing complex projects is simply not to do it at all. Because of the inherent challenges and complexity involved in certain projects, often you can save your company a lot of time by simply buying something off the shelf instead of producing it yourself. Brooks cautions you to consider what actually needs to be made in-house, and where you can cut time, cost, and labor by making a simple purchase.
| When Should You Outsource? Brooks advises you to avoid complicated projects when they are unnecessary. But how do you know when it’s time to find an outside contractor? Business experts offer four recommendations on when to outsource: 1. Your team is at maximum capacity. If your employees already have too much on their plate, consider approaching them to see what tasks they’d like to delegate elsewhere. 2. Your company lacks certain skills or specializations. It’s a good idea to outsource when you don’t have the staff to deal with a highly specialized problem or task. 3. There’s no advantage to doing it in-house. Consider what competitive advantage you gain by doing something in-house. If it’s hard to come up with one, you might want to outsource. 4. Scaling up too fast. If you’re a small startup growing quickly and find that you can’t keep up with demand, you may want to start delegating. |
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Frederick Brooks's "The Mythical Man-Month" at Shortform.
Here's what you'll find in our full The Mythical Man-Month summary:
- A guide to managing large teams and completing complicated projects
- How to keep your staff working together smoothly
- Strategies for keeping long-term projects on schedule
