Adding People Slows You Down — At First
In 1975, software engineer Fred Brooks published The Mythical Man-Month, a book that remains one of the most cited works in software management. His central observation: "Adding manpower to a late software project makes it later."
This is counterintuitive. If one person takes 10 months to build something, shouldn't two people take 5 months? In theory, yes. In practice, no — because software work is not perfectly parallelizable. New people require onboarding, generate questions, need code reviews, and consume the attention of your most senior engineers at exactly the moment you need those engineers to be shipping.
The Ramp-Up Tax
When you get headcount approved, you must account for the full cost of bringing someone productive:
| Phase | Duration | Net Effect on Team |
|---|---|---|
| Recruiting | 1–3 months | Distraction for interviewers |
| Onboarding | Month 1–2 | New hire is net-negative (consuming senior time) |
| Ramping | Month 3–5 | New hire reaches ~50% productivity |
| Full productivity | Month 6+ | Positive contribution begins |
This means a hire approved in January may not generate positive ROI until July. If your crisis is happening now, a new hire will not save you.
The Strategic Implication
Do not hire to solve a crisis today. Hire to solve the crisis you expect next year.
If you are drowning in Q2, the only levers available to you are:
1. Cut scope — reduce what you committed to deliver.
2. Reduce quality — ship with known bugs (technical debt).
3. Work overtime — unsustainable and damages retention.
Adding bodies to a burning project is not a lever — it is an accelerant. The correct response to "we need more people to hit this deadline" is almost always: "No. We need to cut scope for this deadline, and I want the headcount for the next planning cycle."
Interviewers at Staff+ and Director levels frequently ask: "Your team is behind on a critical deadline. The VP offers you two contractors starting next week. Do you take them?" The correct answer is nuanced: it depends on how far behind you are and how well-defined the remaining work is. If the work is highly parallelizable and well-scoped (e.g., writing independent integration tests), contractors can help. If the work requires deep context (e.g., debugging a distributed systems race condition), they will slow you down. Always qualify your answer with the nature of the remaining work.