When a project at Bilberrry is running late, we try to avoid adding manpower. In fact, one of the first things we consider is pulling people off a project. We don’t feel radical doing it, either. Even though it sounds counterintuitive, we know that “adding manpower to a late software project makes it later.” It’s Brooks’ Law.
In The Mythical Man Month, Fred Brooks explains the myth that “men” and “months” on a project are interchangeable. The myth is this: if it takes one person five months to do a job, then it’d take five people one month to do a job. He found the math only works for jobs that are partionable between workers and require no communication. So, if one person would need five weeks to pick all the apples in an orchard, then, yes, roughly five people could do the job in one week.
Designing and developing websites and software does not work like that. As Brooks put it, “it’s not even approximately true.”
Adding people to a late project can actually make it later
Brooks found three ways that adding more people to a project doesn’t add pure manpower. First, more people on a project means there are more lines of communication. The web of relationships becomes more complex and communication takes more time and effort.
There’s also the work of onboarding the new folks. Brooks’ Law goes into full effect when you toss new team members onto a project and expect the team to figure out how to use them. Everyone was at full throttle to finish the project, and now they’ve got newcomers who need to learn the work, ramp up, and start completing assignments. If you’ve ever thought, “This will be so much faster if I just do it myself,” then you know exactly what we’re talking about.
Brooks’ third explanation was that not every task on a project can be divided between multiple people. Imagine telling a writer you’re going to speed things up by having another writer finish their sentences. Or, that you’ll come help me cook a frozen pizza faster. It’ll take one person just as long to cook a frozen pizza as it would two people. In fact, it’ll probably take longer now that we’d have to talk about who’s going to turn on the oven, who’s going to set the timer.
There’s now also A Fourth Explanation to Brooks’ Law: The Aspect of Group Developmental Psychology. That is, when new people are added to a group, the group development falls back — the team has to re-establish the group norms, its goals, and its roles. This set-back is easy to feel when new people are added to something as simple as a Slack channel. There’s work to be done to teach them how the group operates, or for the group to adjust to operating in a new way that works for all its members, new and old alike.
Still, even among people who know about Brook’s Law, it’s easy to want to throw people on a problem. We’re late? More people! We’re lost? More people! Something’s broken? More people!
We’ve written about the idiom that “No one got fired for choosing IBM” — and that same “safe” move applies here. Adding more people to the team isn’t likely to get anyone in trouble, especially at a large or traditional company. In fact, late in a project, if a manager requests budget to hire temps, or asks to use resources from other projects, they’ll likely get approval.
Why? One theory is that it simply feels productive to do something. The impulse is totally rational, but we try to train ourselves that something can also be pumping the brakes and reassessing.
removing people from a project can save it
We faced this reality before — in fact, very recently. During the active development phase of a complex e-commerce platform, we decided to grow development and start working on additional features. We hoped with more people working in parallel, we’d speed up. While one team was working on the API layer and product data architecture, the other team was trying to build a promotion engine for the platform to generate, deliver, and validate special offers and discounts. As you might have guessed: it turned out to be a disaster.
Since the promotion engine required the API and data layers to be finalized, we were shooting a moving target — and we failed to deliver. The structure also meant our tech leads were focused only on the most critical parts of the platform; other “less important” features didn’t get their attention. Ultimately, we also had to refactor/rebuild some of the functionality.
After two months of hustling, we scaled down the team, discussed priorities, and reshaped our focus to start delivering functionality at a predictable pace with the right attention to quality and long-term maintainability of the code. Less really was more.
Instead of having more people jump in and do, do, do, simplifying the team and task can get it back to the launch timeline. What’s necessary and important? And, who’s essential?
Our POV: Ask, What is the actual constraint?
Once you know that instead of adding manpower, you might be adding complexity — and we’ve written before on the ways complexity can mess things up — it’s a much less compelling choice. Here are some of the questions we ask before re-assigning head count:
- What is the actual constraint? The team might actually need more or less of something else: more structure, more computing power, more leadership, fewer meetings, fewer check-ins, fewer distractions.
- Before we add team members, what else can we do? Even if we choose to add manpower, we don’t have to make that move in a vacuum. We can make other changes at the same time: remove other people from the team, change or reorganize the work, add a new tool or equipment, order more pizzas. There’s a volatility cost for sure, but it’s worth considering.
- Then, how resilient is our team? Some groups absorb change better than others.
- Who are we adding? If the person is familiar with the team already and they’re an amazing talent, the risk is much lower than adding someone who’s brand new to the team, the work, and the project.
- What’s our onboarding process? Finding defined, individual tasks for the new members to do and on-boarding them with context mitigates that negative impact.
- Is the delay worth the trade-off? Delivering a better result might be worth pushing the project out, or it might not. Just as technical debt isn’t always bad, being late isn’t automatically the worst option; it’s simply one route to consider.
