Team Topologies & the Socio-Technical Platform

You cannot buy a platform, and you cannot install one — you have to grow an organization that produces one. That is the uncomfortable, load-bearing truth this page is about. A platform is a socio-technical system: the software and the shape of the teams that build it are two faces of the same object, welded together by Conway’s Law. Get the team structure wrong and no amount of clever YAML will save you; get it right and the good architecture almost falls out for free. This lesson goes past the exam blueprint into the org-design discipline that underpins every platform — Team Topologies (Skelton & Pais): the four fundamental team types, the three interaction modes, cognitive load as the thing you are really optimising, and how to evolve an organization deliberately toward the platform you want.

Conway’s Law & the socio-technical system

☺ Like you’re 10: The shape of your software copies the shape of who-talks-to-whom in your company, whether you meant it to or not.

In 1968 Melvin Conway published a single observation so durable that we now teach it as a law. Paraphrased: any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure. It is not a slogan or a warning — it is a description of a force that acts on you the way gravity acts on a dropped cup. If you have four teams building a compiler, you will get a four-pass compiler. If your database team and your API team sit on different floors and communicate only through tickets, the seam between the database and the API will be brittle, over-formalised, and painful — because that seam is the ticket queue, rendered in code.

Conway’s Law, stated plainly

The mechanism is simple once you see it. To integrate two software modules, the people building them must reach agreement about the interface between them — and reaching agreement requires communication. The easiest interfaces to build are the ones between people who talk constantly, so software naturally coalesces around the clusters of high-bandwidth human communication. The org chart is a communication map; the architecture is that same map with the labels swapped from people to services. This is why re-orgs silently reshape systems, and why “we’ll fix the architecture next quarter” fails if the teams stay the same shape — the old structure keeps regrowing because the communication paths that produced it are untouched.

The homomorphic force — it’s a mirror, not a suggestion

Engineers often treat Conway’s Law as advice they can ignore with enough discipline. They cannot. The relationship is homomorphic: structure-preserving. You may draw a beautiful microservices diagram on the whiteboard, but if your teams are organised by technology layer — a front-end team, a back-end team, a DBA team — then every user-facing feature has to be threaded through all three, and the “services” will be coupled along exactly those layer boundaries. The architecture on the whiteboard loses; the architecture implied by the org chart wins. The practical corollary, which the rest of this page builds on, is that if you want a particular architecture, you must first arrange the teams whose communication paths would naturally produce it.

The platform is org design, not just technology

This is why a platform is a socio-technical system and why platform engineering is, unavoidably, an act of organizational design. A platform’s real job is to change the communication structure of the whole engineering org: to let a product team get a database, a pipeline, and a production deploy without opening a ticket to another team. Every ticket you remove is a communication dependency you dissolve, and every dependency you dissolve reshapes the architecture toward loose coupling. When we say the platform lifts developers out of Ticket Swamp, we are describing a Conway-scale intervention, not a convenience feature. The technology (GitOps, CRDs, portals) is the medium; the change to who-must-talk-to-whom is the message.

The four fundamental team types

☺ Like you’re 10: Team Topologies says you only ever need four kinds of team. Almost everyone should be the first kind; the other three exist to help the first kind go fast.

Team Topologies makes a radical simplification: in a modern software organization you need only four fundamental team types, and every team should clearly be exactly one of them. The power isn’t in the labels — it’s in the discipline of refusing to let a team be a vague blob of “miscellaneous responsibilities.” Ambiguous teams create ambiguous, sprawling architectures (Conway again). A team that knows precisely which of the four it is knows what it owns, what it doesn’t, and how it should interact with everyone else.

Stream-aligned teams — the default

A stream-aligned team is aligned to a single valuable stream of work: a product, a user journey, a market segment, a business capability. It owns that slice end to end — build, test, deploy, run, and support — with as few hand-offs as possible. This is the default; in a healthy org the overwhelming majority of teams are stream-aligned, and the other three team types exist for one purpose only: to reduce the friction and cognitive load on stream-aligned teams so they can keep flowing. 🦆 Dot the Duck is a stream-aligned developer. If you ever find yourself creating a team that isn’t stream-aligned, you should be able to explain precisely which of the other three types it is and why that’s justified.

