Scaling Engineering Teams: What It Takes to Grow from 2 Engineers to 60

Scaling engineering teams means growing an existing team from a few engineers to dozens without losing delivery speed or quality. Beyond hiring, it covers who owns which part of the product, who leads each team, and how new people learn the system.

The need usually appears when a small team can no longer carry the roadmap. For example, customers still use your existing product and expect regular fixes. At the same time, the same engineers have to build the next version, and new hires don’t arrive fast enough to cover the gap.

Getting the structure right before adding people is important because every new engineer needs time to learn the system and adds more conversations to the team. Without that structure, a bigger team can ship more slowly than the small one did.

Practical answers are hard to find. Of the 8 guides on the topic we reviewed in October 2026, 6 from Google’s top 10 and 2 from a web search, none showed a named client example with headcount figures or listed the 5 current delivery metrics from DevOps Research and Assessment (DORA).

That is why we wrote this guide. We show the approach on our own work with MasterControl, a provider of manufacturing execution and quality management systems for regulated industries. Zoolatech’s team on that account grew from 2 engineers to a 60-engineer delivery organization and worked directly with MasterControl’s product teams on the existing platform and the new one.

Besides that case, we cover when to scale, why capacity grows slower than headcount, and how to scale an engineering team in six steps, each with a way to check the result.

By the end, you will know what to change before you hire, how to check that the bigger team delivers more, and when a partner’s engineers are the right way to add capacity.

When Is It Time to Scale Your Engineering Team?

It is time to scale your engineering team when work you have already agreed on is waiting for people to do it. If the delay comes from unclear priorities or ownership, new engineers spread the same confusion across a bigger group.

These signals usually show that the problem is a lack of engineers:

• Approved work waits for the same few people. The business has signed off on the tasks, and they sit in the queue because the engineers who can do them are busy.
• A single team supports two versions of the product. Every hour spent fixing the existing product comes at the expense of the new version.
• Open roles stay unfilled when the roadmap needs them. The work is planned for this quarter, and the people for it are still in interviews.
• Only a couple of engineers know a key system. When one of them is on vacation, work on that system stops.

Before you add anyone, check that three things are already in place:

• Priorities that stay the same for more than a sprint or two.
• Product teams with a named owner that new engineers can join. Step 1 explains how to set them up.
• A person on your side who can explain the system to newcomers. Step 4 covers this role.

The clearest sign that you should wait is a roadmap that changes every few weeks. DORA found in 2024 that unstable organizational priorities meaningfully decrease productivity and substantially increase burnout. The effect held even in teams with strong leaders and good documentation.

If your roadmap looks like this, stabilize the priorities first. Scaling software development teams on top of shifting goals only makes the problem bigger.

When the signals do point to a lack of engineers, it helps to know what to expect from new hires. Doubling the team rarely doubles delivery, and the next section explains why.

Why Capacity Often Grows Slower Than Headcount When Scaling Engineering Teams

Capacity often grows slower than headcount because each new engineer takes time to become productive and makes coordination harder for everyone else. The second effect is easy to underestimate because it grows much faster than the team.

Melvin Conway described this math in 1968. In his paper “How Do Committees Invent?”, he noted that the number of possible communication paths in an organization is approximately half the square of the number of people.

For example, a team of 6 people has 15 possible pairs who may need to talk. At 12 people, that number grows to 66, and at 24 people, it reaches 276. Smaller teams with firm boundaries keep most of these conversations inside the team, which is why the steps below start with structure.

Brooks’s law shows what happens when a plan ignores this. Frederick Brooks summed it up in The Mythical Man-Month (1975): “Adding manpower to a late software project makes it later.”

The law applies to projects already behind schedule. Brooks himself later called it an “outrageous oversimplification” that still captures the general rule. It rests on the same two effects, since new people need time to become productive and communication overhead grows with every person you add.

Data from Quantitative Software Management (QSM), a company that sells software estimation tools, shows the cost side. In a 2019 comparison of 390 applications of the same size, teams of 9 or more people cut the schedule by about 30% compared with teams averaging fewer than 4 people, while project cost rose by 350%.

This vendor dataset compares small and large teams across different projects, so it doesn’t describe one team growing over time.

For your growth plan, these findings point to two rules:

• Add people where communication stays cheap, inside teams with firm boundaries and a ready onboarding path.
• Avoid adding people to rescue a release that is already late.

The six steps below follow both rules.

How to Scale an Engineering Team in Six Steps

