scalable/scale/team topologies/lesson 01 cph / /
lesson 01 / 07 · 12 min · updated ·

the four team types

stream-aligned, platform, enabling, complicated-subsystem. what each is for, and what happens when you mix them up.

the mistake to avoid

most org charts classify teams by function — backend, frontend, data, mobile, sre. that's a job-title taxonomy. it tells you what people do at a desk, not how value flows through the company. team topologies classifies by purpose: what is this team for, and who depends on it to do their work?

four types, each with a job. every team in the org should map cleanly to one of them. if it maps to two, it's probably two teams in a trenchcoat — and that's lesson six.

the four types

  1. stream-aligned the default. owns a single, valuable flow of work end-to-end — a product area, a user journey, a customer segment. ships to users directly. most teams in most orgs should be this. if you don't know what a team is, assume stream-aligned.
  2. platform serves other teams as customers. builds an internal product — ci/cd, observability, a container platform, an auth service — that stream-aligned teams consume without raising tickets. the measure of a good platform team is how often its customers choose to use it vs route around it.
  3. enabling a temporary coaching team. shows up, closes a capability gap in a stream-aligned team (cloud adoption, security practices, a new testing discipline), then leaves. if an enabling team becomes permanent, it's misclassified — either they're platform, or they're stream-aligned, or they shouldn't exist.
  4. complicated-subsystem owns something whose mastery is so specialised the rest of the org can't reasonably hold it. pricing engines, video codecs, simulation models, tricky numerical libraries. small, insulated, and provides its output as a crisp interface others can use without understanding the internals.
the ratio matters. in a healthy topology, stream-aligned teams dominate — typically 60–80% of the teams. platform teams are few (one or two per hundred engineers). enabling teams come and go. complicated-subsystem teams are rare by construction; if you have five of them, four are probably stream-aligned teams hiding.

try it

classify these teams

eight teams from a fictional company. click a team, then click the type you think it belongs to. check your answers when you've assigned all eight.

the cost of getting it wrong

misclassification is the origin of most team-dysfunction complaints. a platform team that behaves as stream-aligned ends up owning features nobody else can work on. a stream-aligned team that's secretly a platform team never ships anything because every other team keeps interrupting it. complicated-subsystem teams that forget to publish an interface become oracles — the org can't ship without asking them a question.

the four types are simple, but the discipline of applying them cleanly is where most of the value lives. the rest of the course is about that discipline.

next: the three interaction modes, and why picking the wrong one is so expensive.

scalable labs·cvr 30091604·github·linkedin·hello@scalable.dk