Platform teams — the paved road

A platform team provides a compelling internal product — a curated set of self-service capabilities (compute, delivery, observability, secrets, golden paths) — that stream-aligned teams consume to accelerate delivery. The keyword is compelling: adoption is voluntary and earned, not mandated. A good platform is the “easiest correct way” to do a thing, so teams choose it. Crucially, a platform team is thin by default — it wraps and curates the underlying complexity rather than reinventing it, aiming for the thinnest viable platform that meaningfully lowers cognitive load. Everything in the rest of this course — GitOps, self-service APIs, observability — is the substance a platform team curates into that product.

Enabling teams — the coaches

An enabling team is a small band of specialists (in testing, security, CI, architecture, or a new technique) whose job is to help stream-aligned teams acquire a missing capability — and then leave. They coach; they do not do the work for others, and they do not become a permanent gatekeeper standing between a team and production. The defining property of a healthy enabling team is that its engagements are time-bounded: it works alongside a stream-aligned team for weeks, transfers the skill, and moves on. An enabling team that never leaves has quietly become a bottleneck — a dependency the stream-aligned team must now coordinate with forever, which is exactly the coupling we’re trying to remove.

Complicated-subsystem teams — the deep specialists

A complicated-subsystem team owns a part of the system that requires such deep, specialist knowledge that it would overwhelm a stream-aligned team to carry it: a video codec, a real-time pricing or tax engine, a machine-learning ranking model, a physics solver. Concentrating that expertise in one team is a deliberate cognitive-load decision — it lets the many stream-aligned teams consume the subsystem through a clean interface without having to understand its internals. The test for creating one is strict: it exists only where the specialist knowledge is genuinely rare and deep, not merely because a component is “important.” Over-using this type fragments your architecture into technical layers and re-invites the Conway problem.

The three interaction modes

☺ Like you’re 10: There are only three ways two teams can work together. A platform team should almost always use the “vending machine” way — you take what you need without asking a person.

Team types tell you what a team is; interaction modes tell you how two teams relate at a given time. Team Topologies names exactly three, and — like the team types — the discipline is in being explicit about which mode is in force between any two teams, because an unstated interaction mode is where hand-offs, resentment, and coupling breed.

Collaboration — high bandwidth, high cost, temporary

Collaboration is two teams working closely together, sharing responsibility, for a bounded period of discovery. It has the highest bandwidth and is wonderful for exploring an unknown — co-designing a brand-new capability where neither side yet knows the interface. But it is expensive: blurred ownership, more communication overhead, and a larger combined cognitive load. Collaboration should be a phase, not a lifestyle. The healthy pattern is “collaborate to discover the interface, then transition to a cleaner mode once it stabilises.” A collaboration that never ends is two teams that should probably be one team, or a missing service boundary.

X-as-a-Service — the platform’s default mode

X-as-a-Service is one team consuming something another team provides — a platform, an API, a component — with minimal ongoing collaboration. The consumer doesn’t need to understand the provider’s internals; they read the docs and self-serve. This is the low-friction, low-cognitive-load mode, and it is the mode a platform team should be in with its consumers the vast majority of the time. The whole design goal of a platform is to make “X-as-a-Service” real: a stream-aligned team gets a database, a pipeline, or a preview environment by making a request to an API or clicking a button — not by scheduling a meeting. Every interaction you can move from Collaboration to X-as-a-Service removes a hand-off and buys back flow.

Facilitating — the enabling mode

Facilitating is one team helping another to learn or unblock — the natural mode for an enabling team. It’s about clearing impediments and transferring skill, not delivering features. Facilitating is deliberately lightweight and, like collaboration, time-bounded. A platform team occasionally facilitates too — for instance, briefly pairing with a stream-aligned team to help them adopt a new golden path — but it must be careful not to let facilitating curdle into “the platform team does your migration for you,” which turns self-service back into a service desk.

Why the platform should mostly be X-as-a-Service

