The observation is old and still routinely ignored: adding people to a late project makes it later. It is not a morale problem or a management failure. It is arithmetic about how coordination scales.
Links grow quadratically, output does not
Four people have six possible pairs. Ten people have forty-five. Every pair is a channel that may need to stay synchronised, and the total coordination load rises roughly with the square of headcount while capacity rises linearly at best.
There is a size beyond which additional people spend more time staying aligned than producing, and that point arrives earlier than most organisations expect.
New people consume the experienced ones
A new joiner is not neutral for the first months; they are a net cost, funded by exactly the people who were previously most productive. Adding four engineers to a struggling team of six removes a meaningful share of the capacity that was working.
This is why reinforcements arriving near a deadline reliably make things worse rather than better.
Split the work before splitting the team
Larger efforts do sometimes need more people. What makes that work is decomposition: independent areas with real interfaces between them, so coordination happens at boundaries rather than continuously.
Adding people without that structure just increases the number of participants in every conversation.
Prefer depth to headcount
One engineer who knows the system well is frequently worth several who do not, particularly for changes that touch several areas. Retaining people is a delivery strategy, and it is generally cheaper than hiring against attrition.
When a project is behind, the useful levers are scope and sequencing. Headcount is the intuitive lever and the one most likely to make the situation worse.