Team Topologies and splitting a team

"You have a 15-person team owning too much. Split it. Walk your reasoning."

What it is

Team Topologies (Skelton and Pais, 2019) is an organisational design vocabulary with three parts: four team types, three interaction modes, and one sizing principle.

The four team types. Stream-aligned teams own a slice of business value end to end and are the default; most teams should be this. Platform teams reduce the cognitive load of stream-aligned teams by providing self-service capabilities. Enabling teams temporarily raise another team's capability and then leave. Complicated-subsystem teams own a component requiring deep specialist knowledge (a pricing engine, a video codec, a ranking model).

The three interaction modes. Collaboration is high-bandwidth and temporary, for discovery. X-as-a-Service is clean consumption across a stable interface. Facilitating is coaching.

The sizing principle is cognitive load: a team's scope is bounded by what the team can hold in its collective head, not by headcount or by lines of code.

The mistake worth naming up front: applying the labels without changing the interaction modes. Renaming your infrastructure team to "platform team" and leaving them as a ticket queue changes nothing, because the defining property of a platform team is that consumers self-serve, not what the team is called.

The problem it solves

Teams are usually split by layer (frontend, backend, database, mobile) or by technology (the Java team, the data team). Both feel natural and both create the same failure: every feature must pass through three backlogs, so lead time is the sum of three teams' queues and nobody owns the outcome. Conway's law then freezes the architecture into the same shape, and you get an integration-heavy system that mirrors the org chart.

The alternative framing is that team boundaries are an architectural decision. Splitting by stream of value gives you teams that can ship without cross-team coordination; splitting by layer guarantees they cannot.

Mechanics

Cognitive load, made concrete

The abstract version ("don't overload teams") is useless in a design discussion. The operational version has three components, from Sweller's original categorisation:

• Intrinsic: the inherent difficulty of the domain. Reduce it with training and hiring, not with reorganisation.
• Extraneous: the accidental burden of the environment. How to deploy, how the CI pipeline works, how to get a database provisioned. This is what a platform team exists to eliminate, and it is usually the largest and most fixable component.
• Germane: the effort of learning the business domain. This is the valuable part and you want teams spending their capacity here.

To measure it, count the things a team must hold: distinct services on call for, distinct business domains, distinct languages and runtimes, distinct external integrations, distinct stakeholder groups. There is no magic number, but a team carrying nine services across four unrelated domains in three languages is demonstrably over capacity and you can say so with evidence rather than vibes.

The strongest indicators, in order of how convincing they are in a room:

1. Onboarding time. How long until a new hire ships independently? Six weeks and climbing means the domain no longer fits in a head.
2. Bus factor per area. If exactly one person can safely change the billing code, the team does not own billing; that person does.
3. Interrupt rate. Fraction of a sprint consumed by unplanned support for areas nobody is actively working on.
4. Deploy coupling. How many other teams must be involved to ship a typical change.

The split procedure

Step 1: map the value streams, not the code. List what users actually do: search for a product, add to cart, check out, track an order, request a refund. These are the candidate stream boundaries. Do this before looking at the service list, because the service list encodes the old org chart.

Step 2: map the current services onto those streams. Services that serve exactly one stream are easy. The interesting cases are services touched by several, which are either a genuine platform capability, a complicated-subsystem candidate, or an accidental god-service that should be decomposed.

Step 3: check the cut against change history. This is the empirical step most people skip. Pull the last six months of commits and compute which files change together:

# For each commit, list the top-level directories it touched.
# Pairs that co-change frequently should probably be inside one team boundary.
git log --since=6.months --name-only --pretty=format:'---%n' \
  | awk '/^---$/{if(n>0)print s; s="";n=0;next} NF{split($0,a,"/"); if(!(a[1] in seen)){s=s" "a[1]; seen[a[1]]=1; n++}} /^$/{delete seen}' \
  | tr ' ' '\n' | sort | uniq -c | sort -rn | head -30

If your proposed boundary cuts through a set of directories that change together in 40 percent of commits, the boundary is wrong: you have just converted an in-team change into a cross-team negotiation. This is the single most useful evidence to bring to the discussion, because it turns a debate about opinions into a debate about data.

Step 4: assign types and, critically, interaction modes. The types are the easy part. The interaction modes are where the design actually lives, and they are what nobody writes down.

Step 5: name what you are deliberately not doing. A split creates new seams. Say which ones you accept and how you will manage them.

The interaction modes matter more than the labels

