Scaling Engineering Teams from 4 to 90+: The Inflection Points That Actually Matter

Over the past decade, I have scaled engineering teams through four distinct phases: from 4 to 15 at Riot Games, 15 to 45 at Tally, 45 to 72 at Chainlink Labs, and 72 to 90+ at Sky Mavis. Each phase broke everything that worked in the previous one.

The single most important lesson: what got you here will not get you there. The org design, communication patterns, delivery systems, and leadership behaviors that work at each stage are fundamentally different. Leaders who fail to recognize these inflection points — and adapt their approach accordingly — become the bottleneck their teams route around.

Phase 1: The 4-to-15 Transition (Riot Games)

When I joined Project L at Riot Games, we were four engineers building a AAA fighting game from scratch. By the time I transitioned out, we had scaled to 15. This phase is deceptively simple — you are still small enough that everyone can fit in a room.

The critical shift at this stage is from individual contribution to team architecture. At 4 engineers, you do not need process. You have lunch together. You pair program. Everyone knows what everyone else is working on because you overhear it. At 10, small cracks appear. At 15, those cracks become canyons.

When to Add Your First Engineering Manager

The most common question I get from founders: "When do I need my first engineering manager?" The answer is not a headcount number — it is a symptom set.

You need your first engineering manager when:

• The technical lead is spending more than 40% of their time on people issues (1:1s, hiring, conflict resolution) instead of technical decisions
• Engineers are waiting more than a day for decisions because the bottleneck is one person
• You are missing milestones not because of technical complexity but because of coordination failures
• Two or more engineers have told you they are not sure what they should be working on

At Riot, we hit this around engineer 8. I shifted from writing Unreal Engine 4 and Go code full-time to splitting my time between architecture decisions and team coordination. The milestone predictability improvement was roughly 35% once we formalized this role. That number is not coincidental — it is what happens when engineers stop context-switching between technical work and organizational guesswork.

The "Two-Pizza Team" Myth

Amazon's "two-pizza team" heuristic gets repeated as gospel, but having been at Amazon Lab126 and then managing teams at four companies since, I can tell you: the right team size depends on the coupling of the work, not an arbitrary pizza metric.

At Riot, our 15-person engineering team operated as three loosely-coupled pods of 5. Each pod owned a vertical slice of the game — networking, gameplay, and tools. This worked because the interfaces between pods were well-defined. At Tally, a 7-person team working on a single acquisition funnel was too large because every change touched shared state. We split it into 3 and 4, and velocity doubled.

The real heuristic: a team is too large when it takes more than 15 minutes to get everyone aligned on a single decision.

Phase 2: The 15-to-45 Transition (Tally)

At Tally, I managed 45+ engineers and 4 engineering managers across full-stack, client, and QA teams. This is where most engineering leaders fail for the first time, because this phase requires you to stop being the best engineer in the room and start being the best manager of engineers.

How Delivery Systems Change

At 15 engineers, your delivery system can be a Trello board and a weekly standup. At 45, you need:

1. A real sprint cadence with estimation, capacity planning, and retrospectives
2. Cross-team dependency management — because teams now block each other
3. An experimentation platform — at Tally, we built one that doubled our feature iteration speed
4. Formalized on-call and incident response — because outages now have revenue impact
5. Engineering-wide demos — because the left hand no longer knows what the right hand is building

The experimentation platform we built at Tally was a turning point. Before it existed, shipping a feature meant committing to it. After, we could test 10 ideas per sprint and kill 8 of them quickly. This single system change doubled our feature iteration speed and fundamentally changed how product and engineering collaborated.

The Manager-of-Managers Shift

At 45 engineers with 4 managers, you are no longer managing individual contributors. You are managing managers. This is a fundamentally different skill that most people underestimate.

The biggest mistake I see: leaders who become "super managers" — attending every standup, reviewing every PR, second-guessing every decision. This kills your managers' authority and creates learned helplessness. Instead, you need to:

• Set clear outcomes for each team, then get out of the way
• Coach your managers, not their reports
• Intervene only when a team is off-track for more than one sprint
• Build a leadership team culture where managers hold each other accountable

Phase 3: The 45-to-72 Transition (Chainlink Labs)

At Chainlink Labs, I led 72 engineers across 7 teams, delivering 35+ blockchain integrations supporting over $50 billion in total value locked. This phase is where organizational design becomes your most important technical decision.

Process vs. Culture at Scale

