This article is based on original reporting from enterprisersproject.com, featuring perspectives from CTOs, CIOs, and DevOps practitioners.
If DevOps is ultimately more about culture than any particular technology or platform, then remember this: there is no finish line. DevOps is a continuous journey of change and improvement — and the C-suite does not get a pass.
Leaders who want DevOps to deliver measurable business outcomes need to revise some of their traditional approaches. Below are seven actionable rules for more effective IT leadership in the DevOps era.
1. Say “Yes” to Failure
The word “failure” has long carried very specific — and almost universally negative — connotations in IT: server failure, backup failure, hard drive failure. A healthy DevOps culture, however, depends on redefining the term entirely. IT leaders need to reframe failure as opportunity.
“Prior to DevOps, we had a culture of punishing failure. The only learning we had was to avoid mistakes. The number one way to avoid mistakes in IT is to not change anything: don’t accelerate the release schedule, don’t move to the cloud, don’t do anything differently!”
— Robert Reeves, CTO and co-founder of Datical
That kind of stasis is itself a form of failure. Organizations that release slowly and avoid modernization out of fear are not playing it safe — they are falling behind.
“IT leaders must embrace failure as an opportunity. Humans not only learn from their mistakes, they learn from others’ mistakes. A culture of openness and psychological safety fosters learning and improvement.”
— Robert Reeves
Building psychological safety — where engineers can experiment, fail fast, and share lessons openly — is one of the most impactful things a leader can do to accelerate DevOps maturity.
2. Live, Eat, and Breathe DevOps in the C-Suite
DevOps culture can grow organically, but organizations transitioning away from monolithic, siloed IT practices need unambiguous executive buy-in. Without visible leadership commitment, mixed messages will embolden those who prefer the status quo.
“Top management must fully support DevOps in order for it to be successful in delivering the benefits.”
— Derek Choy, CIO at Rainforest QA
Becoming a DevOps organization touches nearly every dimension of the business: technical teams, tooling, processes, and roles and responsibilities. Partial commitment from leadership produces partial — and often frustrating — results.
“Without unified sponsorship from top management, DevOps implementation will not be successful. It is important to have leaders aligned at the top level before transitioning to DevOps.”
— Derek Choy
3. Don’t Just Declare “DevOps” — Define It
Even in organizations that have embraced DevOps enthusiastically, a common and underestimated obstacle is definitional ambiguity. Different teams may be operating with fundamentally different interpretations of what DevOps means, leading to misaligned priorities and conflicting practices.
“DevOps can mean different things to different people. It is important for C-level and VP-level executives to define the goals of DevOps, clearly stating the expected outcome, understand how this outcome can benefit the business, and be able to measure and report on success along the way.”
— Derek Choy
Beyond an agreed definition, DevOps requires frequent, transparent communication at every level of the organization — not just within engineering teams.
“Inevitably, there will be hiccups, failures, and disruptions to the business. Leaders need to clearly communicate the journey to the rest of the company and what they can expect as part of the process.”
— Derek Choy
4. DevOps Is as Much About Business as Technology
IT leaders running successful DevOps organizations have come to treat DevOps as a business strategy, not merely an engineering methodology. DevOps culture is one of the most effective levers for shifting IT from a cost center to a strategic business driver.
“IT leaders must shift their thinking and approach from being cost/service centers to driving business outcomes. A DevOps culture helps speed up those outcomes via automation and stronger collaboration.”
— Mike Kail, CTO and co-founder at CYBRIC
“An effective IT leader will need to be more engaged with the business than ever before. Gone are the days of yearly or quarterly reviews — you need to welcome bi-weekly backlog grooming. The ability to think strategically at the year level, but interact at the sprint level, will be rewarded when business expectations are met.”
— Evan Callendar, Director of Performance Services at West Monroe Partners
Promoting smart risk-taking and innovation are not soft leadership ideals — they are operational necessities for any organization competing in a continuous-delivery world.
5. Change Anything That Hampers DevOps Goals
Declaring your department a DevOps shop while resisting necessary changes to processes or tooling is counterproductive. DevOps culture must be enabled by the right infrastructure — and that starts with automation.
“IT leadership has to put an emphasis on automation. This will be an upfront investment, but without it, DevOps will simply engulf itself with inefficiency and lack of delivery.”
— Evan Callendar
Automation is foundational, but meaningful change extends further — into monitoring strategies, continuous delivery pipelines, team structures, and role definitions.
“Leaders need to push for automation, monitoring, and a continuous delivery process. This usually means changes to many existing practices, processes, team structures, and roles. Leaders need to be willing to change anything that will hinder the team’s ability to fully automate the process.”
— Derek Choy
6. Rethink Team Structure and Performance Metrics
If your organizational chart has barely changed in a decade, it’s overdue for a serious review. Rigid team boundaries are antithetical to the cross-functional collaboration that DevOps depends on.
“IT executives need to take a completely different approach to organizational structure in this new era of DevOps culture. Remove strict team boundaries, which tend to hamper collaboration, and allow teams to be self-organizing and agile.”
— Mike Kail
The rethinking must extend to how you measure success. Vanity metrics — lines of code written, test coverage percentages, server uptime in isolation — tell you little about whether DevOps is delivering business value.
“DevOps metrics should be tied to business outcomes in some manner. You probably don’t really care about how many lines of code your developers write, whether a server had a hardware failure overnight, or how comprehensive your test coverage is. But you do care to the degree such metrics can be correlated with customers abandoning shopping carts or leaving for a competitor.”
— Gordon Haff, Red Hat technology evangelist
“Measure initiatives in terms of business outcomes and overall positive impact. And something I believe to be the most important aspect of management: be empathetic.”
— Mike Kail
7. Chuck Conventional Wisdom Out the Window
The DevOps age demands new ways of thinking about leadership — which means some longstanding approaches need to be retired. When asked which ones, the answer from practitioners is blunt.
“To be honest, all of them. Get rid of the ‘because that’s the way we’ve always done things’ mindset. The transition to a culture of DevOps is a complete paradigm shift, not a few subtle changes to the old days of Waterfall and Change Advisory Boards.”
— Mike Kail
One concrete example of outdated thinking: the preference for architecture consolidation in homogenous environments as a cost-saving strategy.
“One of the big rules I see going out the window is architecture consolidation, or the idea that long-term maintenance is cheaper if done within a homogenous environment.”
— Evan Callendar, West Monroe Partners
Modern infrastructure approaches — containers, microservices, hybrid IT — embrace heterogeneity as a feature, not a liability. Leaders who refuse to engage with these models risk constraining both their engineering teams and their competitive agility.
Summary: The DevOps Leadership Checklist
- Reframe failure as a learning opportunity and build psychological safety into your culture.
- Secure genuine C-suite alignment before launching a DevOps transformation.
- Define what DevOps means for your organization and communicate it clearly and consistently.
- Connect DevOps to business outcomes, not just engineering velocity.
- Remove process and tooling blockers, especially by investing in automation and continuous delivery.
- Restructure teams and metrics to reflect cross-functional collaboration and business-aligned KPIs.
- Discard legacy assumptions about architecture, governance, and management style.
DevOps leadership is not a destination — it is an ongoing practice of questioning assumptions, enabling your teams, and relentlessly aligning technology decisions with business value.