Brooks’ Law: When Hiring Only Makes Things Worse

That's not a valid work email account. Please enter your work email (e.g. you@yourcompany.com)
Please enter your work email
(e.g. you@yourcompany.com)


Too Much, Too Late, Brook's Law

TOO MUCH, TOO LATE/Image: Michael Moffa

The software company you represent is running behind schedule on completing a project roll-out. They ask you to hire extra staff to help out. Should you tell them it’s a bad idea?

Surprisingly, a software project management principle  called “Brooks’ Law” suggests there is a real chance that you should tell them not to take on additional staff—or, given your own spin on the law, that you should deviously shut up and wait for them to ask you to hire even more staff as the project falls even farther behind.

Brooks’ Law is a software development principle that says that “adding manpower to a late software project makes it later”. Formulated by Fred Phillips Brooks, Jr., the heavyweight software engineer and computer scientist, who managed the development of IBM’s System/360 family of computers and the OS/360 software support package, the principle was enunciated in his 1975 book The Mythical Man-Month.

A so-called “corollary” to Brooks’ Law, the observation that there is an incremental person who, when added to a project, makes it take more, not less time seems to be only a restatement of the familiar economic law of diminishing returns and diminishing marginal utility.  Brooks’ Law itself seems to be stating something more unexpected and insightful than these two second laws, namely, that even adding just one member to a project team will, or at least can, slow things down—which is a proposition that is very different from saying, as the diminishing returns laws do, that as you add more members, eventuallyproductivity, efficiency and time-management gains will decline (if not in fact ultimately begin to be reversed).

His reported quip that “Nine women can’t make a baby in one month” seems to illustrate both Brooks’ Law and the diminishing returns corollary, in that adding just one woman to a pregnancy may at least make it seem agonizingly longer—if that woman is a nagging mother-in-law (Brooks’ Law), while adding servants, midwives and others will be helpful, but only up to the point of diminishing marginal returns and utility, e.g., as the financial cost or household congestion yields smaller dividends (Brooks’ Corollary).

Why Is It True?

Although Brooks himself characterizes his own law as an “outrageous oversimplification”, he cites two prima facie arguments and evidence for it:

  1. Ramp-up time: It takes what Brooks calls “ramp-up time” for the additional project team members to become productive.  This is time for orientation, education, integration and oversight to prevent new-member-created mistakes. Each of these will siphon off and perhaps even conflict with the time-allocations and efforts of current project members and exacerbate existing delays—especially if the delays have already taken a performance toll in the form of time-driven anxiety, pressure to cut corners, etc.
  2. Increased communication overhead: The number of possible different communication channels increases disproportionately as the number of people increases. With two people, there is only one channel or conversation, with three, there are four possible conversations with at least two people; expand that to four members and the number becomes 11, growing exponentially as members are added.

Hence, adding another member to an already large team can potentially impose huge communication costs in terms of provision for additional “conversations” and teamwork.

(Technical note: In general, excluding the case of self-talk, the formula for the number of possible communications channels/conversations among project members is the sum of all [n!/(n-k)!k!] , where n=the total number of members and k=the number of members in a given conversation, given that k>1, i.e., k ranges from 2 to n. This restriction represents disallowing self-talk by each member in virtue of not being in communication with anyone else.)

Brooks’ Law seems more likely to apply with a vengeance to projects that are already running very late—perhaps because the panic factor will cloud judgment about what is needed or will work, rush and stress everyone and compromise the screening process for additional staff. But, suppose the project is only a little late. Under what circumstances, apart from the two Brooks cited and discussed above, could hiring additional staff for a slightly late project only make things worse? There are countless possibilities, but some of the most likely and catastrophic will include hiring someone

  • Who will be perceived as a rival by at least one key staff member, thereby jeopardizing productive collaboration, if not fueling outright sabotage of the new guy and the project
  • Whose hiring is construed as a criticism of the talents, efforts or judgment of the team or of individual members of the team, which would impact morale in negative ways that are unlikely to create the synergy and efficiency sought in the hiring
  • Hired at a pay grade normally achieved through seniority, which would breed resentment
  • Who will undo or redo the work of a permanent team member or members, a development that would create resentment.

Exceptions

However, the pessimism of Brooks’ Law is offset by some conceivable exceptions to it—unlike the inviolable laws of nature. Among the loopholes that have been mentioned or are otherwise worth mentioning in connection with Brooks’ Law are these:

  • Projects that are not really late, especially those with unrealistic or otherwise flawed timetables. Just create a more realistic timetable. It’s like getting out of debt by printing more money, except that in this case the extra “money” (extra time as extra money) is actually going to make things much better, rather than possibly much worse, in the long run.
  • Over-hiring: Add more staff than are needed, it is suggested. This can work if something like a principle of “economies of scale” applies to the “ramping up”—including orientation—of the new staff. For example, if 5 man-hours of team time have to be allocated to bring one new member up to speed, that 5 hours/new member can be reduced to 1 hour/new member, if five new members can attend the same orientation session at the same time.

Of course, this will reduce ramp-up time and communication overhead for the project, but at the risk of cost overruns, if the savings generated by the time, effort and client contracts saved do not offset the salaries and benefits provided the four extra staff.

  • Good project segmentation: The notion here is that if a team is broken up into sub-teams, the addition of a new member will drain fewer time, talent and energy resources from the project, since fewer team members will have to be involved in the ramping-up of a new player whose responsibilities and tasks are compartmentalized and relatively isolated—in terms of inputs, outputs and impact on the “big picture” or project as a whole.

Clearly, if the project and team are well designed and project sub-teams are “well-insulated” from each other, this can work, e.g., hiring an extra auto-body paint inspector at a Ford motor plant. This concept can be extended to the insulation of individual members from each other, such that the addition of a new member minimally incurs ramp-up time and communication overhead, e.g., addition of another seamstress in a garment factory. In this instance, the members of the team, rather than the component teams of the project, are insulated from each other. The implication is that the less integrated and “organic” the project stages and dimensions, the less likely it is that the additional worker will also be working to prove Brooks’ Law.

…Which is a good thing, since that would truly be a “thankless task”.

By Michael Moffa