How to scale your engineering team / Common problems
Why adding engineers can slow you down
Adding people to a late project often makes it later, not sooner. New engineers cost the team time before they save it, and past a certain size the cost of coordinating a larger team is larger than the extra output. This is a real, well-documented mistake, and it catches experienced leaders because the instinct to add people feels so obviously right.
Published July 27, 2026. Editorial.
Key takeaways
- New engineers take time from the team before they add to it, so a late project can get later when you add people.
- Coordination cost rises faster than headcount, so past a point each new person adds less than they cost.
- The mistake is worst when you add junior people or add them in a panic without onboarding.
- Add capacity ahead of the need, favor seniority, and structure the team so most work stays inside one team.
The most natural response to a late project is to add people to it. It feels obviously correct: more people, more work done, sooner finish. It is also one of the oldest known mistakes in building software, because it often does the opposite. Understanding why protects you from making the late project worse at the exact moment you are trying to finish it.
The mechanism, in plain terms
Two forces work against you when you add people to a project under pressure.
The first is the learning cost, meaning the time a new person needs before they are productive. A new engineer is not productive on day one. They need context, they ask questions, and their early work needs review. All of that time comes from your existing engineers, the very people who were already busy. So in the short term, adding a person reduces the team's output before it increases it. On a project that is already late, that short-term dip is the last thing you can afford.
The second is coordination cost. As we cover in how to structure engineering teams, the connections between people grow much faster than the people. Each new person adds communication, alignment, and the chance of two people building things that do not fit. Past a certain size, the extra coordination a new person creates can cost more than the work they add. You end up with a bigger team producing less per person.
Why it fools smart leaders
This mistake catches experienced people because the logic of adding help is so intuitive, and the cost is invisible until later. When you add an engineer, the extra salary and the extra headcount are obvious. The learning cost and the coordination cost are hidden, spread across the existing team as slower reviews, more meetings, and more rework. Nobody sees a line item for it, so it does not get weighed against the obvious benefit of more people.
It is made worse by the pressure of a deadline. When a project is late, there is little time to onboard anyone properly, so new people are added quickly and left to guess, which maximizes the learning cost. And the panic often leads to adding whoever is available fast, which tends to mean less senior people, which makes the coordination and rework problems worse. The mistake is worst exactly when the temptation is strongest.
What actually helps
The fix is not to never add people. It is to add them in a way that avoids the mistake.
Add capacity ahead of the need, not in a panic. Because new people cost time before they add it, the worst moment to start is when you are already too far behind. Growing before the busiest period, as we cover in when to scale your engineering team, lets people become productive before they are needed rather than during an emergency.
Favor seniority over headcount. A senior engineer becomes productive faster, needs less direction, and produces less rework, so they cross from cost to gain sooner. Adding two senior engineers often beats adding five junior ones on a project under pressure. This is the same point we make in small senior team outbuilds a big one.
Onboard properly even when time is tight. It feels backwards to spend time on onboarding when you are behind, but skipping it is what makes the new people a cost for months instead of weeks. The fast path is covered in how to onboard engineers quickly.
When more people is genuinely the answer
None of this means growth is bad. When you have a clear plan, strong senior leadership, and work that is well understood, adding capacity is exactly right, and the learning and coordination costs are worth paying because the extra output is real and lasting. The mistake is specific: it is adding people, often late and often junior, to fix a project that is behind, without the plan or the onboarding to integrate them.
So before you add anyone to a late project, ask whether capacity is really the constraint. If the project is late because the plan keeps changing or decisions are not getting made, more people will not fix it and will likely make it worse. If it is late purely because there is more clear work than there are people, then add capacity, but add it the way that avoids the mistake: ahead of time, senior, and properly onboarded. If you need that senior capacity faster than you can hire, staff augmentation is the quickest clean way to get it.
Best for
- Adding capacity when the plan is clear, leadership is strong, and work is well understood
- Bringing on senior engineers who become productive fast and need little direction
- Growing ahead of the need, so new people become productive before the busiest period
Avoid if
- Do not add people to a project that is late because the plan keeps changing or decisions are not being made
- Do not add junior engineers in a panic to a project already under deadline pressure
- Do not skip onboarding to save time, because that is what turns a new hire into a months-long cost
Check before you decide
- Confirm capacity is really the constraint, not an unclear plan or a missing decision maker
- Confirm you have the senior time to onboard the new people before you add them
- Confirm you are adding seniority, not just headcount, on a project that is already behind
Common questions
Does adding more engineers speed up a late project?
Often the opposite. New engineers cost the team time before they save it, because they need context and review from people who are already busy. Past a certain size, the cost of coordinating a larger team is also larger than the extra output, so a late project can get later.
Why does adding people to a project make it slower?
Two reasons. New people take time from the existing team while they learn, and the connections between people grow faster than the people, so each addition raises coordination cost. Under deadline pressure, with rushed onboarding and less senior hires, both effects get worse.
How do I add engineers without slowing the team down?
Add capacity ahead of the need rather than in a panic, favor seniority over raw headcount, and onboard properly even when time is tight. And confirm capacity is really the constraint, because if the project is late due to an unclear plan, more people will not fix it.
Is it ever safe to add people to a late project?
Yes, when the project is late purely because there is more clear, well-understood work than there are people, not because the plan keeps changing or decisions are delayed. In that case adding capacity is the right step, but it still needs to be senior, onboarded properly, and added before the busiest period rather than added quickly during the panic.
Why do junior hires make the late-project mistake worse?
Because a panic hire under deadline pressure tends to favor whoever is available fast, which usually means less senior people. Junior engineers need more direction and produce more rework, which raises both the learning cost and the coordination cost right when the team can least afford either, making the mistake worse instead of avoiding it.
How much can adding people to a late project cost in lost time?
The exact cost depends on the project, but the mechanism is well documented: a new engineer reduces the team's output in the short term through the questions, review, and context they require, while the connections between people also grow faster than headcount. Together those effects can make a late project measurably later rather than sooner.
What should I check before adding engineers to a struggling project?
Confirm that capacity is genuinely the constraint, not an unclear plan or a missing decision maker, since only a true capacity gap responds to more people. Confirm you have senior time available to onboard the new people properly. Confirm you are adding seniority rather than just headcount, since senior engineers become productive faster and produce less rework under pressure.
What are the two forces that make adding engineers have the opposite effect?
Learning cost and coordination cost. A new engineer is not productive on day one and needs context, questions answered, and review, which pulls time from the existing team before it adds any. At the same time, the connections between people grow faster than the people themselves, so each new hire raises coordination cost past a certain team size.
Related reading
Why a small senior team now outbuilds a big one
Adding people used to be how you went faster. With modern tools, a small team of senior engineers often releases more work, with fewer problems, than a large mixed one.
You cannot measure engineers by how much they produce
Lines of code, tickets closed, and hours logged all measure activity rather than progress. Here is how we think about engineering output without numbers that only look good.