Here is the single most important design rule for a platform team, and it follows directly from the modes above: your steady-state relationship with stream-aligned teams should be X-as-a-Service, not Collaboration. Collaboration is seductive — “let’s just jump on a call and set up your environment together” feels helpful — but every collaboration is a hand-off in disguise and a dependency the other team must schedule around. If your platform can only be adopted through a series of pairing sessions, you have not built a platform; you have built a consultancy. The correct arc is: briefly collaborate with an early team to discover what the self-service interface should be, harden that interface, then move every subsequent team onto pure X-as-a-Service. When collaboration is the exception rather than the rule, you know the platform is real.

The platform team as an internal service provider

☺ Like you’re 10: The platform team runs a little shop, and the other teams are its customers. If the customers don’t like the shop, they won’t come — so you have to make it genuinely good, not force people in.

Once you accept that a platform team should be X-as-a-Service, a whole posture follows: the platform team behaves like an internal service provider running a product, and stream-aligned teams are its customers. This is the bridge between Team Topologies and everything on Platform as a Product — the org-design lens and the product lens are describing the same team from two angles.

Thin by default — the thinnest viable platform

A platform team’s instinct should be to build as little as possible. The thinnest viable platform (TVP) is the smallest set of capabilities that measurably reduces the cognitive load of stream-aligned teams — sometimes just a well-curated wiki page and two paved paths, not a sprawling in-house PaaS. Every capability you add is a capability you must run, secure, document, and support forever; a platform that boils the ocean becomes its own maintenance swamp. The discipline is to wrap and curate proven building blocks (Kubernetes, a CI system, a secrets manager) into a coherent product, rather than reinventing them. Start thin, and let real demand — not architectural ambition — pull the next capability into existence.

Self-service, not tickets

The defining behaviour of a platform-as-service is that capabilities are consumed through self-service interfaces — an API, a CLI, a portal, a Git commit — rather than a request to a human. This is the concrete mechanism by which the platform delivers X-as-a-Service. A stream-aligned developer provisions what they need and moves on; the platform team is never in the critical path of anyone’s Tuesday afternoon. Here is what that consumption looks like from the developer’s side — no ticket, no meeting, no hand-off:

# A stream-aligned developer consuming the platform as-a-service.
# No ticket. No pairing session. No hand-off to the platform team.
$ platform new service --template golden-path --name payments-api

✓ repo created            github.com/acme/payments-api
✓ CI/CD pipeline wired    build → scan → sign → deploy (see cicd-progressive-delivery)
✓ managed Postgres        Crossplane claim submitted & reconciling
✓ dashboards + SLOs       pre-provisioned in Grafana
✓ on-call rotation        registered in the incident tool
✓ secure-by-default       network policy, RBAC & policy gates applied

→ merge to main deploys to prod in ~4 min. You own it; we paved it.

Product-managed — the platform is the product

Because it has customers, a platform team needs the machinery of a product: a product manager, a roadmap driven by discovery rather than by the loudest requester, adoption and satisfaction metrics, versioning, deprecation policies, and support. The platform is the product; the stream-aligned teams are the market. This reframing changes everything about how the team prioritises — you stop asking “what do we think is cool to build?” and start asking “what is the biggest source of friction for our users, and how do we remove it?” The habits that make this work in practice — treating adoption as voluntary, measuring it honestly, and managing the platform’s lifecycle — are covered in Platform as a Product and the platform best practices. Registered in the developer portal, the platform is a first-class product with a named owner, a lifecycle, and versioned APIs — not an anonymous pile of scripts:

# catalog-info.yaml — the platform registered as a PRODUCT in the developer portal.
# The platform team owns it as a product; stream-aligned teams are the consumers.
apiVersion: backstage.io/v1alpha1
kind: System
metadata:
  name: developer-platform
  description: Internal developer platform — self-service golden paths
spec:
  owner: group:platform-team          # a real, long-lived team owns it (persistent funding)
