Team Topologies in Practice: Stream-Aligned, Platform, and When to Split

Last updated: August 27, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

Team Topologies is an org-design model with four team types, stream-aligned, platform, enabling, and complicated-subsystem, plus three interaction modes. Most companies need two of them. You split a team when its cognitive load outgrows one complex domain, not when its headcount crosses a number.

A CTO handed me a printed org chart last spring with a box on it labeled PLATFORM, and asked whether the box was sitting in the right place on the page. Fair question. It was also about the fourth most important question in the room, and we spent the first hour getting to the other three, which is roughly how these conversations go when somebody has already decided the answer is structural.

Here is what was actually inside that box. Six people who had been the operations team eighteen months earlier, and a Jira project carrying 214 open tickets, and a standing rule from the previous VP that every infrastructure request had to route through them first. I asked what had changed. He paused. Nobody had changed what those six people did all day. Somebody had changed what they were called.

That is the version of Team Topologies I walk into most often. Renaming a queue does not make it a product. The model itself is good, genuinely good, and I recommend it more than any other org-design framework I have used, but the adoption is usually cosmetic, because four boxes are easy to draw and the boundary decisions underneath them are not. The boxes get drawn. The boundaries do not move.

KORE1 asked me to write this one because the same shape keeps surfacing in their engineering staffing conversations. A client calls wanting three platform engineers. Two questions in, the real situation is that one team owns four domains and nobody has said out loud which two of them need to leave.

The Four Types, Without the Diagram

Team Topologies is an approach to organizing software teams around the flow of work rather than around technical layers, published by Matthew Skelton and Manuel Pais in 2019. It gives you four team types and three ways those teams are allowed to interact. That is the model. Everything else in the book is application.

The official definitions are short enough to quote, so I will, and then I will say what each one looks like when it goes wrong, since that is the column nobody puts on the slide and it is the only column I have ever found useful in a room full of executives.

Two things in that table matter more than the rest of it. Both get skipped.

Stream-aligned is supposed to be the overwhelming majority. IT Revolution, the book’s publisher, puts stream-aligned teams at 60 to 80 percent of the total teams in an organization. So count your boxes. I do this in the first meeting. If half of them are platform and enabling teams, you have not adopted the model, you have borrowed its vocabulary to describe the org you already had, and the relabeling will buy you about one quarter of executive patience before somebody asks what changed.

The interaction modes carry as much weight as the types and get about a tenth of the attention. Collaboration, where two teams work together for a defined period to discover something. X-as-a-Service, where one team consumes what another provides. Facilitation, where one team mentors another. That phrase “defined period” is load-bearing. Collaboration that never ends is two teams that failed to agree on an interface.

Conway Wrote the Constraint in 1968

Every org-design conversation I have ever had was already answered, badly, by a paper from 1968. Melvin Conway wrote it. Datamation published it that April after Harvard Business Review turned it down, and Fred Brooks gave the finding its name a few years later in The Mythical Man-Month, which is how a rejected paper ends up as the one law in our field that nobody has managed to repeal. The line itself is one sentence.

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” That is Conway’s own phrasing, minus one parenthetical. It still holds.

Read it as a constraint and not a slogan. Your architecture is not independent of your org chart. You pick one of the two deliberately, and the other one arrives on its own, shaped by whoever happens to talk to whom on a Tuesday, and you do not get a vote on it after the fact. Team Topologies calls the deliberate version the reverse Conway maneuver. You draw the team boundaries you want the software to have. Then you wait.

I have seen both versions. A lending platform I worked in had a frontend team, a backend team, and a data team, which is the layered default almost every company lands on by accident. Every customer-visible change needed all three. Every change therefore needed a meeting, then a handoff, then a second handoff, and the median change touched three teams before it ever touched a customer. Nobody was slow. The org chart was slow, and it had written itself into the code years before any of us arrived, and by then it read as an architecture decision rather than the staffing accident it actually was.

Why the Platform Box Is the One That Breaks

Platform teams are where this model gets misused most, and the evidence is not soft. Google’s DORA program studied internal developer platforms in its 2024 State of DevOps research and found the trade-off nobody wants on the slide. Individual productivity rose about 8 percent. Team performance rose about 10 percent. Delivery throughput fell around 8 percent, and change stability fell around 14 percent.

