Skip to main content
Team Topologies is a framework for designing how software teams are structured and how they interact. It was developed by Manuel Pais and Matthew Skelton and laid out in their book Team Topologies - one of the more influential ideas in how modern tech companies think about organisation design 🏗️

​
The core insight

Conway’s Law states that organisations design systems that mirror their own communication structure. Team Topologies takes this seriously and flips it: if your software architecture is shaped by your team structure, then deliberately design your team structure to produce the architecture you want. It also introduces cognitive load as a first-class concern. Teams that own too much, depend on too many other teams, or have unclear boundaries become slow and frustrated. Good team design minimises unnecessary cognitive load.

​
The four team types

Stream-aligned teams - the primary team type. Aligned to a flow of work from a specific part of the business or user journey. Full-stack, autonomous, and able to deliver value end-to-end without constant dependency on other teams. The product trio model fits here. Platform teams - provide internal services that stream-aligned teams consume. Their job is to make other teams faster, not to deliver features directly. A good platform team treats its internal users as customers 💡 Enabling teams - temporary teams that help stream-aligned teams acquire new capabilities - new practices, tooling, or technical approaches. They’re not a permanent dependency; they upskill and move on. Complicated subsystem teams - own parts of the system that require deep specialist knowledge. Used sparingly, only when the complexity genuinely warrants it.

​
The three interaction modes

Collaboration - two teams work closely together for a defined period, usually to solve a complex problem or build a new capability. High bandwidth, not sustainable long-term. X-as-a-service - one team consumes another’s output with minimal interaction. Clear API, low coordination overhead. The goal for most platform relationships. Facilitating - an enabling team helps a stream-aligned team upskill. Temporary by design 🙌

​
Why PMs should care

Team topology shapes what’s possible for product teams. If your stream-aligned team has too many external dependencies to ship independently, the team design is the problem - not the team. Understanding this gives product leaders a lever beyond process and prioritisation. Lesson learned: the most common team topology problem I’ve seen isn’t the wrong type of team - it’s stream-aligned teams that aren’t actually stream-aligned. They own a technical component, not a user outcome. Reorienting around outcomes changes everything.