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, typically one or two people, and functionally aligned. They are staffed by the most senior experts in their field, who have a deep understanding of the craft 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.
Each Enabling Team is staffed with a Staff or Principal Functional Expert.
Each company will have a different set of Enabling Teams depending on which crafts most need attention. Some illustrative examples:
| Enabling Team | What they enable |
|---|---|
| Research | Coach designers across Stream Teams on customer research practices, raising research quality without putting a researcher on every team. |
| Design | Maintain the design system and coach designers on design craft, accessibility and visual consistency. |
| QA | Coach Stream Teams on automated testing, observability and quality practices so quality is built in rather than inspected in. |
| Developer Experience | Improve the tools, pipelines and platforms developers depend on so the Stream Teams can move quickly and safely. |
| Engineering Practices | Coach developers on architectural patterns, code quality and technical practices. |
| ProductOps | Coach Stream Teams on metrics, instrumentation and decision-making so each team can read its own numbers and act on them. |
| Data | Coach Stream Teams on data practices, analytics and instrumentation. |
This is not a fixed list. Other crafts such as Marketing, Security, Accessibility may justify their own Enabling Team as the organisation grows.
Enable, don't deliver
An Enabling Team is at risk of becoming a dependency the moment it starts doing the work for the Stream Teams instead of enabling them. The boundary has to be defended deliberately. If the Research Enabling Team starts running interviews on behalf of teams, or the QA Enabling Team starts writing tests for teams, the Stream Teams stop developing the skill and the Enabling Team becomes a dependency.
How Enabling Teams improve performance
Every Enabling Team works along three axes (people, process and technology) and follows the same four-step improvement loop on each axis. The loop is what makes the work systematic rather than ad-hoc.
- Define what good looks like. Roles and responsibilities for each level on the people axis. Good-practice playbooks and templates on the process axis. Tooling standards and reference architectures on the technology axis. Without an explicit "good," the team is auditing against personal preference.
- Upskill. Identify training needs against the standards, design the curriculum, and create the content. Apprenticeships, workshops, and dojos are typical formats.
- Transfer knowledge. Document the guidelines and playbooks. Run communities of practice that connect practitioners across Stream Teams. Cross-team knowledge transfer is where most of the practice's leverage lives.
- Implement high-quality tools. Assess the tools the Stream Teams use, recommend the standard, and run the procurement and integration so that each team isn't independently evaluating the same options.
The four steps apply equally to every axis:
| Axis | Define good | Upskill | Transfer knowledge | Tooling |
|---|---|---|---|---|
| People | Capability standards per level | Curriculum, courses, apprenticeships | Communities of practice | Performance and 360-feedback tools |
| Process | Good-practice playbooks | Workshops, internal training | Repository database, internal blogs | Process automation, workflow tools |
| Technology | Reference architectures, fitness functions | Tooling workshops | Engineering knowledge bases | The tools themselves |
Treating people, process and technology as separate axes prevents the common Enabling Team failure mode of focusing entirely on tools and neglecting the underlying skills, or running great workshops but never updating the playbook so the learning evaporates.
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, MarketingOps etc. Often the responsibilities of these teams will bridge the gap between facilitating 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, a MarketingOps team that writes copy for Stream Teams instead of coaching them on positioning, or ProductOps who analyse and deliver reports to the Stream Teams. We need to separate these "service" responsibilities from the "facilitating" responsibilities.
A Marketing Enabling Team, for example, should define positioning and messaging capability standards, create go-to-market playbooks and templates, run communities of practice for growth and marketing specialists across Stream Teams, and coach people on customer language and competitive positioning. It should not be running campaigns or producing marketing assets. That is the responsibility of the Marketing Operations Internal Product Team.
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.