Centers of Excellence Are Where Transformations Go to Die

Most technology leaders trying to speed up software delivery walk into the same trap.

The playbook is familiar. Leaders announce a big change effort. They hire experts, give them budget, and name them the DevOps Center of Excellence. The goal sounds simple: set shared standards, build central tools, and teach teams how to ship fast.

Within a year, the plan stalls. The Center of Excellence becomes the exact bottleneck it was hired to fix.

Instead of speeding up delivery, the central team turns into a ticket line. Product teams wait weeks for the central office to approve a pipeline, set up cloud access, or sign off on a build. Experts in the center write abstract rules that clash with daily production work. Frustrated engineers bypass official tools, while leaders wonder why costly programs produce zero speed.

The failure stems from a flawed design: treating engineering change as a central monopoly rather than a peer network.

The topology of failure

In team systems, structure sets behavior.

A Center of Excellence uses a hub-and-spoke setup. Tools and rules live at the center. Delivery teams sit at the edges as passive buyers.

This structure creates three clear failure modes:

First, the empathy gap. When central experts do not carry pagers for live production services, their rules drift away from real constraints. They build complex tools that look neat on paper but slow down daily work. As Matthew Skelton and Manuel Pais show in their work on team topologies, an enablement team that isolates itself from production becomes an isolated group that manufactures busywork.

Second, the ticket line bottleneck. When one central team owns all deployment tools and templates, every product team becomes a dependent customer. Work stops flowing. Wait times multiply according to basic queueing rules: a central team with fixed staff faced with dozens of product requests becomes an operational gatekeeper.

Third, single-point fragility. A central office depends on its executive sponsor. When leaders change or budgets shrink, the center gets cut as corporate waste. The habits die with the team because knowledge was hoarded instead of shared.

What high performers actually do

The data on technology change confirms this pattern.

In the 2019 Accelerate State of DevOps Report, researchers tracked how teams scale technical skills.

The data shows a clean split. Elite teams are twice as likely to use grassroots Communities of Practice (57 percent) as low performers (24 percent). Communities of Practice are the top scaling tool among top software teams.

Central Centers of Excellence show the reverse trend. They gather in low and medium performers (34 percent each), but drop among elite teams. Low performers also suffer from stalled work at more than twice the rate of elite teams (41 percent to 16 percent).

When researchers grouped top teams by how they scale, 91 percent used community models. Community Builders led at 46 percent, Emergent Teams at 23 percent, and Experimenters at 22 percent. Central training groups made up less than one-tenth of top teams.

Elite organizations scale modern engineering through decentralized community networks, not centralized authority hubs.

The mesh network model

Scaling technical skill requires replacing the central hub with a peer network.

Top companies do not build central gatekeeping groups. They sponsor peer groups. Engineers from different teams meet to share tools, fix real production issues, and build shared habits.

Instead of pushing top-down rules, they use small proofs of concept as seeds. A team solves a real problem in production. They turn their fix into a shared template. Other teams adopt the pattern voluntarily because it works, rather than obeying a committee mandate.

They treat internal tools like open source. In an effective internal platform, the central team acts as product stewards rather than sole authors. When a product team needs a feature in a shared pipeline, they contribute a pull request directly. The platform improves through daily production use across the entire company.

The operational transition

To shift from a central hub to a peer network, leaders must change how they invest capital.

First, stop funding full-time transformation staff who do not ship production code. Fund short rotations instead. Let strong engineers spend time coaching peers, building shared templates, and leading workshops.

Second, measure tool adoption by voluntary pull rather than compliance mandates. If a shared deployment template is good, product teams will adopt it willingly. If teams reject a central tool, treat their refusal as product feedback rather than an infraction.

Third, reward engineers who export solutions. When a team solves a hard cloud problem, reward them for turning that fix into a shared library for peers.

Change works when skills spread through peer networks across the company.

Stop funding central groups that write abstract rules. Sponsor grassroots groups. Reward teams that turn working code into shared tools. Build a mesh network that outlives any single sponsor.