Team Topologies: How to structure your teams using nine principles and six core patterns for better value

Blog

6 Mar

Designing organizations is hard. I started my career as an engineer and quickly found myself designing organizations. I've made my share of mistakes. When you're knee-deep in the turbulence of scaling a company, no manual tells you exactly how to repeat the success of what worked for one team in order to structure other teams for maximum effectiveness.

Everyone is mindlessly copying the Spotify model, SAFe, Scrum—you name it. All without understanding why they're doing it or what problem they're trying to solve. It's cargo cult thinking at its worst. I've seen executives lose millions implementing frameworks that worked for other companies without considering their unique context. They grab playbooks from successful companies without grasping the principles behind them, then wonder why they don't get the same results. Go figure.

The hard truth is that most team structures evolve accidentally rather than intentionally. They're shaped by historical accidents, personalities, politics and temporary crises that somehow became permanent fixtures. But you do have control over how these structures evolve, and shaping them is an art. I'll take an intentionally designed organization over an accidental one any day, even if the design isn't perfect.

Team Topologies addresses just that. While everyone else was frantically reorganizing their org charts every six months, Team Topologies offered something different: a coherent system for thinking about how teams should work together. I've since used it to turn around multiple failing delivery organizations. The brilliance isn't in complex frameworks but in its laser focus on reducing dependencies and respecting cognitive limits.

Not Properly Designing Organizations Costs You Money and Happiness

Most leaders drastically underestimate the cost of poor organizational design. Let's assume you're waiting on the right things. Think about the last time you waited for someone in order to proceed with work. Now multiply it by the number of days and number of people. You're burning millions (often billions) of dollars due to people sitting idle.

But it's not just about money. I've watched talented engineers become cynical and burned out after years of fighting bureaucratic structures designed by people who have never shipped anything meaningful. They join companies to build things, not to attend coordination meetings and file tickets requesting permission to make changes.

Your best people will leave if they spend more time navigating organizational complexity than solving customer problems—the ones who stay become increasingly disengaged. I've seen entire engineering departments fall to mediocrity because the organizational structure made excellence impossible.

I've seen what happens to high performers in poorly designed organizations, and the pattern is clear: they either leave or become mediocre. Your 10x engineers become 0.5x engineers when they spend most of their day navigating absurd approval processes and explaining the same thing to several different stakeholders. The real tragedy isn't just losing your best people—it's that they tell everyone they know not to work for you. Your organizational dysfunction becomes your employment brand.

Team Topologies offers a way out of this mess. It provides practical patterns for reducing dependencies, clarifying responsibilities, and letting teams deliver value without drowning in organizational overhead.

Problems Team Topologies Solves

Team Topologies transforms organizations suffering from these common dysfunctions:

Too many dependencies between teams. I've seen organizations where making a single change requires coordinating across eight different teams. They spend more time in synchronization meetings than doing actual work. The result is glacial delivery and frustrated teams who can't deliver without begging for help.
Zero meaningful autonomy. Teams need permission for fundamental decisions. I'll take a mediocre team with autonomy over a brilliant team that needs five approvals for every move. Autonomy enables speed, and speed beats perfection in today's market.
Communication hellscapes. Everyone complains about communication issues, but few people fix them. The solution isn't more meetings or Slack channels—it's intentional team design. You can't communicate your way out of a structural problem.
Overloaded teams. Most teams are juggling too many responsibilities and cognitive loads. An overloaded team moves like molasses and makes terrible decisions, no matter how talented they are. No amount of "prioritization" fixes a fundamentally overloaded team.
Failed transformation attempts. I've watched countless organizations try to "transform" themselves by reorganizing. They change the organizational chart but not how people truly work, and then they wonder why nothing has improved. Real transformation changes how work flows, not just who reports to whom.

Team Topologies That Most Know (But Implement Poorly)

Most people who have heard of Team Topologies fixate on the four team types and three interaction modes. They are important, but implementing them without understanding the underlying principles is like flying an airplane after you played a few hours on Microsoft Flight Simulator.

