How do you scale an engineering team from 5 to 50+?

Key facts

• The number of possible one-to-one channels in a team grows roughly in proportion to the square of its size: 10 among 5 people, 105 among 15 and 1,225 among 50.
• Amazon's two-pizza rule says no team should be big enough that it would take more than two pizzas to feed it, ideally fewer than 10 people, with single-threaded ownership of one product or service. (Source: AWS Executive Insights, Amazon's two-pizza teams)
• Melvin Conway argued in How Do Committees Invent?, published in Datamation in April 1968, that organisations which design systems produce designs that copy their own communication structures, an idea now known as Conway's law. (Source: Melvin Conway, How Do Committees Invent? (1968))
• Google's research on team effectiveness found that how a team works together matters more than who is on it, and ranked psychological safety first of five dynamics, ahead of dependability, structure and clarity, meaning and impact. (Source: Google re:Work, Understand team effectiveness)
• DORA measures software delivery with five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. (Source: DORA, Software delivery performance metrics)
• Team Topologies, by Matthew Skelton and Manuel Pais, describes four fundamental team types: stream-aligned, enabling, complicated subsystem and platform. (Source: Team Topologies, Key concepts)
• Dr. Dulan Dias founded EchonLabs in a university boarding room in 2017 and grew it to a team of 60+ before its acquisition by AINSUNHZ Global Technology Pte. Ltd. in 2026. (Source: Dr. Dulan Dias, career record)

Definitions

Stream-aligned team

A team that owns one flow of work, usually a slice of the product or a customer journey, from idea through production and support. The term comes from Team Topologies.

Platform team

A team that builds internal services, such as deployment, observability or data tooling, which other teams use as a product instead of each rebuilding them.

Engineering manager

The person accountable for a team's people and delivery health: hiring, one-to-ones, growth and performance. A tech lead, by contrast, is accountable for the team's technical direction.

DORA metrics

Measures of software delivery from the DORA research programme, covering throughput (lead time, deployment frequency, recovery time) and instability (change fail rate, rework rate).

Why does a team that worked at five stop working at fifteen?

Communication load grows much faster than headcount. Five people have 10 possible one-to-one channels; fifteen have 105; fifty have 1,225. At five, everyone knows everything because they were in the room. At fifteen, decisions start happening in conversations half the team never hears, and at fifty nobody can hold the whole system in their head.

Structure is the answer, and it shapes the product as much as the team. Conway's law, from a 1968 paper by Melvin Conway, holds that a system's design copies the communication structure of the organisation that builds it. So choose team boundaries that match the architecture you want.

What changes at each stage of growth?

The bands below are rough and drawn from practice rather than research. Teams reach each one at different sizes, so watch the warning signs rather than the headcount.

How should you split an engineering team into smaller teams?

Split by product area or customer journey, not by technology layer. A front-end team and a back-end team need each other for every feature; a team that owns checkout or onboarding end to end can ship on its own. Amazon's version is the two-pizza team: ideally fewer than 10 people, with single-threaded ownership of one product or service, including running it after launch. When demand grows, Amazon splits a team rather than enlarging it.

Team Topologies, by Matthew Skelton and Manuel Pais, names the other team types a growing organisation needs: platform teams that turn shared infrastructure into an internal product, enabling teams that help others adopt new practices, and complicated-subsystem teams for genuinely specialist work, such as a model that needs deep machine learning expertise. Create a platform team when several teams keep rebuilding the same deployment, observability or data tooling, not before.

When should you add engineering managers?

Add the first engineering manager when a tech lead can no longer do both jobs well: one-to-ones, hiring and performance conversations crowd out technical work, or happen badly because there is no time. Other signals are engineers asking who looks after their career, and performance problems that linger because nobody owns them.

Do not make the best engineer a manager by default. Offer two tracks with equal standing: management for people who want to grow others, and a technical track (staff or principal engineer) for people who want to stay deep in the system. Promote into management people who have shown they want the work, and train them before their first team, not after their first crisis.

How do you hire quickly without lowering the bar?

Fast growth exposes hiring as a process. Write a scorecard for each role before interviewing, use the same structured questions and a realistic work sample for every candidate, and have each interviewer score independently before the debrief. Treat onboarding as part of hiring: a written guide, a buddy, and a first change in production within the first week.

Dr. Dulan Dias founded EchonLabs in a university boarding room in 2017 and grew it to a team of 60+ before its acquisition in 2026. Growth on that scale only holds together once hiring, onboarding and everyday decisions stop depending on the founder being in every conversation, and making that true is most of the work of scaling an engineering team.

Hire leaders slightly ahead of need. A manager who joins before a team is overloaded can shape it; one who joins after spends a year repairing it.

Which processes do you need as the team grows?

Each piece of process should answer a failure you have actually seen. Add these roughly in this order as the signals appear.

1. Written technical decisions: short documents recording what was decided and why, once people start reopening old choices.
2. An on-call rota and blameless incident reviews, once outages affect customers.
3. A release routine with automated tests and one way to deploy, once shipping depends on a particular person.
4. Planning on a fixed cadence, once teams depend on each other's work.
5. Delivery metrics. DORA's five (change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate) show whether a process change helped or hurt.
6. Review for changes that cross team boundaries, once one team's change can break another team's system.

How do you keep the culture as the team grows?

Culture is what people do when the founders are not in the room, so it has to be written down and modelled. Google's research on team effectiveness found that how a team works together matters more than who is on it, and ranked psychological safety first: people need to be able to admit a mistake or ask a basic question without it being held against them.

To protect that while scaling, write values as behaviours (we write decisions down; we review incidents without blame), have leaders admit their own mistakes first, keep teams stable long enough to build trust, and check in early with new managers' teams through skip-level conversations. For the first hires on an AI product specifically, see how to build an AI team; for how senior technical roles split, see technical co-founder vs CTO.

Frequently asked questions

Sources

1. AWS Executive Insights, Amazon's two-pizza teams
2. Melvin Conway, How Do Committees Invent? (Datamation, 1968)
3. Google re:Work, Understand team effectiveness
4. DORA, Software delivery performance metrics
5. Team Topologies, Key concepts