When a project is behind schedule, diagnose the cause before you add developers. In our judgment, cut scope by default, because it's the lever you can pull this week without a hiring lead time. Add people only when the work splits cleanly, enough time remains, and the person needs little ramp-up. In practice that means one senior engineer on a separable bottleneck, not a team. Related leadership guides are in Startup CTO guides: leadership, diligence and the first hires.
Why is the project actually late?
"We're behind" is a symptom. Four causes produce it, and each has a different fix, so spend the first two days finding which one you have.
First, the estimate was wrong. The original forecast was a guess, and the remaining work is bigger than anyone said. Test: compare the first estimate for finished items with what they took. As a rule of thumb, if completed work ran 1.5x over, the remaining work probably will too. Steve McConnell, in his article on Brooks's law (more below), notes that late chaotic projects are usually later than managers believe, because the original estimate was too low.
Second, scope grew. Work entered the plan after the date was set. Test: count tickets added since kickoff against tickets removed. If the list only grows, headcount doesn't address it.
Third, there's a bottleneck. One person, one review queue or one environment holds up everything else. Test: look at where finished work waits. If it piles up in one column or behind one name, the constraint is there, not in total capacity.
Fourth, a dependency is late: a vendor, an API, another team. Test: list the items blocked on something outside the team. Hiring rarely unblocks those.
Slips often have more than one cause at once. That matters for the decision: if you find only a bottleneck, there's a case for adding a person. If you find an estimate problem or scope growth, adding a person fixes neither.
What does Brooks's law say, and what did Brooks himself claim?
Fred Brooks put it in The Mythical Man-Month (1975): "Adding manpower to a late software project makes it later." Wikipedia's entry on Brooks's law lists three effects behind it.
First, ramp-up. New people need training and context, and the people who provide it stop doing their own work. Second, communication. Paths between people grow as n(n-1)/2 (Brooks's formula), so a team of 5 has 10 paths and a team of 10 has 45. Third, limited divisibility. Some tasks can't be split, which is Brooks's "nine women can't make a baby in one month".
Brooks later called his law an "outrageous oversimplification", according to the same entry. It's a warning about a default reaction, not a theorem.
When does adding people not make it later?
McConnell's "Brooks' Law Repealed?" argues that adding people can work when it happens early, when enough schedule remains for new people to become productive, and when training cost is low. Good tracking and documentation on the project help too. McConnell, who once promoted the law, now rejects it in its general form.
Wikipedia's entry also lists three other studies, which we haven't read in full, so treat these as reported findings. Hsia, Hsu and Kung's 1999 system dynamics paper is reported to find that added staff raises cost but doesn't always delay delivery, depending on slack and sequential dependencies. Gordon and Lamb's 1977 article is reported to advise adding more people than seems necessary, and early. Scott Berkun's 2006 essay on exceptions is reported to argue that the law wrongly assumes all added labour is equal.
What is the real cost of adding one person?
Here's a worked example. The inputs are illustrative assumptions, not benchmarks, so replace them with your own. Say a new senior engineer produces 40% of a full engineer's output in their first four weeks, and the colleague who onboards them loses 30% of their time over the same period.
- New engineer's output in four weeks: 4 weeks x 0.4 = 1.6 engineer-weeks.
- Onboarder's lost time: 4 weeks x 0.3 = 1.2 engineer-weeks.
- Net gain after four weeks: 0.4 engineer-weeks.
You've bought almost nothing in the first month, and that excludes the weeks spent hiring. If the deadline is six weeks away, the person adds about 2.4 engineer-weeks in total (0.4 from the first four weeks, plus two full-capacity weeks), assuming the onboarder is back to full capacity after week 4. If it's three weeks away, the person adds about 0.3 engineer-weeks before hiring time and coordination overhead, which is effectively nothing. Our guide to how much capacity a new engineer adds in sprint one covers the capacity side.
DX measured time to a new hire's tenth pull request at six multinational enterprises: 91 days for those not using AI tools, 49 days for daily AI users. It's observational (a comparison of groups, not an experiment), and those are new hires at large enterprises; DX doesn't name the companies or industries. Treat it as a reference point for large enterprises, not a forecast for a contractor on a small team.
To shorten the ramp, prepare access, scope and review before the person starts. A 14-day onboarding plan with a dated first PR covers the steps.
Cut scope, move the date, or add people? How to choose
| Option | Works when | Breaks when | Check this week |
|---|---|---|---|
| Cut scope | A product owner can rank features by value, and a smaller release is still useful | Everything is contractually fixed, or "must-have" covers the whole list | Which items could ship in a later release without anyone leaving? |
| Move the date | The date is a preference, not a commitment tied to money or a customer | A customer, launch or funding event depends on it | What does a range forecast say, and how wide is it? |
| Add one senior to a separable bottleneck | The constraint is one stage or person, the work splits, and enough time remains | Dependencies are sequential, or the deadline is within the ramp period | Can this person take a whole piece of work with a clear interface? |
| Add general headcount | Rarely. Early, with slack, and with low training cost | Often, once the project is late and ramp time exceeds the time left | Is the project early enough, and well enough documented, for that to hold? |
| Reduce work in progress and interruptions (our judgment) | Context switching and meetings eat the week | The team is already focused | Count hours in meetings and unplanned requests across the last two weeks |
If date and scope are both fixed, you aren't choosing between options. You've been handed a risk, and your job is to say so. For a range instead of a point, see re-forecasting with throughput or reference classes.
How to decide in two weeks when a project is behind schedule
1. Day 1-2: freeze scope intake and name the cause
Stop new work entering the plan until you've finished diagnosing. Run the four tests above. Checkpoint: a one-page note naming the cause and the evidence for it.
2. Day 2-3: re-forecast the remaining work
Forecast what's left as a range, using your team's recent throughput or the actual-versus-estimate ratio on finished items. Don't reuse the original estimate. Checkpoint: an earliest and latest finish date, with the assumptions written next to them.
3. Day 3-5: rank scope by value and cut to a releasable slice
Rank remaining items by customer value and cut from the bottom. A cut can be a deferral, a simpler version, or a feature flag that ships the code dark. Checkpoint: a slice that you could release and defend, with the cut list agreed by the product owner.
4. Day 5-7: test the bottleneck
Ask three questions. Is the remaining work separable? Who is blocked on whom? Is one person, or one review queue, the constraint? Checkpoint: a named bottleneck with a one-line description of the work that could be handed over, or a note that none exists.
5. Day 7-9: decide the people question with three gates
Add a person only if all three hold: the work is separable, the calendar leaves more time than the ramp needs, and you can onboard within a couple of weeks. If you add anyone, size it as one senior engineer, not a team. Checkpoint: yes or no, in writing, with the gate that decided it.
6. Day 9-12: reset the date and tell the stakeholder
Give the new date as a range, say what was cut, and say what's still at risk. Checkpoint: the message is sent, and the stakeholder has confirmed the cut list.
7. Day 12-14: set the check-in
Choose one metric and one date to review it. If you added a person, agree a stop condition up front: if they aren't unblocking the bottleneck by the end of their second week, you change the plan. Checkpoint: the date is in the calendar and the stop condition is written.
What this means for your delivery decision
In our judgment, the default answer is to cut scope and give the date as a range. The senior hire is an exception you have to earn through the three gates. If you can't show the work is separable, you can't show a hire helps. If you can, the cost is bounded: one person, one piece of work, a stop condition at two weeks.
Don't promise a recovered date because you've added someone. If you need sign-off for even one senior, the numbers belong in the case for one senior hire, which compares in-house, contractor and nearshore routes by cost and time to start.
Adding a senior engineer through HighCircl
A new engineer still needs ramp time, whoever supplies them, so this only helps when the bottleneck is real and the deadline is far enough away. If it is, HighCircl matches senior engineers from a vetted shortlist of 3-5 candidates within 72 hours. There's no minimum hour commitment and no recruitment fee, and if the engagement isn't working there's a replacement at no additional recruitment cost. The 20% margin is capped and applied on top of what the engineer earns.
FAQ
Is Brooks's law true?
Brooks's warning is a sound default: new people cost time before they return any, and the evidence on whether they pay back is mixed. Brooks himself called the law an outrageous oversimplification, and McConnell argues it doesn't hold when people are added early, with enough schedule left, and with low training cost.
Should you add developers to a late project?
Usually not. Add one senior only if the work is separable, the calendar leaves more time than the ramp needs, and onboarding is short. Cutting scope has no ramp cost.
How long does a new developer take to become productive?
It depends on the system, the person and how well you prepare. DX's study found 91 days to a new hire's tenth pull request without AI tools and 49 with daily use, at large enterprises. For a senior contractor on a small team, plan from your own history: how long did your last hire take to merge a first change?