Organizing Your Team with Team Topologies - Part 2 - The Six Patterns
If Part 1 showed why modern teams succeed, Part 2 is where it gets real.
This is where founders, CTOs, and engineering leaders usually get stuck. Not in the philosophy, but in the implementation. Most leaders understand the principles of flow, trust, and reducing cognitive load. What they wrestle with is how to turn that into an actual team structure that scales without creating chaos.
When a company grows from 5 to 15 to 50 engineers, the old ways of working crack.
Ownership blurs
Every change requires multiple approvals
Teams spend more time coordinating than shipping.
Team Topologies solves this, but only if you apply its patterns with intention.
The six patterns below are the practical building blocks that translate principles into an operating model. They help you design teams that
Move fast and stay aligned
Communicate clearly without handholding
Maintain flow as complexity increases.
If Part 1 helped you diagnose your team’s challenges, Part 2 will help you fix them.
Let’s get into it.
1. Four Team Types
Don’t overcomplicate this. Every team in your organization should fit cleanly into one of these four types:
1. Stream-Aligned Teams
These teams deliver direct value along a specific customer or business value stream. They own outcomes end-to-end.
2. Platform Teams
They provide internal services that accelerate stream-aligned teams by removing complexity and reducing cognitive load.
3. Enabling Teams
Specialists who temporarily support other teams, help them adopt new practices, and then step away.
4. Complicated-Subsystem Teams
Experts responsible for highly complex parts of the system that require deep, specialized knowledge.
Avoid inventing new categories or hybrid teams. It only creates confusion and unclear expectations. Find the value stream, build a team around it, and give them autonomy backed by trust. If the workload becomes too heavy, create another stream-aligned team. this is a sign of growth, not fragmentation.
As a leader, your responsibility is to nurture teams as they gain independence and to ensure dependencies between them are intentional, limited, and aligned with the three interaction modes discussed next.
2. Three Interaction Modes
Most team dependencies become painful because no one explicitly defines how teams should work together. These three interaction modes bring clarity, predictability, and purpose to cross-team collaboration:
1. Collaboration
High-bandwidth, short-term, and high-cost.
Teams work closely together to solve complex problems or shape new capabilities.
2. X-as-a-Service
Low-cost, low-coordination.
One team provides something stable and well-defined; another team consumes it with minimal interaction.
3. Facilitating
Temporary guidance from an enabling team to help another team remove obstacles, adopt new practices, or build new skills.
Example of How These Modes Play Out:
A frontend stream-aligned team collaborates with a backend stream-aligned team to design and shape a new API.
A physical therapist doing clinical research exposes their work as a service to product teams.
An AI specialist facilitates the adoption of an ML model by pairing temporarily with a delivery team.
When interaction modes are explicit, dependencies stop being bottlenecks and become predictable, intentional parts of value delivery.
3. Managing Team Cognitive Load
Just as an overloaded computer slows down, overloaded teams make poorer decisions, move slowly, and struggle to deliver reliably. Teams need more than time in their schedule, they need mental bandwidth to reason about problems, anticipate consequences, and make sound decisions.
When a team’s domain becomes too large or too interconnected, no one can fully grasp the cascading impact of a change. Complexity becomes unmanageable, fear increases, and flow collapses.
Leaders must actively monitor cognitive load and reduce unnecessary complexity by:
Clarifying ownership
Removing or consolidating tools
Minimizing cross-team dependencies
Splitting oversized domains
Streamlining interfaces and responsibilities
You can always spin up another stream-aligned team to share the load. This isn’t a sign of failure; it’s a clear sign of growth.
Healthy teams operate within a domain they can understand, own, and improve. Managing cognitive load intentionally keeps your teams fast, confident, and effective.
4. Thinnest Viable Platform (TVP)
Platform teams exist to abstract complexity and provide simple, reliable interfaces that make stream-aligned teams faster and more effective. But “platform,” does not always mean infrastructure. Platforms can be anything that removes friction.
In the earlier example, the research data exposed as a service is a platform. So is a deployment pipeline. So is onboarding.
The problem is that most internal platforms become bloated over time, accumulating features, integrations, and constraints that slow teams down. A platform that adds cognitive load is not a platform; it’s a bottleneck.
The Thinnest Viable Platform (TVP) delivers just enough capability to unlock flow, without unnecessary complexity. A good platform should:
Reduce cognitive load
Speed up delivery
Provide clear and stable interfaces
Require minimal coordination
And a platform doesn’t need to be code. A simple onboarding checklist qualifies as a platform if it consistently removes friction.
Whether it’s infrastructure automation, or a printed onboarding guide, the test is simple:
Does this make stream-aligned teams faster?
If not, it’s not a platform — it’s overhead.
5. Flexible Team Boundaries
Team boundaries shouldn’t be fixed permanently. They need to evolve as the product, technology, and team capabilities grow. Organizations that allow teams to adjust their responsibilities based on local knowledge avoid the painful, disruptive reorganizations that plague rigid structures.
Teams that stay together longer perform better. As they gain experience, their boundaries should naturally expand or shift. If a team develops new capabilities, let them own it. Ownership should follow competence and context.
The strongest companies empower teams to negotiate boundary changes directly, not wait for top-down directives. This requires trust. Trust in the team, trust in their judgment, and trust in their ability to manage their domain.
As a leader, your job is to monitor for friction between teams and intervene only when necessary. Keep teams healthy, autonomous, and capable of evolving their boundaries without heavy-handed control.
Flexible boundaries create resilient teams that adapt as the system grows, not teams that wait for permission.
6. Continuous Adaptation
Organizational design is never “done.” It must evolve as the business, technology, and team change.
Regular feedback loops help you spot friction early and prevent organizational debt, described as the silent accumulation of misalignments, bottlenecks, and unclear ownership.
Small, frequent adjustments are far less costly than large, reactive restructures. Evolve continuously, and your organization stays flexible, resilient, and ready for what comes next.
If you’ve recognized gaps in your team structure while reading this, that’s a good sign. It means you’re paying attention to the system, not just the symptoms.
Most organizations don’t fail because of bad code or weak engineers. They fail because the team structure can’t support the work they’re trying to deliver.
Team Topologies gives you a clear, proven way to fix that, but only if you put it into practice.
If you want help assessing your current structure, mapping your value streams, or designing a healthier organization as you scale, I work directly with founders and CTOs to do exactly that.
Reach out if you want an experienced partner to walk with you through this journey, or even a one-time structural checkup.
Your next stage of growth depends on the strength of the teams you build today.
Next I’ll go over how I evaluate teams for high performance.
Attribution
This article draws on concepts from Team Topologies by Matthew Skelton and Manuel Pais.
Original source materials can be found at the official Team Topologies website: https://teamtopologies.com/key-concepts
Team Topologies is a registered trademark of Skelton Thatcher Consulting Ltd. all credit for the original framework belongs to the authors.
