Team Topologies

Why Team Topology Matters

Team Topologies (the book by Matthew Skelton and Manuel Pais) provides a model for designing organisations around fast flow of software delivery. The core insight: how you structure teams determines what software architecture you can build — and how fast you can change it.

Most organisational problems — slow delivery, endless coordination overhead, blocked teams — are actually topology problems. The wrong team structure generates the wrong communication patterns, which generates the wrong software.

Conway's Law

"Any organisation that designs a system will produce a design
whose structure is a copy of the organisation's communication structure."
— Melvin Conway, 1967

In practice:
→ Teams with high coordination overhead → tightly coupled software
→ Siloed teams → siloed architecture with integration problems
→ One team owns payments → payments service has one interface

Inverse Conway Manoeuvre:
→ Design the team structure you want FIRST
→ The architecture will follow
→ Want microservices? → create teams with bounded domains first
→ Want a platform? → create a dedicated platform team first

Cognitive Load

Every team has a finite capacity to understand and manage the systems they own. Cognitive load is the total mental effort required to maintain, build, and operate those systems. Teams that exceed their cognitive load slow down, make mistakes, and burn out.

Three types of cognitive load:
Intrinsic   → Fundamental complexity of the domain (unavoidable)
Extraneous  → Process and coordination overhead (eliminate this)
Germane     → Learning and skill-building (invest in this)

Team Topologies goal:
→ Minimise extraneous cognitive load through good topology
→ Cap team scope so intrinsic load stays manageable
→ Use enabling teams to build germane load (capability)

Signals that a team is overloaded:
→ Onboarding new members takes months
→ Fear of touching certain parts of the codebase
→ No time for anything except firefighting
→ "We can't do that — it touches too many systems"

The Four Team Types

Characteristics:
→ Long-lived, stable team (not project-based)
→ End-to-end ownership from idea to production
→ Full stack capability (design, dev, test, ops)
→ Empowered to make technology decisions
→ Minimal external dependencies to ship

Examples:
→ "Checkout team" (owns the checkout flow end-to-end)
→ "Mobile team" (owns the iOS and Android apps)
→ "Growth team" (owns acquisition and activation)

What they need from other teams:
→ Platform team to provide internal services as self-service
→ Enabling team to upskill on new capabilities
→ Complicated-subsystem team for specialist components

Characteristics:
→ Treats internal teams as customers
→ Self-service API/tooling (not ticket-based)
→ Provides "golden paths" — opinionated, well-lit routes
→ Absorbs complexity so stream teams don't have to

Examples:
→ Developer platform team (CI/CD, environments, observability)
→ Data platform team (pipelines, warehouse, BI infrastructure)
→ Security platform team (auth, secrets, compliance tooling)

Success metric:
"Stream-aligned teams can ship features independently
 using the platform, without raising a ticket to our team."

Characteristics:
→ Temporary engagement (weeks to months, not forever)
→ Teach and leave; do not create permanent dependency
→ Focus: upskill the stream team, not do the work for them
→ Proactively identify emerging capability gaps

Examples:
→ DevOps enabling team (embeds to roll out CI/CD practices)
→ Accessibility team (teaches accessibility; team then owns it)
→ Security champions team (trains and certifies team members)

Anti-pattern: enabling team that never leaves
→ If an enabling team is permanent, it has become a service team
   or a bottleneck — both are wrong

Characteristics:
→ Deep specialist expertise (maths, physics, signal processing, ML)
→ Exposes well-defined interfaces; not a coordination point
→ Stream teams consume output — do not need to understand internals
→ Used sparingly — most teams should not be this type

Examples:
→ Video encoding team (FFmpeg specialists; exposes encoding API)
→ Fraud detection ML team (statistical models; exposes a scoring API)
→ Search relevance team (Elasticsearch tuning; exposes search API)

When to use:
Only when the cognitive load of the subsystem is genuinely too high
for a stream-aligned team to own AND use simultaneously.

3 Interaction Modes

How teams interact is as important as how they are structured. Team Topologies defines three explicit interaction modes. Each is appropriate in certain contexts and should evolve over time.

Interaction mode evolution:
New capability discovery → Collaboration (2–3 teams work closely)
Capability stabilises    → X-as-a-Service (platform exposes API)
Upskilling needed        → Facilitating (enabling team coaches)

Healthy flow:
Stream team ←X-as-a-Service← Platform team
Stream team ←Facilitating← Enabling team
Stream team ↔ Collaboration ↔ Stream team (temporarily)

Anti-Patterns

Team Topologies Cheat Sheet

4 Team Types
Stream-Aligned      → primary type; owns flow end-to-end
Platform            → reduces cognitive load via self-service
Enabling            → grows stream team capability; temporary
Complicated-Subsystem → isolates specialist complexity as a service

3 Interaction Modes
Collaboration  → close work on discovery; high cost; time-limited
X-as-a-Service → consume API/service; low overhead; steady-state goal
Facilitating   → enabling team teaches; ends when capability transferred

Key principles
→ Conway's Law: team structure → software structure
→ Inverse Conway: design the team structure you want first
→ Cognitive load: cap team scope; eliminate extraneous complexity
→ Stream teams are the goal; all other types exist to support them

Signals you need a topology change
→ Teams blocked waiting on other teams every sprint
→ "Simple" features require 4+ teams to coordinate
→ Platform team drowning in tickets from stream teams
→ Onboarding takes months; fear of touching systems