Scaling an Engineering Team from 10 to 100
A practical guide to growing a tech organisation without losing the velocity and culture that made it work at small scale.
The bottleneck moves from code to coordination
At fifteen engineers, the limiting factor is how fast people can build. At eighty, it is how much they have to know about each other to get anything done. The work of scaling is mostly about keeping that second number small.
This is why team topology — how you split ownership — matters more than almost any individual hiring decision. Every boundary you draw is a decision about which conversations have to happen and which do not.
Small, durable teams with clear ownership consistently outperform large pools reshuffled per project. The reshuffling looks efficient on a resourcing spreadsheet and is expensive everywhere else.
Ownership has to be real
A team owns something when it can change it without asking, is on the hook when it breaks, and decides its own trade-offs within an agreed goal. If any of those is missing, you have assignment, not ownership, and the coordination cost stays.
The most common failure is ownership on paper with approval gates in practice. The team is accountable for an outcome but cannot make the calls that determine it, which produces exactly the passivity the structure was meant to remove.
Shared ownership of a critical system is usually worse than clear ownership by the team best placed to hold it. Two teams half-owning a service means nobody is confident enough to change it.
Invest in the paved road early
Shared CI/CD, observability, and onboarding documentation compound. What feels like overhead at fifteen engineers is the thing that keeps eighty productive, and it is much cheaper to build before the sprawl than after.
The signal to watch is how long a new engineer takes to ship something real. If that number is growing as the team grows, the paved road is behind the headcount and the gap will keep widening.
A useful discipline: whenever someone solves an environment problem for the second time, that solution belongs in the shared setup rather than in their notes.
Hire for the next stage, not the last one
The skills that built the product rarely match the skills that scale the organisation. Early engineers are often excellent at moving fast with little structure and less interested in building the structure that follows.
Plan hiring against where the team is going, and give early engineers an explicit path — technical depth or people leadership — rather than defaulting them into management because it is the only title available. Losing your first engineers during the scale-up is common and mostly avoidable.
Hire ahead of the pain for roles with long ramp times, and behind it for roles that can be productive in weeks. Getting that the wrong way round is what produces a team that is simultaneously overstaffed and blocked.
Keep the quality bar visible
Standards erode quietly. Nobody decides to lower the bar; it drops because the people who held it are now in more meetings, and the newest engineers calibrate against whatever they see merged.
Write the bar down — what review looks for, what has to be tested, what "done" includes — and it becomes teachable rather than tacit. Tacit standards do not survive tripling the team.
This is the same principle behind stop conditions for autonomous systems: if done and not-done are not distinguishable to someone new, they will diverge.
Related Reading
Building High-Performance, Outcome-Owned Pods
The principles behind embedded engineering pods that ship to commitments — dedicated teams, a delivery SPOC, and KPI-based accountability.
Read articleEngineering & DeliveryChoosing the Right SaaS Stack for a Growing Business
How to pick tools that fit your stage — and avoid the integration debt that slows teams down as they scale.
Read articleDigital MarketingSEO and AEO Are Not the Same Job
They share tooling and get sold together, but they optimise for different outcomes — a click versus a citation. Treating them as one job is why teams rank well and still go unmentioned.
Read article