TL;DR - Team Topologies gives you four team types and three interaction modes. Almost everyone adopts the four boxes - rename the ops team “platform team”, call the senior engineers an “enabling team” - and quietly ignores the three interaction modes, which is where the entire value lives. The book’s real payload is a single idea: organise teams to minimise cognitive load, and make the way teams interact both explicit and temporary by design. Here is how that plays out for a real platform group, and the failure modes I see most.
I have watched a lot of engineering orgs “adopt Team Topologies.” What that usually means is a reorg slide with four coloured boxes on it. The infrastructure team gets renamed the platform team. A rotating cast of senior engineers gets labelled an enabling team. Someone puts “stream-aligned” in a few job titles. The org chart changes; nothing else does.
That is not adopting Team Topologies. That is renaming your teams and hoping the book’s results come with the vocabulary. They don’t. The four team types are the least important thing in the book, and treating them as the whole model is the single most common way teams get no value out of it.
This post is about the parts that actually do the work: the interaction modes, cognitive load as the organising principle, and what all of it means concretely for a platform team.
The four shapes, honestly
Let me get the taxonomy out of the way, because you do need the shared language, you just shouldn’t mistake it for the strategy.
- Stream-aligned teams own a slice of the product end to end and ship it to users. These are the only teams that produce value a customer would notice. Everything else exists to make these teams faster.
- Platform teams turn the messy underlying capabilities - compute, delivery, observability, secrets - into a self-service product that stream-aligned teams consume without filing a ticket.
- Enabling teams are specialists who help a stream-aligned team climb a capability it lacks - test automation, a new database, security practice - and then leave.
- Complicated-subsystem teams own a piece with genuinely deep domain complexity - a video codec, an ML ranking model, a pricing engine - that isn’t worth every stream-aligned team learning.
That’s the whole zoo. Notice how little it tells you about how to run anything. It’s a filing system for teams, and a filing system is not an operating model. If your Team Topologies adoption stopped at deciding which box each team goes in, you did the easy 10% and skipped the 90%.
The part that matters: the three interaction modes
The interaction modes are the actual model, because they describe the relationships, and the relationships are what makes an org fast or slow.
- Collaboration. Two teams work closely together, sharing responsibility, for a bounded period to figure something new out. It’s high-bandwidth and expensive, and it’s supposed to be temporary. You collaborate to discover the interface; you don’t collaborate forever.
- X-as-a-Service. One team consumes what another provides with minimal fuss - an API, a template, a paved road - and neither team needs a meeting to make it work. This is the low-cognitive-load, high-throughput mode. It’s what you want most of your interactions to eventually become.
- Facilitating. One team helps another get better at something, then gets out of the way. This is the enabling team’s whole reason to exist. Its success condition is that it becomes unnecessary.
Here is the sentence the reorg slide always leaves out: the interaction mode is a decision you make on purpose, you write it down, and you set an expiry on it. “Platform and the payments team are in collaboration mode for the next six weeks while we shape the deploy API, then we move to X-as-a-Service.” That is the practice. Most orgs never name the mode at all, which means every relationship silently defaults to permanent collaboration - everyone in everyone else’s meetings, forever - and then they wonder why nothing scales.
The platform team’s job is X-as-a-Service, not collaboration
If you take one thing from this post, take this. The steady-state interaction mode for a platform team is X-as-a-Service. A platform team that is permanently in collaboration mode with its consumers is not a platform team. It’s a shared services team with a fashionable name, and it will scale linearly with the number of teams it supports - which is exactly the human-bottleneck problem platform engineering exists to kill.
You can diagnose this without a survey. Ask: to get something from the platform, does a stream-aligned team need a conversation with the platform team? If the answer is “yes, they open a ticket and we do it,” you have a service desk. If the answer is “no, they consume a paved road and only talk to us when it breaks,” you have a platform. The whole discipline is the second answer.
That’s why your first golden path matters so much: a golden path is X-as-a-Service made concrete. A template repo, a default pipeline, and sane defaults that a developer consumes without booking your time - that is the interaction mode, encoded in software instead of a working agreement. The paved road is how a platform team stops collaborating with everyone and starts serving everyone.
This also reframes what a developer portal is for. The portal is not the platform. It’s the storefront of the X-as-a-Service relationship - the place consumers discover and self-serve what you provide. Which is exactly why building it before you have anything to serve is premature: you can’t run a storefront with empty shelves.
Collaboration mode still has its place for a platform team, but only briefly and only on purpose. When you’re shaping a new capability with the first team that will use it, collaborate hard - sit together, co-design the interface, iterate in hours. Then, deliberately, convert the relationship to X-as-a-Service and move on to the next capability. The trap is the collaboration that never ends because nobody decided it should.
Cognitive load is the actual organising principle
Underneath the four types and three modes is the idea the whole book is really about, and the one that survives when you throw away the vocabulary: teams have a finite cognitive load, and you should organise work so that no team is carrying more than it can hold.
Cognitive load is the sum of everything a team has to keep in its head to do its job - the domain, the codebase, the infrastructure, the deploy process, the on-call surface, the five internal tools each with its own quirks. When that sum exceeds what a team can reasonably hold, the symptoms are familiar: slow delivery, brittle changes, heroic individuals who are the only ones who understand the deploy, and a bus factor of one.
Team Topologies’ answer is that the team types and interaction modes exist to move cognitive load around. A platform exists so that stream-aligned teams don’t have to hold the infrastructure in their heads. A complicated-subsystem team exists so that nobody else has to learn the codec. An enabling team exists to raise a team’s capability without permanently expanding what it has to own.
This gives you a sharper design test than “which box does this team go in.” Ask instead: is this boundary reducing someone’s cognitive load, or just moving a coupling problem across a team line? A platform that hands developers a more complicated abstraction than the thing it wrapped has increased cognitive load while claiming to reduce it. That’s the same failure as a boring-stack violation one altitude up: an abstraction is only worth its weight if it’s genuinely cheaper to hold than the thing it hides. Most of the time, the honest platform capability is the one that lets a developer forget an entire category of problem exists.
The enabling team is not a permanent SWAT team
The most abused shape is the enabling team, because it’s the easiest to corrupt into something that feels productive.
An enabling team is supposed to work in facilitating mode: it embeds with a stream-aligned team, lifts that team’s capability in some specific area - contract testing, a migration to a new datastore, threat modelling - and then leaves, having made itself unnecessary on that team. Success is measured by the team’s new independence, not by the enabling team’s utilisation.
Two failure modes, both common:
- The permanent SWAT team. The enabling team becomes a pool of senior engineers that management parachutes into whatever’s on fire this quarter. They never leave, because leaving isn’t the goal; being useful is. This is staff augmentation wearing a Team Topologies badge, and it quietly deskills the teams it “helps” by doing the hard parts for them instead of teaching them.
- The disguised platform team. The enabling team starts owning and operating the thing it was supposed to teach. Now it’s a platform team without the self-service, which is to say a bottleneck. If people can’t do the thing without you after you’ve helped them, you were operating, not enabling.
The tell for a healthy enabling team is that it works itself out of each engagement and the teams it touched get measurably more self-sufficient. If your enabling team has been embedded with the same group for a year, it isn’t enabling. It’s been quietly absorbed, and you should either make that permanent and honest or actually finish the handoff.
How to roll this out without a reorg theatre
If you want the results and not just the vocabulary, invert the usual order. Don’t start by drawing four boxes. Start with the load.
- Map cognitive load first. For each stream-aligned team, list what they have to hold to ship: domain, infra, delivery, on-call, the internal tools. Find the teams that are visibly over capacity. That map, not an org chart, tells you where a platform capability or a complicated-subsystem boundary would actually help.
- Name your interaction modes out loud. For each important cross-team relationship, write down the mode and, if it’s collaboration, its expiry. “Platform ⟷ Search: collaboration until the indexing API stabilises, target end of Q3, then X-as-a-Service.” Half the value is just making the implicit explicit.
- Turn one collaboration into a service. Pick the platform team’s busiest, most-ticketed relationship and ask what paved road would let that consumer stop talking to you. Build that golden path. That single conversion, from collaboration to X-as-a-Service, is Team Topologies delivering value - no reorg required.
- Give the enabling work an end date. Every facilitating engagement gets a defined capability goal and a rough exit. If you can’t state when the enabling team leaves, you haven’t scoped facilitating work; you’ve scoped a permanent dependency.
Notice that none of these steps require renaming a single team. You can run the entire model on your existing org chart, because the model was never about the boxes. The reorg is the least important, most disruptive, and most-adopted part.
When you don’t need any of this
Honesty compels the off-ramp. Team Topologies is a scaling framework, and at small scale it’s overhead pretending to be structure.
If you have three teams and everyone still fits in one room, you don’t have a cognitive-load-distribution problem that an operating model solves. You have a “talk to each other” problem, and the solution is to talk to each other. Declaring a two-person “platform team” and a one-person “enabling team” inside a twelve-engineer org is the same category error as running Kubernetes for three services: you’ve imported the machinery for a scale you don’t have, and the machinery costs more than the problem.
You start earning this model when cross-team friction becomes the dominant cost - when teams are visibly over cognitive-load capacity, when the same handoffs keep going wrong, when “who owns this?” is a recurring question rather than an obvious answer. That’s typically well past a few dozen engineers. Until then, the four boxes are a solution looking for the scale that justifies them.
The bottom line
Team Topologies is not four coloured boxes. It’s a claim that you should organise teams to minimise cognitive load, and manage the ways they interact as explicit, mostly-temporary decisions. The four team types are just vocabulary for that claim. The three interaction modes are the model. And the single most important line in the whole thing, for anyone building a platform, is that your steady state is X-as-a-Service - self-service paved roads that let developers consume what you provide without consuming your time.
So skip the reorg. Map where your teams are drowning in load, name your interaction modes and put expiries on the temporary ones, and convert your busiest collaboration into a service. That’s the book, applied. The org chart can stay exactly where it is.
If you’re trying to work out whether your platform team is actually a platform or a service desk with a new name, let’s talk.