How to Scale an Engineering Team From 5 to 50 Engineers

Scale an engineering team by changing its structure one step before the current structure breaks. Hire senior generalists first, then a first engineering manager and someone who owns production, then specialists, then managers of managers. Split into stream-aligned teams of five to eight engineers that each own their services in production, pager included, and add a process only when you can name the problem it fixes.

Key takeaways

• Teams break at predictable sizes because communication paths grow as n(n-1)/2: 10 paths at 5 people, 105 at 15, 1,225 at 50. Structure exists to cut that number down.
• Hire in sequence. Each role in the sequence removes a specific bottleneck, and hiring it early or late has a cost you can predict.
• Organize around product streams, not technical layers. A team that owns onboarding end to end ships without waiting on anyone; a "frontend team" waits on the "backend team" for every feature.
• Ownership is only real when it is written down and wired into tooling. CODEOWNERS, the service catalog and alert routing should all name the same teams.
• On-call needs enough people to be sustainable. Google's SRE book puts the floor at eight engineers for a single-site 24/7 rotation with a primary and a secondary.
• Hire at the pace onboarding can absorb, and measure it: time to first production deploy for every new engineer.

Why engineering teams break at predictable sizes

Three old observations explain most of what goes wrong.

Communication paths grow quadratically. With n people there are n(n-1)/2 possible pairs who might need to talk. Five engineers have 10 paths and can keep all of them warm in a standup. Fifteen have 105, and nobody can. Fifty have 1,225. Teams, ownership boundaries and written decisions are all ways to stop most of those paths from being necessary.

Brooks's law. Fred Brooks observed in The Mythical Man-Month that adding people to a late software project makes it later. New engineers consume the time of existing engineers before they contribute. Hiring is an investment with a delay, not an instant capacity bump.

Conway's law. Systems end up mirroring the communication structure of the organization that builds them. If two teams share one service, that service grows two inconsistent halves. If you want clean service boundaries, draw team boundaries first.

The sizes below are approximate. A senior team on a well-factored codebase breaks later; a junior team on a tangled monolith breaks sooner. The order of failures does not change.

The hiring sequence

Most scaling pain is a hiring order problem. The table is the sequence we would follow for a typical B2B product company. Adjust it for your domain, but keep the logic: each hire should remove a bottleneck you can name today.

Three hires to avoid early. A VP of Engineering from a large company before there are managers to manage: they arrive with processes built for a different size. A separate QA team: testing is part of owning code, and a hand-off to QA lengthens every cycle. An architect who does not write code: decisions get made in documents that nobody who ships has to live with.

Stage 1: the founding team (3 to 8 engineers)

At this size the only job is finding product-market fit. Structure should be nearly invisible.

Topology. One team. The CTO is the tech lead and usually the manager. Everyone works on whatever matters most this week.

Ownership. Everyone can change everything, but every area still has a named point person in a short document: billing, auth, the data pipeline, infrastructure. "Everyone owns it" is fine for writing code. It fails at 2 a.m., when "everyone" means nobody.

On-call. Informal but explicit. One person per week carries the phone, founders included. Alerts fire only on user-facing symptoms (the site is down, checkout fails, error rate spikes), not on CPU graphs.

Practices to set up now, because they are cheap now and expensive later:

• Trunk-based development with short-lived branches and CI on every pull request.
• One command to get a working dev environment.
• Error tracking, uptime checks and an incident channel.
• A one-page RFC for decisions that are hard to reverse: database, tenancy model, identity provider.
• Production access through individual accounts, never a shared admin login.

Our startup infrastructure checklist covers the technical side of this stage in order.

What breaks first is knowledge concentration. One engineer understands billing; the CTO is the only person who can restore the database. Check it with git rather than guessing:

git shortlog -sn --no-merges --since="6 months ago" -- src/billing src/auth

If one name dominates the output for a critical path, pair someone else on the next change there. Bus factor is fixed by rotation, not by documentation alone.

Stage 2: the first teams (8 to 15 engineers)

This is the most dangerous stage. The team is too big for everyone to know everything and too small for process to feel natural, so most teams delay the changes until something hurts.

Topology. Split into two or three stream-aligned teams, each owning a product area or customer journey: activation, core workflow, payments. Each team gets a one-paragraph mission, a tech lead and a list of what it owns. Do not split by layer. A frontend team and a backend team turn every feature into a negotiation.

First manager. Promote from within if someone wants the job and has the team's trust. Hire externally if nobody does. Never push your strongest engineer into management as a reward; you lose a strong engineer and may not gain a manager.

