The Mythical Man-Month offers guidance to managers leading large teams, especially teams coordinating detail-oriented projects with lots of moving parts. Its advice centers on reducing complexity—the number of people and components that need to work in coordination. By reducing complexity, you can make complicated projects much more manageable.
Frederick P. Brooks led the division of IBM that programmed computer operating systems in the 1960s. He managed over 100 employees to create cutting-edge programs that required an intense degree of coordination: If all the parts didn't work together correctly, his operating system wouldn't work. Brooks found that the more parts he needed to coordinate with each other, the more opportunities there were for errors.
High complexity, and the...
Unlock the full book summary of The Mythical Man-Month by signing up for Shortform .
Shortform summaries help you learn 10x faster by:
READ FULL SUMMARY OF THE MYTHICAL MAN-MONTH
Here's a preview of the rest of Shortform's The Mythical Man-Month summary:
When managing his team to create operating systems, Brooks found his main obstacle was complexity—the number of people and components that need to coordinate with each other for the program to work. Because each interaction between components creates an opportunity for poor coordination, the more complex a program becomes, the more errors it likely will have.
Brooks also found that the relationship between complexity and errors is exponential rather than linear. In other words, with each new person or component, you're not just adding the potential for error: You're multiplying it. Therefore, the more complex a project becomes, the more time it takes to test and repair all its errors. Once Brooks realized that his teams spent most of their time repairing errors, he set out to simplify his processes, teams, and program designs to prevent sinking vast amounts of effort into testing and repair.
(Shortform note: Understanding the [difference between exponential and linear growth can clarify Brooks's...
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...
This is the best summary of How to Win Friends and Influence PeopleI've ever read. I learned all the main points in just 20 minutes.
Now that we've discussed tactics for reducing excess communication, we'll turn our attention to one of Brooks’s most daunting challenges in overseeing complex projects: completing them on schedule. Even with teams optimized to reduce miscommunication, any long-term project can fall behind schedule. In this section, we'll discuss Brooks’s insights on why managers often create inaccurate time estimates for their projects, factors that throw projects off schedule, and how to keep projects on track.
Sometimes projects go off schedule because the schedule itself is a poor estimate of how long they will take. Brooks identifies two reasons why managers create inaccurate estimates.
When clients ask for a specific deadline, managers may be tempted to fit timing estimates to their clients' goals instead of their team's capacities. Managers may be even more tempted to overpromise when they're pressured by a competitor promising an even faster time—whether the competitor can meet those promises or not.
Brooks offers two solutions to the temptation of overpromising. First, managers must...
No matter how carefully you plan your project, errors and problems inevitably arise. Regardless of the industry, large projects typically involve a lot of testing, repairing, and perfecting. This last section will explore Brooks's advice on planning for and managing errors to bring your project to completion.
Brooks argues that you should expect to discard your first attempt at your project and treat it as a learning opportunity. He cautions against sinking time and effort into fixing your first draft at all. In his experience at IBM, there were so many errors in the first attempt, that it was more efficient to simply learn from the process, cut his losses, and begin fresh again. Therefore, Brooks advises you to treat your first draft of the entire project as a trial run.
Reducing Complexity in the First Draft
In later editions of the book, Brooks changed his mind about throwing out the first draft after discovering a new process that made this unnecessary. After leaving IBM, Brooks became a computer science professor, where he was influenced by many of the ideas of his close friend, programmer David...
"I LOVE Shortform as these are the BEST summaries I’ve ever seen...and I’ve looked at lots of similar sites. The 1-page summary and then the longer, complete version are so useful. I read Shortform nearly every day."
Brooks explains that often projects fall behind not because workers are lazy, but because they are poor at creating accurate estimates of work times and keeping themselves on schedule. In this exercise, pick a project and put Brooks's advice into action by creating both a schedule and a strategy for meeting your deadlines.
Pick out a project that you would like to complete. It could be a personal goal or a work project. Once you pick out your project, break it down into steps. Get as detailed as you can. What needs to be done, and in what order, for you to complete this project? Explain your answer.