Productivity up, delivery down. Both at once. That result should bother you.

DORA’s own explanation is that a platform can add handoffs and gates rather than remove them, which is the thing every platform team swears it is not doing. The most likely culprits are the automated checks a platform inserts before production. Nobody added those in bad faith. Every one of them was defensible on the day it went in. The gates accumulate. Nobody removes one.

The adoption numbers say this is now nearly everybody’s problem. DORA’s 2025 report, built on responses from close to 5,000 technology professionals, found 90 percent of organizations reporting some use of an internal platform and 76 percent with a dedicated platform team. Gartner forecast that 80 percent of large software engineering organizations would establish platform engineering teams by 2026, up from 45 percent in 2022. That forecast landed. The question stopped being whether to have a platform team.

The Team Topologies group published a piece in late 2024 cataloguing how platform teams get misused, and the failure I see most is the one they list as malicious compliance. Developers adopt the mandated tooling. They adopt it exactly, and minimally, and without a shred of goodwill, and then they route around it wherever the mandate happens to have a gap. They complied. Nothing improved. Your compliance metrics look terrific, and the platform is not one.

So here is the test I use. It takes one question.

If the mandate disappeared tomorrow, would the stream-aligned teams keep using your platform?

Yes means it is a product. No means it is a queue with better branding. There is no third answer, and the leaders who cannot answer it immediately have usually never asked, because the mandate has been doing the work of the answer for a year and a half and nobody had a reason to look underneath it.

The related rule is thinnest viable platform. Build the smallest thing that removes real load, ship it, and let demand pull the next piece out of you. Most platform teams I meet built the roadmap first. One spent two quarters on a self-service portal for a request that arrived eleven times a year. Meanwhile the thing engineers actually complained about, a 40-minute local environment setup, sat untouched. It was unglamorous. Nobody wanted it on their promo packet. So it waited.

Cognitive Load Is the Split Criterion. Headcount Is Not.

This is the section I came here to write. The definitional articles skip it.

Team Topologies borrows cognitive load theory and splits it three ways. Intrinsic load is the difficulty of the work itself, understanding the domain and the algorithm. Extraneous load is the overhead of the environment around the work, the deploy incantation, and the four config systems, and the ticket you have to file to get a database provisioned. Germane load is the good kind, the effort of learning and connecting things. You are protecting that one. Most orgs protect nothing.

Almost every intervention worth making reduces extraneous load. That is what a platform is for. Stack Overflow’s 2025 Developer Survey found 54 percent of developers now use six or more tools to do their job, and each one has its own mental model, and its own auth, and its own particular way of failing on a Friday afternoon. The tax is real. It just never shows up on a roadmap.

The split heuristic in the book is about domains, not people. One complex domain per team, or two to three simple ones. Never two complicated domains on one team, even if the team is big enough on paper, because a nine-person team holding two complicated domains does not behave like one team. It behaves like two subteams whose members are all expected to know both domains, which is the most expensive arrangement available. Split it into two teams of five. Then hire the extra person.

Headcount is a symptom, and it helps to know where the thresholds sit. The book leans on Dunbar’s research on group size. Around five people is the limit for close working relationships. Around fifteen is the limit for deep trust. Fifty for mutual trust, 150 for remembering what everyone can do. Stable teams of five to nine is the recommendation. The research is old. It has not moved. That number describes trust, not capacity.

Five signals it is time to split

1. Two domains, one standup. Half the team tunes out for half the meeting. Watch the faces.
2. Nobody can answer an on-call page without asking somebody else first. That is a load ceiling, and it shows up in your recovery time long before anybody raises it in a retro.
3. The manager has twelve or more direct reports. Eight is roughly the practical limit. Twelve means the manager stopped coaching a while ago and is now dispatching, whether or not they have noticed.
4. The team’s own backlog has two distinct vocabularies in it. Pull up the last 60 tickets and read the titles. If a stranger could sort them into two piles without knowing anything about your business, then the split has already happened somewhere below the org chart and the only open question is whether you are going to staff it.
5. Estimates got worse as the team got bigger. That one surprises people. It is the clearest signal in the list.