To scale an engineering team without slowing delivery, change the structure first and add people second. If you hire before teams, leads, and onboarding are ready, newcomers land in a system that cannot absorb them, and your strongest engineers spend their days answering questions.

This order is the core of how to scale engineering teams, because each step makes the next one cheaper. For example, once every product area has an owning team, you already know where each new hire will go and who will guide them.

The table sums up the plan. Each row is one step, with what you do, the result you should see, and a way to check it. You can copy it into your planning document and use the last column as a checklist after each hiring wave.

Step 1 – Set team boundaries, size and ownership before you hire

Set team boundaries, size, and ownership before you hire, because new engineers need a team and a product area to join. Without them, newcomers end up in a shared pool and wait for someone to hand them work.

Team boundaries also shape the product. In the same 1968 paper, Melvin Conway made the point now known as Conway’s law. A system’s design copies the communication structure of the organization that builds it.

Engineering team size has no universal number:

• Team Topologies limits a team by cognitive load, the amount of complexity it can keep in its head.
• Amazon’s two-pizza rule keeps teams small enough for two pizzas to feed, and the AWS whitepaper on the rule gives no headcount.
• A 1997 QSM study of 491 projects found that teams of 3 to 7 people worked best on medium-sized systems, though the data is old.

Team Topologies calls a team that owns one flow of work from design to release a stream-aligned team. For example, one team owns customer onboarding, and another owns reporting.

When you decide how to organize an engineering team for growth, add newcomers to existing teams if their work belongs to those teams’ areas. Create a new team when a new product line or platform needs its own owner. At MasterControl, Zoolatech engineers joined existing product teams directly.

Expected result: A team map where every component has one owning team and one lead.

How to check: Anyone can name the owner of a component in one step.

Common mistake: Hiring first and drawing the team boxes later.

Once each team has an owner, the next question is who leads it as it grows.

Step 2 – Add leads and management layers before teams outgrow them

Add leads and management layers before teams outgrow them, because an overloaded lead becomes the slowest part of delivery. Reviews, decisions, and questions from new engineers all queue up behind one person.

The right moment depends on workload, so we don’t tie it to headcount. Scaling engineering organizations requires a structure that can carry the coordination that used to happen in one room.

The table shows the usual stages of that structure. Each row describes how the work is organized, the signal that it is time to move on, and what to add next. Use the signal column to see which stage your team has already outgrown.

Keep teams talking as their number grows:

• Write decisions down where every team can find them.
• Review dependencies between teams on a fixed schedule, for example, every two weeks.
• Keep company-wide priorities visible to every team, even when each group plans its own roadmap.

If your teams work from different locations, our guide on how to manage a remote development team covers this in more detail. Culture needs the same attention, since new engineers copy what they see, so describe your way of working before the team doubles.

Expected result: Each lead has a workload they can handle, and each decision that affects several teams has an owner.

How to check: Leads’ calendars show time for reviews and one-on-ones, and few decisions wait for a single person.

Common mistake: Promoting your strongest engineer into management without support, or adding layers before they have a problem to solve.

With leads in place, you can decide where new engineers will come from.

Step 3 – Decide what to hire and what to add through an embedded partner

Decide what to hire and what to add through an embedded partner by considering how long each role needs to hold product knowledge. Without this split, the roadmap waits for hires, or key product knowledge ends up with people who will not stay.

Hire in-house for the roles that will hold product knowledge and lead teams for years, such as tech leads, architects, and engineers in your core product areas. Keep the same hiring bar, plan your interviewers’ time as part of the growth plan, and give every new role a team before the search starts.

Add an embedded partner team when an agreed roadmap needs capacity faster than you can hire. This is a group of a partner’s engineers who join your product teams, use your tools, and take direction from your leads.

Your main sources of engineering capacity:

• In-house hiring.
• Embedded partner engineers, a model also called team augmentation. Zoolatech calls its version team extension.
• A managed delivery team that owns a whole workstream.
• A project vendor for a defined deliverable with a fixed scope.
• An offshore delivery center for large, long-term teams.

Whatever mix you choose, count the hidden costs. A 2013 Strategic Management Journal study on services offshoring found that decision makers misestimate costs more often as setup and tasks grow more complex, and that experience and deliberate organizational design reduce these errors. Budget for onboarding, your leads’ time and coordination, along with the rates.

