Enabling Teams
Enabling Teams streamline the performance of Stream Teams. As functionally aligned teams, they define what good looks like in terms of skills, processes, and tools, and help to upskill the team members within Stream Teams to meet these standards.
The Team
Enabling teams are small, functionally aligned teams. They are staffed by the most senior experts in their field, who have a deep understanding of the domain in which they work. While they would be proficient in the delivery of software products, they provide much higher leverage by guiding and coaching others in their area of expertise.
| Role | Skills | Responsibilities |
|---|---|---|
| Staff/Principal Functional Experts | Deep understanding of the domain in which they work | Define what good looks like in terms of skills, processes and tools and help to upskill the Stream Teams to meet these standards. |
How Enabling Teams work
Aligning
Aligning with the Ecosystem Team to ensure that Enabling Teams focus on the highest priority, and measurable, areas of impact.
People
Defining the expectations for people in their roles and coaching and developing people to achieve the high standards.
Process
Creating and maintaining good practice guidelines, playbooks and templates that help to accelerate the work of the Stream Teams.
Technology
Assessing the tools that are used by the Stream Teams and making recommendations on which tools to use.
The Difference between Enabling and Internal Product Teams
Collaboration between teams is very expensive. By being explicit about the way that teams interact, we can reduce the cost of collaboration. The book Team Topologies by Matthew Skelton and Manuel Pais describes three interaction modes between teams: collaboration, x-as-a-service, and facilitating. X-as-Service is the most efficient way to interact because it is a self-service model, which means the second team is not disturbed. This is only possible when the types of request and expected responses are well known.
Service providers, who deliver part of the work needed by a Stream Team operate in the collaboration mode, as they need to understand the context of the Stream Team to deliver the work. This is the most expensive and least efficient way to interact. We want to avoid this mode of interaction as much as possible.
Enabling teams could be viewed as service providers but we want to explicitly avoid this. Enabling teams are not service providers, they are facilitators. They are not delivering work for the Stream Teams, they are helping the Stream Teams to deliver the work themselves. This is a subtle but important distinction.
A lot of companies are implementing Enabling Teams, with names such as ProductOps, ResearchOps, DesignOps etc. Often the responsibilities of these teams will bridge the gap between facilitiating and delivering work. This is a mistake because it will make all interaction with the team less efficient, even if the team is trying to deliver facilitating type work. An example is a ResearchOps team who also provides research-as-a-service, or ProductOps who analyse and deliver reports to the Stream Teams. We need to separate these "service" responsibilities from the "facilitating" responsibilities.
There are two ways to achieve these outcomes. Enabling Teams can provide guidelines and playbooks to enable Stream Teams to be self-sufficient. Or the work can be delivered by an Internal Product Teams. Internal Product Teams include other service providers such as Finance, Legal, a technology platform or a design system. By defining a clear separation between the teams, we can ensure much more streamlined interactions between Enabling Teams and Stream Teams.