Card

Team Topologies

Team Topologies is a set of principles and patterns, introduced by Manuel Pais and Matthew Skelton, for organizing product, design and engineering roles into fast & effective teams.

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.

What challenges does this help with?

I'd put Team Topologies on your radar and read on, if you're facing these challenges:

  •

    Too many team dependencies can slow progress, as teams must wait for each other to complete tasks before moving forward. Learn more

  • Your teams have no decisions about what they’re building or even how they’re building. They seek approval for most things. Learn more

  • The most common issues within the organization. You probably won’t be able to get rid of this, once you have a scale, but you can (and should) try to fight it as hard as possible. Learn more

  • High cognitive load means that the team has too many things on their shoulders, making them slower to move or to think. Learn more

  • Failed transformations occur when attempts to adapt or improve a product or process result in setbacks or do not achieve the desired outcomes. Learn more

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.

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:

Four team types

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

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:

The Nine Principles inform Team Topologies by establishing fundamental organization design values around flow, trust, stability, and complexity management.

1 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.

2 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.

3 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.

4 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.

5 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.

6 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.

7 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.

8 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.

9 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:

The Six Patterns provide concrete implementation structures that organizations can apply to optimize team interactions and value delivery.

1 Four Team Types

Don't overthink this. Every team in your organization fits into one of these four types.

  • deliver direct value to customers along a value stream. They own the outcomes.
  • create services that accelerate stream-aligned teams, removing complexity.
  • temporarily boost skills in other teams, then move on.
  • 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.

2 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.

You can read more on them here: .

3 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.

4 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.

5 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.

6 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.

How to implement it step-by-step

  1. Add Team Topologies to your deck / :
    (unavailable until launch)
  2. Communicate the start of work on the practice to the team.
  3. Assemble strike team to work on the practice.
  4. Identify the stable business your technology teams should be working on.
  5. Map your current teams to . Provide them with a containing their mission, the problem they're trying to solve, metrics they need to work on, and the systems they own.
  6. Map the rest of your teams to the other three team types ( , , ) and provide them with their team charters.
  7. Keep those teams .
  8. Identify as-is and to-be (Collaboration, X-as-a-Service, and Facilitating).
  9. Revisit this map every six to twelve months.

PS: If you need help with implementing the Team Topologies, contact me. I have 20+ years of commercial experience working with bigger and smaller companies, upgrading product, design, and engineering teams to the next level. I can also connect you with experts on this subject.

Evolving Topologies Board Template

Evolving Topologies Board Template

This Miro board will help you identify current topologies, mark hotspots, and create a map of evolving topologies using Team Topologies.

Download links:

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. If you need help, find me.
  • 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."

Linked cards

Here are other practices related to Team Topologies:

  •

    Stream-aligned are responsible for delivering direct product value to users and customers by working on certain value stream. Learn more

  • Platform teams serve stream-aligned teams. They offer essential services, tools, and infrastructure for other teams to deliver work with high autonomy. Learn more

  • Enabling teams help other teams (typically stream-aligned teams) with some expertise, for example adopting new technology. Learn more

  • Product Trio is a product team leadership group consisting of three critical roles to deliver high-quality products: a product manager, a designer, and a tech lead. Learn more

  • Team interaction modes (as defined in Team Topologies) define three ways teams can interact with each other – collaboration, X-as-a-Service, facilitating. Learn more

  • Cross-functional teams are teams permanently containing all roles necessary to deliver product work without relying on different teams. Typically that’s PM, Designer, Tech Lead and engineers. Learn more

  • Value stream is a mid-to-long-lived area of work that company find valueable. It could be a problem, it could be persona, it could be market segment. Learn more

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 an approach 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?

Learn more

Here are some useful links if you want to learn more:

Hope that's useful!

Piotr Kacała