Zoolatech uses the embedded model with several clients. At Kin Insurance, we placed backend, frontend, full-stack, quality assurance (QA), and software development engineer in test (SDET) specialists, who became engineers integrated into Kin Insurance’s Agile product teams.

If you plan to grow from a few engineers to several dozen with a partner, set the rules before the first engineer starts. The partner’s engineers should work in your tools, join your team rituals, and go through your code review, with your leads directing the work. Agree in advance how the team can grow or shrink and where documentation lives.

The table lists the questions to settle with any partner before its engineers join your teams. The left column is the question, and the right column explains why it matters. You can forward it to procurement as a starting checklist.

If you want engineers who join your product teams this way, see Zoolatech’s team extension service.

Expected result: A written split of roles by source, with the team each person joins and the lead who directs them.

How to check: Every planned role has a source and a team, and partner engineers have a named lead on your side.

Common mistake: Handing a partner a package of requirements that depend on your product context and waiting for the result. Embed its engineers in the teams that own that work, and keep fixed-scope projects for a managed team or a project vendor.

Step 4 – Make onboarding repeatable, especially into legacy code

Make onboarding repeatable, especially into legacy code, because the speed at which newcomers start contributing sets the pace of the whole scaling plan. If each new engineer learns the system by asking whoever is free, your senior people lose their week, and the next wave arrives before the last one is ready.

Microsoft researchers open their 2021 study of developer onboarding by noting that onboarding experience is correlated with productivity, job satisfaction, and other outcomes. The study interviewed 32 developers moving into new teams and 15 engineering managers, then surveyed 189 developers and 37 managers, all at one company.

The link to productivity comes from earlier research the authors cite. That earlier work suggests onboarding can take more than six months, even for developers moving within the same company.

Legacy code makes this harder. Customers still depend on older code, often with little documentation and tightly connected parts, so a change in one place can break another.

The MasterControl case study names this as the key early challenge for our team, which had to quickly understand complex legacy systems. A dedicated expert guided the team through the existing systems’ challenges.

Before each wave of new engineers, prepare:

• One named guide who answers questions and reviews first changes.
• A short map of the system that marks its riskiest parts.
• First tasks in low-risk areas, each with a reviewer.
• Pair programming on every change to legacy code.
• Decisions written down as they are made.

We recommend starting the next wave only after the previous one ships reviewed changes on its own.

The same approach works when you onboard offshore developers onto an existing engineering team. Give them the same guide, map and first tasks as in-house hires, and plan enough overlapping hours for reviews. Our article on how to onboard offshore and other external teams has the full checklist.

Expected result: Every new engineer starts with a guide, a system map and safe first tasks, and begins shipping reviewed changes early.

How to check: For each wave, count the days between a person’s start date and their first reviewed change in production. If that number goes down from wave to wave and newcomers’ changes need no more rework than before, that is a good sign for your onboarding. Compare waves with similar roles and first tasks.

Common mistake: Skipping onboarding for senior engineers. Even experienced people need guidance and time to learn your legacy code.

Once new engineers can contribute, the next risk is that each writes and tests code differently.

Step 5 – Build standards and test automation into the growth

Build standards and test automation into the growth while the team is still small enough to agree on them. Every new engineer copies what the current team does, so habits that live only in a few people’s heads spread unevenly, and quality slips as headcount rises.

In the MasterControl engagement, our team improved development standards and QA automation as part of the scaling work, along with database performance.

What to put in place before the next wave:

• A written definition of done that every team uses.
• Rules for who reviews which changes.
• Automated tests for critical user flows that run on every change.
• The same rules for in-house and partner engineers.

In our view, quality is best when each product team owns its tests. In a separate MasterControl project with a different team, we moved test ownership to the development teams, removing SDET bottlenecks. That project also produced a reusable, centralized enterprise test automation framework for MasterControl that keeps new technical debt from piling up as teams grow.

For help building these checks into your pipeline, see our quality assurance and test automation services.

AI coding tools do not replace missing standards. DORA’s 2025 report, State of AI-assisted Software Development, describes AI’s primary role as an amplifier of an organization’s existing strengths and weaknesses. If your standards are weak, AI tools help the team produce more code with the same weaknesses.

Expected result: Every engineer follows the same written standards, and automated tests check each change before it ships.

How to check: Count how many releases cause problems in production. If that number stays the same as the team grows and code reviews do not wait for days, your standards are working.

Common mistake: Leaving testing to a separate group at the end of the process. Each product team should write and run its own tests as part of everyday work.

