Expanding on Team Topologies

Team Topologies has quickly become the defacto guide for how to structure technology teams, and more importantly, the ways that the teams interact.

But Teams Topologies focuses on the software delivery teams so as we were creating the ZeroBlockers framework we recognised the need to introduce some new teams and interaction modes to cater for the different needs and use cases.

Team Topologies Team Types

Team Topologies defines 4 different team types:

1. Stream Aligned Teams. These are the teams that build the products. They are assigned a “flow of work” and have full autonomy to go from idea to delivered product.

2. Enabling Teams. These teams monitor the work being delivered by each stream-aligned team and offer coaching and mentoring whenever a skill gap is identified.

3. Complicated Sub-System Teams. When systems require dedicated specialists it is not feasible to distribute the skills across all of the Stream Aligned Teams so a separate team can be created.

4. Platform Teams. Platforms abstract away common, repeated tasks so the Stream Teams can focus on differentiating features instead of generic work.

Team Topologies Interaction Modes

Collaboration is expensive. By clearly identifying the expectations around how teams should interact with each other we can both reduce confusion and increase efficiency.

1. Collaboration. Where two teams work together to deliver a feature. This is the most expensive interaction mode since it requires dedicated time where teams are distracted from their individual goals.

2. X-as-a-Service. Teams collaborate through well-defined self-service APIs. This is the most efficient collaboration mode.

3. Facilitating. A team helps (or is helped by) another team to clear impediments through coaching and guidance. Enabling teams use this mode to help upskill stream-aligned teams in specific areas.

So what is missing?

Product Teams

As a product grows the number of Stream-aligned teams will grow as well. These teams need some context about the goals of the product to help them make high-quality decisions about the best solutions for the opportunities they identify.

In the ZeroBlockers framework, we introduced a new team to provide this context: The Product Team. The Product Team decides how the product should be broken up into separate areas of scope, funds and staffs the teams and then provides them with the context needed to make product decisions via a product vision, strategy and quarterly objectives. Critically, they do not tell the teams what to build but give them the necessary context to enable the teams to decide on what is best.

For example, we might have an e-commerce Product Team with three Stream Aligned Teams:

1. Catalogue: The team responsible for products offered, home page and search.

2. Buy: The team responsible for the purchase journey

3. After-Sales: The team responsible for returns and customer support

The defined interaction modes don’t fit neatly with the way that a Product Team and Stream Aligned Teams would interact so we have also introduced a new Aligning interaction mode.

Internal Product Teams

An internal product team is almost identical to a Product Team except that the customers are internal to the company rather than external. There are two types of internal teams: internal departments and platforms.

Internal departments are teams like Finance, Legal, HR and Operations. Stream Aligned Teams often need to interact with these internal teams, but the ways of working and expectations for responsiveness are often not aligned. Since blockers remove accountability we need to encourage internal teams to be more customer-centric and productise their offerings so they can shift to an X-as-a-Service interaction mode where possible.

Platform teams include technical platforms but also includes other platform types like Design Systems and Data Reporting systems.

So we have rebranded the Team Topologies Platform Team as an Internal Product Team, but with more scope than the original Platform Team.

Ecosystem Teams

Once you scale to the point where you have multiple Products, Internal Products and Enabling Teams there is a need for another team to coordinate their work. In the same way that Product Teams direct the work of Stream Teams, Ecosystem Teams direct the work of Product, Internal Product and Enabling Teams.

Summary

Team Topologies has, rightly, been lauded by people as a revolutionary new way of designing how to structure teams and, in particular, how teams interact with each other.

ZeroBlockers is definitely “standing on the shoulders of giants”. Our scope is broader than the scope that Matthew Skelton and Manuel Pais had for their book so that is why we needed to extend their model. We have tried to remain consistent with the goals and motivations of the original work while making the changes needed to help teams scale more effectively.

Let us know your thoughts on the new team types and interaction mode. Does it enhance the original Team Topologies or take away from it?