Why Adding Engineers to a Late Project Makes It Later — And What Actually Fixes It
Brooks' Law says adding developers makes late projects later. But the real culprit isn't communication overhead — it's the project context no one thought to document.
7 min read
It's late July. The Q3 deadline is already slipping. Your engineering manager suggests adding a senior developer — someone from another team who has bandwidth. The PM agrees. They start Monday.
Six weeks later, velocity has dropped further. The new engineer is still asking questions the team thought they'd answered. Three senior devs are spending chunks of each day in impromptu Slack threads, walking them through architecture decisions that happened eight months ago. The project is now further behind than it was before you added the headcount.
This isn't bad luck. It has a name: Brooks' Law. And while the observation is 50 years old, the conventional explanation — "more people means more communication paths" — misses the deeper problem. What's actually killing your project isn't the extra meetings. It's the project context that was never written down — and that a new engineer now has to reconstruct from scratch.
- What Brooks Actually Said (and What It Gets Wrong)
- It's a Context Problem, Not a Communication Problem
- The Three Types of Context New Engineers Have to Rebuild
- Why Your Senior Engineers Slow Down Too
- What Actually Fixes It
- A Pre-Hire Context Checklist
- Frequently Asked Questions
What Brooks Actually Said (and What It Gets Wrong)
Fred Brooks introduced his law in The Mythical Man-Month in 1975: "Adding manpower to a late software project makes it later." His reasoning centred on two costs: the ramp-up time for new workers, and the exponentially increasing number of communication paths as team size grows.
Both are real. But for the past five decades, teams have been trying to solve the wrong half of the problem. They optimise for communication: better standups, cleaner tickets, more documentation sprints. The project still slows whenever new people join.
That's because the communication explanation is incomplete. It frames the problem as a volume issue — too many channels, too many people, too many handoffs. The harder problem is about what those conversations are actually about: the institutional knowledge that exists only in the heads of the people who've been on the project since the beginning.
The real onboarding bottleneck isn't the number of people talking. It's the six months of informal decisions, abandoned approaches, and why-we-did-it-this-way context that nobody ever wrote down.
It's a Context Problem, Not a Communication Problem
Think about what a new engineer actually needs to be productive on a live project — not in theory, but in practice:
- Why the database schema is structured the way it is, even though it looks wrong
- Which third-party integration is fragile and needs careful handling
- What approach was tried nine months ago, failed for non-obvious reasons, and shouldn't be tried again
- Why the PM is firm on a constraint that doesn't seem to matter
- Who to actually ask about a given part of the codebase, regardless of what the org chart says
None of this is in the tickets. Most of it isn't in the documentation — if there is any. It exists in Slack threads from last autumn, in meeting notes nobody saved, in the collective memory of the engineers who were there when the original decisions were made.
According to the Cortex 2024 State of Developer Productivity Report, 40% of developers cite difficulty finding critical context as their primary productivity complaint — ranking higher than waiting for approvals, managing tech debt, or any other bottleneck. For engineers who are new to a project, that figure skews significantly higher.
The same report found that 72% of engineering leaders say new hires take more than one month to submit their first three meaningful pull requests. Most of that lag isn't spent learning how to code. It's spent rediscovering context that existing team members have long since internalised — and asking questions that interrupt the people who are supposed to be closing out the project.
The Three Types of Context New Engineers Have to Rebuild
To understand why onboarding takes so long even with good intentions on both sides, it helps to separate project context into three distinct categories. Each one has its own location problem.
1. Technical context
This is the most visible type, but still dramatically underestimated. It includes architectural decisions ("we structured it this way because the previous approach couldn't handle concurrent writes"), known technical debt ("the auth module is fragile — the session handling has a race condition we've deliberately deferred"), and failed experiments ("we tried caching this endpoint and it caused data consistency issues across regions").
None of this ends up in the README. It gets discussed during an incident, resolved in a ticket comment, and then lives permanently in the memory of whoever was oncall that week.
2. Product context
Why does this feature work the way it does? What got deprioritised and why? What specific customer edge case drove that unusual flow that looks like a bug but isn't?
Product decisions get made in planning calls and Slack threads, and the rationale almost never makes it into the ticket. New engineers inherit the output without the reasoning — which means every unexplained oddity triggers either a question or, worse, a refactor that breaks something that was intentionally left that way.
3. Process and social context
Who actually approves changes to this service? Which channel is where real decisions happen, versus which is just noise? Who's the de facto expert on the payment system even though they don't officially own it?
This type of context is entirely undocumented by definition — it's absorbed through weeks of observation, failed attempts, and quiet corrections. It cannot be found in any tool.
A study commissioned by Panopto found that 42% of institutional knowledge is unique to individuals — meaning nearly half of what a team member knows about how to get work done doesn't exist anywhere else in the organisation. When those people are busy, on leave, or have moved on, that knowledge becomes inaccessible — or disappears entirely.
This is closely related to the broader context loss problem that slows teams down even when no one new has joined. Onboarding simply concentrates it into a visible, time-bounded crisis.
Why Your Senior Engineers Slow Down Too
The new engineer isn't the only one absorbing the cost. The people already on the project lose significant time during any onboarding period — and that loss compounds precisely when the project can least afford it.
The Panopto research found that employees lose an average of 5.3 hours per week waiting for a colleague to answer a question or recreating knowledge that already exists somewhere, inaccessibly. On a late project, those 5.3 hours belong to the senior engineers who were supposed to be closing out final tasks.
Research cited in MIT Sloan Management Review shows that new professionals take approximately 20 weeks to reach full productivity, operating at roughly 25% capacity in the first four weeks. That's not slow learning — that's the physics of context transfer. The existing team is absorbing that gap through interrupted focus and repeated explanations, all while trying to ship.
| What you expect when adding a developer | What actually happens |
|---|---|
| Immediate capacity boost | Net productivity drag for 4–6 weeks |
| Senior engineers freed to focus on delivery | Senior engineers pulled into daily knowledge transfer |
| New engineer solving the problem you hired for | New engineer reconstructing months of informal history |
| Tickets moving faster | New hire at ~25% productivity for first four weeks (MIT Sloan) |
This pattern is why coordination overhead spikes whenever teams scale: the existing team shifts from building to teaching, and the new member shifts from contributing to learning. For several weeks, neither group is doing the thing the additional headcount was meant to accelerate.
What Actually Fixes It
The goal isn't to eliminate Brooks' Law — some onboarding drag is unavoidable. The goal is to compress the ramp-up by making context explicit before the new engineer needs it.
Most teams try to solve this with documentation: a wiki, a README, a Confluence space that's out of date the moment it's written. That approach consistently fails because it treats context as something to be written separately from the work — meaning nobody does it, and when they do, it goes stale within months.
The better approach is to capture context where the work already happens.
Log decisions at the point they're made
When a significant technical or product decision happens in Slack, pin it, add a one-line summary to the thread, or link it from the relevant ticket. The decision log doesn't need to be formal. "We chose X over Y because Z — see thread" is worth ten pages of after-the-fact documentation. It's searchable, timestamped, and attached to the work that prompted it.
Treat commit messages as project memory
Commit messages are the most underused form of durable project context. A commit that says "fix bug in auth" is disposable. One that says "fix session race condition — root cause was shared cache between instances; see Slack thread #link for full context" is searchable, attributable, and still readable two years later when someone else hits the same issue.
Do a context tour before day one
Before a new engineer's first day, run a 45-minute recorded walkthrough: here's the architecture, here's the technical debt, here are the three things you'll be tempted to change that are deliberately left as-is. This recording replaces dozens of repeated one-on-one questions and lets senior engineers answer asynchronously rather than on-demand. According to GitLab's 2024 Global DevSecOps Survey, nearly half (44%) of organisations report that developer onboarding takes over two months — in most cases, not because the codebase is complex, but because context transfer is unstructured.
This is also why project trackers consistently fail to reflect reality — they capture what was done, not why it was done or what was decided along the way. Onboarding exposes this gap acutely, but it exists throughout the entire project lifecycle.
A Pre-Hire Context Checklist
Before adding someone to a late project, work through this list. Each item that's missing extends the new engineer's ramp-up — and costs that time from the people already on the team.
- Architecture decision log — Document the three to five most significant technical decisions and why they were made. Doesn't need to be comprehensive; just cover the choices someone would be tempted to revisit.
- Known technical debt map — Which parts of the codebase are fragile, deliberately incomplete, or carry known risks. A short informal list is far better than nothing.
- Recent failed experiments — What approaches were tried and abandoned, and why. New engineers will attempt the same things without this information.
- Product constraint glossary — The constraints and priorities that aren't apparent from the features themselves. Why is X hardcoded? Why does Y behave this particular way?
- Communication map — Which channels are actually active, who owns what, and who to reach for which decisions. "Check Confluence" is not actionable guidance.
- A designated first-contact person — Not the PM, not the tech lead. One person whose explicit job for the first two weeks is to field incoming questions, so everyone else can maintain focus.
- A recorded context tour — Even a rough screen recording walkthrough of the codebase, the key architectural decisions, and the current project status eliminates a large portion of repeated questions.
The Right Time to Add People Is Before You Need To
Brooks' Law is a lagging indicator. By the time you're considering adding engineers to rescue a late project, the context deficit has already accumulated over months — and you're about to make it visible by forcing a new person to excavate it all at once.
The only real fix is building context capture into how work happens from the beginning, rather than scrambling to reconstruct it when someone new needs it. That's a harder cultural shift than hiring. But it's the one that compounds in your favour.
Teams that capture decisions in real time don't just onboard faster — they also spend less time relitigating old choices, lose less institutional knowledge when people change roles, and build projects that survive the people who built them. The question isn't whether Brooks' Law applies to your team. It's whether you've reduced the context gap enough that the ramp-up is short enough to matter.
Frequently Asked Questions
How long does onboarding a new engineer actually take?
Research cited in MIT Sloan Management Review puts time to full productivity for professionals at approximately 20 weeks, with the first four weeks at roughly 25% capacity. The Cortex 2024 State of Developer Productivity Report found that 72% of engineering leaders report new hires take over a month to submit their first three meaningful pull requests. With structured context handoff in place, that window can be significantly compressed — but the lower bound is still several weeks.
Is Brooks' Law always true, or are there exceptions?
Brooks himself noted exceptions: for highly parallelisable work with well-defined interfaces, adding people can genuinely accelerate delivery. The law applies most strongly when new work requires understanding the history and context of existing decisions — which describes the majority of mid-project software development. The shorter the ramp-up, the weaker the effect. Context documentation is the primary lever for shortening ramp-up.
What's the most common mistake teams make when onboarding a new engineer?
Assuming documentation is sufficient. Most project wikis capture structure but not rationale. A new engineer can read everything in Confluence and still not understand why anything works the way it does. The highest-value knowledge is the reasoning behind informal decisions — and that requires active effort to surface, not just a link to existing docs.
How do you capture knowledge from informal conversations before it's lost?
The most practical starting point is adding a one-sentence "why" to wherever work already lives: commit messages, ticket comments, Slack thread pins. The goal isn't comprehensive documentation — it's capturing reasoning at the moment it exists, rather than reconstructing it weeks or months later when the people who know are no longer paying attention to that problem.