Split when one team can no longer hold its work in one head, and a clean line exists to cut along. Otherwise don't. In our view the squad model is often sold as a scaling strategy when it's really a response to conditions: too many people for one backlog, work that separates into areas with few cross-dependencies, and a lead who has become the bottleneck. If you're a VP Engineering at 15 engineers wondering about the next 25, the useful questions are the ones below: where to cut, who leads each side, and what happens to on-call, code ownership and contractors. The wider set of leadership topics sits in our Engineering management guides for CTOs and VPs of Engineering.
What a squad is, and what it is not
A squad is a team that owns an outcome, not a list of tickets. Team Topologies calls the closest thing a stream-aligned team and defines it in one line: "Stream-aligned teams deliver direct value to customers along a value stream. They own the outcomes." That's the test. If the team can ship, run and fix its slice of the product without waiting on another team for routine work, it's a squad. If it only receives tasks, in our judgment it's a feature team or a project team with a nicer name.
The Spotify model is where most people first met the word. Our judgment is that it's best treated as one company's snapshot, not a template. Take the part that travels (small, outcome-owning teams) and leave the tribes and guilds until you have a reason for them.
When to split one team into squads (and when not to)
Start with the Scrum Guide, which describes a Scrum Team as "large enough to complete significant work within a Sprint, typically 10 or fewer people." It also says larger groups should consider "reorganizing into multiple cohesive Scrum Teams, each focused on the same product." That's the one sourced threshold here, and it's a ceiling, not a trigger.
Signals that say split (our judgment, none of these has a published threshold):
- Planning and stand-ups have become broadcast events, and most of the room waits through items that don't touch their work.
- Delivery is slowing as headcount grows. Each new hire adds less than the last.
- One lead reviews, decides and unblocks for everyone, so throughput is capped by their calendar.
- Engineers can name the part of the product they know well, and they rarely touch the rest.
Team Topologies gives the underlying reason: "Just as overloaded CPUs slow down computers, overloaded teams make poor decisions and move slowly." Cognitive load is what you're managing, not headcount.
When not to split: when there's no separable domain, because every change touches every part of the codebase and you'd create two teams that block each other daily. And when you're small. Our judgment is that below roughly 8 engineers you can't staff two teams with real autonomy, so add a senior engineer or a tech lead first. If you're unsure, run the test in the next section. If no axis comes out clean, stay one team.
Choose the split: product area, customer journey or platform
Every split has an axis. Pick it with evidence, not taste.
| Axis | Use when | Risk | Example |
|---|---|---|---|
| Product area (domain) | Features cluster into areas with their own data and rules | Shared code gets orphaned | Billing squad, search squad |
| Customer journey or segment | Different users need different things, and the flows rarely overlap | Duplicated components across squads | Onboarding squad, enterprise squad |
| Platform | Several squads keep rebuilding the same infrastructure or tooling | The platform team drifts from what squads need | Deployment, auth, data pipelines |
| Complicated subsystem | One area needs rare expertise (video encoding, a pricing engine) | Becomes a single point of failure | Rules engine, ML models |
Team Topologies describes the platform row as teams that "create services that accelerate stream-aligned teams, removing complexity." In our judgment, most teams at 15 to 40 engineers need stream-aligned squads first and a platform team later, if at all.
The risks are our judgment, not research findings.
A quick test: pull the last 90 days of merged pull requests (and closed tickets) and tag each by product area. Count how many involve more than one area. The axis with the fewest cross-cutting changes is your cut. If a large share of PRs cross your proposed boundary, you've drawn it in the wrong place, or the code isn't ready to be split. This is our heuristic; decide your tolerance before you look at the data.
Who leads each squad
Decide two roles per squad: a technical lead and a person accountable for people and delivery. On a small squad one person can do both for a while. For what the technical role covers, see what a tech lead owns.
The management question is the hard one. The instinct is to promote two new engineering managers on day one. The Engineering Manager newsletter on Substack argues against it, in a piece about a director of engineering who made themselves redundant: promote or hire one engineering manager for one sub-team, and lead the other sub-team directly yourself. The piece's concern is too many new managers learning the ropes at once. The point that two new managers would have no experienced peer to learn from is ours. In our judgment this works if you currently manage 8 or more engineers directly and have the energy to keep leading a squad for a few months. It doesn't work if you're already stretched.
Choose the second leader before the split date, not after.
Each squad also needs a clear product counterpart, a product manager or product owner who sets priorities. Our judgment is that one PO covering two squads is a short-term fix that tends to turn into a standing bottleneck.
For membership, ask engineers for their preferences in 1:1s, then balance for seniority and domain knowledge so no squad ends up all-junior or all-new. That's judgment, not research. Levels can be a sensitive topic during a reorg, so check how squad leads and contractors sit on your career ladder before you announce anything.
What breaks when you split
The split looks tidy on a slide. These four things come apart in the first month.
On-call
Decide whether each squad runs its own rota or everyone shares one. Our recommendation: start with a single shared rota, then move each service to a squad rota as that squad shows it can own it. A squad that can't debug its own service at 3am shouldn't be paged for it alone. Once ownership is real, per-squad rotas keep incident pain close to the people who can remove its cause. For rota length, escalation and handover, see setting up an on-call rotation.
Code ownership
Write down who owns what. GitHub's CODEOWNERS is one way to do it: according to GitHub Docs, a code owners file names the people or teams responsible for code in a repository, and they're requested for review on pull requests that touch it. Map paths to squads, keep cross-squad review for shared areas, and give every shared library a named owner. In our judgment, a library everyone depends on and nobody owns is the likeliest thing to rot after a split.
Shared services and platform work
Every shared service needs three things: an owner, a way in, and an expectation of response time. Run intake as a visible queue, not a Slack DM to whoever knows the system. Team Topologies defines one interaction mode as "X-as-a-Service: one team provides and one team consumes something 'as a Service'." In our opinion it's the cleanest fit for anything stable (CI, deployment, auth), and you should expect closer collaboration while the service is still being shaped.
Knowledge silos and the first 90 days
In our judgment, squads create silos by design, so expect speed to dip at first and pockets of knowledge to harden. We haven't found a sourced figure for how long the dip lasts, so treat any number you hear as a guess, ours included. A reasonable plan, as judgment: budget about two months of reduced throughput, and set a review date at eight weeks. Counter the silos with cross-squad design reviews, a shared incident review, and rotating engineers through other squads' code in review.
Where contractors and nearshore engineers sit
Spread them or group them? In our judgment, spread them. A dedicated contractor squad is easy to manage on paper but gets the leftover work, and in-house knowledge never reaches it. Put contractors inside squads that own an outcome, next to in-house anchors.
Keep in-house anchors in every squad. Our guide to sizing a blended agile team sets a floor for in-house engineers per team, and no squad should drop below it after the split. Give contractors the same repo access as employees on the same squad, the same on-call obligations if they own the service (agree this in the contract before the first page, not after), and IP terms in writing before they commit code. If you bring in nearshore engineers to staff a new squad, plan the offboarding as carefully as the onboarding: access revocation, knowledge handover and who owns the runbooks.
How to split a team into squads
1. Decide the axis
Run the 90-day PR test from above and choose the axis with the fewest cross-cutting changes. Write down the one-sentence reason, so you can revisit it later.
2. Name each squad's mission
Give every squad an outcome, not a component. "Own checkout conversion" works; "maintain the payments module" doesn't. If you can't write the outcome in a sentence, the boundary is wrong.
3. Pick the leads
Choose the technical lead for each squad, and decide who manages each one. Follow the single new manager rule if you can: one new manager, and you lead the other squad directly. Tell the chosen leads before the team hears.
4. Allocate engineers
Collect preferences in 1:1s, then balance seniority, domain knowledge and the in-house anchor floor. Place contractors inside squads rather than in a separate one.
5. Assign on-call and ownership
Publish the shared rota, the service-to-squad map and the code ownership file on the split date. Name an owner for every shared library and every shared service.
6. Review at eight weeks
Put the review in the calendar now. Check cross-squad PR volume, incident handling and lead workload. Move a boundary if the data says so; a first split is rarely the final one.
What this means for your headcount plan
You're deciding where the next five hires sit and who runs squad two. The split drives both. It sets how many leads or managers you need, and it decides where contractors go.
Hire or promote the second lead before the split date, because a squad that starts without one will route every decision back to you. Keep at least your in-house anchor floor in every squad before you place a single contractor. And plan the budget and the roadmap for roughly two months of reduced throughput (our judgment, not a measured figure), so the dip doesn't read as failure.
If the split leaves one squad without a manager, start with our guide to when to hire your first engineering manager, which covers the signals, promoting versus hiring, and the span of control to plan for.
FAQ
How many engineers do you need before splitting into squads?
There's no sourced minimum. The Scrum Guide's ceiling is "10 or fewer people" per team, so a team past 10 is where reorganising starts to make sense (our judgment; the Scrum Guide gives a ceiling, not a trigger). As judgment, we'd want at least four engineers per squad for real autonomy, which puts the floor for two squads at about eight. Below that, one team with a strong tech lead is simpler.
Should each squad have its own engineering manager?
Not on day one. The advice in the Engineering Manager newsletter is to promote or hire one manager for one sub-team and lead the other directly. That limits the number of new managers you're training at once. Revisit when you've run the split for a couple of quarters (our judgment).
Who is on call when a squad owns a service?
Ideally the squad that owns it. In practice, start with a shared rota and move each service to its squad's rota once the squad can debug and fix it. Contractors who own code in that service should join the rota, with the terms agreed in the contract in advance.
How long until a new squad structure pays off?
We haven't found a trustworthy sourced figure, so we won't give you one. Expect an initial dip in speed, plan a review at around eight weeks (our judgment), and judge the result by cross-squad dependencies and incident handling, not by velocity alone.