You have twelve engineers. Velocity is down. Standups are running long. Two workstreams keep stepping on each other in code review. The obvious move feels like splitting the team — create two focused squads, reduce the coordination overhead, ship faster.
Here's the thing: you're probably looking at the wrong variable.
The reflex when a team gets unwieldy is to divide by the number of workstreams, or by product surface area, or by some org chart logic that made sense in a slide deck. Csaba Okrona, via Exec Engineering, makes a sharper argument: the number of bets or workstreams is the wrong thing to divide on. What actually gates the split is how many leaders you have ready to run the resulting teams. Hiring an engineer takes a quarter. Finding someone who carries your codebase, your domain knowledge, and a real read on your people takes considerably longer.
That reframe changes the whole decision.
The Signal You're Actually Seeing Is a Coordination Problem
When teams slow down as they grow, the mechanism is usually communication overhead, not capability. The math is brutal: a 5-person team has 10 possible communication channels; a 9-person team has 36; a 15-person team has 105. Each new hire doesn't add one relationship — they connect with everyone already there. Past 7 people in a decision-making group, research cited by Bain & Company found that each additional member cuts decision effectiveness by roughly 10%.
So yes, your twelve-person team probably does have a coordination problem. The question is whether splitting solves it or just relocates it.
A split creates two teams that now need to coordinate with each other at the seam. If the work is genuinely separable — different domains, different codebases, different users — that seam is thin and the split pays off. If the work is entangled, you've traded internal coordination overhead for cross-team coordination overhead, which is often worse because it's slower and more formal. The same logic applies to microservices: split only when you can draw a clean data boundary, when teams are actually blocking each other in the release process, or when parts of the system have genuinely different scaling needs. "The monolith feels messier every sprint" is not a reason. Neither is "we might need to scale someday."
The test for a team split is the same test: can you draw a clean boundary? If the answer requires a lot of asterisks and exceptions, the split will produce two teams that spend half their time in cross-team syncs, which is just a standup that runs even longer.
The Constraint That Actually Limits You
Assume you've confirmed the boundary is clean. The work is genuinely separable. Two teams would be better than one. Now you hit the constraint Okrona identifies: who runs the second team?
This is where most managers make the mistake. They announce the split, draw the org chart, and then go looking for a lead — or worse, they promote someone into the role because the structure demands it, not because the person is ready. The promotion-as-default problem is one this newsletter has covered before: the best IC on the team is not automatically the right person to run half of it.
A team lead who isn't ready will cost you more than the coordination overhead you were trying to escape. They'll need more of your time, not less. The team under them will feel the uncertainty. The split that was supposed to accelerate delivery will slow it down for six months while the new structure finds its footing.
The honest version of the split decision is: do I have two people who can run these teams, or do I have one? If the answer is one, you're not ready to split yet. You're ready to develop a second leader — which is a different project with a different timeline.
What to Do While You Wait
If the coordination overhead is real but the leadership bench isn't there yet, you have options that aren't a full split. Cleaner domain ownership within the existing team reduces the stepping-on-each-other problem without requiring a new reporting structure. Small teams operate differently than large ones — the practices that work at twelve people aren't just diluted versions of what works at thirty. Explicit ownership of subsystems, async-first communication for non-urgent coordination, and ruthless prioritization of what actually needs to be in the same room can buy you significant runway.
The split is the right call eventually. Teams that stay too large under a single manager hit the same ceiling every time. But the timing is set by leadership readiness, not by headcount or the number of workstreams on the roadmap.
When you have two people who can run teams — not two people you're hoping will grow into it, but two people who are ready now — that's when you split. Everything before that is preparation.