All articles
Engineering Leadership2 min read

33. Adding People To A Late Project Makes It Later…

Brooks's Law says adding manpower to a late project makes it later. True—unless the people you add already share standards and know how to work together.

Delft blue tile reading "Adding People To A Late Project Makes It Later… Unless The People Already Know How To Work Together" — Developers Tiles of Wisdom

Unless The People Already Know How To Work Together.

One of the most famous quotes in software development comes from Fred Brooks:

"Adding manpower to a late software project makes it later." And honestly? In most cases, he was absolutely right.

When a project starts slipping, the instinct is often: "Let's add more developers." 🚀

But adding developers also adds:

  • onboarding time
  • communication overhead
  • more pull requests
  • more meetings
  • more opinions
  • more inconsistency
  • more chances for mistakes

A team of 5 developers does not communicate like a team of 10. The complexity grows fast

I've seen projects slow down dramatically because new developers were added too late, without proper guidance, standards or structure.

But…

I've also experienced situations where adding people actually saved the project.

Several years ago, when I was working as Global Frontend Director at MediaMonks, deadlines were extremely important. Missing a deadline was basically not an option ⏳

That was not always easy, especially when projects turned out to be much larger or more complex than initially estimated.

At the time, our Frontend department consisted of around 140 developers spread across multiple countries, time zones and cultures 🌍

Under normal circumstances, scaling a team that quickly should have created chaos.

But because everyone worked according to the same:

  • coding standards
  • communication standards
  • architectural principles
  • review processes
  • quality expectations

…we were actually able to efficiently add developers to projects and still hit difficult deadlines — without sacrificing quality ✅

That experience taught me something important:

Adding random people to a late project usually makes it later. Adding people who already know how to collaborate can completely change the outcome.

And that is one of the main reasons why I started Glaciavis.

Not to provide "extra hands".

But to provide experienced developers who already know how to work together, follow clear standards, communicate efficiently and integrate into projects without creating unnecessary overhead.

Because scaling development is not really about adding more people.

It is about adding the right people. 🎯

Have you ever seen a project speed up after adding developers? Or did it create even more chaos? 👀

Related articles