Ownership in tooling. Put team ownership in a CODEOWNERS file so reviews route automatically. Later rules override earlier ones, so order matters:

*                         @acme/eng-leads
/apps/web/onboarding/     @acme/team-activation
/services/billing/        @acme/team-payments
/services/billing/tax/    @acme/team-payments @acme/security
/infra/                   @acme/platform
/db/migrations/           @acme/platform @acme/team-payments

Decision records. Start writing Architecture Decision Records: a page or less per decision, covering context, options considered, the choice and what would make you revisit it. At eight people decisions happen in conversations; at fifteen, half the team was not in the room.

On-call. Formalize it. A weekly rotation with a primary and a secondary, a written handoff at each change, and a runbook linked from every alert. Pay people back for bad nights with time off. A single shared rotation across all teams is fine at this size, as long as everyone on it has the access and runbooks to act.

What breaks: hidden dependencies. One team's migration breaks another team's query. A shared cron job fails and both teams assume the other is looking. The fix is boring and effective: every job, queue, table and service gets exactly one owning team.

Stage 3: multi-team coordination (15 to 30 engineers)

Coordination is now the main cost. The practices that got you here start to work against you.

Team types. Team Topologies by Matthew Skelton and Manuel Pais gives the most useful vocabulary for this stage: four team types and three ways they interact.

The platform team. Start with two to four engineers and run the platform as an internal product: the other teams are customers, and adoption is the measure of success. A platform team that works from a ticket queue becomes a bottleneck with a new name. Our guide to internal developer platforms covers how to build one teams actually use.

A service catalog with enforced owners. Every service gets a small metadata file in its repository. Backstage's format is a reasonable default even if you never run Backstage:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: billing-api
  description: Subscriptions, invoices and usage aggregation
  annotations:
    acme.io/runbook: https://runbooks.internal/billing-api
    acme.io/oncall-schedule: payments-primary
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: billing

Then make missing ownership a build failure, so the catalog cannot rot:

