Team Topologies for Startups in Plain English: Stream-Aligned, Platform, Enabling, and Complicated-Subsystem Teams Without the Jargon

At some point between 10 and 30 engineers, every startup I work with hits the same wall. The team that used to ship fast now feels slow. Features that used to take a week take a month. Engineers step on each other. Something has to change about how the team is organized, and nobody quite knows what.

There is a book that got written for this exact moment. It is called Team Topologies by Matthew Skelton and Manuel Pais, and it is one of the few org-design books I actually recommend to founders. The ideas are good. The language, unfortunately, is not founder-friendly. Terms like "cognitive load" and "stream-aligned" and "complicated-subsystem team" land like a textbook instead of a playbook.

This article is a translation. I will walk through the four team types, what each one actually does, when you need one, and how to apply the framework at three specific stages: 10 engineers, 25 engineers, and 50 engineers. No academic language.

The core idea in one paragraph

Most engineering orgs grow by accident. You hire the next engineer, they pick up whatever is in front of them, and six months later you look around and nobody knows who owns what. Team Topologies says: stop growing by accident. Decide what kinds of teams you need, give each one a clear purpose and a clear way of working with the other teams, and change the shape on purpose when the system tells you to. That is it. Everything else is detail.

The four team types, translated

1. Stream-aligned team (the "shipping team")

Academic name: Stream-aligned team. Plain English: A team that owns a user-facing slice of the product end to end and ships changes to it.

This is the default team type. It is probably 80% of the teams in your org. A stream-aligned team owns a product area — say, billing, or onboarding, or the reporting dashboard — and has everything it needs to ship changes to that area without waiting on anyone else.

What "everything it needs" means in practice: they have their own backlog, their own repo or well-defined slice of a shared repo, their own deploys, their own metrics, and enough cross-functional skill on the team to handle the work that lands on them. If they have to open a ticket with another team every time they want to change a database schema, they are not truly stream-aligned.

The mistake I see at startups: every team is called "the product team" and they are all sort of doing everything. That is not a stream-aligned team, that is a pile of engineers sharing a standup.

2. Platform team (the "make-the-other-teams-faster team")

Academic name: Platform team. Plain English: A team that builds internal tools and services so the shipping teams can go faster.

CI/CD pipeline. Observability stack. Developer environments. Auth and permissions. A deploy system. A feature flag service. These are the things a platform team owns.

A platform team does not ship features to customers. It ships features to other engineers. Its customers are the stream-aligned teams, and it measures itself by how much it speeds those teams up.

Common mistake: creating a platform team before it is painful not to have one. At 10 engineers, you do not need a platform team. You need a lead engineer who cares about tooling. At 25 engineers you probably do.

3. Enabling team (the "temporary coach team")

Academic name: Enabling team. Plain English: A small, expert team that parachutes into other teams to level them up, then leaves.

If two of your stream-aligned teams are struggling with frontend performance, an enabling team of two or three people who are great at performance work joins them for a few weeks, fixes the worst issues, teaches the team how to measure and maintain performance themselves, and then leaves.

Enabling teams are temporary by design. They are not there to own anything. They are there to transfer capability. If your enabling team is still on a problem six months later, it has turned into a stream-aligned team by accident and you should formalize it.

Most startups under 30 engineers do not need a dedicated enabling team. They do need individuals who play this role occasionally, usually the most experienced engineers on the team. Formalizing it into a real team is a Series-B+ move in most cases.

4. Complicated-subsystem team (the "weird hard thing team")

Academic name: Complicated-subsystem team. Plain English: A small team of specialists who own a piece of the system that is genuinely hard in a specialist way.

A machine learning inference pipeline. A realtime collaboration engine. A cryptography layer. A physics simulation. A payments processor with its own regulatory footprint. Something where you genuinely need people with specialist knowledge that a general full-stack engineer cannot reasonably acquire in a few weeks.

The trap: declaring ordinary work "complicated" to justify a separate team. Building a REST API is not a complicated subsystem. Writing a video encoder is. Be honest about which category your work falls into. If you cannot name the specialist knowledge the team needs that the rest of the org does not have, it is not a complicated subsystem.

The interaction modes (how teams should talk to each other)

Team Topologies also defines three interaction modes between teams. This is the part founders most often skip, and it is actually the most important part. The shape of your teams matters less than the way they interact.

Collaboration. Two teams work closely together for a short, defined period. High communication, high flexibility, high cost. Use sparingly and always with an end date.

X-as-a-service. One team provides something (an API, a tool, a service) that the other team consumes without needing to coordinate day to day. Low communication, low flexibility, low cost. This is what most stream-aligned → platform team interactions should look like.

Facilitating. One team helps another team temporarily. This is how enabling teams interact by definition.

The rule of thumb I use: you want most of your inter-team interactions to be X-as-a-service. Every collaboration interaction is expensive. If two teams are in constant collaboration mode, they are either actually one team wearing two hats, or one of them should be absorbing the work.