There is a persistent myth in engineering that process kills culture. The opposite is true: the absence of process at scale kills culture. When 72 engineers do not know how decisions get made, who owns what, or how to escalate blockers, frustration breeds faster than features.

At Chainlink, we implemented what I call "minimal viable process" — the lightest-weight system that maintains coherence across teams:

• Team charters — one-page documents defining each team's mission, boundaries, and interfaces
• RFC process — any cross-team technical decision required a written proposal before a meeting
• Weekly sync of leads — 30-minute standing meeting where the 7 team leads surfaced blockers and dependencies
• Quarterly roadmap alignment — 2-day planning sessions where teams presented proposals and negotiated priorities

This process reduced partner onboarding time by 45% because teams could operate independently while staying aligned on shared standards.

Phase 4: The 72-to-90+ Transition (Sky Mavis)

At Sky Mavis, I led a 90+ person global organization spanning Engineering, Product, and DevRel. This was not just more engineers — it was a fundamentally different organizational shape because it crossed functional boundaries.

Metrics That Matter

At 90+ people, you cannot rely on intuition. You need measurement systems that tell you whether the organization is healthy before problems become visible. The four metrics I track religiously:

1. Deployment frequency — how often you ship to production. At Sky Mavis, we achieved a 2.2x improvement in deployment frequency through CI/CD pipeline optimization and team autonomy
2. Cycle time — time from code commit to production. We reduced this by 40%, which compounded into dramatic throughput gains
3. Change failure rate — percentage of deployments that cause incidents. This is the quality check on velocity
4. Time to restore — how quickly you recover from failures. This measures operational maturity

These are the DORA metrics, and I have found them to be the most reliable signal of engineering health at scale. The 2.2x deployment frequency improvement at Sky Mavis did not come from asking people to work harder — it came from removing organizational friction.

Platform Strategy at Scale

At 90+ engineers, you need a platform strategy. Individual teams cannot afford to rebuild common infrastructure. At Sky Mavis, we invested heavily in our Layer-1 platform capabilities, which tripled monthly active developers building on our ecosystem.

The platform team investment formula I use: dedicate 20-25% of total engineering capacity to platform work once you pass 50 engineers. Below that, the overhead of a dedicated platform team is not justified. Above that, the cost of duplicated effort across teams exceeds the cost of the platform team.

The Universal Patterns

Across all four phases, certain patterns hold true regardless of team size:

1. Communication Overhead Grows Quadratically

At 4 people, you have 6 communication pathways. At 15, you have 105. At 72, you have 2,556. Every new hire makes communication harder, not easier. Your job as a leader is to create structures that reduce the communication burden — clear ownership, well-defined APIs between teams, and written-first culture.

2. Hiring Speed Is a Trailing Indicator

The fastest way to destroy a team is to hire faster than you can absorb. I use a simple rule: never grow faster than 30% per quarter. Every new hire requires onboarding bandwidth from existing engineers. Exceed the absorption capacity, and you get a team that is large on paper but moves slower than when it was half the size.

3. Culture Is Set by the First 15

Your engineering culture is effectively locked in by the time you reach 15 people. After that, you are reinforcing or fighting what already exists. This is why the 4-to-15 phase matters so much — the technical practices, communication norms, and values you establish there become the DNA of the organization.

4. The Leader's Job Changes Every 18 Months

At every phase, I had to unlearn what made me successful in the previous one. The hands-on technical leader who was essential at 4 engineers is a liability at 45. The process designer who scaled the team from 45 to 72 needs to become a strategist at 90+. If your job feels the same as it did 18 months ago, either you have stopped growing or your team has.

What I Would Do Differently

Looking back across these four scaling arcs, three things I would change:

1. Invest in written communication earlier. At every company, the transition from verbal to written decision-making came too late. Start RFC culture at 10 engineers, not 30.
2. Hire engineering managers before you need them. By the time you feel the pain, you are already 3 months behind. Bring in your first EM at engineer 8, not 15.
3. Measure from day one. Deployment frequency, cycle time, and change failure rate should be tracked from the first sprint. You cannot improve what you do not measure, and retrofitting metrics into a running organization is far harder than building them in from the start.

Scaling engineering teams is not a linear process. Each phase has its own physics, and the leaders who succeed are those who recognize the inflection points before they become crises. If you are in the middle of one of these transitions and want to talk through it, I work with companies navigating exactly these scaling challenges.