for f in services/*/catalog-info.yaml; do
  yq -e '.spec.owner' "$f" > /dev/null || { echo "no owner in $f"; exit 1; }
done

On-call moves toward the teams. Once teams own distinct services, "you build it, you run it" produces better alerts and faster fixes. The constraint is headcount: a team of five cannot staff a sane 24/7 rotation alone. Common patterns:

Google's SRE book derives a minimum of eight engineers for a single-site 24/7 rotation with a primary and secondary, which puts each person on call about one week a month. For two sites it suggests at least six per site. A rotation of three or four people is a burnout plan.

Levels. Engineers need to see how they grow. Four to six levels with written expectations is enough at this size, with the individual contributor and manager tracks splitting at senior. Without a framework, promotions follow visibility rather than impact, and people notice.

What breaks: platform work done on the side by one senior engineer who is also on a product team; alerts inherited from stage 1 that nobody tuned; teams paged for services they cannot deploy. Each of these looks like a people problem and is actually an ownership problem.

Stage 4: building an organization (30 to 50 engineers)

At this size you are designing an organization, not running a team.

Managers of managers. Once there are four or more engineering managers, someone needs to coach them, run calibration and own cross-team priorities. Keep each manager's span at a level where real 1:1s still happen every week or two.

Staff engineers. A staff engineer owns technical direction across teams: the migration nobody owns, the service boundary everyone argues about, the reliability standard for tier-1 services. This is the role that keeps your best engineers growing without forcing them into management.

A hiring system, not a hiring habit. Multiple teams hiring at once need a structured loop with a written rubric per interview, interviewers who have been trained and shadowed, and debriefs where people submit scores before discussion so the loudest voice does not set the outcome. Give one person the authority to hold the bar across teams.

Incident management with roles. Separate the incident commander (coordinates, decides) from the people fixing the problem. Define severity levels in writing, require a blameless postmortem for the top severities, and track action items to closure. Our incident response playbook has templates you can adapt.

Architecture follows teams. Do not adopt microservices because you passed a headcount. A modular monolith with module boundaries that match team boundaries carries most organizations well past fifty engineers. Extract a service when a team boundary, a scaling need and a deploy cadence all point the same way.

Measure the system, not the people. Track delivery and reliability at team level: deployment frequency, change lead time, change failure rate and recovery time. Our post on engineering metrics defines each one with formulas and explains how to avoid turning them into targets.

On-call and ownership at each size

Two rules hold at every size. Every page must be actionable, and pages get reviewed weekly: if an alert fired and nobody had to do anything, delete or fix it. And the person paged must be able to fix the problem: access to logs, permission to deploy and roll back, and a runbook that someone has tested.

How fast to hire

Every new engineer costs existing engineers time: interviews before they join, then onboarding, pairing and reviews after. That cost is invisible on a hiring plan and very visible in output.

A useful constraint: one onboarding buddy per new hire, and a buddy takes one person at a time. Count the engineers who can be good buddies. That number, not the budget, is your hiring ceiling for the quarter. In practice a team rarely absorbs more than one or two new people at once without its own output dropping.

Track two numbers for every hire:

• Time to first production deploy. It measures your dev environment, CI, documentation and code clarity all at once.
• Time to first on-call shift. Shadow first, then secondary, then primary. If nobody new reaches the rotation, the rotation shrinks as the team grows.

If both numbers lengthen as you hire, slow down until onboarding catches up. A simple onboarding plan:

• Day 1: laptop ready, access granted through SSO groups, not individual grants
• Days 2 and 3: dev environment running from one command; first small PR opened
• Week 1: first change deployed to production with a buddy
• Weeks 2 and 3: shadow an on-call shift; read the last three postmortems
• Weeks 4 to 6: own a small feature from design to release
• Weeks 6 to 8: join the rotation as secondary

What goes wrong in production as teams grow

These are the failures that show up on the pager rather than in a retrospective.

Reorgs orphan services. Two teams merge, a third is renamed, and the alert routing still points at a team that no longer exists. The page goes to a channel nobody reads. Fix: make the service catalog the source for alert routing, and add "move the pagers" to the reorg checklist.

The departed engineer's credentials. A nightly job runs with a token created by an engineer who left. Their account is deprovisioned, the job silently stops, and you find out at month end. Fix: automation runs as service accounts owned by teams, and offboarding includes a search for credentials the person created.

On-call without authority. The paged engineer can see the problem but cannot deploy the fix because another team owns the service or the pipeline. Fix: rollback rights for whoever is on call, and an escalation path that reaches the owning team at night.

Hero culture. One senior engineer quietly fixes everything at night. It looks like resilience until they take a vacation or leave. Fix: route pages through the rotation even when the hero is awake, and count after-hours interventions per person.

Inherited alert noise. Alerts written at stage 1 fire on causes, not symptoms, and nobody tuned them. People start ignoring the pager, then miss the page that mattered. Fix: a weekly review of every page, with deletion as a normal outcome.

The shared database. Teams have separate services but one database, and one team's migration locks a table another team reads. Fix: table-level ownership, migrations reviewed by the owner, and online migration patterns for large tables.

Access sprawl. Everyone still has the admin rights they were given when there were five of you. Fix: SSO groups per team, least privilege by default and a break-glass role for emergencies that alerts when used.

Frequently Asked Questions

When should a startup hire its first engineering manager?

Hire or promote a first engineering manager when the CTO can no longer hold regular one-on-ones with every engineer and still do technical work. That usually happens somewhere between eight and twelve engineers. Promote from within when someone wants the job and has the team's trust, and do not push your strongest engineer into management as a reward.

What is the ideal size for an engineering team?

Most effective product teams have five to eight engineers. Smaller teams struggle to cover on-call, vacations and code review, while larger teams spend more time coordinating than building. When a team grows past about nine people, split it along a product or customer-journey boundary rather than by technical layer.

How many engineers do you need for an on-call rotation?

Google's SRE book sets the minimum for a single-site 24/7 rotation with a primary and a secondary at eight engineers, which puts each person on call about one week a month. With fewer people, limit paging to business hours, share an after-hours rotation across teams, or cut alerts down to user-facing symptoms. A rotation of three or four people burns out quickly.

Should developers be on call for the code they write?

Yes, once teams own distinct services. Engineers who carry the pager for their own code write better alerts, fix root causes faster and design with failure in mind. It only works when the on-call engineer has the access and authority to deploy or roll back, and when pages are rare enough to be sustainable.

When does a startup need a platform team?

Form a platform team when three or more product teams are duplicating infrastructure work, or when CI, deploys and observability are maintained as a side job by one senior engineer. That typically happens somewhere between twenty and thirty engineers. Start with two to four people and run the platform as an internal product with the other teams as its customers.

How fast can you hire engineers without hurting productivity?

Hire only as fast as you can onboard. Each new engineer needs a buddy, review time and a small first project, so a team can usually absorb one or two new people at a time. Track time to first production deploy for every hire, and slow down if it keeps getting longer.

Need help scaling your engineering team?

We are senior engineers who build systems and then run them: if we built it, we are on the pager. We can help you draw team and service boundaries, set up ownership and on-call that survive growth, and close the production gaps that a growing team exposes.

• Startup tech consulting
• Software development
• Talk to an engineer