How to apply this at 10, 25, and 50 engineers

Theory is cheap. Here is what this looks like in practice at three startup sizes I see all the time.

At 10 engineers: do not over-engineer this

You have one team. Maybe two. You do not need Team Topologies vocabulary yet. What you need is one clear question answered: does every engineer know which half of the product they own?

If everyone owns everything, everyone owns nothing. Split into two stream-aligned teams if natural seams exist (e.g., the customer-facing app vs. the admin / internal tools, or the marketing site vs. the product app). Give each team a clear surface area and a clear owner. That is it.

Do not create a platform team. Do not create an enabling team. Do name one senior engineer the de facto owner of developer tooling and give them 20% of their time for it.

At 25 engineers: this is when Team Topologies earns its keep

Now you have three or four teams and they are starting to collide. This is the stage where the framework pays off.

Typical shape I would propose:

Three stream-aligned teams, each owning a customer-facing area (for example: Core product, Growth and onboarding, Enterprise and integrations).
One small platform team (three to five people) owning CI/CD, observability, dev environments, feature flags, and the shared data layer.
No enabling team yet. That role is played by two or three senior ICs who rotate through other teams as needed.
One complicated-subsystem team only if you actually have a complicated subsystem. Most 25-person startups do not.

Crucially: make the interaction modes explicit. Write down on a wiki page which teams collaborate with which, and in which mode. The platform team provides services to the stream-aligned teams as X-as-a-service. The stream-aligned teams collaborate with each other only at defined integration points. The senior ICs facilitate as needed. Putting this on paper resolves 80% of the territorial arguments before they happen.

At 50 engineers: the model matures

You now need something closer to the full framework.

Four to six stream-aligned teams, each with a sharper focus than before.
A real platform team or two, possibly split by domain (e.g., developer platform vs. data platform).
An enabling team is now justified, probably two or three people, focused on whatever your biggest cross-cutting capability gap is — frontend performance, observability practices, AI-assisted dev workflows, whatever.
Any complicated subsystems are explicit teams with named specialists and clear interfaces.

At 50 engineers you also need to start paying attention to cognitive load — the concept from the book that I did not translate above. The plain-English version: a team should not be expected to hold more domain knowledge in its collective head than it reasonably can. If a team owns seven different services across three different domains, it is overloaded and will start missing things. Shrink the scope or grow the team. Do not do both at once.

The three mistakes I see most often

One. Copying the Spotify model. Squads, tribes, chapters, guilds. It looked great in a conference talk in 2014. It did not work as advertised even at Spotify. For a startup under 50 engineers it is cosplay. Use Team Topologies instead.

Two. Splitting teams by technology layer. "The frontend team." "The backend team." "The database team." This is the worst possible shape for shipping customer value, because every feature now requires coordination across three teams. Teams should be split by user-facing slices of value, not by tech stack layers. Full stop.

Three. Reorganizing too often. A reorg is not free. It costs three to six weeks of productivity and a slug of morale every time you do it. If you are reorging more than once a year at the 10–50 engineer scale, the problem is not the shape of the org — it is something else (usually unclear strategy or unclear leadership).

The signal that it is time to change shape

You do not reorg on a schedule. You reorg when the system sends a clear signal. The signals I watch for:

Lead time on PRs is growing week over week for multiple teams.
"Who owns this?" has become a common question in Slack.
A single team is being pulled into every incident regardless of the service.
Engineers are frustrated by coordination costs more than by the work itself.
You are hiring faster than the shape of the org can absorb.

Any two of those at once and it is time to seriously look at the topology. All five and you are already late.

Counterpoint: org design is not a silver bullet

Team Topologies is a useful lens, not a magic one. Plenty of teams with a perfect topology still ship slowly because their product strategy is unclear, their engineers are unhappy, or their tech debt is crushing them. Fixing those problems with a reorg is a classic founder mistake — it looks like action, and it feels decisive, but it rearranges the deck chairs without touching the underlying issue.

Before you reorg, ask: if the team shape were perfect, what would actually change? If the honest answer is "not much," the problem is elsewhere.

Your first step

If you are somewhere in the 10–50 engineer range and the team feels slow, start with a very simple exercise. Take a piece of paper. List every team you have. Next to each one, write in one sentence what they own and who their customers are. Then list every interaction those teams have, and write "collaboration," "as-a-service," or "facilitating" next to each.

If you cannot write the sentences cleanly, that is the problem. The framework is not the hard part. Clarity about ownership is the hard part. The framework just gives you language for it.

Where I come in

Designing team shape is one of the most common things founders hire me for — usually around the 15-engineer mark, when the original "everyone does everything" model has started to crack. I spend the first week listening, the second week mapping the current state, and the third week proposing a new shape, with a migration plan that does not torch productivity in the process.

If you are staring at an org chart wondering whether you need to reshuffle, let's talk. I will tell you what I am seeing in similar companies and whether a reorg is actually the right move for you, or whether the real lever is somewhere else. Thirty minutes, no pitch.