Source: enterprisersproject.com — Original insights from Kevin Baril, Technology Strategy & Management Principal at advisory firm Grant Thornton.
The Culture-Shock Problem With DevOps Adoption
For IT leaders trying to move their organizations from traditional, waterfall-style development to a DevOps model, the biggest threat isn’t tooling — it’s culture shock. Forcing an entire organization to change how it thinks about delivery, ownership, and feedback all at once is a recipe for disruption, resistance, and rollback.
One proven strategy for navigating this transition is to establish a DevOps Center of Excellence (CoE): a dedicated, protected team or environment where DevOps practices can start small, demonstrate value, and gradually expand across the organization. Rather than asking everyone to change at once, the CoE creates a beachhead from which the new approach can grow organically.
“Your business needs to run day-to-day into the future, so you have to find a separate area where you can create things in new ways,” says Kevin Baril. “An innovation hub, center of excellence, tiger team — whatever you want to call it. Create an environment where you can break from the traditional waterfall approach and leverage agile capabilities.”
Here are four concrete steps Baril recommends for building a successful DevOps Center of Excellence.
Step 1: Choose the Right Use Cases
The DevOps CoE will succeed or fail based on which business functions it targets first. Picking the wrong use case — one that is too complex, too politically sensitive, or too tightly coupled with legacy systems — can doom the initiative before it gains momentum.
Baril frames this as a leadership alignment problem first. “This is part of the transformational leadership concept. You have to have a leader who’s done a good job of aligning corporate business strategy with IT strategy and the architecture you’re using to enable it.”
When that alignment exists, it becomes much clearer which capabilities need to be commodity and cost-efficient versus which need to be differentiated and highly responsive to change. Target the latter category for your first DevOps initiatives — those are the areas where faster iteration and tighter feedback loops deliver the most measurable value.
Take your time here. As Baril puts it: “It takes a while to build that understanding of which use case should be first.” Rushing into the wrong domain wastes the goodwill and momentum that a successful early project would otherwise generate.
Step 2: Learn the Business Process Deeply Before You Build
Once you’ve identified your first use case, resist the urge to jump straight into toolchain setup or sprint planning. The CoE team needs to develop a thorough understanding of the business process they are improving before they can improve it effectively.
“Have a clear understanding of the outcome you’re trying to achieve and organize your team to accomplish that,” Baril says. “Your core team, introducing this new, transformative concept, needs to be fluent in the business on those concepts. Because using agility to create improvement depends a lot on the process you’re trying to improve.”
This means defining success criteria up front — whether the goal is faster release cycles, reduced manual effort, improved uptime, or lower infrastructure cost — and ensuring the entire team understands what “done” looks like. Without this clarity, velocity alone is not a useful measure of progress.
Step 3: Expect and Encourage Deep Business Involvement
One of the most important — and often underestimated — aspects of building a DevOps CoE is involving business stakeholders as active participants, not passive observers or end-users.
Baril points out that the frustration with waterfall development is shared equally between IT and the business. “Over the last 10 to 20 years, requirements were gathered in a structured way and by the time you built the system, a lot of the requirements had changed.” Business leaders often end up with technology that no longer matches what they actually need — a problem DevOps practices, with their emphasis on continuous feedback and iteration, are specifically designed to address.
Crucially, the boundary between IT and business functions has been blurring for years. “Increasingly, effective IT leaders and effective members of IT departments have a solid understanding of the business application of whatever they’re looking to accomplish,” Baril notes.
This cuts both ways. Modern low-code and platform-oriented tooling means that technically capable people in business departments can now play a direct role in building and deploying solutions. “So digital natives may be working with the rollout of new applications, and it wouldn’t be strange to have those people come from a business area instead of IT.” Your CoE should actively recruit from both sides of that fence.
Step 4: Don’t Assume You Need a Large Team to Start
Talent acquisition is often cited as the most challenging barrier to standing up a DevOps CoE. The skill set required — spanning development, operations, security, and business domain knowledge — is genuinely hard to find in one place. But that doesn’t mean you need a large team from day one.
Some organizations free up existing IT staff by automating routine tasks or consolidating systems, redirecting that capacity toward the CoE. This is a slower route but has the advantage of preserving institutional knowledge. The faster approach is targeted hiring.
“In many companies, it’s affordable to do that,” Baril says. “You have turnover, and the CIO has wide discretion about hiring. If you make the decision that this is a priority for us, then you can bring on a core group of people with the mindset to create a DevOps center of excellence.”
The key word here is mindset. The CoE team doesn’t need to be large — it needs to be composed of people who are genuinely committed to iterative improvement, cross-functional collaboration, and shared ownership of outcomes. A small, motivated team with the right culture will outperform a larger group that is simply executing instructions.
Key Takeaways
- Start with a protected space. A CoE lets DevOps practices prove their value without disrupting the rest of the organization.
- Use case selection is a strategic decision, not a technical one. Align it with business strategy before picking tools or hiring staff.
- Business fluency is non-negotiable. The CoE team must understand the processes they are modernizing, not just the technology they are deploying.
- Business stakeholders are partners, not customers. Involve them early and often; they have as much to gain from DevOps as IT does.
- Team size matters less than team mindset. A small, aligned group with the right culture can bootstrap a CoE effectively.
Building a DevOps Center of Excellence is ultimately an exercise in change management as much as it is an engineering challenge. Getting the organizational design right from the start gives the initiative the best chance of scaling across the rest of the enterprise over time.