10-to-50 Scaling Playbook

The startup doubled its engineering team in a year and shipped less than it had the year before.

At 12 engineers, the founder made the technical calls and "just ask someone" worked. By 40, the founder was the bottleneck on every decision, three teams had built three deployment scripts, and the best engineer had been promoted to manager and was still writing most of the critical code. The leadership team's answer was a weekly status meeting.

(Composite example, assembled from patterns common in engineering teams growing quickly past their first few dozen people. The figures are illustrative.)

The breakage between 10 and 50 is mostly math, not management failure: the number of relationships grows much faster than the headcount. This playbook starts from what breaks, then works through team design, managers, process and the timeline, so you redesign deliberately instead of just adding chairs.

Step 1: name what's breaking

• ☐ Which of these is hurting most right now: ______

• ☐ The evidence you're seeing: ______

Step 2: make the team topology decisions

(Vocabulary from Team Topologies, Skelton and Pais, 2019.)

• ☐ Stream-aligned by default: teams own a product area or domain end to end (front end, back end, data and infrastructure). Avoid component teams split by layer, because they turn every feature into a multi-team handoff, unless the subsystem genuinely needs specialist depth (Team Topologies' "complicated-subsystem" team).

• ☐ Team size ~5–8 (Team Topologies' range): below 5 struggles to absorb absences; much above 8 and communication starts to degrade. Will Larson's guidance of six to eight engineers per manager points the same way.

• ☐ Platform team, our rule of thumb: somewhere around 20–40 engineers, once infrastructure duplication across teams is a measurable drag. Building one at 15 is usually early.

• ☐ Name the interaction mode for each team pair: Collaboration (high-bandwidth, temporary, used sparingly), X-as-a-Service (the most common mode once boundaries are stable) or Facilitating (enable, then step back).

Step 3: manage the manager transition

• ☐ Accept that your best individual contributor is not automatically your best manager. The skills are different.

• ☐ Build a dual ladder early, so Staff and Principal engineers match Managers and Directors in seniority and pay.

• ☐ Support first-time managers, who tend to avoid hard conversations, micromanage and keep doing IC work.

• ☐ Keep engineering managers focused on people development, team health, delivery coordination and cross-team communication.

• ☐ As a working rule, keep IC coding to roughly 10–20% of an EM's time, and never on the critical path. That's a rule of thumb from experience, not a research figure.

Step 4: add minimum viable process

The goal is enough structure to prevent chaos, not so much that it prevents speed.

Step 5: document only the high-leverage knowledge

• ☐ Architecture decisions (ADRs, Nygard's format: what you chose, what you rejected, and why).

• ☐ System operations: deploying, incident response, production access.

• ☐ Team interfaces: APIs and what each team can expect from the others.

• ☐ Onboarding paths: week one, month one, quarter one.

Skip the rest and let it live in the code and the commit history.

Step 6: plan for the trough

(A pattern we see often, not a benchmark. Treat the month ranges as a rule of thumb from experience, including the 12–18-month trough.)

• ☐ Where you are on this timeline: ______

• ☐ What you'll do if the trough arrives: ______

Step 7: decide what to keep and what to let go

• Can't keep: everyone knowing everything, a flat hierarchy, zero process.

• Can keep, because it's cultural, not size-bound: a bias to action, technical excellence, trust and autonomy, psychological safety, an ownership mentality.

How to use it

• Who: the head of engineering with the tech leads and managers. Revisit it each time headcount grows by about a team.

• Output: a named list of what's breaking, a team map with interaction modes, a manager-support plan, a short list of processes to formalise, and a dated note of where you are on the timeline.

• Done when: every team has an owner and a named interaction mode with its neighbours, deployment, on-call and technical decisions each have a written process, and the leadership group has agreed in advance how it will respond to the trough.

Where this changes

Below about ten engineers most of this is premature: one team and one decider work fine until they don't. In regulated or very large organisations, change approval, access control and audit trails become part of "minimum" process, and one platform team becomes several. The reasoning behind this playbook is in scaling from 10 to 50 engineers without losing the culture. For keeping delivery speed, read scaling engineering teams without losing velocity, and to start recording decisions, use the architecture decision record (ADR) template.

Final takeaway

Growing from 10 to 50 changes the shape of the problem, not just its size. Design the teams on purpose, help new managers become managers, add only the process that prevents chaos, and expect the trough so you don't mistake it for failure.

Sources

• Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution, 2019). https://teamtopologies.com/book. Key concepts: https://teamtopologies.com/key-concepts

• Frederick P. Brooks Jr., The Mythical Man-Month (Addison-Wesley, 1975; anniversary ed. 1995). Overview, including n(n−1)/2: https://en.wikipedia.org/wiki/The_Mythical_Man-Month

• Michael Nygard, Documenting Architecture Decisions, Cognitect blog, 15 November 2011. https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions

• Will Larson, Sizing engineering teams, lethain.com, 14 July 2018. https://lethain.com/sizing-engineering-teams/