Scaling an engineering team from 5 to 25: the costs and failures nobody warns you about

01The real cost of an engineer

Salary is roughly 60-70% of what an engineer costs. Plan against the fully loaded figure or your budget will be short by a third before you have hired anyone.

The recruitment line is the one most often forgotten. Agency fees of 18-25% of first-year salary are standard for senior roles, and even a strong internal function costs real money in tooling, referral bonuses and the interviewing time of engineers who are not shipping while they interview.

02Output does not scale with headcount

Communication paths grow quadratically while output grows, at best, linearly. Five people have ten pairwise relationships; twenty-five have three hundred. Nobody manages three hundred relationships, so structure has to replace informal coordination - and until it does, the additional engineers mostly generate coordination overhead.

The practical consequence is a plateau. Most teams see per-engineer output fall as they grow, and the ones that handle it well are the ones that pay for structure before they need it rather than after velocity has visibly stalled.

03The structural costs that appear on the way

These are the specific spends that a five-person team never encounters and a twenty-five person team cannot function without. They are cheap relative to the salary bill and are still the first things cut.

04Onboarding is the cost you pay every single hire

A senior engineer joining a non-trivial codebase takes six to twelve weeks to reach full productivity, and consumes existing engineers' time throughout. At scale that is a permanent tax: a team hiring ten people a year is running roughly one continuous onboarding at all times, plus the mentoring load on the people who already know the system.

The cost is highly sensitive to preparation. A documented codebase with a one-command local setup and a curated set of first tasks halves the ramp. That documentation costs a few weeks to produce and pays back on the second hire.

• Full cost of one senior hire's ramp: 6 - 12 weeks reduced output, plus 30 - 60 hours of other engineers' time.
• One-command local setup is the highest-leverage onboarding investment there is.
• Maintain a standing list of good first issues, curated rather than scavenged.
• Assign one named onboarding owner per hire; shared responsibility means nobody does it.
• Architecture decision records let a new engineer learn why, which is what actually takes the time.

05The failures that are specific to this range

The problems between 5 and 25 are recognisable, and every one of them is a structural gap rather than a people problem - which is why they are so often misdiagnosed as one.

• Promoting your best engineer to manager and losing your best engineer without gaining a manager.
• Founders or early engineers remaining the approval bottleneck for every decision.
• Nobody owning the codebase's shared parts, so quality drifts where responsibility is diffuse.
• Hiring seniors into a codebase with no documentation, then concluding they are not very senior.
• Adding process in response to a single incident and never removing any of it.
• Splitting into teams along technology lines rather than data ownership, creating a dependency for every feature.

06Sequencing the growth

Growth works when structure is added slightly ahead of the size that requires it. The sequence below is not the only order, but it consistently costs less than reacting to each failure as it arrives.

• At 6 - 8: write decisions down, set up an on-call rota, invest in CI speed before it hurts.
• At 8 - 10: split into two teams with genuinely separate ownership, and make onboarding a documented process.
• At 10 - 12: hire the first engineering manager, and fund per-developer environments.
• At 15: define service ownership explicitly, and appoint a staff-level engineer for cross-team technical direction.
• At 18 - 20: fund platform or developer-experience work as a real team, not a rotation.
• At 25: second manager, formal architecture review, and a deliberate decision about how teams take dependencies on each other.