You have fifteen engineers. Standup runs forty minutes. Half the room checks out after the first ten. PRs sit for days because nobody's sure who owns what. You keep telling yourself you'll fix the process — better Jira hygiene, clearer swim lanes, a proper definition of done. But the process isn't the problem. The team is too big, and you've been managing around that fact instead of addressing it.
Here's what makes team splits hard: the moment you actually need one, you're already past the point where it's clean.
The Overhead You're Not Counting
The math on communication overhead is unforgiving. A team of five has ten communication paths. A team of fifteen has 105. That's not a linear increase — it's a coordination tax that compounds silently until velocity collapses and nobody can quite explain why.
This is what Brooks' Law is actually pointing at. Adding people to a complex project doesn't linearly increase output because onboarding and coordination costs are real. The new hire isn't the problem. The structural overhead they inherit is.
I'd argue most managers misread the signals because they're looking for a single dramatic failure — a missed deadline, a blown incident — rather than the slow bleed of friction. The real signals are subtler: standups where more than half the content is irrelevant to most of the room; engineers who've stopped asking questions in planning because the answer will probably change anyway; PRs that sit not because reviewers are busy but because nobody's sure they're the right reviewer.
Two or more of those at once and you're not approaching the threshold — you're past it.
What You're Actually Optimizing For
Before you draw the new org chart, get clear on what a split is supposed to accomplish. The goal isn't smaller headcount per manager. It's reduced coordination surface per engineer — smaller teams with clear ownership that can each operate with low overhead while aggregate output scales.
That distinction matters because it determines how you split. The worst splits are by technical layer: frontend team, backend team, infrastructure team. You've traded one coordination problem for another. Now every feature requires cross-team negotiation, and you've formalized the silos that were already slowing you down.
The better split is by domain ownership — product surface, customer segment, or system boundary. Each team gets a clear answer to "what do we own?" and the authority to make decisions within that boundary without running everything through a joint planning session.
Em-tools puts it plainly: plan your target structure before you start splitting. If you're going from one team of twelve to two teams of six, who manages each? What does each team own? What decisions can they make independently? Having that target in mind before you announce anything is what separates a restructure from a reorganization that takes six months to stop being disruptive.
Where Splits Go Wrong
The most common failure mode isn't choosing the wrong boundary — it's splitting before you have the management layer to support it. A single manager can effectively oversee five to eight engineers. If you're at twelve direct reports and you split into two teams of six, you need a second manager. That person needs to exist before the split, not after.
Promoting into that role mid-restructure is possible, but it stacks two hard transitions on top of each other: the new manager is learning the job while the team is learning its new identity. Both are recoverable, but doing them simultaneously is a choice with real costs.
The second failure mode is splitting on paper while leaving the actual work entangled. Two teams that share a codebase without clear ownership boundaries, or that both need to touch the same service to ship anything, aren't really two teams. They're one team with extra meetings. The split has to follow the work, not just the headcount.
A third pattern worth watching: the split that's really a demotion in disguise. If one of the new teams gets the interesting greenfield work and the other inherits the legacy system nobody wants to touch, you haven't solved a coordination problem — you've created a retention problem. The engineers who end up on the maintenance team will notice within a quarter.
How You Know It's Working
Three months after a clean split, you should see standup get shorter and more relevant. Engineers should be able to describe what their team owns without hedging. Planning sessions should produce decisions rather than parking lot items.
The leading indicator I'd watch most closely: are engineers making calls within their domain without escalating? If the answer is yes — if the team lead is resolving scope questions without pulling you in — the ownership boundary is real. If everything still routes through you, the split was organizational theater.
Three questions to ask before you split:
- Can I draw a clear boundary around what each new team will own — and would the engineers on each side agree with that description?
- Do I have (or can I develop) a manager for each team before the restructure, not after?
- Is the work actually separable, or are the teams going to need each other to ship anything meaningful?
If you can't answer all three, you're not ready to split. But you're probably already overdue to figure out why.