More engineers means more progress, right? Not necessarily.

Every engineer you add to your team puts strain on your existing systems. What are they going to work on without stepping on toes? Who is onboarding them? Who is reviewing their PRs? Who is answering their questions?

If you do not have a plan to answer those questions before people join, progress stalls.

I scaled a team from four engineers to 25 over 18 months across three timezones. It happened in three bursts, each driven by unpredictable business events you may see at your own company.

Every doubling broke a process that had been working at the previous size. The process required an operating-model redesign, not just more engineering power.

Here is what broke, what I changed, and what I would do differently next time.

The context

We started as a team of four tasked with modernizing an on-prem .NET 4 application and moving it to AWS. Each of us had broad expertise, and we operated as peers with no clear lead.

Our PM extracted requirements from the client, and the rest of the team picked up whatever needed to happen next. There was enough surface area in the codebase that we rarely got in each other’s way.

It was effective. It was simple.

That simplicity did not survive what came next.

Doubling 1: 4 engineers to 8

We got the app running in AWS and onboarded production users. Then a bombshell dropped: the client was being acquired by a multi-billion dollar company.

The acquiring company wanted to replace their current vendor with our platform, so they had a huge incentive to move fast.

The problem was that reaching feature parity with the old platform required a lot more hands. We scaled to eight engineers.

What broke

The “everyone picks up whatever is next” model collapsed immediately. With eight engineers, overlapping work became common.

Requirements arrived faster than anyone could process, and nobody had the full picture of what we actually needed to deliver.

What I changed

I became the dedicated lead. Roughly half of my time went to stakeholder meetings to clarify scope. The other half went to translating those requirements into tickets, Slack threads, and Zoom calls.

Being the lead let me catch impossible requirements early and identify scope cuts that saved weeks of work and budget.

This worked. We hit our first couple of milestones. But it was already clear we were not going to make the big deadline at the end of the year.

Doubling 2: 8 engineers to 12

We added four engineers: two seniors and two juniors.

That was enough growth that the model of “one flat team with Ken in every conversation” ground to a halt.

What broke

I could not be in every standup, PR review, and architecture conversation while also managing stakeholder communication.

Decisions stalled when I was in meetings. Junior engineers sat idle waiting for direction.

What I changed

I split us into two teams and designated a lead for each.

We were already roughly separated by timezone: half in Thailand, half in the Western U.S. I retained leadership of the U.S. team and formalized a lead for the Thai team.

I also defined clear ownership boundaries:

• Thai team: catalogs and new vendor integrations
• U.S. team: reporting, billing, and a Vue-to-React migration

The key move was splitting by feature domain, not seniority or skillset. Each team owned its area end to end. This reduced cross-team blocking and increased decision speed.

After a few months, we had successfully onboarded the new engineers and velocity was climbing. Then the next earthquake hit.

Doubling 3: 12 engineers to 25

A third, larger UK company wanted to form a joint venture around our platform. Overnight, scope doubled.

We added a second PM, a full set of performance and test engineers in the UK (a third timezone), and several new senior and junior developers across both existing teams.

This is where our issues really ramped up.

What broke

Just about everything broke at once.

We added a third responsibility group and redistributed engineers by skill set, but we were missing critical pieces. At the same time, the new partner mandated a full SDLC shift from agile-lite plus kanban to hard Scrum.

The impossible part: the UK company required Scrum and even replaced our CTO to enforce it, while the U.S. company still demanded hard deadline commitments.

Scrum assumes sustainable pace. If your deadline is faster than sustainable pace, Scrum stops working in practice.

We should have frozen development to focus on training, documentation, and team operating rules. Instead, we kept pushing impossible deadlines and spent six months with very little deliverable output.

What I would do differently

If I could do it again, I would fully step out of hands-on engineering and into a pure architect plus information-disseminator role.

I had 24 direct reports, which is too many for one person. I would assign three engineering managers, each owning six to eight people with clear expectations and goals.

Then I would own three functions only:

• Architectural vision across teams
• Clean information flow between teams and stakeholders
• Relentless documentation

With 12 engineers, context can live in Slack and standups. With 25 across three timezones, if something is not written down, it does not exist.

What I would not recommend

Do not pile too many roles onto one person.

I spent 80% of my time in client meetings and 20% managing 24 engineers. That is not workable. At this scale, you need dedicated management capacity for expectations, growth, performance, and day-to-day unblock support.

Lessons I learned

1. Treat each doubling as a re-org, not a staffing event. Pause, reset team boundaries, train people, and document operating rules before pushing feature velocity.

2. Install a management layer before you need it. Once direct reports pass the six-to-eight range, split people management from architecture and stakeholder communication.

3. Default to written communication in distributed teams. With three timezones and mixed seniority, undocumented decisions get lost and re-litigated.

What to watch out for

Acquisitions and partnerships

If your team grows gradually, transitions are smoother. Each new person has time to absorb the existing culture and process.

When a new company suddenly doubles your team, hit the brakes and realign.

Changes in team composition

A senior-heavy team that lives close to each other can survive on more informal communication. A team that lives across three timezones with mixed seniority cannot.

As distribution and experience gaps increase, management and documentation become survival infrastructure.

These are lessons learned from my high-pressure scaling event, but your constraints may be different. The core pattern still holds: what works at N people breaks at 2N.

The fix is almost always more structure and more delegation, not more effort from the same people.

What’s next

If this story of scaling from 4 to 25 engineers felt familiar, stay tuned for how a technical leader can keep writing meaningful production code without neglecting the team.

I will break down how AI tools change the math on a CTO or director staying hands-on, and which work you should still code yourself versus delegate.

If you want that post when it publishes, sign up below for alerts.