Why we recommend The Mythical Man-Month
Frederick P. Brooks Jr. wrote about software projects long before cloud platforms, remote teams, and AI. The technical setting has aged. The human part has not: intellectual work does not split like an assembly line, and coordination carries a cost that plans routinely hide.
How a late project can become later
- Late projectscope · dependencies · uncertainty
- More peoplehiring · reassignment
- Onboardingdomain · code · tools
- More coordinationmeetings · decisions · interfaces
- Less focusmentoring · interruption · rework
- Further delayuseful capacity arrives late
Short summary
The book challenges the idea that people and months are interchangeable. Software creation includes learning, communication, design, and decisions that cannot be divided without cost. Brooks also argues for conceptual integrity: a system needs a coherent direction even when many people help build it.
- Calendar time and total effort are different variables.
- Splitting work creates interfaces, and every interface needs coordination.
- Plans routinely omit testing, integration, and correction.
- Architecture loses clarity when nobody protects the whole design.
Brooks's Law, with context
Adding people to a late software project makes it later. The sentence does not say hiring is always harmful. It says late onboarding can consume more capacity than it adds: someone must teach the domain, explain decisions, arrange access, and review work while the number of communication paths grows.
- The effect is stronger when the work depends on tacit knowledge.
- A close deadline leaves little time to recover the onboarding cost.
- More hands cannot remove a sequential dependency or a pending decision.
- Pressure for visible activity can reduce the capacity to finish.
What it means for a company
A late project is not automatically a staffing problem. Before hiring or moving people, the company should find the bottleneck: unstable scope, slow decisions, technical debt, external dependencies, missing tests, or an architecture that forces every change through the entire team.
- Reducing scope can protect a date better than expanding the team.
- Small teams need clear ownership and fast access to decisions.
- Onboarding belongs in the plan as work, not instant capacity.
- Management should measure finished, operable software rather than busy people.
When adding people can help
Hiring can work when there is time to learn, genuinely divisible work, stable interfaces, and a clear owner for integration. It can also create capacity that survives the immediate deadline. The dangerous move is using late hiring as a substitute for cutting scope or resolving decisions.
- Separate independent tasks with concrete acceptance criteria.
- Protect the people teaching and account for the focus they lose.
- Assign ownership for integration and technical coherence.
- Plan for the capacity the company will need after the milestone.