Team Topologies in Practice: Choosing the Right Team Structure
Skelton and Pais's "Team Topologies" (2019) gave engineering leadership a shared vocabulary for team structure. But I've seen organizations read the book, rename all their teams to fit the four types, and change nothing about how work actually flows. Others create platform teams before they had anything to platform-ify.
Here's how to actually apply it in practice, including when to restructure and when to leave things alone.
The Four Team Types: A Quick Refresher
If you've read the book, skip to the next section. If you haven't, here's the core model.
Stream-aligned teams are the primary value-delivery units. They own a stream of work — a product, a feature set, a business domain. Cross-functional and able to deliver end-to-end. Most of your engineers should be here.
Enabling teams help other teams adopt new technologies or capabilities. They don't build things for other teams — they help other teams build things themselves. Temporary by design.
Platform teams provide internal services that stream-aligned teams consume as self-service. CI/CD, deployment, shared infrastructure. If teams need to file a ticket and wait, you've built a bottleneck, not a platform.
Complicated-subsystem teams own components requiring deep specialist knowledge — ML models, real-time data pipelines, complex financial engines. Created when the cognitive load is too high for a stream-aligned team to carry.
When to Create Each Team Type
The most common mistake is creating all four types at once because the book describes four types. In practice, you introduce them as the need arises.
Stream-Aligned: Start Here, Always
Every engineering org starts with stream-aligned teams, whether they call them that or not. If you have one team building one product, that's a stream-aligned team.
As you grow, the question becomes: how do you split? The answer should follow your domain boundaries, not your technical layers. Split by user journey, business domain, or product area — not by frontend/backend/infrastructure.
When to create a new stream-aligned team: When the cognitive load on an existing team is too high — they own too many domains, context-switching is constant, and the team is busy all the time but shipping slowly.
Platform: Not Until You Have Real Demand
This is where I see the most mistakes. The conversation goes: "We should have a platform team." "What would they build?" "You know... the platform."
A platform team makes sense when:
- Multiple stream-aligned teams are building the same thing independently. Three teams all building their own deployment pipeline or logging setup signals a shared platform capability would save time.
- Stream-aligned teams are spending significant time on undifferentiated work. If product teams spend 30% of their time on infrastructure or CI/CD maintenance, a platform team can absorb that burden.
- The self-service model is viable. If the "platform" requires custom work for every consumer, you have a shared services queue, not a platform.
Don't create a platform team when: You have fewer than 4-5 stream-aligned teams, or when the "platform" is really just one team's infrastructure needs dressed up as a shared initiative. Start with documentation and shared libraries. If the demand for a real platform grows, you'll know.
Enabling: The Most Underused Type
Most organizations don't have enabling teams, and they should. The enabling team is the answer to a question I hear constantly: "How do we get all our teams to adopt X?"
X might be:
- Observability (logs, metrics, traces)
- A new testing framework
- Security best practices
- A migration from one database to another
- API design standards
Without an enabling team, adoption either gets mandated top-down (creating resentment) or doesn't happen at all. An enabling team works alongside stream-aligned teams as coaches — pair-programming, running workshops, building tooling that makes adoption easier.
Key principle: Enabling teams should be time-boxed. They exist to transfer a capability, not to own it permanently. If yours has been "helping teams adopt observability" for 18 months, something is wrong.
Complicated-Subsystem: The Rarest Type
You need a complicated-subsystem team when the specialist knowledge required for a component is so deep that embedding it in a stream-aligned team would overwhelm that team's cognitive load.
Examples:
- A real-time recommendation engine that requires ML expertise
- A payments processing module with complex regulatory requirements
- A video transcoding pipeline that requires deep media engineering knowledge
- A compiler or language runtime
The test is simple: Could a strong generalist engineer on a stream-aligned team maintain this component? If yes, you don't need a dedicated team. If the answer is "only if they spend 80% of their time on it," that's your signal.
Most startups and mid-scale engineering orgs have zero or one complicated-subsystem team. If you have more than two, question whether you're over-specializing.
The Three Interaction Modes
The interaction modes are the part of Team Topologies that people skip, and they shouldn't. How teams interact matters as much as how they're structured.
Collaboration mode. Two teams work closely together for a defined period. High-bandwidth, high-cost. Use for discovery and early-stage work, not as a permanent state. If two teams are permanently collaborating, they should merge.
X-as-a-Service mode. One team provides a capability through a well-defined interface. The primary mode between platform and stream-aligned teams. Only works if genuinely self-serve.
Facilitating mode. One team helps another learn or adopt a capability. How enabling teams interact with stream-aligned teams. The goal is self-sufficiency.
When to Restructure (and When Not To)
Reorganizations are expensive. Every reorg disrupts relationships and costs weeks of productivity.
Restructure when: Teams can't deliver end-to-end without blocking on others. A team's scope is so large they're permanently context-switching. Two teams are in permanent collaboration mode (merge them). You have clear platform demand but no platform team.
Don't restructure when: You just want to "try Team Topologies." The problem is people, not structure. The team works well but doesn't fit the taxonomy. You reorganized less than 6 months ago.
Common Mistakes
Creating a platform team too early. Building tools nobody uses while stream-aligned teams solve their own needs.
Not having enabling teams at all. Every adoption initiative becomes a top-down mandate or a grassroots effort that fizzles.
Labeling teams without changing how they work. Renaming "Backend Team" to "Platform Team" doesn't make it one.
Ignoring cognitive load. The entire framework is built on it. If you're not assessing whether teams are overloaded, you're missing the point.
At Conectia, when we embed senior LATAM engineers into growing engineering organizations, we pay close attention to team structure. The right engineer on the wrong team delivers less value than a good engineer on a well-structured team. Our engineers are experienced with distributed, multi-team setups and understand how stream-aligned, platform, and enabling team dynamics work in practice — not just in theory.
Structuring your engineering teams for growth? Talk to a CTO — we place senior engineers who understand team dynamics and integrate cleanly into your squad structure from week one.