For the people who have not heard of them, let's get these basics first:

Four Team Types:

Team types are the basic categorization for every team you'll find in a tech organization—no more, no less:

Stream-aligned teams deliver direct value to customers along a value stream. They own the outcomes.
Platform teams create services that accelerate stream-aligned teams, removing complexity.
Enabling teams enable some capabilities in other teams, then move on.
Complicated subsystem teams handle complex components requiring specialist knowledge.

Three Interaction Modes:

These define how your teams should work together:

Collaboration: Working closely together (high bandwidth, high cost)
X-as-a-Service: Consuming or providing with minimal interaction (low cost, clear boundaries)
Facilitating: Helping remove obstacles (temporary and focused)

Applied thoughtfully, these team types and interaction modes can transform your organization. Unfortunately, most places I've consulted treat them as a simple categorization exercise—"You're a platform team now, you're stream-aligned"—without addressing the fundamental patterns of work. When leaders check the "Team Topologies implemented" box without doing the hard work, they make real change even harder. It's organizational theater at its worst.

Beyond What Most Know: The Nine Principles and Six Patterns

Don't be fooled by the pretty diagrams of team types—that's just the surface. The real power of Team Topologies lies in the foundational principles that determine whether value flows or stagnates in your organization:

The Nine Principles:

Focus on Flow, Not Structure: Flow is how quickly work moves from idea to customer value without getting stuck in organizational bottlenecks. Structure only matters if it helps ideas become reality faster. I've seen perfectly designed org charts produce nothing but meetings and documentation. Elegant structures mean nothing if the value moves slowly to your customers.
High Trust Is Non-Negotiable: Trust shouldn't just be a corporate buzzword—it's the foundation that everything else relies on in great organizations. Low trust means trouble. Low trust environments build excessive documentation and wasteful, defensive processes that slow everyone down. I've watched organizations waste millions on process frameworks built around lack of trust in their people.
Keep Teams Together: I'll take a team that's worked together for years over a newly assembled group of rock stars any day of the week. Stable teams develop shared context and communication patterns that dramatically accelerate delivery. The hidden cost of constantly reshuffling teams is astronomical, yet most organizations do it without a second thought.
Respect Cognitive Limits: Teams can only handle so much complexity before breaking down. Each new tool, responsibility or domain your team is given taxes their mental bandwidth. Competent teams become ineffective when leaders keep adding to their plate without taking anything away.
Make Changes Small and Safe: Teams that can ship small improvements daily will always beat teams making big, risky releases quarterly. This applies to both product changes and team adjustments. The goal is to deliver value continuously in small, safe increments rather than betting everything on massive rollouts that might fail spectacularly.
Connect Teams Directly to Customers: Many teams never talk to the people using their products—they receive directives filtered through three layers of management. This game of telephone distorts customer needs and slows everything down. Teams with direct customer contact make better decisions faster because they understand the real problems. This connects back to trust—you must trust your teams to interpret customer needs correctly, rather than micromanage every interaction.
Embrace Complexity, Don't Fight It: Modern software systems are too complex for perfect prediction and planning. Organizations waste enormous energy fighting this reality instead of designing for adaptability. I've watched countless projects fail because they assumed they could plan everything ahead. Like Mike Tyson once said, everybody has a plan until they get punched in the face.
Foster Continuous Discovery: Great ideas don't come from fancy offsites or executive brainstorms. They come from teams that have time to experiment and try new things. Sorry, not sorry. When you crush teams with endless backlogs, they stop innovating and mindlessly crunch tasks for you. I've seen teams deliver twice the value when given just one day a week to explore new approaches. This isn't optional work—it's where your next breakthrough will come from.
Eliminate Team Dependencies: Nothing kills productivity faster than one team waiting on another team. Most companies obsess over making individual teams more efficient while ignoring the massive delays that happen between teams. I've watched organizations hire more people and ship less because their teams were still waiting for each other. Fix the handoffs, not just the teams.

