Pitfalls to Avoid When Setting Up a DevOps Center of Excellence

Assembling a center of excellence can help promote knowledge-sharing between colleagues and facilitate DevOps adoption, but you should avoid five common mistakes.

Matt Dickens, CPO and Co-Founder, Gearset

November 19, 2021

4 Min Read
Shpilberg Studios at Adobe Stock

As DevOps adoption continues to accelerate, many leaders are looking to set up their DevOps center of excellence (CoE). The CoE's role is to ensure that the wider company sees the valuable benefits of DevOps: innovation, efficiency, and reduced risk.

With the ongoing trends toward hybrid and remote working, knowledge-sharing between colleagues is less likely to happen organically and developers will default to their preferred processes. Assembling a CoE can help combat these challenges and facilitate DevOps adoption, but you should avoid these five common pitfalls.

1. The mission isn’t clearly defined

The CoE's mission must be defined at the outset. Without a shared understanding of its purpose, the CoE will struggle to identify objectives and find themselves needing to justify their work.

It’s important to define scope and structure. In terms of scope, consider these questions: Will the CoE simply establish effective methods, or is an overhaul of DevOps tooling across the enterprise in view? Are there specific targets for the CoE, or will it drive innovation more generally?

As for structure, some enterprises dedicate a full-time CoE team while others gather experts from various teams who collaborate on improving DevOps processes. The latter approach is similar to Communities of Practice (CoP), which more strongly correlates with DevOps success than traditional CoE setups, according to the DORA report on the State of DevOps. For this reason, I recommend that your CoE takes as much as possible from the CoP model.

2. The CoE becomes detached

Breaking down silos between DevOps teams is a key objective for CoEs. Ironically, some CoEs become an additional silo and risk becoming detached from the rest of the company. While building a CoE guarantees having a team dedicated to the ongoing improvement of DevOps processes, finding a way to keep the CoE integrated with parallel teams can be difficult.

Your CoE might become a bottleneck for innovation, slowing down other teams by advocating an idealistic process that’s difficult to implement. Avoid this scenario by keeping the CoE working on real-world projects so they stay attuned to the nuances of the actual DevOps processes used by teams across the company.

3. No two-way communication

The center of excellence model is all about peer-to-peer knowledge-sharing. A CoE can lend structure and decisiveness to that model, but open communication channels need to be available for other teams to pass their insights and feedback to the CoE.

The CoE should create formal structures for proactively obtaining insight. At some of the enterprises my company advises, the CoE audits other teams across the business regularly. The audit establishes the following:

  • Which tools and processes teams are using

  • Who the stakeholders are for environments maintained by each team

  • How the team is performing in terms of DevOps KPIs (e.g. release cadence and lead times)

This data helps the CoE identify best practices across the organization, not just from the CoE itself. By combining the best bits of each team's process, and forming a coherent approach, the CoE arrives at a process it can share across the enterprise and justify with data-driven analysis.

4. Not prepared to manage internal politics

No team likes to change the tools and processes it uses. Those responsible for setting up the CoE should prepare to navigate internal politics and resistance to change.

Given that the purpose of the CoE is to establish and champion best practice, a single team's preferences should not be allowed to sway the decision-making process. Nor should it be seen as a victory for one team if their tools and processes are found to be more successful than others.

It’s a good idea to draw people from teams across the company when forming the CoE. A CoE that reflects the makeup of your organization is better equipped to handle the potential controversies that transformation can provoke.

5. Failure to measure impacts and demonstrate ROI

As with any other team, the CoE needs to demonstrate ROI to help key decision-makers understand the value it contributes to the business. Otherwise, management may slash the CoE's budget.

To champion the value of mature DevOps processes, the CoE should have a good understanding of the key metrics that need to be tracked to demonstrate success. For instance, the CoE should be able to show that releases are accelerating and articulate the business value of increased agility. They should be able to highlight that code quality is improving and calculate the avoided costs of refactoring or maintaining poor code. The CoE must show how the ROI in their work warrants further investment.

Foster Collaborative Innovation

The expertise needed for a high-performing CoE often exists in large enterprises, dispersed across different teams. Bringing that expertise together and tasking the team with finding innovative DevOps solutions can be valuable if you avoid the pitfalls that cause CoEs to underperform.

About the Author(s)

Matt Dickens

CPO and Co-Founder, Gearset

Matt Dickens is the CPO and Co-Founder of Gearset. Passionate about solving users’ problems, Matt has spent 15 years in the software engineering and DevOps space and is now using this experience to build the best Salesforce DevOps solution on the market.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights