Team Topology: How to Split and Merge Teams
Every boundary you draw between teams is a handoff you have agreed to pay for indefinitely. That is the whole discipline: structure is not about drawing tidy boxes, it is about choosing which conversations get to be free and which will require a meeting, an email, and a two-day delay. Teams that grow too large slow down internally; teams split along the wrong line slow down externally, and the second problem is much harder to see because it looks like a coordination culture problem rather than a boundary error.
What’s inside
Draw boundaries where the traffic is lightest
Four signals to split
Three signals to merge
How to split without breaking what the team owns
The four boundary types
What to do about work that spans
Where Blomma fits
Draw boundaries where the traffic is lightest
The single principle worth internalising. Inside a team, communication is nearly free — people overhear each other, share context, and make small decisions without ceremony. Across a boundary, every exchange has a cost: a scheduled conversation, a written handoff, a priority negotiation between two managers.
So when you draw a boundary, you are deciding which communication becomes expensive. The right place to draw it is where the least communication needs to happen. Put the work that requires constant back-and-forth inside one team, and accept the cost at the seams where traffic is naturally light.
Most bad team structures come from drawing boundaries by discipline or convenience rather than by traffic. Splitting frontend from backend when every feature requires both puts a boundary directly across the highest-traffic path in the company. It looks tidy on a chart and it means every piece of work now requires two teams to agree on priority.
The practical test before any split: list the ten most common pieces of work and check how many would cross the proposed boundary. If most of them do, you are drawing it in the wrong place.
Four signals to split
One. The team is past the point where everyone holds the context.Somewhere around eight to ten people, depending on how similar the work is, a team stops being able to keep one shared understanding. Symptom: standups where half the updates are irrelevant to half the people, and decisions being made by subsets who then have to inform the rest.
Two. There are two distinct streams of work with different rhythms.One part of the team ships weekly, another part works on three-month projects. They will keep interrupting each other’s cadence, and the long-horizon work will always lose to the urgent work.
Three. The manager’s span is genuinely exceeded.Count reports, then weight for new hires, dissimilar work, and whether the manager is also carrying delivery. A wide span degrades development first and silently, and splitting is one of the two available fixes.
Four. Two clear ownership areas have emerged with little overlap.If the team has effectively become two groups who rarely need each other, the boundary already exists informally and formalising it costs little.
What is not a signal: the team is under pressure and splitting feels like doing something. Splitting a struggling team usually produces two struggling teams and a new coordination cost.
Three signals to merge
Merging gets far less attention than splitting and is often the better move.
One. Two teams cannot ship anything without each other.If every meaningful piece of work requires both, the boundary is in the wrong place and merging removes a permanent tax. This is the most common and most under-diagnosed structural problem in growing companies.
Two. The teams are negotiating priority constantly, and it escalates.Two managers arguing monthly about whose roadmap wins is a boundary problem presenting as a relationship problem.
Three. One team is too small to be a team.Two or three people with a manager is usually an expensive way to have three people. They lack the range to absorb absence, they have no internal peer review, and the manager is underemployed.
Merging is politically harder than splitting, because it usually means one manager loses a team. That is a real cost and it is frequently worth paying — but handle the conversation properly, because the manager who loses the team is the person who will make or break the merge.
How to split without breaking what the team owns
Splits fail on the details, and the details are predictable.
Decide what each new team owns — outcomes, not activities.If both new teams own “parts of the product,” you have created a permanent negotiation. Each needs an outcome it can be held to.
Assign the shared assets explicitly.The codebase, the on-call rotation, the documentation, the customer relationships, the test infrastructure. Anything unassigned becomes nobody’s, immediately and durably. This is where most splits actually degrade.
Name the interface.How the two teams request things from each other, and who decides when they conflict. Without this, the answer becomes “escalate,” and the escalation lands on you.
Do not split the specialists to zero.A split that leaves each new team with one designer, one data person, and no peers has solved a span problem and created an isolation problem. Check the specialist count before you split, and consider whether those roles should stay grouped.
Keep one team intact where the risk is highest.If one area is fragile or in the middle of something critical, split around it rather than through it.
The four boundary types
Useful vocabulary, because most companies use only one and need several.
Outcome-owning teams.Own a customer-facing result end to end, with enough function inside to deliver it. Should be the default and the majority.
Platform teams.Build things other teams use. Their customer is internal, their success measure is other teams’ velocity, and they fail when they are treated as a request queue rather than a product team with a roadmap.
Specialist groups.Deep expertise consulted across the company — security, data science, sometimes design. Small, and they work when engagement is deliberate rather than ad hoc.
Temporary teams.Assembled for a specific push, dissolved after. Legitimate and underused. The failure is not dissolving them — a temporary team that persists becomes a permanent boundary nobody chose.
Most structural confusion comes from a team being one type and treated as another: a platform team measured on features shipped, or a specialist group expected to own delivery.
What to do about work that spans
Some work will always cross your boundaries, whatever you choose. Three options, in order of preference.
Move the boundary.If the same work keeps spanning, the boundary is wrong. This is the honest answer more often than people want.
Give one team the decision and the other an obligation to support.Not a joint decision — one owner, with the other required to contribute within an agreed time. Joint ownership of spanning work is what produces the negotiations that escalate.
Create a temporary team.For a defined push, with an explicit end date and a named owner. Genuinely effective and requires the discipline to actually dissolve it.
What does not work: a standing coordination forum whose job is to manage a boundary you drew badly. That is paying an ongoing tax to avoid a one-off structural fix, and the forum will grow.
Where Blomma fits
Split and merge decisions are argued by the people whose teams are being split or merged, which means the input you get is sincere and positioned. A manager whose team is being merged into another is losing scope. A manager advocating for a split may be advocating for a bigger remit. Neither is acting badly and neither is neutral.
Blomma is an always-on AI career coach with no stake in your structure. Use it to run the traffic test before a split — the ten-pieces-of-work check that determines whether the boundary is in the right place. Use it to work through the merge cases, which founders systematically avoid because the conversation is harder. Use it to make sure the shared assets get assigned, which is the detail that most often degrades a split. And use it to prepare the conversation with a manager who is losing a team, which is the single thing that determines whether a merge works.
The second application: a split creates a new manager, usually someone who has not managed before, and a merge creates a manager with a suddenly larger and unfamiliar span. Both are stretch situations, and coaching is what turns them into growth rather than a struggle attributed to the individual..
Team boundaries are the most consequential structural decision you make repeatedly, and the principle is simple enough to hold: draw them where the traffic is lightest, and be willing to redraw them when the traffic moves.