---
apiVersion: backstage.io/v1alpha1
kind: API
metadata:
  name: golden-path-scaffolder
  description: Self-service creation of production-ready services (X-as-a-Service)
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: openapi
  lifecycle: production               # versioned & supported, with a deprecation policy
  owner: group:platform-team
  system: developer-platform

Cognitive load as the organizing principle

☺ Like you’re 10: Your brain can only hold so much at once. The platform’s job is to carry the boring, in-the-way stuff so your brain has room for the actual problem.

Underneath team types and interaction modes sits the concept that makes sense of all of them: cognitive load. Team Topologies borrows the idea from John Sweller’s learning research and turns it into an organizing principle: you size a team’s responsibilities to fit the cognitive load the team can carry. When a team is asked to hold more than fits in its collective head, quality and flow both collapse — not because the people are weak, but because the load exceeds capacity. Almost every good structural decision on this page is, at bottom, a move to keep some team’s cognitive load under its ceiling.

The three kinds of cognitive load

Sweller splits load into three parts, and the distinction is the whole game:

• Intrinsic — the load inherent to the problem itself (the essential difficulty of the business domain, the algorithm, the maths). You can’t remove it; you can only build skill against it.
• Extraneous — the load imposed by how the work is presented: fighting a flaky deploy, deciphering undocumented infra, wiring the same boilerplate for the hundredth time. This adds no value and is pure tax.
• Germane — the load of building useful mental models: genuinely learning the domain, designing the solution, the thinking that creates value.

The platform’s entire reason to exist, expressed in these terms, is to drive extraneous load toward zero so that a team’s finite capacity is spent on intrinsic and germane load — on the actual problem, not the plumbing around it.

The platform caps extraneous load

Notice the leverage. A platform team cannot reduce another team’s intrinsic load — the business problem is theirs to solve — and it shouldn’t touch germane load, which is where the good thinking happens. Its entire target is the extraneous slice: the deploy tooling, the environment wrangling, the observability wiring, the security boilerplate. This is why what platform engineering is can be defined almost entirely in cognitive-load terms: it’s the practice of systematically removing extraneous cognitive load from stream-aligned teams so their capacity flows to the problems only they can solve. A “successful” platform capability is one you can point at and say “this used to cost every team three days of extraneous load; now it costs zero.”

Sizing a team’s domain to fit

Cognitive load also tells you how big a team’s responsibilities should be. A stream-aligned team should own a domain small enough to fit comfortably within its collective head — Team Topologies calls this a “team-sized” slice of the world. When a team is drowning, you have two moves: reduce the intrinsic load by splitting the domain so each team owns less, or reduce the extraneous load by giving them better platform capabilities. The subtle failure is to keep piling responsibilities onto a “full” team because it looks organisationally tidy on a chart; the load doesn’t show up on the chart, but it shows up in the incident count. Cognitive load is the invisible budget every org-design decision spends.

Sizing, funding & structuring the platform team

☺ Like you’re 10: A platform is a real product, so it needs the same things a product needs — someone deciding what to build, enough builders, and steady money — not a one-off project grant that runs out.

If the platform is a product, it must be staffed and funded like one. This is where many platform initiatives quietly fail: they’re run as a time-boxed “platform project” with borrowed engineers and no product owner, and when the project money ends the platform rots. Structuring the team well is as important as any architecture decision.

The product trio & staffing

A healthy platform team is built around a product trio: product management, engineering leadership, and design/developer-experience, working together rather than in a hand-off line. Product decides what and why, engineering owns how, and DevEx/design ensures the thing is genuinely usable — because a platform nobody can figure out delivers zero cognitive-load relief no matter how powerful it is. Staffing should be sized to run the platform as a service (including on-call for the capabilities it operates), not merely to build it once and walk away. A platform with no operational staffing is a platform that will page a stream-aligned team at 2am for something the platform team promised to own.

The platform product manager

The platform PM is the role most often missing and most sorely needed. Their job is discovery — continuously sensing what stream-aligned teams struggle with — and translating it into a prioritised roadmap, rather than building whatever the most senior engineer finds interesting. They own the platform’s adoption and satisfaction metrics (adoption rate, time-to-first-deploy, developer NPS, the fraction of teams on golden paths), and they make the hard calls about what not to build and what to deprecate. A platform PM is what keeps a platform team pointed at its users instead of at its own cleverness — the antidote to the ivory tower we’ll meet in the next section.