The sequence that works is collaborate to discover the interface, then converge to X-as-a-Service. A pair of teams stuck in permanent collaboration is the tell that the boundary is in the wrong place.

A worked example: splitting the 15

A 15-person team owning a retail platform. Nine services, four unrelated domains, three runtimes. Symptoms: onboarding takes eight weeks, on-call pages 4.2 times per week per person, and 35 percent of each sprint goes to unplanned support.

Value streams identified: browse and search; cart and checkout; order fulfilment and returns. Plus a set of capabilities every stream needs: CI/CD, observability, environment provisioning, the shared design system.

Co-change analysis: search-api and indexer change together in 61 percent of commits touching either, so they belong in one team. checkout-api and payment-adapter co-change in 48 percent. order-service and notifications co-change in 9 percent, which means the obvious "orders and notifications go together" grouping is wrong; notifications is a shared capability.

The proposed structure:

Where the numbers come from and what breaks. Fifteen people do not divide into four teams cleanly, which is the real constraint and worth stating plainly. The honest version: three stream teams of five, four and five, with the ranking specialist embedded in Discovery initially and the complicated-subsystem team formalised at the next hire. There is no platform team yet, because with 15 people a platform team of two would starve the streams and produce a half-functional platform. Instead, extraneous cognitive load is attacked by adopting a paved road from outside (managed CI, managed observability, an internal developer platform if the company has one) and by rotating one engineer per quarter onto tooling.

That last decision is the interesting one, and it is the answer to the follow-up you will get: at 15 people you cannot afford a platform team. Platform teams pay off somewhere north of 50 to 100 engineers, because below that the platform's consumer base is too small to amortise its cost. Below that scale you buy the platform or you designate a paved road and enforce it.

What I would deliberately not do: split frontend from backend, which would force every feature through two backlogs; create a "shared services" team owning notifications and payments, which would become the bottleneck every stream waits on; or reorganise before instrumenting, because without a baseline for onboarding time, interrupt rate and deploy coupling there is no way to tell whether the split worked.

