How to Scale Your Engineering Team from 10 to 100

Most engineering leaders hit a wall somewhere between 10 and 30 people. What worked when you could hold the whole team in one standup stops working — fast. The communication overhead explodes, delivery slows down, and the processes that felt lightweight suddenly feel like they're strangling you.

I've been through this transition multiple times. Here's what I've learned.

The 10-Person Team Is a Prototype

A 10-person engineering team is a prototype of an engineering organization, not the real thing. Everyone knows everyone. You share context informally. Pull requests get reviewed by whoever has bandwidth. Hiring decisions feel obvious because you're hiring people into a culture that lives in people's heads.

That works — right up until it doesn't.

The fundamental problem with scaling is that the things making you effective at 10 people become liabilities at 30, and outright blockers at 100. Informal communication doesn't scale. Shared context doesn't scale. "We'll figure it out" doesn't scale.

The teams that scale well are the ones that recognize this early and start building infrastructure — not just technical infrastructure, but organizational infrastructure — before they need it.

Stage 1: 10 to 30 People — Build the Foundation

This stage is where most of the architectural decisions about your organization get made, often without anyone realizing it. The patterns you establish now will calcify fast.

Introduce Team Topology Intentionally

At 10 people, you probably have a single team doing everything. That's fine. But by the time you hit 20–25, you need to make an explicit decision about how to split. The options are essentially:

• By layer (frontend team, backend team, platform team) — easy to start with, creates handoff friction at scale
• By product domain (payments team, onboarding team, growth team) — harder to set up, dramatically better at scale

I've seen companies make the wrong call here and spend 18 months untangling it later. If you're building a product company and you know you'll keep scaling, start orienting around domains early, even if it feels premature.

Promote From Within — But Pick the Right Person

The question I get asked most often: when do I promote an IC into management vs. hire externally?

My strong bias is to promote from within. An internal hire already has team context, earned credibility with peers, and a realistic picture of the problems they're stepping into. External management hires take months to build trust that an internal candidate already has — and sometimes they never do.

But the filter matters. Don't promote your best engineer. Promote the person with the strongest soft skills and genuine ambition to grow people. Those are different things. The best coder on your team is often the worst choice for EM — you lose a great IC and gain a reluctant manager.

What I look for: someone who naturally helps teammates think through problems, who others go to when they're stuck, who gets energy from seeing people around them grow rather than from their own output. Couple that with real ambition — not just contentment to take the role — and you have a strong candidate.

When a team hits 5–6 engineers, it needs a dedicated manager. Not a tech lead who also manages as a side job. A manager. Give them real scope and real expectations from day one.

Document How You Work

At 10 people, your engineering process exists in people's heads. That has to change.

This doesn't mean bureaucracy. It means writing down:

• How work gets from idea to production
• What "done" means
• How incidents get handled
• What on-call looks like and what's expected of people in it
• How code review works

You don't need a 50-page engineering handbook. You need enough documentation that a new hire can orient themselves without shadowing someone for two weeks.

Stage 2: 30 to 70 People — Operationalize Everything

This is the stage that breaks the most companies. The team is big enough that things genuinely get complex, but leadership hasn't yet built the operating model to handle that complexity.

Span of Control Is a Real Constraint

I've watched senior leaders try to manage 12 direct reports while also being the technical decision-maker for the whole organization. It doesn't work. You end up with a bottleneck disguised as a leader.

The rough limits that hold up in practice: ICs can handle 6–8 direct reports if the work is similar. EMs managing EMs can push a bit higher. But when span of control exceeds those limits, you lose signal, decisions slow down, and people feel unsupported.

Audit your org chart regularly. If someone has too many reports, it's not a personal failing — it's an org design problem.

Define the Technical Leadership Structure

Around 40–50 engineers, you need clarity on the distinction between technical leadership and people management. These are different tracks, and conflating them makes both tracks worse.

I use a model where Staff Engineers own technical direction within a domain, and Engineering Managers own team health, delivery, and people development. They're peers. Neither reports to the other. This sounds simple but requires real discipline to maintain — especially when a strong engineer wants people responsibility or a strong manager wants to weigh in on architecture.

Stay Technical — Even as a Manager

This one is personal, and I don't think it gets talked about enough.

Pure people managers who fully detach from code lose two things over time: technical credibility with their team, and a sense of the work itself. That second loss is underrated. Management burnout is real, and one of the biggest drivers is the feeling that your day is 100% meetings, politics, and process — with nothing to show for it at the end.

