Product leaders’ guide to team topologies

Product leaders have a strong interest in how problems are broken down into team responsibilities, also known as a “team topology.”  As Marty Cagan writes in Product Leadership is Hard, “Coming up with an effective team topology is one of the most difficult but important responsibilities for product leaders, especially at scale.” A good delivery structure is essential both for empowering teams and promoting outcome-oriented execution, which in turn leads to fast flow of value to customers.

When product team boundaries are poorly drawn, though, teams often spend significant time blocked by other teams. If a single piece of work, say a feature, requires coordination from multiple teams, teams often waste precious time waiting on each other, checking status, and context switching. Not only do these pauses delay value going out to customers, they also weaken teams’ feeling of responsibility, as the team only partially contributes to success or failure of the work. These cracks in commitment can run deep, all the way down to uncertainty over purpose. Team handoffs turn out to have a profound effect on teams.

You may be able to detect structural issues directly via low engagement and weak execution. They may also crop up in other ways, like high levels of people moves between teams or repeated attempts to solve the same issues, without success. From the outside, you may also have difficulty understanding who to talk to about a particular customer-relevant topic, being sent from one person to another, often in circles. These signals point to structural problems, and a product leader has a responsibility to notice and take action.

When to revisit team structures

When structure challenges are severe, the need to make changes may be urgent and obvious. Development teams themselves may even suggest collectively revisiting their boundaries – if they do, it’s worth taking that seriously.

More often, problems simmer below the surface, and the timing rarely feels right to address them, especially given mountains of immediate customer work. This is where product leadership has a critical role to play: supporting and making space for structural change that increases the flow and quality of work.

Unfortunately, the overall structure of teams is not something that can be decided in a change initiative working off to the side; the quality of decisions, and later effectiveness of change-management, rely on broad-based participation from the org. This means that it’s important to plan the work in a period of relative calm when both product and development orgs have the space to participate, and to hold that space as an organizational priority.

A natural time in the business cycle to update team structures is in the transition of budgeting or strategy cycles to delivery. In fact, any point where an org needs to scale up or down, or shift how resources are distributed, is a good time to improve effectiveness. While the emotional context is very different between scaling up and scaling down, it is generally obvious to the org why it’s important to address team structural issues at these moments. In the case of scaling up, structural weaknesses will get magnified; they need to be addressed to avoid further increasing complexity of work hand-offs, leading to progressive slowdowns. In the case of scaling down, it’s important to be intentional about stopping work, so teams aren’t put on the burnout track of trying to do the same work with fewer people.

Once you embark on team structure improvements, in true iterative fashion, you should plan for continuing to evolve the structure as new needs are uncovered.

Aligning on a framework and constraints

Like any other change initiative, organizational redesign needs to establish goals, principles and constraints. Some may vary with the particulars of your business, but some principles don’t vary and are common across healthy product organizations.

As discussed above, the most common motivations for organizational redesign are feelings of ineffectiveness that are traceable to weak team boundaries and excessive handoffs. The opposite of this is what the authors of the book Team Topologies call “fast flow.” Design principles to promote fast flow include:

• An overall approach of defining purposeful teams and interrelationships
• Limited team sizes and multi-team groupings
• Minimized cognitive load (the number of different things a team member needs to keep in mind to be effective)
• Minimized handoffs

In the book, the authors give a mature set of concepts and tools for mapping business needs to effective teams. The approach optimizes for sustainable, low-drama delivery of end-user value, which is the aspiration of the vast majority of delivery organizations. Your org may have reasons to optimize, or at least allow for, other goals than fast flow; for example, you may need to keep funding lines separate or have non-negotiable compliance boundaries between teams.

However, it’s important to recognize the tradeoff of these needs against effective delivery; generally it makes sense to organize the largest possible team surface area according fast-flow principles and minimize exceptions.

Team structures should be driven by customer value

