Team Topologies, developed by Matthew Skelton and Manuel Pais, provides a practical framework for organising engineering teams around the flow of change. Rather than defaulting to component-based or project-based teams, Team Topologies aligns team structure with software architecture and business domains. This guide shows engineering managers how to apply Team Topologies to reduce cognitive load, improve delivery speed, and create sustainable team structures.
The Four Fundamental Team Types
Team Topologies defines four fundamental team types, each with a distinct purpose. Stream-aligned teams are the primary team type - they are aligned to a single flow of work, typically a business domain, product, or user journey. These teams have end-to-end ownership and can deliver value independently without waiting for other teams. Most teams in an organisation should be stream-aligned.
Platform teams provide internal services that reduce the cognitive load on stream-aligned teams. Rather than each stream-aligned team building its own deployment pipeline, logging infrastructure, or authentication system, a platform team provides these as self-service capabilities. The key principle is that platform teams should be treated as internal products - they succeed by making stream-aligned teams more productive, not by mandating adoption.
Enabling teams help stream-aligned teams acquire new capabilities - a team of specialists in observability, security, or test automation that works alongside stream-aligned teams to build their skills and then moves on. Complicated-subsystem teams own a part of the system that requires deep specialist knowledge - a machine learning model, a real-time data processing engine, or a financial calculation engine - that would be unreasonable to expect a stream-aligned team to maintain.
- Stream-aligned teams are the primary type - they own end-to-end delivery for a business domain
- Platform teams provide self-service capabilities that reduce cognitive load on stream-aligned teams
- Enabling teams temporarily embed with stream-aligned teams to build new capabilities
- Complicated-subsystem teams own components requiring deep specialist knowledge
- Most teams should be stream-aligned; other types exist to support them
Team Interaction Modes
Team Topologies defines three core interaction modes that clarify how teams should work together. Collaboration is a close partnership where two teams work together on a shared goal for a defined period. This mode is useful for exploring new approaches or building new capabilities but is expensive and should not be the default - sustained collaboration indicates unclear team boundaries.
X-as-a-Service is the most scalable interaction mode. One team provides a service (API, platform capability, or tool) that other teams consume through a well-defined interface. The provider team can serve many consumers without tight coupling, and consumers can use the service without understanding its internal implementation. Platform teams typically interact with stream-aligned teams via X-as-a-Service.
Facilitating is the interaction mode used by enabling teams. The enabling team works alongside a stream-aligned team to help them learn a new skill or adopt a new practice, then disengages once the capability is transferred. This mode avoids creating permanent dependencies while ensuring knowledge transfer happens effectively.
Managing Cognitive Load Through Team Design
Cognitive load is the central concept in Team Topologies - teams have a finite capacity for complexity, and exceeding that capacity leads to slow delivery, poor quality, and burnout. The three types of cognitive load are intrinsic (the inherent complexity of the domain), extraneous (unnecessary complexity imposed by tools, processes, or poor architecture), and germane (the complexity of learning and adapting to new challenges).
Engineering managers should actively manage their teams' cognitive load. Measure it informally by asking: does the team feel overwhelmed by the breadth of what they need to know? Are there parts of the system that nobody fully understands? Is the team struggling to keep up with the pace of change? Positive answers to these questions indicate excessive cognitive load that should be addressed through team restructuring, platform investment, or architecture simplification.
When cognitive load exceeds a team's capacity, the solution is usually to split the team's responsibilities - creating a new team that takes ownership of part of the domain. This is preferable to simply adding more people to an overloaded team, which increases coordination costs without necessarily reducing per-person cognitive load. Conway's Law tells us that system architecture follows team structure, so aligning team boundaries with natural architectural seams produces the best outcomes.
Applying Team Topologies in Your Organisation
Start by mapping your current team structure and identifying pain points. Which teams are bottlenecks that other teams frequently wait on? Which teams have cognitive load that exceeds their capacity? Where are team boundaries misaligned with the software architecture? These pain points indicate where Team Topologies can provide the most value.
Implement changes incrementally rather than reorganising everything at once. Start by converting one overloaded team into a stream-aligned team with clearer boundaries, or by forming a platform team to address a common bottleneck. Measure the impact - faster delivery, reduced waiting, improved team satisfaction - and use these results to build the case for broader changes.
Engage with Conway's Law deliberately. If your desired architecture requires independent, loosely coupled services, your team structure must support that - teams that share code repositories, databases, or deployment pipelines will inevitably produce tightly coupled systems. Align team boundaries with the architectural boundaries you want, and the architecture will follow.
Common Team Topologies Pitfalls
The most common pitfall is creating platform teams that become gatekeepers rather than enablers. A platform team that requires tickets and approvals for routine operations is not providing a platform - it is providing a bureaucracy. Platform teams should provide self-service capabilities that stream-aligned teams can consume independently. If a stream-aligned team needs the platform team's permission or assistance for routine operations, the platform is not yet mature enough.
Another pitfall is over-rotation toward enabling teams. Enabling teams are meant to be temporary - they embed with a stream-aligned team, transfer knowledge, and move on. If an enabling team permanently supports the same stream-aligned teams, it has become a dependency rather than an enabler. Set clear timelines for enabling engagements and measure whether the stream-aligned team can sustain the capability independently.
Ignoring cognitive load when defining team boundaries leads to teams that look good on paper but fail in practice. A team that owns a user-facing application, its backend API, and its data pipeline may be logically coherent but cognitively overwhelming. Test team boundaries against the cognitive load question: can this team reasonably understand and maintain everything they own?
Key Takeaways
- Most teams should be stream-aligned with end-to-end ownership of a business domain
- Platform teams should provide self-service capabilities, not act as gatekeepers
- Cognitive load is the key constraint - teams have finite capacity for complexity
- Align team boundaries with desired architectural boundaries to leverage Conway's Law
- Implement changes incrementally, measuring impact before broader reorganisation
Frequently Asked Questions
- How many people should be on a stream-aligned team?
- Team Topologies recommends teams of five to nine people, consistent with the well-established research on team size. Smaller teams lack the diversity of skills for end-to-end ownership. Larger teams suffer from coordination overhead that reduces productivity. If a domain requires more than nine people, split it into multiple stream-aligned teams with clear boundaries rather than creating a large team.
- When should you create a platform team?
- Create a platform team when multiple stream-aligned teams are independently building similar capabilities - deployment pipelines, monitoring systems, authentication flows - and the duplication is creating waste. The platform team should treat its consumers as customers and build self-service products that are compelling enough that teams choose to use them. Do not create a platform team until you have at least three stream-aligned teams with the same need.
- How does Team Topologies handle cross-cutting concerns like security?
- Cross-cutting concerns like security, observability, and accessibility are best handled through a combination of enabling teams and platform capabilities. An enabling team helps stream-aligned teams build security competence, while the platform team provides automated security scanning, policy enforcement, and secure defaults. This avoids creating a security gatekeeping team that blocks delivery while ensuring security is built into the development process.
Explore Engineering Manager Templates
Download our Team Topologies assessment template, cognitive load survey, and team boundary mapping tools to optimise your engineering organisation's structure.
Learn More