Hey!
If you’re wondering — I’ve renamed Product Blocks to Ship It and updated the brand colors to be consistent. :)
And without further ado, here’s my guide on structuring your teams using Team Topologies.
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
Too many team dependencies can slow progress, as teams must wait for each other to complete tasks before moving forward.
Limited team autonomy
Your teams have no decisions about what they’re building or even how they’re building. They seek approval for most things.
Communication issues
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.
High cognitive load
High cognitive load means that the team has too many things on their shoulders, making them slower to move or to think.
Failed transformations
Failed transformations occur when attempts to adapt or improve a product or process result in setbacks or do not achieve the desired outcomes.
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 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 idly.
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:
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.
Click here to see a full example of team types in one Netflix-like company
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.
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.
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.
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.
Thanks for reading so far! You’ll find the full version of this article on ShipIt.cards:
What You'll Find in the Full Article:
I've shared the basics of Team Topologies' four team types and three interaction modes, along with the nine principles that underpin effective organizational design. But this preview is just the beginning.
When you continue reading the full article, you'll discover:
Detailed explanations of all nine principles with real-world examples
Practical implementation strategies for each of the six core patterns
Common obstacles organizations face and exactly how to overcome them
Key success factors that separate organizations that succeed with Team Topologies from those that fail
Convincing frameworks to help you gain buy-in from skeptical stakeholders
Don't settle for accidental organizational design. Learn how intentional team structuring can transform your delivery capabilities, reduce dependencies, and create an environment where your best people thrive instead of burning out.
Explore More in the Ship It Catalog:
Beyond this Team Topologies article, the Ship It catalog offers additional methodologies and frameworks for building better products, including:
Stream-aligned Teams and Platform Teams implementation guides
Product Trio collaboration models
Value Stream Mapping techniques for identifying bottlenecks
Cross-functional team structures that accelerate delivery
SPACE framework for measuring engineering productivity
See you soon!
—
Piotr
Share this post