The Six Patterns:

Four Team Types
Don't overthink this. Every team in your organization fits into one of these four types.
Stream-aligned teams deliver direct value to customers along a value stream. They own the outcomes.
Platform teams create services that accelerate stream-aligned teams, removing complexity.
Enabling teams temporarily boost skills in other teams, then move on.
Complicated subsystem teams handle complex components requiring specialist knowledge.
Adding more types or creating hybrids just confuses everyone. I've seen companies try to create "hybrid platform-stream teams" and other nonsense that always ends in disaster. Stick to these four—they cover everything you need.
Three Interaction Modes
Most team dependencies are messy because nobody defines how teams should work together. These three modes solve that by making it crystal clear when teams should collaborate closely, provide services to each other or offer temporary assistance.
Collaboration: Working closely together (high bandwidth, high cost)
X-as-a-Service: Consuming or providing with minimal interaction (low cost, clear boundaries)
Facilitating: Helping remove obstacles (temporary and focused)
No more ambiguous "we need to coordinate better" mandates that solve nothing.
Managing Team Cognitive Load
Just as overloaded CPUs slow down computers, overloaded teams make poor decisions and move slowly. Actively monitoring and reducing unnecessary complexity is key to maintaining team effectiveness. I've seen leadership pile responsibilities onto teams until they break, then blame the team for "underperforming" when the real problem was cognitive overload.
Thinnest Viable Platform (TVP)
Most internal platforms become bloated monstrosities that slow teams down rather than accelerate progress. The TVP approach creates platforms that provide just enough capability without unnecessary complexity. A good platform should make stream-aligned teams move faster, not generate more dependencies to manage.
Flexible Team Boundaries
Team boundaries shouldn't be fixed permanently; they must adapt as products and technologies evolve. Organizations that allow teams to adjust their responsibilities based on local knowledge avoid painful reorganizations. The best companies enable teams to negotiate boundary changes directly rather than wait for top-down directives.
Continuous Adaptation
Organizational design is never "done"—it must evolve as business needs, technologies and people change. Building feedback loops that identify when adjustments are needed helps prevent organizational debt from accumulating. Small, frequent adjustments are far less disruptive than massive reorganizations forced by accumulated problems.

Key Success Factors

Let me tell you what separates organizations that succeed with Team Topologies from those that fail miserably:

Long-Term Commitment: This isn't a 90-day transformation. If you want quick fixes, hire another consulting firm to sell empty promises and return here for "I told you so." Team Topologies take months to show initial results and years to implement fully. I've watched impatient executives abandon it after one quarter and return to their dysfunctional ways. Don't be that executive.
Many Small Changes: Forget the big bang reorganization. It fails every time. The organizations that win make dozens of small, sometimes uncoordinated changes that add up to significant improvement. I've seen teams deliver breakthrough results through fifty minor tweaks rather than one major restructuring.
Technical Foundations: Your organizational design can't outrun your technical debt. Without good engineering practices—automated testing, continuous integration, fast feedback loops—your teams will still move painfully slow, regardless of structure. Fix your technical foundation first or simultaneously, not after.
Stable Team Ownership: Teams must own their products for the long haul. Constantly shuffling who owns what destroys knowledge and accountability.
Knowledge Sharing: Information has to flow across team boundaries, or you're just creating new silos. I've seen teams unknowingly solve the same problem three different ways because they had no idea that other teams had already figured it out. Build practices to share knowledge.
Psychological Safety: Teams won't take risks or suggest improvements if they're afraid of being punished. Leadership needs to visibly reward honesty and experimentation, even when it fails. The best indicator of Team Topologies' success is how teams respond when things go wrong. I messed up many teams as an executive, and I am not afraid to admit it.

Common Obstacles and How to Overcome Them

Implementing Team Topologies isn't all sunshine and rainbows. Here are the roadblocks I've encountered and how to get past them:

