It’s fifty years since Fred Brooks wrote his famous warning: “adding people to a late software project makes it later.” Tools have changed, but human coordination and onboarding still take time. The lesson holds.

Fred Brooks was inducted into On a Back of an Envelope’s Hall of Fame where there is a short biography and an assessment of his wider influence.

In 1975, computer scientist Fred Brooks published The Mythical Man-Month, a book based on his experiences managing IBM’s large System/360 programme. Managers often assumed that if a project was behind schedule, they could add more people and speed it up. Brooks showed why that usually fails.

New team members take time to learn the ropes. Existing staff must pause to train them. And as the team grows, everyone spends more time just keeping in touch. Productivity can dip before it rises, and deadlines slip further.

Brooks revisited the ideas in 1995 and stood by his conclusion. The technology changed; the human dynamics didn’t. Half a century from his original book, despite agile methods, cloud platforms, and AI Copilots. Brooks’ warning still describes what project managers see every day

Why it still matters today

• More people = more conversations. Every extra person means extra meetings, messages, and coordination.
• Onboarding takes time. Even skilled newcomers need help to understand context, tools, and norms.
• Complex work has limits. Big, interconnected projects aren’t easy to divide cleanly.
• Remote and global teams add friction. Time zones and handovers slow feedback loops.
• Budget lines don’t equal progress. Headcount does not automatically translate to progress.
• No single tool or method will ever make software development magically easy a theme he expanded on a year later in ‘No Silver Bullet’. This is also true for project management.

What to do instead

• Trim the scope. Deliver a smaller version that still provides value.

• Fix the bottleneck. Tackle the slowest or most blocked part first.

• Finish what’s started. Focus the team on completing current tasks before adding new ones.

• Make responsibilities clear. Define who owns which parts to avoid overlaps.

• Automate the routine. Remove repetitive checks and handoffs where you can.

• Add people carefully. Start with a small, experienced group and give them a clear area to own.

• Value mentoring. Treat training as planned work, not something squeezed in.

• Review progress honestly. Make obstacles visible so they can be fixed quickly. A project rarely misses by a year all at once. It drifts there in small steps. That’s why frequent review and decisive action matter. Spot the slip early; fix the cause now—not later.

Question: How does a large software project get to be one year late? Answer: One day at a time!

When adding people can help

• Independent, well-documented workstreams where tasks don’t collide.

• Testing, data labelling, or migration steps that can be run in parallel safely.

• Backlogs, where the real constraint is slow human review and where it can be distributed cleanly.

Takeaway

Before you add people, change the work: simplify scope, clarify ownership and remove friction. Then, if you still need more hands, add them carefully and plan for the onboarding dip.

Further reading

• Fred P. Brooks Jr., The Mythical Man‑Month (1975; Anniversary Edition 1995).
• Fred P. Brooks Jr., “No Silver Bullet—Essence and Accident in Software Engineering” (1986/1987).