How I would know it worked, and this is what makes it a proposal rather than a diagram: onboarding time under four weeks within two quarters; interrupt rate under 15 percent of a sprint; cross-team changes (a single logical change requiring commits in two teams' repositories) under 20 percent of changes; and pages per person per week under two. Set the baseline before the split, review at one quarter, and be explicit that a reorg that does not move these numbers should be partly reversed rather than defended.

Production evidence

Team Topologies (Skelton and Pais, IT Revolution 2019) is the source, and its core claim (that cognitive load should bound team scope, and that interaction modes should be designed rather than emergent) is now common vocabulary in engineering leadership interviews.

Conway's law (Melvin Conway, "How Do Committees Invent?", 1968) is the underlying mechanism: organisations design systems that mirror their communication structures. The inverse Conway maneuver (reshape teams to get the architecture you want) is the actionable form, and it is why team design is architecture.

Spotify's squad model is the most-cited and most-misapplied example. Worth knowing that Spotify engineers have publicly disowned it as a model to copy: it described one company at one moment, it was aspirational rather than descriptive even then, and organisations that adopted the labels without the underlying autonomy got the ceremony and none of the benefit. Naming this scepticism is a good signal, because it shows you distinguish a framework from a cargo cult.

Amazon's two-pizza teams and the API mandate are the strongest large-scale evidence for the X-as-a-Service interaction mode: teams communicate through service interfaces rather than shared databases or meetings, which is what makes independent deployment possible at their scale.

Team Topologies' own platform guidance ("platform as a product", "golden path not golden cage") matches what the successful internal platform teams publish: adoption is voluntary and measured, the platform competes with the alternative of teams doing it themselves, and mandates without product quality produce shadow tooling.

The debate

The credible alternative is not reorganising. Reorgs are expensive: they destroy institutional knowledge at the seams, cost a quarter of productivity, and are frequently a response to a problem that better tooling or clearer ownership would fix more cheaply. A team overloaded by extraneous cognitive load (bad CI, manual deploys, no self-service environments) does not need splitting; it needs its toil removed, and splitting it just distributes the same toil across more teams.

The diagnostic question is which kind of load is the problem. If it is extraneous, fix tooling. If it is intrinsic or germane (too many unrelated domains), split.

Between splitting strategies, the real argument is stream-aligned versus component-aligned. Component teams (a search team, a payments team) have deeper expertise and cleaner code ownership. Stream teams ship features without coordination. The evidence favours stream alignment for delivery speed, and the honest counter is that some components genuinely need specialists, which is exactly what the complicated-subsystem type is for.

My position: split by stream of value, size by cognitive load rather than headcount, and treat interaction modes as the actual design work. Carve out a complicated-subsystem team only where genuine specialist depth is required, and do not create a platform team below roughly 50 engineers, because the platform's consumer base is too small to justify it. Measure onboarding time, interrupt rate and cross-team change rate before and after, and be willing to say the split failed.

Reorganising is the wrong move when the real problem is an unclear roadmap, when a single person is the bottleneck (that is a knowledge-sharing problem, not a structural one), when the team has just been through a reorg, or when leadership wants a visible action more than an effective one.

Follow-up Q&A

"Split this 15-person team. Walk your reasoning." Map value streams first, not the service list, because the service list encodes the old structure. Check the proposed boundaries against six months of co-change data, so a cut does not run through files that change together. Assign team types, and then spend most of the effort on interaction modes, because that is where the design lives. Size by cognitive load: count services on call, distinct domains, runtimes, integrations. And name the metrics that will tell you whether it worked, with a baseline taken before the change.

"Why not split frontend and backend?" Because every feature then crosses two backlogs and lead time becomes the sum of two queues, with nobody owning the outcome. Conway's law also means the architecture will calcify into that shape, so you get an integration-heavy system that is expensive to change. Layer-based teams are the canonical Team Topologies anti-pattern, along with a shared "DevOps team" that becomes a bottleneck.

"When do you create a platform team?" When enough stream teams are solving the same extraneous problem that a self-service capability amortises. Practically that is somewhere north of 50 engineers; below that a platform team of two starves the streams and ships half a platform. The test is whether stream teams would voluntarily adopt it: platform as a product, golden path not golden cage. A platform nobody chooses is a mandate, and mandates produce shadow tooling.

"How do you handle the specialist who owns the ranking model?" That is a complicated-subsystem candidate, but one person is not a team. Two options. Embed them in the stream team that consumes the subsystem most, with an explicit mandate to spread knowledge, and formalise the team when it reaches three people. Or make them an enabling team for a quarter, teaching the stream team enough to own it, and accept that depth will be lower. Which one depends on whether the subsystem's depth is a durable competitive advantage or an accident of hiring.

"What if the team disagrees with the split?" Ask what they would propose and why, because they have information you do not, particularly about which parts of the system are actually coupled. Then bring the co-change data, which usually resolves the disagreement empirically. If it does not, this is a one-way door being treated as a two-way one: run the boundary as a virtual team for a sprint or two (same people, new ownership, new on-call) before making it structural. And if I still disagree after that, I make the call, say why in writing, and define the trigger that would make me reverse it.

Common misconceptions

The most common is that Team Topologies is about the four team types. The types are the easy part; the interaction modes are the design. A "platform team" that takes tickets is an infrastructure team with a new name.

The second is that cognitive load means workload. It means how much distinct context the team must hold. A team can be underutilised and cognitively overloaded at the same time, and that combination is exactly what produces long onboarding and high interrupt rates.

The third is copying Spotify's model. Its own authors have disowned it as a template, and organisations that adopt squad and tribe vocabulary without the autonomy get the ceremony without the benefit.

Interview delivery note

Say this: "I'd start from value streams rather than the service list, because the service list already encodes the structure I'm trying to change. Then I'd check the proposed boundaries against six months of co-change data, so I don't cut through files that change together and turn an in-team change into a cross-team negotiation. Team types are the easy part; the design work is the interaction modes: collaborate where the interface is still being discovered, X-as-a-Service once it's stable, and I'd say explicitly when I expect the collaboration to end. I wouldn't create a platform team at 15 people; below about 50 engineers the consumer base doesn't amortise it, so I'd buy the paved road instead."

The depth signal is twofold: the co-change evidence, which almost nobody brings, and refusing to create the platform team, which shows you understand that the framework has a scale where it applies. Close with the measurement: "I'd baseline onboarding time, interrupt rate and cross-team change rate before the split and review at a quarter, because a reorg that doesn't move those should be partly reversed rather than defended."

Further reading

• Skelton and Pais, Team Topologies (2019), particularly the chapters on cognitive load and the three interaction modes.
• Melvin Conway, "How Do Committees Invent?" (Datamation, 1968), for the underlying mechanism and the basis of the inverse Conway maneuver.
• Adam Tornhill, Your Code as a Crime Scene, for change-coupling analysis as evidence for architectural and organisational boundaries.
• Team Topologies' platform-as-a-product material, and the published critiques of the Spotify model by Spotify engineers.