One thing is deliberately missing from that list. “We have too much work.” Every team has too much work. I have never met an exception. That is a capacity conversation, and it has a different answer, usually a worse one.

The Axis You Split On Decides Everything

Say you have accepted the split. Now comes the decision that determines whether the next two years go well, and most orgs make it in about ten minutes based on who reports to whom today.

You can split by component or by flow. Component means frontend and backend, or services and data, or web and mobile. It feels natural. It matches how people describe their own skills. It is almost always wrong, because Conway then guarantees you an architecture with an integration seam sitting exactly where you drew the org line, and every feature you ship for the next two years has to cross it. Every feature needs two teams. Every feature needs a schedule.

Flow means each team owns a slice of the customer journey end to end. In a lending shop that reads as origination, then servicing, then payments, and each of those slices needs a bit of everything in order to work at all. It looks ugly on a skills matrix. Engineers like it anyway. It is fast in practice, because a change to origination is a change that one team can make, and review, and deploy, and then get paged for at 2am when it goes sideways.

The duplicated skill in row two is what leadership objects to, every time, usually in the language of efficiency. Yes, you will have four people who each know a bit of Terraform instead of one person who knows all of it. That redundancy buys the independence. Independence is the entire point. The alternative is one expert who is a hard dependency for four separate teams, and who takes a vacation in July, and who will eventually get an offer from somebody else.

The Boundary Is Where Clarity Fails First

I have a diagnostic I use on stalled engineering orgs called the Clarity Stack. Three layers. No shared definition of done, priorities living in hallway conversations, and decisions that get made and never written down. It applies to a single team. It applies harder at a team boundary, because a boundary tests all three layers at once, on people who do not sit near each other.

Layer one at a boundary is a definition-of-done mismatch. The platform team considers a capability done when it is deployed and documented. The stream-aligned team considers it done when they have used it in production without asking anybody for help. Those are different dates. Sometimes different quarters.

Layer two is two ranked lists that nobody reconciled. The platform roadmap says self-service database provisioning is next. Three product teams say their next blocker is that 40-minute environment setup. No single person holds authority over both lists, so the platform team builds what it planned, and everybody stays polite about it in the readout, and the gap shows up two quarters later as a satisfaction score nobody can explain. I have watched that meeting. It is very quiet.

Layer three costs the most. It is a straight decision-rights map problem. Who gets to change a shared interface? The producing team, the consuming teams, or the room? If your answer is “we talk about it,” you have described a meeting rather than an owner, and the change will happen anyway on somebody’s Thursday afternoon.

So write down the team API. It sounds like process for the sake of process. It takes about an hour. What this team owns, what it provides, how you reach it, how fast it answers, what it will not do. A stream-aligned team and a platform team who have written those five lines to each other argue about roughly a tenth of what they argued about before. Rule out the boring explanation first, though, because a team that is simply out of gas will fail every boundary test for reasons that have nothing to do with structure, and there is a separate read on whether your org is actually slow or just tired.

What a Split Costs You in Hiring

Here is the part KORE1 pays me to say plainly.

Splitting one team into two does not create two teams. It creates two half-teams and two vacancies you did not budget for, and the vacancies are almost never the ones on the org chart. A new stream-aligned team needs somebody senior enough to end an architectural argument, since the whole premise is that it decides without escalating. A new platform team needs a product owner. Everybody skips that hire. It is also why platform teams drift back into being a ticket queue inside a year.

I would rather see a company delay a split by a quarter and land those two people. The reorg is free. The staffing is not, and the bill arrives about six weeks after the announcement, on the day the first hard call has nobody to make it.

KORE1 has been placing engineering talent since 2005, across more than 30 U.S. metros, with a 92 percent twelve-month retention rate on those placements and a 17-day average time to first qualified submittal. Retention is the one I care about for this particular problem. A senior engineer you hired to anchor a newly split team, and then lost at month nine, leaves you worse off than the single overloaded team you started with, because now you have two half-staffed teams and a boundary nobody owns. Their platform engineering staffing practice covers the whole function rather than one seat, product owner included, and they place individual platform engineers on contract, contract-to-hire, and direct hire.

