Back in 1975, when Microsoft was born and the VCR was developed a Duke- and Harvard-trained computer architect/software engineer named Fred Brooks wrote a book titled, The Mythical Man-Month. In it, Brooks shares his experience as a project manager for the IBM System/360 computer family. Specifically, he touches on the human elements of software engineering during the milestone development of compatible peripheral products.
The book stemmed from a question by IBM’s former CEO who asked Brooks why it’s harder to manage software projects than hardware projects. Brooks said, “Adding manpower to a late software project makes it later.” Through his observations as a project manager, Brooks saw that each additional person who is added to a software project in its final phase, in hopes of accelerating it, may actually delay it instead.
When we think in terms of a website development team, for example, it’s typically comprised of tasks that are not really partionable like, say, picking fruit. Adding five people to that task can yield 5x the quantity because each person can work independently; it’s more or less partionable. Software development, however, is not. Sequential constraints and communication with people within and outside of the development circle are necessary for the project to progress. You have a project manager, designer, solutions architect, developer(s), and QA specialist. Unless the requirements of the project expand drastically, adding more members to this core team likely won’t move it out the door faster. Not because the people who are added aren’t competent (presumably), but because of the nature of the non-partionable beast coupled with admin and communication overhead.
Given that the core team is experienced and its workload is managed well, it should be clear how many people need to work on each task and for how long. When it’s discovered that the project is late, a natural inclination is to add more people whether it be a realistic expectation or simply for CYA optics. But, tasks can only be broken down so far, so at some point those additional people won’t be contributing fully and more time will be spent on dynamic communication within the group, to management, and to the client. If only so many people can do the job, the inevitability of diminishing returns looms: It’s all good until it isn’t. The added admin tasks that are necessary with a larger group take away from the core work that needs to be done. Getting new team members up to speed, answering questions, negotiating alternate solutions brought on by new perspectives, and managing schedules can easily slow down a job.
Lines of communication, in particular, have been a focus of those who dig a bit deeper into Brooks’ Law. The concepts of vertical vs. horizontal communication, number of employees, and types of communication (verbal vs. written) are intriguing as they relate to how each affects software projects. A visit to Lighthouse, a leadership and management blog, really needs no explanation as it shows just how complex communication gets as your teams and organization grow. The illustrations clearly demonstrate how the lines of communication increase in relation to the number of employees, or in this case, team members. It’s easy to understand how overwhelming communication overhead can be and how it can burn hours. This isn’t to say that good communication isn’t important, it’s essential. But if you’re adding team members for the wrong reasons, then you’re wasting time and money and delivering projects late; not a solid management mantra.
The moral of the story? If, as a manager, your instinct is to add team members to a project in order to salvage a deadline, then you need to stop and listen. Talk to the team leader and even the whole team to determine what the problems are and how they can be solved. If adding employees and/or contractors is well-advised, then go for it. If not, then find another viable solution, otherwise you probably won’t meet that deadline anyway: It’s Brooks’ Law.