PDF Summary:The Mythical Man-Month, by Frederick Brooks

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.

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.

Our guide explores Brooks's strategies while updating them with comparisons to today’s management advice. We also discuss how his thinking has evolved alongside the rapidly changing computer industry. Along the way, you'll learn why it's so hard to make accurate scheduling estimates, how adding more staff to a late project can make it even later, and how to manage the inevitable errors that arise from managing teams performing complex tasks.

(continued)...

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?

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.

• As we’ve discussed, 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 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 book, 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 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.

Part 3: Managing Time

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.

Why Managers Create Inaccurate Estimates

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.

Reason #1: Desire to Please the Client

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 be honest with their clients, and estimate projects with integrity. As a manager, you need to stick to your professional opinion, even when it disappoints a client. Second, he argues companies should publicly release data on their productivity—including things like past project completion times. This will give clients an accurate understanding of project times and therefore, they will make fewer unrealistic demands. This, in turn, will lower managers’ temptation to make unrealistic promises.

(Shortform note: While overpromising to please a client may offer short-term gains, studies show this can lead to disappointment, conflict, and loss of long-term gains. Research on customer conflict with companies shows that companies that promise more than they can deliver face greater backlash and have to spend more time managing conflicts with customers than companies that make realistic promises. Furthermore, companies that foster personalized relationships with their customers face even greater backlash than those that keep things strictly business, as this increases customer expectations, heightening their sense of betrayal in response to broken promises.)

Reason #2: Underestimating the Time to Repair Errors

Brooks argues that managers often make poor scheduling estimates because they are too optimistic. He considers computer programmers to be particularly optimistic by nature—as he notes, people drawn to the cutting edge of technology often like imagining a better future. This optimism often leads them to underestimate the time they will spend testing, repairing, and correcting errors.

Brooks advises programmers to take a more realistic view and plan for errors. He offers his own estimates as a guideline for allotting time to each stage of the process.

• 1/3 for designing
• 1/6 for programming
• 1/4 for testing and repairing components individually
• 1/4 for testing and repairing the system as a whole

Notice that testing and repairing take up half the schedule, while programming itself takes up the least amount of time.

The Planning Fallacy

Brooks's scheduling advice focuses heavily on the field of software development. However, the problem of underestimating project times is much more widespread. In fact, this tendency afflicts so many people that psychologists have given it a name: "the planning fallacy." Some believe this is a self-serving tendency in which we overestimate our productivity to maintain a favorable self-impression. Others attribute it to wishful thinking: You want to accomplish something quickly, so you imagine you will. Psychologists have found three proven strategies for overcoming the planning fallacy:

1. Take the outside view. One of the most useful tools in creating accurate estimates is knowing how long others spent on similar tasks, or how long these tasks have taken in the past. This will ground how much time you imagine it will take for you.

2. Break up your goal into smaller tasks. You may underestimate how long your project will take because you simply haven't considered all the required steps. Breaking down your project into smaller goals can lead to more accurate estimates.

3. Take a more pessimistic view. By expecting things to go wrong, you may be able to counterbalance your optimistic underestimation. Try brainstorming a list of problems that will delay your project, and make these delays part of your estimate.

The Consequences of Poor Scheduling Estimates

Brooks identifies three ways poorly estimated schedules can hinder your project:

1. Inaccurate scheduling ensures your project comes in late.

(Shortform note: While Brooks doesn't explicitly spell this out, finishing a project behind deadline damages your company's relationships with your clients. If they were counting on your project by a certain deadline, delay interrupts their operations too, guaranteeing strain on your relationship.)

2. Missed deadlines demoralize your employees, who feel like they're failing even when they're working productively.

