Brooks’s Law and Startups

Why Adding More People to Your Startup Project Could Be a Costly Mistake (And How to Avoid It)

Patrick Karsh
4 min readSep 18, 2024

When it comes to startups, time is often the most critical resource. Founders and teams are constantly working against the clock to release new features, gain traction, and beat competitors. But what happens when a project starts running behind schedule? The instinct might be to throw more people at the problem, hoping that more hands will speed up the work.

We are all contributing to our burn rate

However, Brooks’s Law suggests that doing this may actually have the opposite effect.

What is Brooks’s Law?

Brooks’s Law comes from Fred Brooks, author of the 1975 classic The Mythical Man-Month. The core idea behind the law is:

“Adding manpower to a late software project makes it later.”

The reasoning is simple: bringing new people onto a project doesn’t just add more labor — it also introduces complexities. New hires need to be brought up to speed, communication overhead increases, and the original team may have to slow down to train or integrate the newcomers. All of this means that adding people often leads to diminishing returns and may even delay the project further.

Why Brooks’s Law is Especially Relevant for Startups

In the world of startups, where teams are lean and time is of the essence, Brooks’s Law can be a cautionary tale. Here’s why it matters so much:

1. High Communication Overhead

Startups typically have small, tight-knit teams. These teams are used to working together and can communicate quickly and efficiently. As more people are added, communication overhead skyrockets. Startups, which thrive on agility, can get bogged down by the need to keep everyone in the loop. As more members are added, meetings increase, more tools are needed to coordinate efforts, and things move slower, not faster.

2. Complex Onboarding Processes

In startups, it’s common for every team member to wear multiple hats. New hires require significant onboarding to understand not only their tasks but also how to navigate the startup’s unique culture and operational chaos. In a time-sensitive environment, training new people becomes a distraction for the existing team, pulling them away from critical tasks.

3. Evolving Goals and Shifting Priorities

Unlike large corporations, startups often operate with evolving goals. What was a priority last month may no longer matter today. When a startup team is working closely together, they can pivot quickly. But adding new people introduces friction. New hires aren’t as familiar with the project’s shifting landscape and may have to rework what they’ve already done when priorities inevitably change.

4. The Myth of Effort Scaling

One of the key misunderstandings of Brooks’s Law is the belief that effort scales linearly with the number of people. For example, if it takes one person 10 days to finish a task, it doesn’t mean that 10 people can do it in one day. More likely, those 10 people will step on each other’s toes, introduce inconsistencies, and require extra coordination time.

In startups, this is even more apparent because tasks aren’t always well-defined. In larger companies, there might be enough structure to benefit from more resources, but in a startup environment, things are often fluid. New hires might spend more time trying to figure out what needs to be done than actually doing the work.

How Startups Can Avoid Brooks’s Law Pitfalls

So, if adding more people to a project won’t speed things up, what should startups do when deadlines loom? Here are a few strategies to navigate the challenges of scaling without falling into the Brooks’s Law trap:

1. Focus on Better Tools and Automation

Rather than adding more people to a late project, invest in tools and automation to streamline repetitive tasks. Automating deployment, testing, and reporting can free up your team to focus on the unique challenges that require human creativity and problem-solving.

2. Hire Specialists at the Right Time

Startups often make the mistake of hiring generalists who can do a bit of everything. While this is great early on, when projects get more complex, it can pay off to hire specialists who can solve specific problems efficiently. The key is timing — adding a specialist too early can slow things down due to onboarding challenges, but bringing them in at the right moment can help overcome bottlenecks.

3. Rescope the Project

Sometimes, the solution isn’t to add more people but to reduce the scope of the project. Reassess which features or deliverables are essential and focus on those. A leaner project can often be delivered faster by a small team than a bloated one with a larger team.

4. Maintain Agile Processes

Agile methodologies, with their emphasis on short iterations and frequent reassessment of progress, help reduce the risk of Brooks’s Law. Agile encourages smaller, cross-functional teams that work closely together, which mitigates communication overhead and allows the team to remain nimble in the face of changing requirements.

5. Nurture Strong Team Dynamics

A small, well-functioning team can often outperform a larger, less cohesive one. In a startup, fostering strong team relationships and clear communication channels can go a long way in preventing the need to bring in additional people.

Conclusion: The Power of Small Teams

In startups, bigger isn’t always better. Brooks’s Law is a valuable reminder that scaling up your team doesn’t automatically translate into faster delivery or greater success. Small teams can stay agile, reduce communication overhead, and adapt to shifting priorities more effectively than larger, more cumbersome teams.

Before adding more people to an already delayed project, consider whether the real bottleneck is people or process. More often than not, a well-oiled, tightly-knit team will deliver faster and better results than a larger, more scattered group.

--

--

Patrick Karsh
Patrick Karsh

Written by Patrick Karsh

NYC-based Ruby on Rails and Javascript Engineer leveraging AI to explore Engineering. https://linktr.ee/patrickkarsh

No responses yet