The platform as a group of teams

At small scale a platform is one team; at large scale “the platform team” becomes a group of teams, and — beautifully — Team Topologies applies recursively to it. Within the platform group, you’ll find stream-aligned teams that each own an internal product (the “delivery experience” team, the “observability” team, the “developer portal” team, each treating the other platform teams and the wider org as customers), possibly a complicated-subsystem team (e.g. the multi-cluster control plane), and even an internal enabling function. The same four types and three modes that structure the whole org also structure the platform’s insides. A platform group that ignores this — one giant undifferentiated “platform team” of thirty people — collapses under its own cognitive load exactly as any over-loaded team would.

Funding models

Finally, money shapes behaviour. Project funding — a lump sum to “build the platform,” then disband — is the classic trap: it optimises for shipping features before the deadline and guarantees the platform decays once funding ends, because no one is paid to run it. Persistent product funding — an ongoing budget for a long-lived team that owns the platform as a product — is what actually works, and it’s what the product framing implies. Some organizations layer showback or chargeback on top (attributing platform cost back to consuming teams) to keep the platform honest about value; done well this is a FinOps-style feedback loop, done badly it turns your internal platform into a toll road that pushes teams back toward building their own snowflakes.

Socio-technical anti-patterns

☺ Like you’re 10: Here are the classic ways a platform team goes wrong — usually by forgetting it has customers and starting to boss them around instead.

Most platform failures are socio-technical, not technical. The tech is fine; the team is in the wrong mode, chasing the wrong incentive, or scoped wrongly. These four failure patterns recur so often they’re worth memorising as smells. Each has a deeper treatment in Anti-Patterns & Pitfalls; here we name them through the org-design lens.

The ivory-tower platform

The ivory-tower platform is built by a team convinced it knows what developers need without ever asking them. It’s architecturally gorgeous and adoption is near zero, because it solves the problems the platform team found interesting rather than the ones stream-aligned teams actually have. The root cause is missing product discovery — no platform PM sensing real needs. The tell is a platform that’s mandated because no one would choose it voluntarily. The cure is to treat adoption as a market signal: if teams won’t use it without being forced, the platform is wrong, not the teams.

The rebranded ops ticket queue

The rebranded ops queue is the old operations team with a new “Platform” nameplate and the same ticket-driven workflow underneath. Developers still request infrastructure by filing a ticket and waiting for a human; nothing about the communication structure has changed, so — by Conway — nothing about the architecture or the flow changes either. This is the interaction-mode failure: the team calls itself X-as-a-Service but operates as permanent Collaboration/hand-off. Renaming Ticket Swamp doesn’t drain it. The fix is to relentlessly convert human-in-the-loop requests into genuine self-service.

Mandate by decree

Mandate by decree is forcing adoption from above (“all teams must be on the platform by Q3”) instead of earning it by being the easiest correct path. Mandates paper over a platform that isn’t compelling and breed malicious compliance — teams technically adopt while building shadow workarounds, and you lose the honest adoption signal that would have told you what to fix. A platform earns its users by lowering their cognitive load so much that choosing it is obvious. If you need a decree, listen to what the decree is hiding.

The too-broad platform

The too-broad platform tries to own everything at once — every language, every workflow, every edge case — and drowns in its own surface area, blowing past the platform team’s own cognitive-load ceiling. It’s the mirror image of the thinnest-viable-platform discipline. The result is a platform that’s mediocre at a hundred things instead of excellent at the ten that matter, perpetually behind on support, and impossible to operate reliably. Scope is a feature: a platform that says “no” to the long tail and does the common paths superbly beats one that does everything badly.

Evolving the organization

☺ Like you’re 10: If you want the software to come out a certain shape, first rearrange the teams into that shape on purpose — then start small and grow only when people actually ask for more.

