Looking for an overview of Fred Brooks’ Mythical Man-Month book? What are the book’s key takeaways?
In The Mythical Man-Month, Frederick P. Brooks offers a guide to managing large teams and completing complicated projects. The book covers strategies for streamlining your process so that you can keep your staff working together smoothly and finish your most daunting projects on time.
Keep reading for a brief overview of Fred Brooks’ Mythical Man-Month book.
The Mythical Man-Month by Fred Brooks
Fred Brooks’ 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 errors that came with it, caused his projects to fall behind schedule and go over budget as his team members were forced to fix error after error. In response, he developed a variety of strategies for reducing complexity while coordinating large teams, keeping lengthy projects on schedule, and managing the errors that inevitably occur in detail-oriented work.
Published in 1975, The Mythical Man-Month was originally a guide for Fred Brooks’ fellow managers in the computer industry. However, it quickly became a business classic as managers found it useful in a wide range of industries.
The Problem of Complexity
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’ ideas. Linear growth occurs when each value in a sequence has an equal difference between them. However, exponential growth occurs when each value has an equal ratio. For example, the sequence “3, 6, 9” is linear because each value has an equal difference of three. Whereas the sequence “3, 9, 27” is exponential because each value has an equal ratio of being three times the previous value. Therefore, if complexity has an exponential relationship to errors, each new component or worker introduced has the power to significantly multiply errors and time spent testing and repairing.)
|Reducing Human Error|
Fred Brooks’ core strategy for reducing errors in The Mythical Man-Month is to simplify your processes. However, you may not always be in a position to change your company’s entire process. Those decisions might be out of your purview, or you may have to work within other logistical constraints. In that case, you might try these three smaller, targeted strategies for reducing errors in complex, detail-oriented tasks:
1. Identify where in the process errors are most likely to occur. Audit your mistakes and try to spot the pattern. If you know where most errors happen, you can implement a better system for prevention.
2. Automate error-prone processes when possible. Often, human errors are introduced during rote tasks like data entry that can be handled by software instead. Automating these tasks can eliminate the possibility of human error.
3. Create checklists. With checklists, your workers no longer need to rely on their own fallible memories for every single detail of a process. Checklists are used in detail-oriented work across industries from engineering to medicine.
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: In The Mythical Man-Month, Fred Brooks’ 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’ 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.)
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.
Plan to Throw Out the First Draft
In the last section of Fred Brooks’ The Mythical Man-Month, he 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 Mythical Man-Month, Fred 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 Parnas. Parnas introduced Brooks to a new process in which one “grew” the program from the middle out.
The process required drawing a distinction between a program’s core functions and its ancillary functions. Core functions are foundational to a program’s operations, whereas ancillary functions are the added features built on that foundation. If you imagine your computer program as a tree, the core functions are like the roots and the trunk, whereas the ancillary functions are like the branches and leaves.
In Parnas’s strategy, the core functions would be programmed first and tested independently before moving on to the program’s ancillary functions—like growing the trunk before the branches. In Brooks’ previous process, the first draft would be a complete tree: branches, leaves, and trunk. Parnas’s process reduced complexity by reducing the number of components that need to work together in the first draft. Once Brooks adopted this strategy, he no longer found it necessary to throw out the entire first draft.