From 10 to 50 engineers, the team stops communicating on instinct. Small teams settle things in the hallway; large teams need written structure. An organization that hires 40 people while keeping the old habits loses the speed it had and picks up the cost of the new size.
Squads of 5 to 8 people per domain
Each squad covers one business domain, such as payments, accounts or search, and ships on its own inside it. Five to eight engineers: large enough to ship alone, small enough to talk directly. A shared domain keeps every feature from depending on another team.
A defined squad changes where decisions happen. Without squads, decisions climb to the CTO. With squads, they happen next to the people executing, and the change shows up in speed within weeks.
Matthew Skelton and Manuel Pais classify this team as stream-aligned in Team Topologies (IT Revolution, 2019) and name cognitive load per team, rather than headcount, as the real constraint on a large organization. Freezing a squad at eight people or fewer is the simplest defense against it.
A platform team of 2 to 4 engineers
A small team owns what is shared: CI/CD, monitoring, internal libraries, test environments. Without it, every squad rebuilds the same tool and holds the same argument. With it, the squad goes back to the product.
Treat that team as a product team with an internal customer. Its metrics: deploy time went down, repeated incidents disappeared, new-hire onboarding got shorter. Skelton and Pais call it a platform team and define its service as reducing the load on the people at the front line.
A guide to what each squad decides
Write what a squad settles alone: framework inside the squad, internal API design, local test patterns. Write what needs alignment: infrastructure changes, high-impact new dependencies, security decisions.
The guide removes the queue. Without it, everything climbs to you and the week becomes triage. With it, you step in for decisions that change the whole organization.
A standing 15% reserve for quality
Reserve 15% of each squad's capacity for work that ships no feature: refactoring, tests, documentation, dependency updates. It belongs in every sprint plan as a continuous practice.
The Google SRE book (Beyer et al., O'Reilly, 2016) defines toil as manual, repetitive work that could be automated and caps it below half of working time. A squad that skips the 15% reaches a point in 18 months where every new feature demands enough stabilization to stop the product.
A 30-day onboarding
Week 1. Environment up, first commit, domain reading. Weeks 2 and 3. Real tickets with mentoring and commented reviews. Week 4. Presentation of an improvement the engineer found on their own.
Documentation alone does not onboard anyone. People who join with someone next to them understand the system in two weeks and stay longer in the role.
Measuring outcomes instead of velocity
Velocity counts points closed inside one team and says nothing about whether the product improved. Replace it with four readings: lead time for changes, deployment frequency, mean time to restore, change failure rate.
Forsgren, Humble and Kim recommend those four metrics in Accelerate (IT Revolution, 2018) and show that they move together with organizational performance. Production bugs and team satisfaction sit beside them as secondary readings.
