Enabling Team
A team whose output is other teams' increased capability, working alongside them temporarily rather than owning a component permanently.
One of the four team types in the Team Topologies model, and the one that resolves a recurring organisational failure: the specialist group — security, performance, data, cloud — that becomes either a bottleneck everyone queues behind or an ivory tower issuing standards nobody follows.
An enabling team's success condition is that it leaves. It works with a stream-aligned team for a bounded period, transfers a capability the team then owns, and moves on. Its measure is the capability of the teams it has worked with, not throughput of its own backlog.
The distinction from a platform team matters in practice: a platform team provides something teams consume indefinitely, an enabling team provides something teams absorb and no longer need help with. Confusing them creates permanent dependency, which is the standard failure of a "centre of excellence" that quietly becomes a delivery team with a grander name.
Architecture functions are frequently better shaped as enabling teams than as governance bodies, which is one of the more useful reframings available to an architecture group struggling for influence.