Noah Labhart logoNoah Labhart

Guide

Scaling an engineering team from 5 to 50

Engineering teams break at predictable sizes — around 8, around 20 and around 50 — and each break is a communication problem before it is a process problem. Add structure one step ahead of the pain, and add only the process that removes a specific failure you can name.

8 min read · Updated 2026-08-06

Where do engineering teams break as they grow?

The breakpoints are social, not technical. At about eight people one person can no longer hold every context; at about twenty informal coordination collapses; at about fifty you are running an organisation of teams rather than a team.

SizeWhat breaksWhat to add
1–7Nothing yet — speed is the advantageSource control hygiene, deploys, on-call basics
8–15One person can't review everythingTwo teams, code ownership, written decisions
16–30Hallway coordination failsEngineering managers, roadmap rituals, on-call rotation
31–50Cross-team dependencies stall deliveryPlatform team, architecture review, career ladder

When should you hire your first engineering manager?

Hire or promote the first engineering manager at roughly 8–12 engineers, or as soon as the person doing 1:1s is regularly cancelling them. Managing more than seven direct reports well while also building is not a thing anyone does sustainably.

Promoting from within works when the candidate already does the job informally — mentoring, unblocking, mediating. It fails when you promote your strongest individual contributor purely as a reward, and lose both a great engineer and a happy person.

How much process should a growing engineering team have?

Add process only in response to a failure you can name out loud. Every ritual should have an owner, a purpose and an expiry review; the ones nobody can justify get deleted.

  1. Name the failure: 'we shipped a regression to production three Fridays in a row'.
  2. Add the smallest countermeasure that would have caught it.
  3. Give it an owner and a date to re-evaluate.
  4. Delete it if the failure has stopped happening for another reason.

How do you keep quality from falling as headcount rises?

Quality falls when the number of people exceeds the reach of the standards. Encode the standards in tooling — tests, CI gates, templates, defaults — so that new hires inherit them without needing to absorb them from a senior engineer.

  • Make the paved path the easy path: project templates, shared libraries, one-command local setup.
  • Gate on automation, not opinion — linting, tests and security checks in CI.
  • Keep a decision log so architectural context survives turnover.
  • Track a small set of health metrics and read them monthly, not daily.

What should stay the same as you scale?

Protect the two things that made the team fast at five people: short distance between problem and decision, and engineers who talk to customers. Most scaling damage comes from inserting layers between those two.

Frequently asked questions

What is a good engineer-to-manager ratio?
Five to eight engineers per manager is the sustainable range. Below four the manager tends to micromanage or slip back into full-time coding; above eight, 1:1 quality and hiring both suffer.
Should engineers be organised by product or by technology layer?
Organise by product or customer outcome wherever possible. Layer-based teams (frontend team, backend team) create handoffs and make every meaningful feature a cross-team negotiation.
How fast can you hire engineers without breaking the team?
A common rule of thumb is not to grow a team by more than roughly a third per quarter. Onboarding capacity, not candidate supply, is usually the real limit.

From the podcast

Founders who lived this

Code Story episodes where founders work through the same problem in their own words.

More on future of workMore on saas & b2b

Keep reading

Related guides

Startup engineering team structure that actually ships

How to structure a startup engineering team: the models that work at 5, 15 and 40 engineers, how to split teams, and the org mistakes that quietly slow delivery.

Engineering metrics that matter (and the ones that don't)

Which engineering metrics to track at a startup: DORA metrics, quality and reliability signals, what they tell you, and why measuring individual output backfires.

CTO vs VP of Engineering: how the two roles actually differ

CTO vs VP of Engineering explained: who owns architecture, who owns delivery, when to split the roles, and how to avoid the overlap that breaks engineering teams.

All guides