A team’s purpose may seem distant from day-to-day work, but a strong purpose will guide decision-making in invisible, healthy ways. As much as a product manager might like to be central to decisions, the key to effective empowerment is supplying enough context that teams can take good decisions independently, with emphasis on both “good” and “independently.”  Product managers cannot be — and should not be — present for every decision a team makes. A clear purpose informs many choices, but especially helps a team figure out what to take on and where to defer to another team.

With a strong purpose, everyone in the org should be able to understand what experiences the team is responsible for and how that ties to customer value. For example, a team’s purpose might be “make checkout frictionless”; this purpose clarifies the specific experience (final stage of purchase) and the obvious business value (accelerated and increased sales). Or take this real-world example from GitLab: their Acquisition Team has a purpose of “improving the trial to paid conversion rate.” Like objectives, not every purpose needs to be understandable to an outsider, but it should be easy to understand within the org, and therefore easy for leaders to navigate the org when needs and questions arise.

It’s also possible to have a strong purpose that supports internal teams. Using Team Topologies language, there are only four fundamental team types: Stream-aligned teams, which serve external customers, and Platform, Enabling, and Complex Subsystem teams that serve internal customers, but still always traceable to a Stream-aligned team.

Apart from being a helpful framing for a team to understand its relationship to other teams, this also forces a breakdown where every team knows:

1. Who gets the immediate benefit of its work
2. How that leads to customer value

In all cases, the teams are expected to employ customer-centric methodologies to understand their users’ needs, solve the right problems, and evaluate outcomes, so product thinking is an essential capability of every team in this structure.

Although Team Topologies emerged from engineering communities, with especially strong roots in DevOps, the approach makes a strong statement that structure should be driven by flow of customer value. This may be a surprise gift from an unexpected direction to product people, but it’s a huge opportunity to bed product principles into the org, using language and techniques that are friendly to people in engineering disciplines.

What does a team topologies refresh look like

In general, org structure work will always be a change initiative that works best with involvement from top to bottom. Especially if the org is currently using a functional team breakdown, moving towards a value-oriented structure is a major change in operating model and will need backing from the highest-level leadership. However, senior leadership is needed mostly to give the space, support, goals, and constraints for the teams themselves to organize along value lines.

A typical pattern for a team topologies transformation is for many people in the org to recognize a need for change, but for senior (C-level) leadership to initiate the actual work. Senior leadership can provide specific goals, decide an overall approach like Team Topologies, set guardrails on the initiative, and establish an internal enabling team for the transition.

An enabling team, while not responsible for deciding structure, is needed because of the sheer amount of work to marshall org-wide perspectives at the right times in the right ways, and help keep progress moving towards goals. Org structure change has the best chance of succeeding if it is conceived as an inclusive process where everyone has the same grounding in team-structure concepts, and everyone has an appropriate way to participate in formulating design principles, value or service maps, new team purposes and boundaries, then the team transitions themselves.

In summary…

The amount of work, especially in an org which may not be used to participatory change, may seem daunting. In particular, you may be wondering why a sharp product leader can’t simply draw a good org chart according to the principles. This is a much riskier approach: not only does that reduce opportunity to hear from people closest to the work, it also makes the transition to new teams much more uncertain. After all, there’s no point in a clear purpose if the team doesn’t live it, and the best way to develop people’s feeling of responsibility is to have them involved in its forging.

Having improved the clarity of the org structure and empowered responsibility, product leaders usually find both benefits they were expecting and additional benefits they weren’t. Marty Cagan summarizes the expected benefits as, “When done well, your product teams are empowered with a high degree of autonomy, and they feel a real sense of ownership over their work, and how it contributes to the greater whole.  The teams can tackle hard problems, moving fast and seeing the results.”

In other words, the org is fitter to deliver on customer-centric objectives. But also, product leaders can expect to personally find themselves involved in less fire-fighting with less structure-generated friction. It also becomes easier to read the org, to understand who is responsible for what and how it is going in an outcome-based way. This improved legibility improves product leaders’ chance of spotting common patterns and challenges across products and acting strategically; in other words, it helps them do more of the real job of product leadership.