Because architecture copies organization, you can run the causality forwards: deliberately design the team structure that would produce the architecture you want, and let Conway’s Law do the building for you. Team Topologies calls this the reverse Conway maneuver, and pairs it with a few practices for making a team’s boundaries explicit and letting the platform grow with real demand.

The reverse Conway maneuver

The ordinary Conway effect is accidental: you don’t plan your architecture, so it defaults to the shape of your org chart. The reverse Conway maneuver is the intentional version: decide on the target architecture (say, loosely-coupled services each owned end-to-end), then restructure the teams so their communication paths naturally produce it — stream-aligned teams with clean, service-shaped boundaries, and a platform team removing the dependencies that would otherwise force them to coordinate. You’re not fighting Conway’s Law; you’re aiming it. This is exactly why standing up a platform is an org intervention as much as a technical one, and why platform and architecture leadership have to move together — as Professor Owl would insist, you can’t draw the reference architecture without also drawing the org.

The Team API

For teams to interact cleanly — especially in X-as-a-Service mode — each team needs a well-defined, published interface, just like a piece of software. Team Topologies calls this the Team API: the explicit surface a team exposes to the rest of the org. It includes the code and services the team owns, its documentation and how to consume its services, its versioning and deprecation approach, how to reach it and request work, and what it’s currently working on. Making the Team API explicit is what lets other teams self-serve against it instead of scheduling a meeting to figure out how to work together. A platform team’s Team API is arguably its most important artifact — it’s the contract that makes “consume the platform as a service” concrete:

# team-api.yaml — the explicit, published interface of the Platform Team.
# Other teams read this instead of scheduling a meeting to figure us out.
team: platform-team
type: platform
mission: >
  Reduce cognitive load for stream-aligned teams via compelling,
  self-service golden paths — the thinnest viable platform, grown by demand.

default-interaction-mode: x-as-a-service   # how we relate to product teams 99% of the time

interaction-modes:
  collaboration:                            # time-boxed & rare, only to co-design a new capability
    - team: checkout
      until: 2026-09-01                     # then we transition them to X-as-a-Service
  facilitating: []                          # we are NOT an enabling team

provides:                                   # our Team API surface — self-service, no tickets
  service-catalog: backstage.acme.dev
  golden-paths:  [ new-service, managed-postgres, observability-as-code ]
  docs:          backstage → /docs/platform
  code:          github.com/acme/platform

consumes:
  - team: cluster-team                      # we build on the k8s substrate they provide (XaaS)

communication:
  chat: '#platform-support'
  office-hours: 'Tue & Thu, 14:00–15:00'
  request-work: 'open a PR to platform/roadmap — do NOT file a ticket'
work-in-progress: backstage.acme.dev/platform/now

Sensing developer needs

A platform that stops listening starts drifting toward the ivory tower. Team Topologies describes a healthy organization as a sensing organization — teams continuously sense their environment and adapt. For a platform team that means running developer-experience discovery as an ongoing product practice: developer surveys, adoption and DORA-style metrics, embedded observation of how teams actually work, and fast feedback loops from support channels back into the roadmap. Sensing is what turns “we think teams need X” into “we measured that teams are losing three days to X.” It’s the difference between a platform that grows toward its users and one that grows toward its own reflection.

Thinnest viable platform, then grow with demand

Put the pieces together and you get the evolution strategy: start with the thinnest viable platform — the least you can build that removes real extraneous load — get it genuinely adopted, sense what hurts next, and grow only in the direction demand pulls you. Resist the urge to pre-build the grand platform; you’ll build the wrong grand platform. Each new capability should earn its place by relieving a load you actually measured, offered X-as-a-Service, funded as a lasting product, and owned by a team whose own cognitive load stays under the ceiling. That’s the whole discipline: aim Conway’s Law, cap cognitive load, stay in service mode, and let real developers pull the platform into being.

Team Topologies is the lens that makes every other lesson click: GitOps, self-service, and observability are how a platform lowers cognitive load, but the four team types and three interaction modes are why those tools change anything at all. Carry one sentence out of this page — architecture and organization are the same drawing — and you’ll design better platforms than most senior engineers who’ve never heard of Conway.