Team Topologies and platform teams

Evolutionary architecture says change happens across multiple dimensions, and team structure is one of them. Team Topologies by Matthew Skelton and Manuel Pais (2nd edition, 2025) gives a vocabulary for designing teams so that change can flow. It’s also where the idea of a platform team that treats its platform as a product comes from.

Why team structure is architecture

• Conway’s law. Systems tend to mirror the communication structure of the organisation that builds them. If two teams have to coordinate on every change, their parts of the system end up tightly coupled.
• The inverse Conway manoeuvre. Design teams around the architecture you want, and the architecture tends to follow.
• Teams and quanta. An architecture quantum evolves independently only if one team can change and deploy it without waiting on others. A quantum split between teams, or a team spread across many quanta, works against independent change.

Cognitive load

The central constraint in Team Topologies is team cognitive load: how much a team can hold in its head at once. It distinguishes three kinds:

Kind	Meaning	Aim
Intrinsic	Fundamental to the task (for example, knowing the programming language)	Reduce through training and good tooling
Extraneous	Incidental to the task (for example, how to get a deployment through)	Minimise, ideally by moving it into a platform
Germane	Domain knowledge that adds value (for example, how payments work)	Maximise; this is where teams should spend their attention

Teams should be sized to their cognitive load. A large share of what a cloud platform does is remove extraneous load from product teams.

The four team types

Team type	Purpose
Stream-aligned	Owns a slice of the business domain end to end (“you build it, you run it”). Most teams should be this type.
Platform	Provides internal services as a product so stream-aligned teams can deliver faster. A platform can be a group of teams, which may include other team types inside it.
Enabling	Helps stream-aligned teams overcome obstacles and adopt new capabilities, then steps away.
Complicated-subsystem	Owns a part that needs deep specialist knowledge (for example, a pricing engine or video codec).

The three interaction modes

Mode	What it looks like	When to use
Collaboration	Two teams work closely together for a defined period	Discovering something new: an API, a practice, a technology
X-as-a-Service	One team provides something; the other consumes it with little interaction	Once the thing is well understood and stable
Facilitating	One team helps and mentors another	Building capability in the other team

The evolutionary part

Interaction modes are meant to change over time. A typical path is: collaboration while a new capability is discovered, then X-as-a-Service once it stabilises, with facilitation to spread it to other teams. The second edition calls this out with patterns for flexible team boundaries and continuous adaptation. Collaboration that never ends is a sign the boundary is in the wrong place.

Fracture planes

When a system or team has grown too big, fracture planes are natural seams along which to split it. The default is the business domain (a bounded context). Others include regulatory compliance, change cadence, risk, performance isolation, technology, and team location. These map closely to the reasons for creating a separate architecture quantum: a part with different characteristics or a different rate of change.

Platform teams

• Platform as a product. Treat stream-aligned teams as customers. Do user research, publish a roadmap, measure adoption, and make the platform the easiest path rather than a mandated one.
• Thinnest viable platform (TVP). Build the smallest platform that actually speeds teams up, and grow it only when there’s demand. A TVP might start as documentation and a few templates. Left alone, platforms tend to grow bigger than anyone needs.
• A clear interface. Each team should make clear how others should interact with it: its services, documentation, how to ask for help, and its current interaction modes. The book calls this a team API.
• Measure it. The CNCF Platforms Working Group’s platform engineering maturity model is a useful lens for assessing a platform. Its authors warn against following any maturity model rigidly.

Applied to the AWS platform

Continuing the scenario from the decision log: a regulated organisation, about 40 product teams, one shared AWS platform.

Team map

Team	Type	Owns	Interaction with product teams
~40 product teams	Stream-aligned	Their workloads, accounts, and event buses	—
Cloud foundation	Platform	Accounts, OUs, identity, guardrails (ADR-0001), Terraform foundation	X-as-a-Service (Account Factory, self-service)
Network	Platform	Transit Gateway, IPAM, egress inspection (ADR-0002)	X-as-a-Service (connectivity in the account baseline)
Developer experience	Platform	CDK construct library and golden paths (ADR-0004), event patterns (ADR-0003)	X-as-a-Service, with collaboration for new paths
Cloud enablement	Enabling	Coaching on AWS, fitness functions, observability	Facilitating, time-boxed
Risk scoring	Complicated-subsystem	A specialist fraud and risk model used by several product teams	X-as-a-Service

Interaction modes over time

Take the EventBridge backbone in ADR-0003:

1. Collaboration (about one quarter): developer experience works closely with three producer teams to build the first cross-account event patterns and schema checks.
2. X-as-a-Service: the patterns become a construct in the golden-path library, with documentation. New teams adopt them without needing the platform team.
3. Facilitating: cloud enablement helps teams that are new to event-driven design, then steps away.

Account vending is different: it’s well understood, so it’s X-as-a-Service from day one.

Fitness functions for team structure

Team structure can be checked too, though some checks are manual or survey-based:

• Number of tickets to platform teams per production deployment (should trend toward zero).
• Share of changes that need coordination across more than one team (from change records or PR links).
• No more than one or two collaboration engagements per platform team at once (collaboration is expensive).
• Each collaboration engagement has an end date and a planned move to X-as-a-Service.
• A regular team cognitive load survey for product teams.
• Golden-path adoption and platform satisfaction (see evolving a cloud platform).

Where the enterprise architect fits

• Shaping fracture planes: helping decide where team and quantum boundaries go, using business domains and the ranked characteristics.
• Acting like an enabling team: facilitating teams to make good decisions (for example, through the advice process and ADRs), rather than becoming a review-board bottleneck that every change has to pass through.
• Watching interaction modes: noticing when a collaboration has gone on too long, or when a dependency between teams suggests a boundary is wrong.

Key takeaway

Team design is architecture design. For a platform, the goal is to reduce product teams’ extraneous cognitive load with a thin, product-minded platform, and to let interaction modes evolve from collaboration to self-service. Good questions to ask a team you’re considering joining: how are teams organised today, and how do they interact with the platform?

Sources

• Team Topologies, Key concepts: the four team types, three interaction modes, and the principles and patterns (including the thinnest viable platform and continuous adaptation).
• Matthew Skelton, Manuel Pais, Team Topologies (IT Revolution); second edition and case studies.
• Team Topologies: reduce cognitive load of software teams (mimacom) and Team Topologies summary: secondary summaries of cognitive load, fracture planes, and the thinnest viable platform.
• Trade Me’s TVP case study (2nd edition).
• CNCF TAG App Delivery, Platform engineering maturity model and Platforms working group.