My approach has always been to keep a small technical contribution alive, even as my scope grows. Not ownership of a critical path, not being a bottleneck. But occasional PRs, staying close to architecture decisions, sometimes pairing with an engineer on something hard. Enough to stay grounded.

It makes me a better manager. I still feel what my engineers feel. I can smell when something is underestimated, or when a technical choice is being driven by convenience rather than correctness. And honestly, it keeps me sane.

If you're a new EM coming from an IC track, don't let anyone tell you that touching code is a sign you haven't fully committed to the role. Find the right balance for your context — but don't abandon technical work entirely. You'll miss it, and your team will notice its absence.

Metrics Actually Matter Now

At 10 people, you know if things are going well. At 50, you don't — not intuitively. You need leading indicators.

The ones I rely on most: deployment frequency, change failure rate, mean time to restore, and cycle time. These are DORA metrics, and they're useful precisely because they're hard to game. A team can inflate velocity easily. Shipping frequently without breaking things is genuinely hard.

Pair engineering metrics with team health signals — eNPS, voluntary attrition, how quickly new hires get to first production contribution. Numbers alone won't tell you everything, but they'll surface problems before they become crises.

Build a Hiring Machine

At this stage, hiring is a constant activity, not a periodic one. That means your process needs to be systematized.

Things that need to exist:

• A defined interview process with consistent scoring
• A structured onboarding program (not "here's a Jira board, good luck")
• Calibration sessions so "strong hire" means the same thing across interviewers
• A sourcing pipeline that isn't entirely dependent on inbound applications

The teams that scale recruiting effectively treat it as a core engineering function, not an HR function that engineering occasionally participates in.

Stage 3: 70 to 100 People — Distributed Leadership at Scale

By now, you're running a real organization. The founder's vision isn't enough to align 90 people — you need operating cadences, clear strategy, and layers of leadership that can make good decisions without you in the room.

Your Job Changes Completely

If you're the CTO or VP of Engineering, your job at 100 people looks almost nothing like your job at 10. You're no longer the best engineer on the team or even the best manager. You're setting direction, developing your senior leaders, and ensuring the organization can execute against a strategy you helped create.

This is a hard transition for a lot of technical leaders. The work that made you good at earlier stages — hands-on technical contribution, being in every important meeting, having context on every project — becomes an antipattern.

The leaders who make this transition well tend to have one thing in common: they figure out what only they can do, and they let go of everything else.

Autonomy With Alignment

The biggest tension at scale is between team autonomy and organizational alignment. If you swing too far toward control, you kill the initiative and speed that makes engineering effective. If you swing too far toward autonomy, you end up with 12 teams building in 12 directions.

The mechanism I've seen work best is a clear, written strategy — not a mission statement, but an actual statement of what you're trying to accomplish, what bets you're making, and what you're explicitly not doing — combined with strong norms around how teams communicate decisions.

Write things down. Run a consistent planning cadence. Make your reasoning visible, not just your conclusions.

Invest in Platform and Internal Tooling

By 100 people, you've almost certainly accrued significant infrastructure complexity. The cost of that complexity — in cognitive load, onboarding time, and lost velocity — is no longer abstract.

This is when a dedicated Platform Engineering team pays for itself. Their job isn't to own infrastructure — it's to make every other engineering team more productive. Golden paths for spinning up new services. Internal developer portals. Standardized observability. Shared authentication and authorization patterns.

The teams that skip this investment at 100 people pay for it at 200.

The Things That Never Stop Mattering

Across all three stages, a few things stay constant:

Psychological safety. People have to feel safe raising problems early. If your culture punishes bad news, you'll get bad news late and in the worst possible form.

Communication overhead is not the enemy. At scale, the instinct is to cut meetings and reduce process. But the real goal is effective communication, not minimal communication. Some overhead is coordination, which is real work.

Culture is a product. You can't set it once and forget it. As the team doubles, the proportion of people who were there for "the early days" drops. Culture has to be transmitted deliberately, through the stories you tell, the behaviors you reward, and the ones you don't tolerate.

Scaling an engineering team is one of the hardest organizational challenges in tech. Not because the tactics are secret — they're not — but because executing them requires making hard decisions under uncertainty, often before the need is obvious.

The teams that get it right don't just scale headcount. They build the organization to match.

I'm an engineering leader and consultant specializing in team scaling, technical strategy, and organizational design. If you're navigating this transition, let's talk.