What is the Enabling Team pattern?
An enabling team spends a few weeks or months with a product team, helping it adopt a practice or technology: threat modelling, accessibility testing, performance profiling or a new framework. It explains, pairs, reviews and leaves behind guides and tooling. Success is the product team no longer needing it. It does not own production services.
What problem does the Enabling Team pattern solve?
Product teams cannot be experts in everything, but some skills are needed everywhere. A central team that does all the security or performance work becomes a queue, and its knowledge never spreads. Coaching teams for a while spreads the skill and leaves the work with the teams that own the software.
How do you implement the Enabling Team pattern?
- Staff the team with experienced specialists who like teaching as much as doing.
- Agree a clear goal and an end date with each team you help.
- Pair on real work in the team's own code, rather than giving training in the abstract.
- Turn what you teach repeatedly into guides, checks or templates that the platform can own.
- Track whether teams keep the practice going after you leave.
When should you use it?
- Many teams lack the same skill, and you cannot hire a specialist into each team.
- A new practice or technology is being adopted across the organisation.
When should you avoid it?
- The work needs deep specialists on an ongoing basis. That is a complicated-subsystem team.
What do you gain?
- Skills spread across teams
- No permanent dependency on a central team
- Practices become part of templates and pipelines
What does it cost?
- Specialists' time is limited
- Results depend on the product team's commitment
- Hard to measure
What are common mistakes with the Enabling Team pattern?
- An enabling team that ends up doing the work, so it becomes a permanent dependency.
- Engagements with no end date, so the team never moves on.
- Teaching practices that the platform's tooling makes hard to follow.
Enabling Team in practice
Riverbend Council Services
Public service screens kept failing accessibility audits. A central team fixed issues before each release, but new screens repeated the same mistakes, and the central team's queue kept growing.
Two accessibility specialists became an enabling team, spending six weeks with each product team in turn, pairing on real screens and adding automated checks to the pipeline. The checks moved into the web platform's template, and audit failures dropped.
Further reading: Team Topologies key concepts
Example decision record
- Context
- Many teams lack the same skill, and a central team fixing issues for them has become a queue.
- Decision
- Turn the specialists into an enabling team that coaches one product team at a time, with a goal and an end date.
- Consequences
- The skill spreads and repeated lessons become tooling.
- Results depend on each product team keeping the practice going.
Test yourself on Enabling Team
Teams keep failing accessibility audits. A central accessibility team fixes the issues before each release, but the same problems come back in every new screen. What is a better approach?
2 questions involve this pattern. Practice all of them →
Saved in this browser only. See your progress →