With standards in place, you need numbers that show whether each wave of hiring made delivery better.

Step 6 – Measure delivery before and after each wave

Measure delivery before and after each wave of new engineers, because a bigger team can look busier and still ship less. Take a baseline before the first hire, then compare the same numbers after every wave.

DORA’s research tracks five software delivery metrics, split into two groups. Throughput shows how fast changes reach production, and instability shows how often those changes cause problems.

The table lists all five. The first column names the group, the second gives the metric, and the third explains what it shows. Use the last column to agree with your leadership on what each number means before you start comparing.

DORA defines change lead time as the time it takes for a change to go from committed to version control to deployed in production. Rising throughput with flat instability is a good sign that scaling is working.

To set up the pipeline and dashboards behind these numbers, see our DevOps services.

Track team-level signals next to the DORA metrics:

• Days from a new engineer’s start date to their first reviewed change in production.
• Share of leads’ time spent on reviews and one-on-ones.
• How long code reviews wait.
• How many engineers leave.

Expected result: You can see in numbers how delivery changed after each group of new engineers joined.

How to check: Compare the numbers for the same service before and after a wave, over periods with similar work and the same release process. If the team ships more often, broken releases don’t become more frequent, and roadmap work moves faster, that is a good sign the growth is working.

Common mistake: Judging success by how many people you hired or how many tasks the team closed. On their own, these numbers do not show whether delivery got better.

The MasterControl case below shows several of these steps in practice.

Case Study: How Zoolatech’s Team at MasterControl Grew from 2 to 60 Engineers

Zoolatech’s team at MasterControl grew from 2 engineers into a 60-engineer delivery organization in about a year and a half. All of this growth happened inside MasterControl’s own product teams, on software used across regulated industries.

MasterControl needed more engineering capacity on two product generations at once. Customers relied on the legacy platform, and the company was building its next-generation platform alongside it.

How the team worked:

• Our engineers joined MasterControl’s product teams directly and worked as part of them.
• The team built new microservices and expanded the functionality of the legacy platform.
• It improved database performance, development standards and QA automation.

What changed for MasterControl:

• More product development capacity on the legacy and the next-generation platforms.
• Better quality, scalability and ability to deliver new functionality.
• Quick delivery of new features thanks to close work with the in-house team.

The case illustrates three steps from this guide. Our engineers joined existing product teams (Step 1), a dedicated expert guided them through the legacy systems (Step 4), and standards and QA automation improved as the team grew (Step 5).

The case does not record growth milestones, onboarding speed or delivery metrics, so read it as one example of the approach. The 60 engineers are Zoolatech’s team within the account, which is one part of MasterControl’s wider engineering organization.

You can read the full story of how Zoolatech’s team at MasterControl grew from 2 to 60 engineers.

Our team extension model places senior engineers, who use AI tools in their daily work, inside your teams with full delivery oversight. Every engagement includes a dedicated Delivery Manager, a live risk register and a formal QA checkpoint, and our teams work in your time zone.

When an Embedded Partner Team Is the Wrong Way to Scale

An embedded partner team is the wrong way to scale when your problem can’t be solved by more engineers. In these cases, outside engineers add cost and coordination work, and delivery stays as slow as before.

The table shows the most common of these situations. Each row names the situation, explains why partner engineers do not help there, and suggests what to do instead. Check your plan against it before you sign a contract with any partner.

The early-stage risk has data behind it. The 2011 Startup Genome report on internet startups found that startups that scaled too early outsourced 4 to 5 times as much of their product development as startups that grew steadily. This correlation comes from the startups’ own answers and does not describe large companies.

The hidden-cost risk comes from the 2013 offshoring study mentioned in Step 3. Its authors found that cost estimates go wrong more often as the setup and the tasks get more complex.

When nobody owns product decisions, no hiring model helps. Name an owner before you add a single engineer, in-house or external.

Final Word

Scaling engineering teams takes careful preparation. You have to redraw team boundaries, free up time for new leads, prepare onboarding, and agree on standards before the first new engineer arrives.

This preparation pays off. The order of the work decides whether a bigger team ships more or spends its days waiting for reviews and answers. A wrong order slows delivery and wears out the senior engineers who hold the system together.

Start with a baseline of your DORA metrics and a team map that gives every product area one owner. Then grow in waves, and let each wave contribute before the next begins.

If you need more engineers than you can hire in time, Zoolatech is ready to discuss how our engineers could join your product teams.