Sometimes the shape of the org is the real question and the headcount is not. KORE1 staffs a senior leader for a four to six week engineering org design advisory engagement that redraws boundaries before anybody opens a req. They also run a two-week engineering velocity diagnostic. It ends in a written verdict on whether your fix is a process change or a hire.

Arguments I Get When I Draw This on a Whiteboard

We have 40 engineers. Do we really need all four team types?

You do not. At 40 engineers you want four or five stream-aligned teams and possibly one small platform team, and that is the whole org.

Enabling teams and complicated-subsystem teams answer problems you do not have yet. An enabling team at your size is two senior people you cannot spare, and the moment you formalize it you have taken your best mentors off delivery. Run the enabling work as a rotation instead. It costs you less. Complicated-subsystem is for genuine specialist depth, a pricing engine or a risk model. It is not for the service everybody finds annoying.

Our platform team is three people and nobody likes the tooling. Fix it or scrap it?

Drop the mandate for one quarter and watch what happens to usage. That measurement beats any survey you could run.

If usage holds, you have a real platform with a communication problem, which is a much smaller fix than it feels like from inside. If usage collapses, you learned something cheaply, and you can rebuild around the one thing people kept using voluntarily. I have run this twice. Both times the answer sat somewhere in between. Both times the piece that survived was smaller and more boring than what the team had been building.

Is there a way to do this without announcing a reorg?

Change the on-call rotation and the standup boundaries first, leave the reporting lines alone, and let the new shape run for six weeks before anybody’s title changes.

The announcement generates the fear, and the fear generates resignations from exactly the senior people whose absence makes the new structure fail. Ownership is what moves. Titles follow it. If two groups already carry separate pagers and run separate standups, the formal split is paperwork by the time it lands. My favorite version of this is the one where an engineer works out three weeks later that the reorg already happened.

Enabling teams sound great. Who staffs one?

Your stream-aligned teams do, temporarily, and the people go back. If nobody goes back, it was never an enabling team.

The permanent center of excellence is the failure mode here, and it is a slow one, because it looks fine for about two quarters. Then the enabling team has a roadmap, and a backlog, and opinions about standards, and it has quietly turned into a governance function that the delivery teams work around rather than work with. Put an end date on it at the start. Write the date somewhere other people can see it. Then honor it.

How small is too small to split?

Below eight people, splitting usually makes things worse. Two teams of four spend more time coordinating than one team of eight spent being confused.

The two-complicated-domains case is the exception, and it is a real exception rather than a hedge. If a team of eight carries two domains that share no vocabulary, then two teams of five beats one team of eight every time, which means the split arrives with two hires attached to it and a budget conversation you were not planning to have. Companies rarely want to hear that a structural fix has a recruiting bill. It does. I say it anyway. Budget for it or delay the split. Either one beats splitting into two teams that are each one person short of functioning.

Draw the Line Where the Work Flows

The four team types are the easy part of Team Topologies. Any leader can read the definitions in ten minutes and sort their existing teams into the boxes by lunch. That exercise produces nothing. Labeling the org you already have is not a design decision.

The design decision is the boundary. Where one team’s ownership ends. What the next team receives, in what shape, on what promise. Whether your platform is something people choose or something they comply with. That last one decides everything.

Go look at your last ten customer-visible changes and count how many teams touched each one. If the average sits above two, then your boundaries are drawn against the flow of work rather than along it, and no amount of relabeling is going to fix that for you. Conway told us this in 1968. We keep rediscovering it in reorgs. I expect we will again.

If you want to argue with me about where your lines currently sit, or you are staring at an org chart trying to decide whether to split, find me on LinkedIn. If the honest answer turns out to be that the new shape needs people you do not have yet, start the search with KORE1’s engineering team before you announce anything.

Related reading: The Four Delivery Metrics That Predict Engineering Velocity, The Hallway-Decision Problem: Why Engineering Priorities Have to Live in Writing, and Load-Bearing Spaghetti: How Engineering Orgs End Up Afraid to Touch Their Own Code.