Resistance to Change: People cling to familiar patterns, even dysfunctional ones. I've watched engineers fight to maintain team structures that made them miserable, simply because change feels threatening. The key is to start small, show concrete benefits quickly, and involve resistant people in the design process rather than imposing change on them.
Middle Management Fear: Team Topologies threatens middle managers who derive power from controlling information flow between teams. They'll fight it tooth and nail, usually with reasonable-sounding objections about ‘coordination needs’ and ‘oversight requirements.’ Combat this by redefining middle management roles toward enablement rather than control, and showing how Team Topologies makes their lives easier, not redundant.
The Temptation to Customize: Everyone thinks their organization is unique and needs a custom framework. I've seen leaders say, "We like Team Topologies, but we're going to create our own hybrid with six team types and five interaction modes." Resist this urge. The four team types and three interaction modes emerged from extensive research and practice. Customize after you've mastered the basics, not before.
Treating Principles as Optional: Some organizations cherry-pick the parts of Team Topologies they like and discard the parts that challenge their current power structures. They'll implement team types without changing interaction patterns, for example. The framework works as a system, not a buffet. Adopt the principles first, then implement the mechanisms.
Missing the Continuous Adaptation Part: Team Topologies isn't something you implement once, and check off your list. I've seen organizations make initial changes, declare victory, and stop evolving. Build feedback mechanisms to evaluate and adjust your organization constantly. The best structures today won't be the best structures tomorrow.
Measuring the Wrong Things: Traditional metrics often punish the behaviors Team Topologies encourages. I've seen teams marked for "low productivity" when they were actually reducing dependencies that would accelerate everyone. Develop new metrics around flow, lead time and team cognitive load, instead of individual productivity or resource utilization. See my article on SPACE.

How to Convince People to Adopt Team Topologies

Getting buy-in is half the battle. Here's how I've successfully advocated for Team Topologies:

Start with Pain Points, Not the Framework: Nobody cares about Team Topologies; they care about their problems. I never open with, "Let me tell you about this great framework." Instead, I ask about delivery delays, team frustrations and coordination overheads. Then, I explain how Team Topologies addresses those specific issues.
Speak the Language of Different Stakeholders: Engineers care about autonomy and focus. Managers care about predictability and visibility. Executives care about time to market and competitive advantage. Tailor your pitch to show how Team Topologies delivers what each stakeholder values most.
Run a Small, High-Visibility Pilot: Pick a critical but contained area with obvious dependencies and problems. Apply Team Topologies principles rigorously and measure the before-and-after impact. Nothing convinces skeptics like seeing results in their organization.
Bring in External Validation: Most organizations overvalue external opinions. Share case studies, books and articles about Team Topologies' successes. Better yet, connect stakeholders with peers at other companies successfully implementing it. An hour with someone who's been through the journey is worth days of internal advocacy.
Focus on Business Outcomes, Not Process Purity: Executives don't care about team interaction modes; they care about delivering faster and beating competitors. I always frame Team Topologies as a means to business ends, not an end in itself. Show how it connects to strategic goals like faster innovation, higher quality or improved customer satisfaction.
Be Patient and Persistent: Organizational change takes time and repeated exposure. I've never seen Team Topologies adopted after a single presentation. Keep bringing it up in the context of recurring problems: "Remember that deployment delay last week? That's exactly the kind of dependency that Team Topologies would have prevented."

Conclusion

The organizations I've seen succeed with Team Topologies share one trait: they commit to the journey and don't expect overnight transformation. They start small, show results and gradually expand.

Team Topologies isn't a silver bullet. It's a framework for thinking clearly about how work flows through your organization. Applied with intelligence and patience, it's the most effective approach for building organizations that deliver consistently without burning out.

Most organizations will continue plugging along with broken structures, wondering why they can't keep up with more nimble competitors. The smart ones will recognize that how they organize their teams is as important as which technology they use or what products they build.

Which one will you be?

The content was originally published here.

Subscribe to the Team Topologies newsletter

About the author