This article draws on insights originally reported by ITWorld, featuring DevOps practitioners from Intuit, MetLife, and Red Hat.
Why DevOps Matters for Digital Transformation
Successful digital transformation demands internal disruption. CIOs committed to a digital future must often overhaul their IT operating models — and nowhere is that more visible than in how software is built and delivered.
Many organizations have already moved from waterfall to agile, partnering with business stakeholders to ship applications iteratively. DevOps takes that evolution further by combining development and operations into a unified discipline that automates software assembly through continuous integration, continuous delivery, and continuous deployment (CI/CD). The result: faster releases, better customer experiences, and a tighter feedback loop between technology and business outcomes.
Despite its momentum, the transition to DevOps is rarely straightforward. Organizational silos, cultural resistance, and change management complexity create real friction. The practitioners below have navigated those challenges firsthand.
DevOps in Practice: Lessons from Intuit, MetLife, and Red Hat
Intuit: Blending Security into DevOps Culture
Shannon Lietz, Director of DevSecOps at Intuit, faced the challenge of shifting roughly 4,500 developers away from years of waterfall habits while simultaneously embedding cybersecurity practices into the development pipeline. Her core insight: the cultural shift is as demanding as the technical one.
“The closer you can get to the customer, the more enriching the experience becomes for developers, the other people within the company, and for your customers.”
Shannon Lietz, Director of DevSecOps, Intuit
Lietz describes DevOps as requiring a scientific rigor that many organizations simply are not used to. Introducing disciplined experimentation and measurement into a company accustomed to project-based delivery is itself a major change initiative.
MetLife: Innovation Through Cross-Functional Teams
For MetLife, DevOps adoption ran in parallel with a broader cloud and containerization strategy, incorporating services from Microsoft and IBM alongside Docker-based container technology. Alex Seidita, Chief Technology Architect at the 150-year-old insurer, credits the company’s ModSquad — a cross-functional team of engineers, cybersecurity professionals, and developers — with driving the cultural shift.
“You don’t wait until you know everything before you start anything.”
Alex Seidita, Chief Technology Architect, MetLife
The ModSquad’s operating principle — learn fast, fail fast, deliver fast — captures the iterative mindset that DevOps requires at the team level.
Red Hat: Reclaiming the CIO’s Role as Builder
Mike Kelly joined Red Hat as CIO in August 2016 after a stint at McKesson, where he had already introduced DevOps practices. His motivation was dissatisfaction with the traditional enterprise CIO role — one dominated by buying packaged software and managing associated change, with little room to customize systems for genuinely unique business needs.
“With DevOps, agile, and culture change, we now have tools in the proverbial toolbox to help address these longstanding issues.”
Mike Kelly, CIO, Red Hat
12 Best Practices for Implementing DevOps
Based on their hands-on experience, Lietz, Seidita, and Kelly offer the following recommendations for CIOs beginning or accelerating their DevOps journey.
1. Align DevOps Strategy with the Business
IT and business alignment is a perennial CIO challenge, and DevOps is no exception. If engineering teams pursue DevOps without business stakeholder buy-in, they risk building at speed in the wrong direction. Lietz puts it plainly: without alignment, “you’re just off creating surprises” — and not the welcome kind.
2. Bolt DevOps into Existing Programs
Avoid treating DevOps as an open-ended science experiment. Instead, integrate it into real projects with real deadlines. Seidita recommends picking two or three projects where you can take measured risks but are still held to delivery timelines. Working within constraints forces the discipline that makes DevOps valuable.
3. Be Inclusive — Go Broad
Culture is foundational to DevOps success. Excluding stakeholders from the transformation — even those in roles that feel peripheral — creates resentment and resistance. Seidita advocates for broad inclusion so that everyone feels they are “participating and contributing to the journey,” not watching from the sidelines.
4. Focus on What Makes You Unique
Choose DevOps projects that genuinely differentiate the business. Kelly’s direct advice: “Don’t try to do DevOps for your core ERP system.” Apply DevOps where the return on speed and innovation is highest — in customer-facing products and proprietary capabilities, not commodity back-office systems.
5. Choose Proven Platforms and Tools
The DevOps toolchain — spanning source control, CI/CD pipelines, configuration management, container orchestration, and monitoring — is large and evolving quickly. Kelly recommends selecting tools with established ecosystems and known community support. Betting on obscure or unproven tools introduces unnecessary risk into an already complex transition.
6. Develop Talent from Within
Qualified DevOps engineers are in short supply on the open market. Look inside your organization for engineers and architects who have the right instincts and are willing to contribute. Lietz describes Intuit’s “boundaryless leadership” model, in which managers can recruit willing contributors from across the company. Employees often say yes because the work is clearly connected to business strategy.
7. Avoid the “Classes of Citizenship” Problem
Many IT organizations have two tiers: engineers working on exciting new technologies and engineers maintaining legacy systems. If the DevOps push signals that only one group matters, morale among legacy maintainers collapses. Kelly is explicit: the people keeping ERP and core systems running are just as important as those shipping new microservices. Leaders must be “incredibly hands-on and authentic” in communicating this.
8. Treat Time as a Strategic Variable
Time pressure is a reality — especially in publicly traded companies with quarterly reporting cycles. Lietz recommends committing to value creation within defined time horizons and ensuring every stakeholder, both IT and business, understands their role in the delivery pipeline. Shared accountability to a timeline is what turns DevOps theory into shipped product.
9. Don’t Solve Problems Too Far in the Future
The velocity of DevOps can tempt teams to over-engineer for problems that may never materialize. This speculative work consumes time that could generate real, iterative value today. Keep the focus on near-term delivery; let the backlog and retrospectives surface future problems at the right time.
10. Embrace Story Writing as a Value Blueprint
Well-crafted user stories are more than agile artifacts — they are a commitment to customer value. Lietz recommends framing each story around a specific verb and outcome (for example, “enabling customers to complete onboarding in under two minutes”). Without a clear story arc mapping technology work to customer needs, teams risk building technically impressive features that deliver little real-world value.
11. Cut Through Bureaucracy
Heavy governance processes and rigid approval chains are antithetical to DevOps. Lietz is direct: “The minute you add bureaucracy to DevOps, you will lose.” This does not mean abandoning controls — particularly in regulated industries — but it does mean designing lightweight, automated governance that does not create bottlenecks. Experimentation must be possible without requiring committee approval for every decision.
12. Commit to Iterative Learning
DevOps is a journey, not a project with a completion date. Teams need psychological safety to experiment, fail, and learn. Seidita recommends resisting the pressure to produce detailed multi-year financial models for DevOps investments: “Go in small chunks.” Each sprint delivers learning that informs the next, compounding value over time in a way that big-bang planning simply cannot.
Getting Started
The common thread across all twelve recommendations is that DevOps is as much a leadership and culture challenge as a technical one. Tools and pipelines can be purchased or built; the harder work is aligning incentives, breaking down silos, and sustaining the commitment to continuous improvement when organizational inertia pushes back.
CIOs who approach DevOps as a holistic transformation — rather than a tooling upgrade — are the ones most likely to see it deliver meaningful competitive advantage.