David Pereira Product Leader with 15+ years of experience. Partner at Value Rebels and interim CPO at omoqo. Almost every product team is trapped somehow; untrapping them is what drives me.

The importance of team topology

4 min read 1192 102

The Importance Of Team Topology

Some teams are set up to thrive and others are bound to fail. To thrive, teams need to be intentional and well thought out. Many teams fail because they lack a quality topology.

However, a topology can only be as effective as its organization. Teams that organize around areas of expertise prevent opportunities for cross-functionality. As a PM, this is important to consider because of the need for reducing dependencies.

In this article, you will learn what team topology is, the common topologies for product teams, and the challenges that accompany its implementation.

Table of contents

What is team topology?

Team topology is the way of organizing teams, responsibilities, flows, and communication by defining who’s a part of each team and which accountabilities the team has. A team topology also establishes guidelines for how each team collaborates.

When the topology is well-defined, teams benefit from a fluid working method that accelerates value creation. When the topology complicates collaboration, teams get distracted and have to prioritize dependencies over value creation.

Common topologies for product teams

When it comes to product teams, there are multiple different topologies to consider. Two aspects are crucial to defining the topology: skillset and responsibility.

The skillset can be defined as follows:

  • Expertise — Teams are structured according to their area of expertise. This way, each team focuses on its particular skill set and must collaborate with many teams to create value
  • Cross-functional — Teams are defined to deliver on their responsibilities. The objective is to reduce dependencies as much as possible

The responsibilities are represented by:

  • Components — Teams are responsible for application components. They care for specific application parts, but don’t own any end-to-end experience
  • Features — Teams are responsible for the whole feature experience. They may touch multiple components to complete their job
  • Domains — One of the most common formats is responsibilities on a specific product domain. This has a balance between component and end-to-end experience

The best topologies I’ve seen focus on reducing dependencies. Teams have all the skills necessary and focus on a domain.

Now, let’s look at the two most common forms:

Expert teams

When teams depend on other teams to transform ideas into meaningful results, they become dependent teams. The more dependent teams are, the slower they become and the more problems they will face.

To demonstrate the disadvantages of dependent teams, let’s consider e-commerce with six teams, four focused on specific domains of the product and two focused on disciplines: UX and QA. Each team has a clear domain accountability and set of skills. The following image represents how teams are structured:

Expert Teams

As you can see, all product teams depend on UX and QA teams. This situation creates the following problems:

  • Miscommunication — Dependencies require constant handovers, and that leads to eventual miscommunications
  • Lack of responsibility — Within dependencies on UX and QA, no team feels accountable from end-to-end
  • Decisions based on limitations — Each team decides what to work on based on what their skills allow them to do instead of thinking about meaningful problems together
  • Superficial domain knowledge — Each team focuses exclusively on their responsibilities, and the dev team implements what’s defined by UX and QA tests

The more dependent teams are, the slower the business can grow.

Cross-functional teams

When teams can create value independently, the results are often remarkable. Yet, it’s hard to remove all dependencies and transform teams into cross-functional ones.

Adapting the previous example to cross-functional teams, we have four teams without dependencies:

Cross-Functional Teams

A cross-functional team has all the required skills to transform ideas into results. They’re independent and don’t need to sync with other teams or hand over tasks to others to complete.

Cross-functional teams can create value at a steady pace when they are empowered to solve meaningful problems.

The core advantages are:

  • Accountability — There’s no room for blame because the team has all the required skills to get things done and they’re accountable for end-to-end results
  • Speed — Communication becomes straightforward and there’s no need for handover or bureaucracy
  • Domain knowledge — As every team member works towards the same goal, they continuously enrich their domain knowledge. The longer they work together, the faster they can discover valuable insights
  • Focus on what matters — Teams don’t waste their energy handling dependencies and beg other teams to prioritize their requests. They focus on creating value

Cross-functional teams help businesses succeed.

Challenges to implementing cross-functional teams

Cross-functional teams seem obvious, but many companies still have dependent teams. Why does that happen?

One of the biggest obstacles is becoming a self-managing team. Most dependent teams receive requests to fulfill, while cross-functional teams receive goals to pursue. The difference between the two scenarios is gigantic.

Requests mainly require execution, while goals require a different strategy for the team to discover what works and what doesn’t.

Another problem teams discover on their journey to becoming cross-functional is how to handle different activities at the same time. For example, a UX designer might look at something far from what the team is implementing.

How can that be combined with the other activities? When UX designers define everything alone, software engineers create resistance because they feel ignored and execute tasks instead of creating solutions.

More great articles from LogRocket:

Influencing the topology

As a PM, you might find yourself in a situation where the topology doesn’t contribute to creating value faster. Most of the time, that’s unintentional, but it remains unchangeable.

When product managers perceive the current topology as unchangeable, complaints will take over. However, when you help leaders see the advantages and disadvantages of the current situation, then leaders can consider changing it.

Once, I landed in a company where teams were responsible for components and divided per expertise. As I explored before, the situation caused more friction than necessary. I shared what happened with the leaders and made it clear that I spent most of my time dealing with dependencies, and opportunities for creating value slipped away.

Then, I asked, “Is this how you want me to continue working?” The leader got curious and decided to listen to me.

I shared a different way of working and presented a cross-functional team. That was enough to convince my manager to give it a try. We then set up a small cross-functional team.

After two months, it was clear that was a better way of working and all the other teams were restructured.

It takes courage to challenge the status quo, but that’s the difference between good and great product managers.

Key takeaways

Team topology plays a significant role in determining the results that a team can create. The more dependent a team is, the slower they can create value. Because of this, encourage your product leadership to implement cross-functional teams that focus on value creation.

As a PM, you need to help senior leadership understand why a change in topology might be beneficial for your product. Help to foster change that pushes you towards your desired outcomes.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try LogRocket today.

David Pereira Product Leader with 15+ years of experience. Partner at Value Rebels and interim CPO at omoqo. Almost every product team is trapped somehow; untrapping them is what drives me.

Leave a Reply