Empowered on Team Topologies

In most companies, the technology teams are not empowered product teams, they are what I call here feature teams.

Feature teams look superficially like a product team. They are cross‐functional, with a product manager, a product designer, and some number of engineers. The difference is that they are all about implementing features and projects (output), and as such are not empowered or held accountable to results.⊕ (Cagan and Jones 2021, chap. 1)

Feature teams are cross‐functional (a product manager doing mainly project management, a product designer, plus some engineers), and assigned features and projects to build rather than problems to solve, and as such they are all about output and not business results.

Empowered product teams are also cross‐functional (a product manager, a product designer, and engineers), but in contrast to feature teams, they are assigned problems to solve, and are then empowered to come up with solutions that work–measured by outcome–and held accountable to results.⊕ (Cagan and Jones 2021, chap. 1)

We consider the two fundamental types of product teams: platform teams, which manage services so they can be easily leveraged by other teams, and experience teams, which are responsible for how the product value is exposed to users and customers.⊕ (Cagan and Jones 2021, chap. 42)

When a platform team is working with an experience team:

the important thing is that the platform team has the same strategic context and goal as the experience team. They are connected as to why the work is important, and what it means for the business.⊕ (Cagan and Jones 2021, chap. 42)

When it comes to empowering platform teams, if you separate in your mind the normal keep‐the‐lights‐on work from the major work to move the platform forward, then the team objectives and the level of empowerment are comparable to experience teams.⊕ (Cagan and Jones 2021, chap. 43)

A key point was that experience teams are most empowered when they are given as much end‐to‐end responsibility as possible.

This is more likely to happen when the scope of ownership for each team follows other natural patterns of the business such as the sales channel, market segment, or user type. More often than not, this means creating a topology that is aligned by customer.

Here are some examples of alignment by customer:

• By user type or persona (e.g., Riders Team, Drivers Team)
• By a market segment (e.g., Electronics Team, Fashion Team)
• By customer journey (e.g., Onboarding Team, Retention Team)
• By sales channel (e.g., Self‐Service Team, Direct Sales Team)
• By business KPI (e.g., New‐User Growth Team, Conversion Team)
• By geography (e.g., North America Team, Asia Pacific Team)⊕ (Cagan and Jones 2021, chap. 44)
  
  

Enterprise products frequently must be specialized for different segments of customers. Sometimes, there are differences by the customer’s vertical market (e.g., manufacturing vs. financial services vs. retail). Sometimes there are very significant differences based on the go‐to‐market strategy. Sometimes there are differences because of the customer’s size (e.g., SMBs are reached through a self‐service portal, while larger customers require a sales force and APIs for customization).

Here, it can make sense to organize experience teams by whatever segmentation is most relevant to the company. Once again, the goal is to organize the experience teams in a way that allows them to best serve their specific customer and also align with other parts of the company.⊕ (Cagan and Jones 2021, chap. 44)