Over the years, I’ve worked in software organizations large and small, from monolithic systems to microservices both cloud-native and on-premise architectures. One of the most transformative models I’ve come across for structuring software teams effectively is Team Topologies, developed by Matthew Skelton and Manuel Pais. It resonated with my architectural work because it bridges organizational design with technical boundaries.
In this article, I want to share how the four fundamental team types from the Team Topologies model may help organizations better align people, processes, and architecture.
Stream-Aligned Teams: Aligning Teams to Business Value
From an architectural perspective, one of the biggest pain points is unclear ownership — systems with too many cooks in the kitchen. Stream-aligned teams address this head-on. They’re formed around a specific business domain or product stream, and crucially, they own their services end-to-end.
Benefits
- Clear service boundaries
- Ownership of data models and APIs
- Easier to implement event-driven or service-based architectures
- Improves testability and deployment independence
Enabling Teams: Accelerating Adoption of New Tech
Every time we introduced new tooling — Kubernetes, service mesh, observability stacks — teams got overwhelmed. That’s where enabling teams made the difference.
These teams don’t deliver business features but instead coach and unblock delivery teams. In architecture terms, they accelerate tech adoption without turning central architecture into a bottleneck.
Benefits
- Faster rollout of cross-cutting concerns (security, infrastructure, SRE practices)
- Reduces misimplementation of complex technologies
- Supports sustainable scaling of tech stacks
Complicated Subsystem Teams: Isolating Deep Technical Expertise
As an architect, I’ve seen teams struggle with parts of the system that require deep, uncommon expertise — like real-time data processing or cryptographic protocols. Pushing this complexity into every team creates a huge cognitive burden. That’s where Complicated Subsystem Teams come in. Such features usually can be easily extracted into separate features and thus, handled by specialized team
Benefits
- Keeps complexity contained
- Allows for rigorous design and performance tuning in isolation
- Reduces risk of bugs in critical, complex logic
Platform Teams: Building the Internal Developer Experience
Platform teams were a game-changer. For years, I saw devs lose time configuring CI/CD, reinventing monitoring dashboards, or dealing with inconsistent environments. Platform teams create golden paths and reusable tools that reduce this friction. As exemplary tools, I can mention: template services, common libraries (e.g. authentication/authorization, feature flags), Kafka platform.
Benefits
- Enforces consistency across systems without being a gatekeeper
- Speeds up provisioning and deployment
- Abstracts away infrastructure complexity
- Enables self-service environments aligned with governance
Final Thoughts
From a practical standpoint, it’s relatively easy to categorize people into the four team types defined in Team Topologies. In fact, most organizations can establish Enabling, Platform, and Complicated Subsystem teams within a short time, if needed.
However, one of the more challenging aspects—rarely addressed explicitly in the book—is how to translate the features defined by Product Management into a structure that aligns with stream-aligned teams. In practice, this is often the most difficult task, and it’s rarely successful.
The core issue lies in the fact that this process requires not only an understanding of the business processes themselves but also how those processes interact across domains. Anyone responsible for modeling these processes needs to be familiar with key software concepts such as APIs, shared models, and domain events. Unfortunately, in many organizations, features are assigned somewhat arbitrarily, without proper regard for ownership boundaries or domain alignment. Often, there is an overemphasis on increasing cross-team collaboration instead of optimizing for autonomy and flow. In most cases, this approach fails to scale effectively.
The most reliable way to divide business processes into coherent technical models is by using a structured approach that reveals the connections between features and underlying domain flows. For this purpose, I strongly recommend using Event Storming. It is a powerful tool for uncovering domain relationships, aligning technical and business stakeholders, and driving effective service boundaries.