(Shortform note: Business experts note that chronically missing deadlines can also lower productivity by leaving your employees with the impression that their deadlines don't actually matter. As a result, even if you start creating realistic deadlines, they might not be motivated to hit them.)

3. Inaccurate schedules lower efficiency. Because many projects require your teams to complete steps sequentially, inaccurate scheduling can create bottlenecks in your workflow.

(Shortform note: Project management experts shed further light on how inaccurate scheduling creates bottlenecks. A bottleneck results when input exceeds capacity. In other words, tasks are assigned to a worker, team, or machine at a faster rate than they can be completed. This is where inaccurate scheduling comes in. If you underestimate the amount of time a step will take, then you will overestimate the amount of work you can send to your worker, team, or machine—leading to the imbalance of capacity and input that produces bottlenecks.)

How to Stick to Your Estimates

Even the best schedule is no guarantee of timely project completion. In this section, we'll explore Brooks's insights on the factors that delay projects and his strategies for keeping a project on track.

Why Projects Fall Behind

Before we can understand how to keep projects moving on schedule, we first need to understand why they fall behind in the first place. Brooks found that projects typically fall behind schedule because of accumulated small delays rather than unexpected crises or catastrophes. In a major crisis, most employees will recognize the gravity of the situation and increase their efforts accordingly. However, smaller delays are often overlooked and allowed to accumulate unaddressed.

This problem is compounded because lower managers often underreport small delays. Brooks suggests that this doesn't necessarily mean you have deceptive lower managers. They may see themselves as taking responsibility to handle the problem themselves instead of bothering supervisors with minor details. Nonetheless, this results in higher managers not knowing when a project is starting to fall behind schedule.

The Three Stages of Potential Delays

In his discussion of projects falling behind schedule, Brooks primarily focuses on delays in perceiving information: You don't know that a project is falling behind, because you haven't noticed all the small delays adding up. However, In Thinking in Systems, Donella H. Meadows explains this is only one stage of the process where delays can slow down a project. Managers also have to consider delays in reacting to information, and delays in the consequences of those reactions.

To use Brooks's example, let’s say a manager finally takes stock of the team's progress and realizes they've fallen behind. Now they must decide when to react: Do they immediately try to address the problem, or do they sit on it and hope the team catches up? This is an opportunity to cause a delay in reaction.

Once the manager reacts by implementing a new efficiency solution, how will they know when it is working? The results may take time to come into effect. This is Meadows's third delay: a delay in the consequences of the reaction. She argues that these delays are especially challenging because they force a manager to make decisions with incomplete information.

How to Avoid Delays

Brooks offers two pieces of advice for cutting back on small delays:

1. Set measurable, binary benchmarks. You can track progress much more accurately by setting measurable, binary benchmarks. A measurable benchmark is one whose progress you can easily track and quantify. A binary benchmark is a benchmark that has only two states: complete or incomplete. The opposite of a measurable, binary benchmark is one that is open to interpretation as to whether it has been reached. For example, if you're building a house and your benchmark is that "most of the roof" will be done by Tuesday, "most of the roof" could mean a lot of things. Conversely, the benchmark of, “nail in 250 shingles by 5 p.m.” isn’t open to interpretation—it’s either met or it's not.

The Difference Between Outcome Goals and Process Goals

Brooks highlights the importance of using measurable and binary benchmarks to assess your progress toward a goal. However, he doesn't cover what kind of goal best lends itself to success. Scheduling experts argue you can track progress even more clearly by distinguishing between outcome-oriented goals and process-oriented goals. Outcome goals are focused on what you want to achieve, or the end result. Meanwhile, process goals are focused on how you will achieve it—the individual steps along the way.

Scheduling experts advise that process goals are often more achievable and realistic. This is because you have more control over a process than you do over its outcome. For example, if your goal is to fix all the errors in a software program by Thursday, this may be unreachable because you don't know how many errors are left in a program. On the other hand, if your goal is to fix five errors a day until they're all eliminated, this is within your control, and will therefore provide a clearer measurement of actual progress.

2. Track the completion of all these specific benchmarks. The more aware you are of small delays, the more you can prevent them from accumulating unnoticed. Once you have measurable, binary goals, record when each is completed. Brooks had an entire team whose job was to record when each goal was met.

(Shortform note: Detailed progress tracking may feel overbearing or invasive to some of your employees. However, it doesn't have to be, so long as you focus on small achievements alongside the small delays. Some management experts argue that recognizing and celebrating small wins will even boost employee morale and productivity. Because larger achievements are rare, focusing on small achievements can sustain the everyday motivation employees need to keep your project on track.)

Brooks’s Law: 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.

Reason #1: New Workers Add New Complexity and Opportunities for Poor Coordination

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.)

Reason #2: Programming Often Requires Sequential Steps

Sometimes, you can't move from one stage of the project to another without completing an important step. If you’re stuck on one step, you may be tempted to add more workers to the subsequent steps to speed up the process moving forward. This will simply reduce your efficiency because they won't have anything to do until that previous step is complete. For example, if you're building a house and waiting for the cement foundation to dry, you can't speed up the process by adding more roofers. They will all just stand around costing money without anything to contribute.

(Shortform note: Project management experts distinguish between sequential and parallel workflows. In a sequential workflow, each step is completed before moving on to the next. Whereas in a parallel workflow, certain steps are completed simultaneously to cut down on work time. For example, let's say you are making a stir fry. Working sequentially, you would chop every ingredient before you began cooking. In a parallel workflow, you would identify the ingredients that had the longest cooking times, chop those first, and then let them cook while you chopped the rest of the ingredients, saving you time. However, parallel workflows often require more planning and management, and only work on certain projects.)

How Ironclad Is Brooks's Law?

Since the publication of The Mythical Man-Month, several researchers have put Brooks's law to the test. Brooks himself reviews this research in one of the later editions of the book. While the rule holds up in general, researchers have found two mitigating circumstances.

1. Adding more workers to a project doesn't necessarily make it later if they are added very early in the process. This will give them more time to onboard and acclimate to the project.

2. Adding more workers to a late project doesn't make it as late if the workers are team players: people who naturally accommodate others and find ways of contributing, but are very open to taking instruction and changing course as directed.

That said, Brooks stands by his law as a rule of thumb. He argues that many managers still make the mistake of thoughtlessly throwing extra staff at a late project to speed it up, and that his law cautions them against this tactic.

Part 4: Managing Errors

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.

Recommendation #1: Plan to Throw Out the First Draft

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 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's 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.

Recommendation #2: Expect to Create Additional Errors

One of the most vexing parts of software development is that repairing errors comes with the risk of adding new errors, because fixing code requires changing it. Once you change something, you always run the risk that it won't coordinate as well with all the other components. Brooks offers two main takeaways.

1. You will reach a point where repairing and debugging provides diminishing returns. There's no value in polishing a program to perfection forever because your project can never be perfect. Plan on cutting your losses eventually and deciding when the project is good enough.

2. Programs that are patched after they hit the market will slowly degrade. As the programmers publish new patches—repairs introduced after the software has already been published—they will continue introducing new errors. Brooks asserts that patched software naturally disintegrates because every patch runs the risk of making it worse. Therefore, he advises you to plan on eventually replacing your software instead of fixing it forever.

What Is The Law of Diminishing Returns?

Managers in all disciplines must think about the law of diminishing returns in deciding on the optimal time and effort to invest into repairing errors. Economists provide clarity about the law of diminishing returns: a microeconomic principle that states that there is an optimal threshold of investment, beyond which you start getting less and less out of your investment.

For example, let's say a farmer living in an arid climate installs a new irrigation system to water their crops. Because the plants had been living under such dry conditions before, this irrigation system leads to enormous yields the first year. So the next year, the farmer installs a second irrigation system hoping to repeat the results. Instead, the crop yield stays the same. Because their first irrigation system hit the optimal threshold of water for their field, adding more water now results in diminishing returns.

Applying this logic to Brooks's theories of programming, we see that there is an optimal threshold of time and effort to invest in debugging. Continuing to repair errors will keep introducing additional errors, and once the optimal threshold is passed, additional repair will no longer improve the product. Similarly, there is an optimal threshold for patching and updating software after it has reached the market. Beyond that threshold, your time and effort will be better spent simply designing the next version of the software.

Recommendation #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.