In today's rapidly evolving digital landscape, organizations must constantly adapt to keep up with the increasing speed of product development, customer expectations, and technological advancements. Factors such as shorter time-to-market, the pressure to innovate quickly, and the growing complexity of cross-functional teams make it essential to optimize team structures. Team Topologies, a book by Matthew Skelton and Manuel Pais, offers a framework that helps organizations design and manage their teams to achieve these goals. However, the concept of team topologies can be interpreted in various ways, depending on one's perspective and experience.

In this blog post, we bring you two distinct takes on team topologies from two seasoned product coaches. We believe that by sharing our contrasting viewpoints, we can provide a richer, more nuanced understanding of how to effectively implement team topologies in your organization. Whether you're a product manager, an engineering lead, or part of the leadership team, our combined insights will offer practical advice and thought-provoking ideas to help you optimize your team structures.

Team topology is about more than just organizing teams—it's about creating a system where teams can thrive, minimizing bottlenecks and maximizing productivity. Imagine crafting an ecosystem where teams are clearly defined, not just by what they do, but by how they interact, share knowledge, and drive value.

Team topology focuses on structuring your teams for optimal flow and minimal friction. It’s about creating purposeful teams with distinct roles and clear communication pathways, ensuring that each team is self-sufficient yet well-connected to the bigger picture. This isn’t about drawing lines on an org chart; it’s about setting up teams in a way that naturally drives collaboration and efficiency.

Done right, team topology allows teams to focus on solving problems rather than navigating bureaucracy, leading to faster delivery of higher-quality products. By defining the right boundaries and responsibilities, you reduce dependencies and enhance clarity. This means your teams can move quickly, adapt to changes, and stay aligned with the company’s strategic goals. The ultimate goal is to foster an environment where teams are empowered to deliver their best work without getting bogged down.

If it ain’t broken…making changes to how the teams work together is costly, so think twice. I would really only touch on this topic if you are sure the current way is not working. Here are a few signs you might need to reconsider your setup:

Teams with a good topology deliver 10x value, no matter the reporting lines. I have been on these teams a few times, and the difference is literally an order of magnitude. A clear indication of teams like that is that you have fantastic alignment across functions and low churn (especially amongst engineering). Teams like that are happy to work on their problem for years and are continuously getting better at it.

Let's take the example of building a team topology for a booking engine for an airline, travel agency, or fashion store like Zalando or Zappos. As the product leadership team, you might wonder: How to organize the teams? Maybe by product line, e.g. the “Pants team” or maybe by business goals, e.g. “Retention team”? Or something else entirely? 

There is no paint by numbers approach, but here’s a step by step guide to think about trade-offs:

The context for team topology: Before you start dividing people up into teams, take a step back and look at the whole product within its context. A visual aid will drastically change your ability to get the topology, here is a simplified example from a real-world use-case:

Here’s a possible setup that carves out clear lines of responsibilities and clearly defines scope:

A case can be made for different topologies, of course, it is always about the trade-off. We can say, let’s have a by product group,  e.g. “Team pants, Team shirts etc.”, because that’s closer to the user's need, right? You might cringe here, yet we actually see this a lot in the wild. Teams would need to work on all components and will fight to squeeze their thing into the UI for instance. Another common concept is by business goal (e.g. “Team for retention”, "Team for conversion”), the same applies here, that team is not actually given a tangible problem they can solve, because their solution will essentially be all over the system. 

What we truly want is for each team will have a very clear and complete agenda in terms of the value they add, with well-defined touchpoints with other teams. These teams are empowered, yet need a strong leadership team to help them connect the dots.

Key takeaways

As the product grows, teams will get more and more specialized and it will be harder to orchestrate high performance across the board. If you’re the VP, CPO, or CEO of a large company, setting topologies for hundreds of people, we are talking about a different challenge altogether.

In many of my coaching sessions with product leadership teams, we often touch on the topic of team topologies. This often comes up when there's friction between teams—either they're too small, too large, or just not optimally structured. This friction can lead to inefficiencies and misalignment. Therefore, understanding and applying the principles of team topologies is crucial for any organization aiming to streamline its product development process.

One common scenario involves organizations wanting to split large teams into smaller ones to improve focus and efficiency. However, this practical necessity brings up important questions: How do you split teams without causing misalignment? How do you ensure that they remain focused on shared goals without stepping on each other's toes? These are critical considerations when thinking about team structures.

Matthew Skelton and Manuel Pais, in their book Team Topologies: Organizing Business and Technology Teams for Fast Flow, outline several team types that can help organizations achieve better flow and alignment:

These team types help align organizational structure with business goals, ensuring seamless value delivery. However, while I admire both Matthew and Manuel, and enjoy their podcast, their concept of team topologies never fully resonated with me. Perhaps this is because I approach the topic more from a product management perspective rather than an engineering one. 

Another expert in this field (and a friend of mine) is Susanne Kaiser, who approaches team topologies through the lens of domain-driven design and Wardley mapping, focusing on optimizing flow in the engineering world. Her approach adds valuable insights, particularly for teams aiming to balance technical flow with user value. Learning about her work has given me new perspectives on structuring teams for both efficiency and product success. If you’re looking to dive deeper into these concepts, I highly recommend checking out her work!

Here are some general rules that guide my approach:

Pro tip on team naming: Naming teams based on the value they create for users is far more effective than using random names like those of Greek goddesses. Descriptive names help maintain focus on the team's purpose and goals.

When it comes to structuring teams within a product organization, consider these dimensions to ensure alignment and efficiency:

A job board example of how you can split teams by the dimensions I suggest. 

While structuring teams, it's equally important to recognize and avoid common anti-patterns that can hinder productivity and alignment:

For a deeper dive into Team Topologies and practical examples, check out these resources:

As we've explored, team topologies are not a one-size-fits-all solution. The way you structure your teams should reflect your unique business context, goals, and challenges. From our two perspectives, you've seen how different approaches can address common issues like misalignment, inefficiencies, and dependencies.

We hope our combined insights have given you a comprehensive understanding of team topologies and how they can be applied to create high-performing, collaborative teams. Remember, the key to successful team topologies lies in continuous evaluation and adaptation. Stay open to experimenting with different structures and be prepared to pivot as your organization evolves.

Thank you for joining us on this exploration of team topologies. We encourage you to share your thoughts and experiences with us—let’s continue the conversation and learn from each other.