Scaling from 5 to 40 Engineers Without Losing the Plot
The magic of a small team isn't culture — it's proximity. When you scale, you can't preserve it. You have to replace it with something deliberately designed. Most teams import a playbook from a company ten times their size instead.
You notice it in the standup. Five engineers, it was five minutes — someone’s stuck, someone pairs, everyone moves. Twenty-five engineers, it’s forty-five minutes of status updates nobody acts on. Somewhere around engineer fifteen, someone says “that’s not my team’s responsibility” for the first time. It’s a small sentence. It marks the end of something.
Then the senior hire arrives. VP of Engineering from a company ten times your size. They look at the org, they look at the process — or the absence of it — and they say the thing everyone’s been thinking: “We need to be more mature about this.” They bring OKRs. Sprint ceremonies. An architecture review board. A four-layer code review process. Each one individually reasonable. Together, they’re a solution designed for a problem you don’t have yet — and by the time you do have it, the team that could have solved it organically has already left.
The magic wasn’t culture — it was proximity
At five engineers, alignment is free. Everyone hears every conversation. Context is ambient. Decisions happen at lunch. You call this “culture” — and you’re fiercely protective of it — but it’s actually a side effect of being small enough that communication overhead is near zero.
Fred Brooks illustrated the problem in The Mythical Man-Month: the number of communication paths in a team grows with N(N-1)/2. At ten engineers, that’s 45 paths. Manageable. At forty, it’s 780. The magic doesn’t die because someone killed it. It dies because it was never designed to survive headcount growth. You’re mourning a property of smallness, not a property of your culture.
The military solved this centuries ago. A sergeant commands a squad of eight to twelve. A lieutenant commands three to four squads. The hierarchy isn’t bureaucracy — it’s a communication architecture designed around the limits of human attention. Engineering organisations rediscover this constraint every time they scale. Most rediscover it the hard way — not by designing the hierarchy, but by letting it emerge from whoever shouts loudest.
This is the part that stings: the early days weren’t as intentional as they felt. The speed was partly skill, partly chaos, partly people working unsustainable hours because they believed in the thing. The alignment was partly shared values, partly the fact that everyone sat in the same room — or the same Slack channel, for teams that were distributed from day one. Romanticising it is natural. Building your scaling strategy around preserving it is a mistake.
The messy middle has no playbook
Startup advice says move fast, stay flat, hire generalists. Enterprise advice says add process, define roles, build hierarchy. Between fifteen and forty engineers, neither works.
This is the gap nobody writes the guide for. Camille Fournier’s The Manager’s Path is precise about how leadership challenges evolve with team size — from IC to manager, from manager to director — but her lens is the individual’s transition, not the organisation’s identity crisis. Claire Hughes Johnson’s Scaling People covers the mechanics well — as Stripe’s COO, she helped scale the company from under 200 to over 7,000 — but Stripe’s resources aren’t typical. The messy middle isn’t a resourcing problem. It’s a design problem, and most teams panic and import the enterprise playbook wholesale because it’s the only playbook that’s written down.
The result is process theatre. OKRs that get written quarterly and never referenced. Sprint retrospectives that produce the same three action items nobody acts on. Velocity metrics tracked on dashboards that nobody opens. Each ceremony performed with the form but not the function — like the original cargo cult building bamboo control towers and waiting for the planes to land.
The adult in the room
The pattern is consistent enough to have a shape.
The company hits twenty engineers. Coordination is painful. The founders — technical, capable, stretched thin — decide they need “an adult in the room.” They hire a senior engineering leader from a company that already solved these problems. The new hire arrives with a playbook that genuinely worked there.
But often the founders hire the VP and then won’t actually delegate authority. The VP has responsibility without power — and the only lever left is process. They introduce structure not because they’re bureaucrats, but because it’s the only tool they’ve been given. The founder still makes every architecture decision, still reviews every PR that matters, still overrides sprint priorities on a Thursday afternoon. The VP imports OKRs because they can’t import trust. The team gets the overhead of management without the benefit of actual delegation.
Spotify’s squad model is the canonical cautionary tale. In 2012, Henrik Kniberg and Anders Ivarsson published a whitepaper describing Spotify’s approach — small autonomous squads, loosely coupled, tightly aligned. The accompanying culture videos landed in 2014 and went everywhere. Hundreds of companies adopted the model. Most of them missed what made it work at Spotify: years of investment in shared infrastructure, sophisticated platform engineering, and a culture that had evolved the model organically rather than imposed it from a presentation. Joakim Sundén, an agile coach at Spotify from 2011 to 2017, later said it plainly: “Even at the time we wrote it, we weren’t doing it.” The imitators hadn’t noticed.
The playbook isn’t wrong. It’s premature. The same code review gates that catch production bugs in a 200-person org create two-day bottlenecks when you have three qualified reviewers. The same OKR process that aligns a thousand engineers across fifty teams creates meaningless busywork when you’re one team that talks every day. The architecture review board that prevents costly mistakes at scale prevents any decision at all when you need to ship in a week.
And the cost isn’t just speed. The engineers who joined because it was fast — the ones who built the thing that’s now worth scaling — watch the process layer thicken and start updating their LinkedIn profiles. You hired the adult in the room to solve a coordination problem. You solved it. You also created an attrition problem. The trade wasn’t intentional, but it was predictable.
What you’re actually solving for
The instinct when things get painful is “we need process.” The actual problem is “we lost shared context.”
At five engineers, everyone knew the deployment pipeline. They knew the on-call rotation by heart because there were three people in it. They knew which endpoint was fragile because the person who wrote it sat two metres away. At forty, a new hire doesn’t know which Slack channel to ask in when the build breaks. The tribal knowledge that was free at ten people doesn’t transfer because nobody wrote it down. Nobody wrote it down because, at ten people, writing it down felt like overhead.
The instinct is to solve this with rules. Approval gates. Mandatory reviews. Documented procedures. But rules replace judgment with compliance. The engineer who used to deploy with confidence now waits for sign-off from someone who has less context than they do. The team that used to self-organise around a problem now waits for a sprint planning session to tell them what to work on. You haven’t scaled the culture. You’ve replaced it with bureaucracy and called it maturity.
The counterweight is real: some process exists for legitimate reasons that have nothing to do with maturity theatre. If you’re selling to enterprise clients, they’ll ask about your change management process before they sign. If you’re in a regulated industry, an auditor will want to see approval trails. If your board is asking how engineering investment maps to business outcomes, OKRs might be the least painful answer. The question isn’t whether process is justified — sometimes it is. The question is whether you’re adding it because the situation demands it or because someone told you that’s what “grown-up” companies do.
The deeper fix is to scale context, not rules. I’ve written about this before — Conway’s Law ensures your systems mirror your communication structures whether you design for it or not. The Inverse Conway Manoeuvre — the core insight of Skelton and Pais’s Team Topologies — is that team structure is itself an architectural decision. The practical version is simpler than the theory. Make the reasoning behind decisions visible. Make ownership explicit. Treat onboarding as architecture — because every new engineer who doesn’t understand the system will build against it.
What to keep, what to kill, what to build
Keep small teams with clear ownership — but be deliberate about who you hire into them. Between fifteen and forty engineers, hiring is the scaling strategy. Generalists who tolerate ambiguity, seniors who build structure without importing it wholesale. The wrong hire at this stage — someone who needs a playbook before they can operate — costs you more than a bad architecture decision. You can refactor a codebase. Refactoring a team that’s been trained to wait for instructions is a different order of difficulty.
Kill any process you adopted because “that’s what mature companies do.” If you can’t name the specific problem a ceremony solves — not a category of problem, the specific one — it’s theatre. At one company, I watched a newly-introduced architecture review board add four days to every deployment. The two engineers who’d built the core system — who had been deploying three times a day — started routing around the process, then stopped caring, then left. The review board was solving a problem the company didn’t have yet, and the cost was the people who’d built the thing worth reviewing. You can always bring process back when you actually need it. You can’t easily bring back the engineers who left because shipping a feature required permission from a committee.
Build the structures you actually need at this scale. Not more meetings — fewer, better ones with explicit decision-making authority, so nobody has to guess who can say yes. Async communication that replaces the ambient awareness you lost — decision logs, short internal write-ups, recorded architecture discussions. A lightweight ownership map so new hires know who to ask. These aren’t glamorous. They don’t photograph well for engineering blog posts. But they work.
The plot you’re trying not to lose isn’t the speed. Speed at five engineers was partly chaos, partly luck, partly hours that nobody should sustain. The plot is alignment without overhead — the ability to move in the same direction without a bureaucracy telling you which way to face. Some companies choose to stay small enough that alignment remains free — Basecamp built a business on that principle, though their 2021 internal crisis showed that small teams have their own failure modes. The rest of us have to design the replacement: enough structure to coordinate, not so much that it suffocates. The line moves as you grow. The discipline is in moving it deliberately rather than letting it drift — and in remembering that the goal was never the process. The goal was the thing you were building before the process arrived.