The instinct in some quarters is to ditch ITSM entirely, or to let the ITSM team operate in a separate orbit from DevOps practitioners. According to several practitioners and analysts, that would be a serious mistake.

“DevOps aims to deliver high-quality software to the business faster and in shorter cycles. However, it still does not eliminate the need for controls.”

Krishna Mohan Reddy, VP and Deputy Global Head of Cognitive Business Operations, Tata Consultancy Services

ITSM and DevOps are often described as the yin and yang of modern IT operations—contrasting viewpoints that, when integrated thoughtfully into a single operating model, can be highly complementary.

“Maintaining the proper balance between ITSM and DevOps helps organizations scale, grow, and become more organized. Both in harmony will increase efficiency and reduce the blame-game within the organization.”

Sachin Agarwal, DevOps Engineer and Solution Architect, Mantra Labs

As organizations work toward that harmony, here are three key pitfalls to avoid.

Mistake 1: Letting Tribal Preconceptions Block Progress

Both camps carry baggage. DevOps and Agile practitioners often automatically discount input from colleagues with ITIL certifications, viewing process-heavy frameworks as the enemy of speed. Meanwhile, traditional operations and development teams can view DevOps practitioners as undisciplined “cowboys” who ignore governance at their peril.

“You need to compromise. A lot of the new, young practitioners in DevOps and Agile will pretty much automatically discount opinions coming from people who have got ITIL certifications. And vice versa—a lot of traditional operations and development teams will look at the people in DevOps and Agile and think they’re all cowboys. But they all have something to learn from each other.”

Andi Mann, Chief Technology Advocate, Splunk

For DevOps practitioners specifically, it is worth recognizing that ITSM controls—service requests, change management, structured incident and problem tracking—do not inherently slow teams down. Done well, they provide exactly the visibility and structure that enable sustainable speed.

“In IT, just like in science, if it isn’t seen, measured, and reproducible, it doesn’t really count. ITSM is actually the perfect complement to DevOps because it aids in the visibility, measurement and reproducibility of key DevOps processes.”

Troy Vetter, COO, Coda Global

The practical takeaway: create cross-functional forums where ITSM and DevOps practitioners design processes together rather than having either side impose its assumptions on the other.

Mistake 2: Ignoring the Change Management Problem

If there is one single flashpoint where DevOps and ITSM consistently clash, it is change management. Traditional Change Advisory Boards (CABs) were designed for a world of infrequent, high-risk releases evaluated in scheduled weekly or bi-weekly meetings. Continuous delivery pipelines can push dozens—or hundreds—of changes per day. Those two realities are fundamentally incompatible without deliberate redesign.

“Change management has often been where DevOps and ITSM collide. The stereotypical Change Advisory Board must radically revise its approach to be in sync with the enormous amount of change that DevOps can produce in a day.”

Roy Atkinson, Service Management Analyst, HDI

The good news is that the ITSM community has been actively rethinking change management for CI/CD environments. The emerging model shifts change management from a gate at the end of a delivery pipeline to a continuous, embedded practice woven throughout the development lifecycle.

“There is some excellent recent thinking in the ITSM world about how change management can serve its intended purpose without being a roadblock—by acting as an enabler of change and being involved all along the way, rather than a bolt-on quality check at the end of the line before the production environment.”

Roy Atkinson, HDI

Practical approaches organizations are adopting include pre-approving standard changes that have been tested in the pipeline, automating change record creation from CI/CD tooling, and restructuring the CAB into a lighter, asynchronous review process for high-risk changes only.

Mistake 3: Maintaining Separate, Disconnected Toolchains

Even when both ITSM and DevOps teams are willing to collaborate, organizational goodwill can be undermined by incompatible tooling. When developers track work in one system and the ITSM team tracks incidents and requests in a completely separate platform, handoffs become manual, error-prone, and slow.

“You might have a tool that developers use for tracking bugs or product backlog and then there’s a completely separate IT service management tool. So what you end up doing is forcing developers to use some process that’s outside of their norm in order to address issues.”

Donna Knapp, Curriculum Development Manager, ITSM Academy; author, DevOps Institute’s ITSM for DevOps course

A significant part of DevOps resistance to ITSM has historically been driven by monolithic, manually-operated ticketing systems that added friction without adding value. Modern ITSM tooling has evolved considerably, but only delivers value if it is properly integrated with the DevOps pipeline.

“Self-service requests, automation flows and IT orchestration are now our front door to actions, and IT service management can and should be happening in the background, automagically created, maintained and measured by our DevOps tools.”

Troy Vetter, COO, Coda Global

Bridging the toolchain gap typically means one of three approaches: integrating existing tools via APIs so that events in the CI/CD pipeline automatically create or update ITSM records; adopting a platform that spans both use cases; or establishing a shared data layer that both toolchains write to and read from. The right choice depends on existing investment and team size, but any of the three is preferable to maintaining two siloed systems.

Bringing It Together

DevOps and ITSM emerged from different problems, but they share the same ultimate goal: reliable, high-quality IT services delivered as fast as the business needs them. Organizations that treat integration as a cultural and process challenge—not just a tooling decision—are far more likely to get both disciplines working in concert.

• Encourage cross-functional empathy. Create shared forums, rotating roles, or joint post-incident reviews so both camps understand each other’s constraints.
• Redesign change management from the inside out. Embed change controls into the pipeline rather than appending them at the end.
• Invest in toolchain integration. Automate the handoffs between development, operations, and service management systems to eliminate manual overhead.

The collision between DevOps and ITSM is real, but it is not inevitable. With deliberate design and a willingness to compromise on both sides, the two can operate as a unified, high-performing system.

Original reporting by devops.com. Quotes and attribution preserved from the source article.

Despite the wealth of courses, certifications, and books now available, some of the most valuable DevOps lessons cannot be taught in a classroom. They come from lived experience — from projects that stalled, rollouts that backfired, and cultural battles that nobody anticipated. The following lessons were shared by DevOps veterans as advice they would give to their earlier selves. Whether you are just starting out or trying to mature an existing DevOps practice, these insights are worth taking seriously.

1. Beware of the “Them and Us” Mentality

Fin Goulding, international CIO, Aviva: “Without a shadow of a doubt, I underestimated the cultural challenges of implementing DevOps. The fusion of two ‘tribes’ into one sounds easy on paper: But the reality is very different and it takes quite some time to remove the ‘them and us’ mentality in order to have developers and engineers working side by side delivering value. I wish I had spent more time coaching individuals rather than just implementing the model across all the technical teams at once. In fact, it would have been best to start in a small way with a ‘lighthouse’ implementation before going for full roll-out.”

Goulding’s experience reflects one of the most consistent findings across DevOps transformations: tooling and process changes are relatively straightforward compared to the human side. Development and operations teams often carry years of entrenched habits, different incentive structures, and mutual mistrust. Forcing them into a shared workflow without adequate coaching frequently produces friction rather than collaboration.

A practical takeaway: before scaling DevOps organization-wide, identify a willing cross-functional team and run a pilot — a “lighthouse” — that can demonstrate value and surface cultural issues at a manageable scale. Use what you learn there to inform the broader rollout.

2. C-Suite Alignment Is Not Optional

Ben Grinnell, managing director, North Highland: “I would have liked to have understood the breadth of the changes needed to have a sustainable impact and the impact required across many of the typical C-suite functional areas. When we started out we were typically working with IT leaders (CIOs, CTOs or CDOs) trying to improve flow, feedback, and continuous improvement between development and operations functions. Often that solution wasn’t sustainable and didn’t deliver the benefits anticipated due to the problems elsewhere in the value stream, which gradually pulled the transformed Dev and Ops functions back to working in the old way.”

“This type of change is easily attacked by the corporate antibodies that destroy anything foreign. In order to stop this effect, you need to change the DNA of the organization.”

Ben Grinnell, North Highland

Grinnell goes on to explain that isolated DevOps improvements — even impressive ones — can be undone when the rest of the organization continues to operate under incompatible financial governance, procurement cycles, security review processes, and audit requirements. Without broader organizational alignment, improved Dev and Ops teams are essentially swimming against the current.

His advice: start small and learn, but invest early in building executive alignment that extends beyond the CIO or CTO. Procurement, finance, security, and audit all touch the software delivery value stream. Getting CEO-level sponsorship, in his experience, can accelerate progress significantly compared to trying to influence individual C-suite members one at a time.

3. When in Doubt, Have a Mitigation Plan

Eran Kinsbruner, director, author, and lead software evangelist, Perfecto: “Looking back, I wish I knew the importance of planning the DevOps pipeline to accommodate for changes. Along each iteration, changes are constantly being introduced, whether it’s a change to requirements, a change in backlog features, or other interruptions around quality (escaped defects, customer reported issues, etc.). Having a mitigation plan ahead of the end of journey can make the difference between business success and failure.”

Kinsbruner points out that mitigation planning is not simply a matter of writing a risk register. It requires strategic decisions about tooling, clear quality guidelines, and — critically — management buy-in to enforce those guidelines when schedule pressure tempts teams to cut corners.

He illustrates the stakes with a concrete example: enterprises that failed to incorporate new device environments into their continuous integration pipelines early enough struggled to ship quality software when major platform updates arrived. The lesson is that a CI pipeline that only reflects today’s environment is not truly continuous — it is already out of date. Regularly expanding test coverage to include emerging platforms, devices, and dependencies is part of maintaining a resilient pipeline.

Practical steps that follow from this lesson:

• Treat market and platform changes (new OS versions, new device form factors, dependency updates) as predictable sources of disruption, not surprises.
• Build explicit checkpoints into each iteration to evaluate whether the pipeline still reflects the real target environment.
• Define escalation paths and rollback procedures before a release, not during an incident.
• Make sure management understands that mitigation planning is not pessimism — it is what separates teams that ship reliably from teams that scramble.

4. Outcomes Define Success — Not the Tools

Mirco Hering, APAC DevOps and agile lead, Accenture: “I wish I’d have known from the beginning that technology is not the only solution; success is defined by the outcome, not the way to get there. I, like so many, was initially focused on ‘how to become DevOps’ rather than using the ever-increasing tool belt of DevOps practices and tools to achieve business outcomes. As technologists, we are sometimes too focused on the next shiny object. If I had learned this lesson earlier in my career I think I would have avoided some of the more spectacular failures of projects that implemented a technology but still did not achieve success.”

Hering’s observation addresses one of the most persistent failure modes in DevOps adoption: treating DevOps as a destination defined by a particular tool stack rather than as a means to a business end. Teams can adopt containers, implement CI/CD pipelines, instrument their services with monitoring, and still fail to deliver meaningful value if none of those choices are tied to a clear understanding of what success looks like for the business.

The antidote is to start every initiative with a clear statement of the business outcome it is meant to improve — deployment frequency, lead time, customer satisfaction, incident recovery time — and then work backwards to the practices and tools that best support that outcome. When a new tool or practice is proposed, the first question should be: “Which of our target outcomes does this improve, and how will we measure that?”

Common Threads Across All Four Lessons

Reading these four perspectives together, several themes emerge that are worth naming explicitly:

• Culture precedes tooling. Every practitioner touched on the human dimension — tribal mentalities, organizational antibodies, management buy-in. Tooling choices matter, but they are secondary to getting people aligned.
• Start small, but plan for scale. Lighthouse implementations and small pilots reduce risk, but they need to be designed with an eye toward how the lessons will propagate across the organization.
• Executive support changes the physics. Without alignment at the leadership level, even successful local improvements tend to regress as the surrounding organization exerts pressure to return to familiar ways of working.
• Define success before you start. Agreeing on measurable outcomes at the outset keeps teams honest about whether their choices are actually delivering value or just generating activity.

These lessons are not new — they recur in DevOps literature, conference talks, and post-mortems year after year. The reason they keep appearing is that they are genuinely hard to internalize until you have experienced the consequences of ignoring them. Treat them as warnings worth heeding before you learn them the hard way.

Original quotes sourced from enterprisersproject.com. Attribution has been preserved as it appeared in the original article.

The rapid adoption of cloud computing has triggered a fundamental shift in how software is developed, packaged, deployed, updated, and retired. Multi-cloud architectures created powerful use cases for containers, and technologies like Kubernetes emerged to orchestrate those containers at scale. Developers now build cloud-native software using service-oriented architectures, decomposing applications into micro-services that can scale independently to handle massive loads.

These changes also drove a rethinking of team culture and process — the core of the DevOps movement — merging development and operations disciplines to enable rapid, reliable software delivery. A new generation of tools supports that mission, spanning infrastructure configuration management, code repositories, release automation, continuous integration and delivery (CI/CD), team collaboration, and service meshes.

Below are ten tools that gained significant traction in the DevOps ecosystem. While some details reflect their state circa 2018, each tool remains relevant and has continued to evolve.

1. XL Deploy (XebiaLabs)

XebiaLabs built a comprehensive DevOps platform focused on intelligence, automation, and control of continuous delivery pipelines at enterprise scale. XL Deploy specifically addresses one of the harder problems in large organisations: reliably propagating software changes across heterogeneous environments — legacy on-premises systems, private clouds, and public clouds simultaneously.

Key capabilities include:

• A visual deployment dashboard for tracking rollouts in real time
• Built-in analytics, security controls, and audit trails
• Support for deploying both containerised workloads and traditional virtual machine packages
• Integrations with major CI servers and cloud platforms

XL Deploy is particularly valued by enterprises that need governance and traceability around production deployments without sacrificing deployment velocity.

2. GitLab

GitLab provides a self-hostable or SaaS Git repository combined with a full DevOps platform spanning the entire application lifecycle. Both the open-source (Community Edition) and commercial (Enterprise Edition) versions include:

• Version control with merge request workflows
• Issue tracking and kanban boards
• Code review with inline comments
• Built-in CI/CD pipelines (GitLab CI)
• Container registry and package registry
• Security scanning (SAST, DAST, dependency scanning)

The “single application” philosophy — where source control, CI/CD, and monitoring live in the same tool — reduces context switching and integration complexity for engineering teams. GitLab saw notable migration interest following Microsoft’s 2018 acquisition of GitHub, though both platforms have since continued to grow.

3. Envoy Proxy

Envoy was originally developed at Lyft to handle the networking complexity of their micro-services architecture at ride-sharing scale. It is now a graduated project under the Cloud Native Computing Foundation (CNCF). Envoy operates as an L4/L7 proxy and forms the data plane for many service mesh implementations.

Core features include:

• Automatic service discovery
• Advanced load balancing (round robin, least request, zone-aware)
• Circuit breaking and retry policies
• Distributed tracing and rich observability metrics
• TLS termination and mutual TLS (mTLS)
• gRPC and HTTP/2 support

Envoy is commonly deployed as a sidecar proxy alongside each micro-service instance, abstracting all network communication from application code. It underpins service meshes including Istio and AWS App Mesh.

4. HashiCorp Consul

Consul from HashiCorp began as a service discovery and distributed key-value configuration tool. It was later expanded into a full service mesh solution with the addition of network segmentation capabilities, enabling secure service-to-service communication across complex environments.

Consul’s primary capabilities include:

• Service registration and health checking
• DNS and HTTP-based service discovery
• Distributed key-value store for configuration
• Automatic mTLS encryption between services (via Connect)
• Identity-based authorisation using service intentions
• Support for containers, VMs, and serverless workloads

Consul is available in open-source and enterprise editions and integrates naturally with other HashiCorp tools such as Vault (secrets management) and Terraform (infrastructure provisioning).

Note: The original source mentions “automatic TLC encryption” — this appears to be a typo for TLS (Transport Layer Security).

5. Netflix OSS

Netflix open-sourced a suite of tools and frameworks that emerged from solving the extreme scalability and reliability challenges of streaming video to hundreds of millions of users. Collectively known as Netflix OSS, these components address common distributed systems problems:

• Eureka — Client-side service discovery and registration
• Hystrix — Circuit breaker library for fault tolerance (now in maintenance mode; Resilience4j is the recommended successor)
• Zuul — Edge service / API gateway for dynamic routing
• Archaius — Dynamic configuration management library
• Ribbon — Client-side load balancing

Many of these components were incorporated into the Spring Cloud framework, making the Netflix patterns accessible to the broader Java enterprise community. Teams building distributed systems with Spring Boot could adopt battle-tested Netflix infrastructure patterns with minimal configuration.

6. BOSH

BOSH is an open-source tool chain for release engineering, deployment, lifecycle management, and monitoring of distributed systems. Originally developed by VMware for Cloud Foundry deployments, BOSH has since been adopted more broadly for managing complex software deployments at scale.

BOSH introduces several key concepts:

• Stemcells — Versioned, minimal OS images used as the base for VMs
• Releases — Versioned packages of source code, scripts, and configuration
• Deployment manifests — YAML files declaring the desired state of an environment

BOSH supports deployments on AWS, Google Compute Engine, Microsoft Azure, VMware vSphere, OpenStack, and CloudStack. It handles both Linux and Windows environments and is capable of managing rolling upgrades, health monitoring, and automatic VM resurrection.

7. Istio

Istio is an open-source service mesh that layers observability, traffic management, and security on top of existing micro-services without requiring changes to application code. It was developed collaboratively by Google, IBM, and Lyft, with contributions from Cisco, Pivotal, Red Hat, and others.

Istio typically uses Envoy as its data plane proxy and provides a control plane that manages:

• Fine-grained traffic routing (canary releases, A/B testing, traffic mirroring)
• Load balancing and circuit breaking
• Mutual TLS for service-to-service authentication
• Role-based access control (RBAC) policies
• Distributed tracing, metrics collection, and access logging

Istio 1.0 was released in mid-2018, marking it as production-ready. Subsequent versions significantly simplified the control plane architecture. Istio is now a CNCF graduated project.

8. Drone CI

Drone is a container-native CI/CD platform where every pipeline step runs inside a Docker container. This design ensures build environment consistency and strong isolation between jobs — issues that plagued earlier CI systems running builds directly on shared agents.

Key characteristics of Drone:

• Pipelines defined in a .drone.yml file stored in the repository (pipeline-as-code)
• Every build step runs in an isolated, ephemeral Docker container
• A plugin ecosystem where each plugin is itself a Docker image
• Supports multiple source control providers (GitHub, GitLab, Gitea, Bitbucket)
• Cloud-native horizontal scaling of build runners

Drone’s architecture makes it straightforward to self-host and scale, which appeals to teams that want full control over their CI infrastructure without the overhead of managing a Jenkins cluster.

9. Helm

Helm is the de facto package manager for Kubernetes. It addresses a core operational challenge: deploying and managing complex applications on Kubernetes requires coordinating many YAML manifests across multiple resource types. Helm simplifies this with a packaging format called charts.

A Helm chart is a collection of templated Kubernetes manifests, a Chart.yaml metadata file, and a values.yaml file containing default configuration. Charts can be versioned, shared via repositories, and installed with a single command:

helm install my-release stable/nginx-ingress

Helm capabilities include:

• Templated manifests with override values per environment
• Upgrade and rollback of releases
• Dependency management between charts
• Hooks for pre- and post-install/upgrade jobs

Helm is now a CNCF graduated project. Major contributors include Microsoft, Google, and Bitnami (now part of VMware). Helm 3, released after the original article’s publication date, removed the server-side Tiller component, addressing previous security concerns around cluster-wide permissions.

10. Jira

DevOps is as much about culture and collaboration as it is about tooling. Atlassian’s Jira is the issue and project tracking tool most widely adopted by agile software teams, making it a common backbone for DevOps workflows.

Jira supports DevOps teams through:

• Sprint planning with story point estimation
• Kanban boards for visualising work in progress
• Bug and incident tracking linked to code commits
• Customisable workflows reflecting real team processes
• Release tracking and version management
• Real-time burndown charts and velocity reporting
• Deep integrations with Bitbucket, GitHub, GitLab, and CI/CD tools

The ability to link Jira issues directly to branches, commits, pull requests, and deployments gives teams end-to-end traceability from business requirement to production release — a key DevOps capability.

Choosing the Right Tools for Your Stack

No single tool solves all DevOps challenges. Effective toolchains are assembled based on team size, existing infrastructure, target environments, and organisational maturity. The tools above often work together: GitLab drives commits that trigger Drone pipelines, Helm deploys artefacts to Kubernetes clusters managed by BOSH or similar, Consul or Istio handles service communication, and Jira tracks the work throughout.

When evaluating any DevOps tool, consider:

• Community and ecosystem health — Active CNCF projects and large contributor bases reduce long-term risk
• Operational overhead — Self-hosted tools require dedicated maintenance capacity
• Integration surface — How well does the tool fit into your existing pipeline?
• Security posture — Does the tool support secrets management, RBAC, and audit logging?
• Open-source vs. commercial licensing — Understand what capabilities are gated behind paid tiers

The DevOps tooling landscape continues to evolve rapidly. Staying current with CNCF project statuses, vendor release notes, and community benchmarks is essential for making sound architectural decisions.

Speed Without Quality Is a Race to the Bottom

One of the most common mistakes organizations make when adopting DevOps is treating it purely as a velocity play. They invest in CI/CD pipelines, containerization, and automation—and then discover that shipping faster simply means shipping broken software faster. A Forrester study commissioned by Tricentis examined 94 quality metrics across four categories and found that for automation to deliver real value in a DevOps context, teams must track quality throughout every stage of development and deployment.

Clark Golestani, managing director of C Sensei Group, put it plainly: “Organizations adopt DevOps to accelerate the delivery of innovative software that creates positive user experiences. If you start accelerating delivery without also rethinking your approach to quality, you will end up rapidly delivering updates that drive your customers to competitors.”

The research also highlighted a distinction in how DevOps leaders approach measurement. Some focus on contextual metrics—which tie quality signals to business outcomes—while others rely on counting metrics, such as defect counts or test pass rates. Similarly, some teams measure user experience across an end-to-end journey, while others focus on application-specific interactions. Understanding which approach fits your organization’s maturity and risk profile is itself a leadership skill.

5 Practices That Define Effective DevOps Leaders

Whether you are establishing yourself as a DevOps leader or looking to sharpen your existing practice, these five disciplines are central to delivering quality at the pace DevOps demands.

1. Allocate Proper Testing Budgets and Continuously Upgrade Testing Skills

Testing is frequently underfunded relative to development, and that imbalance compounds as release frequency increases. DevOps leaders treat test engineering as a first-class investment—both in tooling and in people. This means budgeting for test infrastructure, allocating time for engineers to learn modern testing frameworks, and recognizing that test automation is skilled engineering work, not a checkbox activity.

2. Implement Continuous Testing to Support Continuous Delivery

Continuous testing means integrating automated tests at every stage of the pipeline—not just at the end before a release gate. When tests run continuously alongside development, teams get immediate feedback on regressions, integration failures, and performance degradation. This is what allows continuous delivery to be a reality rather than a goal. Without continuous testing, a CD pipeline is simply a fast path to production incidents.

3. Embed Testers Within Integrated Delivery Teams

The traditional model of a separate QA team that receives a build at the end of a sprint is incompatible with DevOps cadences. Effective DevOps leaders embed testers—or engineers with strong testing skills—directly into cross-functional delivery teams. When testers participate in sprint planning, story grooming, and design discussions, quality considerations surface early, before they become expensive defects.

4. Automate End-to-End Functional Testing

Unit and integration tests catch many problems, but they do not validate that a complete user journey works as intended. End-to-end functional tests simulate real user interactions across multiple services and interfaces, exposing issues that lower-level tests miss. Automating these tests—and running them as part of the pipeline—ensures that deployment velocity does not come at the cost of user-facing reliability.

5. Shift Testing Left in the Development Lifecycle

“Shift left” means moving testing activities earlier in the development process—ideally beginning at the requirements and design phase. When teams write testable requirements, define acceptance criteria before coding begins, and run tests in development environments rather than waiting for staging, defects are found when they are cheapest to fix. Shift-left testing also changes the culture: quality becomes everyone’s responsibility, not something that happens after the fact.

Understanding Business Risk Is Non-Negotiable

The Forrester research emphasized that successful DevOps leaders understand the business risks associated with both DevOps and Agile adoption. Accelerated delivery pipelines introduce new failure modes—automated deployments can propagate bad code to production faster than any manual process could. Leaders who understand this risk landscape can design appropriate quality gates, rollback strategies, feature flags, and monitoring approaches that mitigate exposure without strangling delivery speed.

Every automated software delivery carries the potential for a negative user experience. The difference between organizations that manage this risk and those that are caught off guard is usually the maturity of their testing practice and the business awareness of their technical leaders.

Expanding Your Skillset as a DevOps Practitioner

Beyond implementing these five practices, DevOps leaders should actively work to broaden their skills across the quality, security, and observability domains. Understanding how to instrument applications for monitoring, how to interpret production telemetry, and how to design systems that fail gracefully are all capabilities that distinguish effective DevOps leaders from those who simply manage pipelines. The goal is not just faster software—it is better software, delivered sustainably.

DevOps Is About People, Not Just Tools

Much of the conversation around DevOps centres on the tools, technologies, and platforms that help teams deliver software faster and more reliably. CI/CD pipelines, infrastructure-as-code, container orchestration — these dominate the conference circuit and vendor marketing. But at its core, DevOps is about getting people to work together more effectively and efficiently.

That shift is harder than it sounds. DevOps replaces the linear, stage-gated waterfall model with a continuous, iterative workflow. Releases are frequent, priorities change quickly, and the idea of a “finished” product gives way to ongoing delivery. In this environment, coordination between teams cannot be an afterthought — it has to be built into the culture from the start.

Collaboration as a First-Class Concern

Some leading DevOps practitioners argue that collaboration deserves equal standing alongside automation and scale when designing working environments. The analogy offered by BMC’s Chris Scruggs is instructive: just as an orchestrated piece of music creates order out of chaos by coordinating the role of each individual note, collaboration ensures that each step in a complex application lifecycle serves the broader business goal.

Even a seemingly straightforward task — migrating a legacy application to the cloud — requires tight coordination between multiple systems, platforms, and managers across different teams. Without deliberate collaboration, that coordination breaks down at the seams between groups.

The Concept of Ba: A Framework for Collaborative Culture

Uniting cross-functional teams — each with its own priorities, histories, and ingrained problem-solving approaches — is arguably the most difficult challenge in building a DevOps culture. Success is rarely total, in part because organisations rarely define what success actually looks like.

CA Technologies’ Mick Adcock advocates building collaboration around the Japanese philosophical concept of ba — loosely translated as a shared space for emerging relationships. Applied to DevOps, this philosophy emphasises:

• Trust between individuals and teams
• Knowledge sharing across functional boundaries
• Cross-pollination of ideas and practices between development, operations, QA, and the business
• Treating the business itself as the system being developed, rather than just the software
• A culture that encourages shared responsibility and experimentation

This framing moves the conversation away from org-chart restructuring and toward building the kinds of relationships and trust that enable genuine collaboration over time.

BizDevOps: Bridging the Business–IT Gap

Collaboration is not just a DevOps concern — it is often the deciding factor in whether any IT project succeeds. According to IDC estimates cited in the source material, roughly one-third of all IT projects fail outright, with many more salvaged only through significant additional effort.

A key cause of failure is the disconnect between what the business expects and what development and operations can realistically deliver. Mendix technology evangelist Nick Ford argues that closing this gap — by genuinely bringing business stakeholders into the delivery process — is one of the most impactful things an organisation can do. He refers to this as BizDevOps: an extension of DevOps that explicitly includes business teams as active participants rather than downstream consumers of software.

In practice, this means:

• Business stakeholders participate in sprint planning and backlog prioritisation
• Product owners translate business requirements into actionable development work
• Teams share visibility into deployment pipelines and production metrics
• Feedback loops connect end-user behaviour directly back to development priorities

Why Tooling Alone Won’t Fix Collaboration Problems

One of the biggest risks in any DevOps transformation is treating it as a magic bullet — the assumption that deploying the right tools will automatically dissolve long-standing friction between teams. Patrick Turner, CTO of technology consulting firm Small Footprint, warns that the deep-rooted conflicts between development, testing, QA, and operations often persist even after advanced collaboration platforms are in place.

Standardising collaborative practices helps, but it is not sufficient if standardisation leads to stasis or redundant process. The spirit of DevOps is to continuously pursue better ways of working — which sometimes means deliberately challenging established norms, not just codifying them in a new format.

Collaboration Cannot Be Fully Measured — But It Can Be Cultivated

Unlike deployment frequency or mean time to recovery, collaboration resists direct measurement. You cannot put a number on the quality of a conversation between a developer and an operations engineer, or quantify the degree of trust between a product team and its business stakeholders. Satisfaction surveys among team members, users, and stakeholders can offer a proxy, but they are inherently limited.

What is clear is that DevOps does not work effectively without it. The tools enable the process; the culture sustains it. The most technically sophisticated pipeline in the world will underperform if the people running it are working in silos, protecting their own domains, or communicating defensively.

The difference between teams that talk to one another and teams that talk at one another is not a small one. It is often the difference between a DevOps transformation that delivers real business value and one that simply rearranges the org chart while leaving the same underlying friction in place.

Key Takeaways

• DevOps is fundamentally a people and culture challenge, not just a tooling challenge.
• Collaboration should be treated with the same strategic importance as automation and scale.
• Frameworks like ba offer a principled way to build trust and knowledge-sharing across teams.
• BizDevOps — including business stakeholders as active participants — addresses one of the most common causes of project failure.
• Tools support collaboration but cannot replace the cultural conditions that make it genuine.
• Continuous improvement requires deliberately questioning established norms, not just standardising them.

Introduction: DevOps Velocity Without Security Maturity

In the face of relentless competitive pressure, organisations increasingly adopted DevOps to improve delivery speed and operational efficiency. But many of those same organisations failed to invest proportionally in the security practices, tooling, and talent needed to protect their new automated workflows. The result: faster delivery of potentially vulnerable software, with credentials, secrets, and privileged access scattered across repositories, scripts, and pipeline configurations.

Drawing on incidents and threat landscape data from 2017, three security trends emerged that every DevOps engineering team needed to understand heading into 2018—and that remain directly relevant today.

Trend 1: Credential Sprawl in Source Repositories Is a Systemic Risk

The Uber Breach as a Warning Sign

The 2017 Uber data breach exposed personal data belonging to approximately 57 million customers and drivers. Investigators found that Uber developers had stored credentials in a software repository using an informal workaround—one that gave attackers access to privileged cloud storage accounts. The breach was not the result of a sophisticated exploit; it was the result of developers working around a process that had no convenient, secure alternative.

This pattern is not unique to Uber. Developers are accountable for features and functionality, not for designing secure credential management workflows. When organisations provide no standard, developer-friendly way to handle secrets, individuals improvise—and those improvisations create exploitable gaps.

The Underlying Problem: No Standard for Secure Collaboration on Secrets

At the time, a significant proportion of organisations surveyed in threat landscape research could not identify all the locations where credentials were stored across their environments—including informal workarounds in repositories and configuration files. Many organisations also lacked any documented strategy for managing privileged account security within DevOps pipelines specifically.

The same research found that roughly half of organisations did not fully disclose to affected customers when personal data was compromised in a cyber attack, compounding the breach’s damage to consumer trust.

What Good Looks Like: Secrets Management Integration

The solution is not to retrain every developer as a security engineer—it is to make secure practices the path of least resistance. This means:

• Integrating dedicated secrets management tools (such as HashiCorp Vault or cloud-native equivalents) directly into CI/CD pipelines.
• Enforcing pre-commit hooks or repository scanning to detect accidentally committed credentials before they reach version control.
• Providing developers with clearly documented, easy-to-use workflows for credential injection at runtime rather than at rest in configuration files.
• Rotating credentials automatically so that any exposure has a bounded blast radius.

Security embedded in the developer experience is far more effective than security bolted on after the fact.

Trend 2: DevSecOps Is a Distinct Discipline—and the Talent Gap Is Real

The Problem With Assigning Security to DevOps Teams by Default

Many organisations responded to growing security concerns by assigning security responsibilities to existing DevOps practitioners—engineers who were already fully occupied with pipeline reliability, infrastructure automation, and release velocity. This approach treats security as an additive responsibility rather than a dedicated function, and it consistently produces gaps.

DevOps practitioners are expert in the tooling and workflows of continuous delivery. They are not, by default, expert in threat modelling, access control design, audit log review, or privileged identity governance. Asking one group to fully own both domains without additional time, training, or headcount is a structural problem, not a skills problem.

What DevSecOps Practitioners Actually Do

A DevSecOps engineer sits at the intersection of software delivery and security engineering. Their responsibilities typically include:

• Embedding security controls—static analysis, dependency scanning, secrets detection—as gates in CI/CD pipelines.
• Designing and maintaining identity and access management (IAM) policies for both human operators and automated systems (machine identities).
• Performing threat modelling on pipeline architectures and automated workflows.
• Monitoring runtime behaviour of containerised workloads and detecting anomalous access patterns.
• Owning the privileged access management (PAM) strategy for pipeline service accounts, deployment keys, and API tokens.

This is a full-time role. Organisations that treat it as a part-time addition to an existing job description will continue to accumulate unmanaged risk.

Addressing the Talent Gap Practically

Given the genuine scarcity of professionals with deep competency in both DevOps tooling and security engineering, organisations need to invest in upskilling existing staff, establishing clear security champions within teams, and using automated tooling to enforce policy rather than relying solely on human vigilance.

Trend 3: Least Privilege Must Extend to Machine Identities

The Identity Problem in Highly Automated Environments

The principle of least privilege—granting any actor only the permissions required to perform its defined function—is well established for human users. In 2018, organisations were only beginning to apply it systematically to the non-human actors in their environments: virtual machines, containers, pipeline agents, deployment scripts, and orchestration platforms.

Modern DevOps environments are composed of dozens of interacting components, each of which may hold credentials or tokens granting access to production systems. There was no common standard for machine identity, access control, or audit across this stack. Each layer—VM, container runtime, orchestrator, artifact registry, cloud API—could represent the weakest link in an otherwise carefully managed environment.

Applying Human IAM Concepts to Machines

The practical application of least privilege to machine identities requires asking the same questions used in human access reviews:

• Who are you? — Does this machine identity have a verified, auditable identity? Is it using a short-lived certificate or a long-lived static credential?
• What are you? — Is this a pipeline agent, a microservice, a scheduled job? The role should define the permission scope.
• What are you asking for? — Is this request consistent with the expected behaviour of this identity at this point in the workflow? Anomalies should trigger alerts.

Applying these controls consistently—using workload identity federation, short-lived tokens, just-in-time access provisioning, and continuous audit—reduces the blast radius of any single compromised component.

The Toolchain Is Also an Attack Surface

A critical insight from the 2017–2018 period is that the DevOps toolchain itself—the very tools used to build and deploy software—is part of the attack surface. Compromising a single tool in the pipeline can yield access to the systems that tool is authorised to reach. A phishing attack or credential theft targeting a pipeline agent, deployment key, or CI server can cascade into full production access.

This means that security reviews must include the pipeline and its components, not only the application being delivered through it. Tools such as Terraform, Ansible, and GitHub Actions are not security tools in themselves—they are high-privilege actors that require the same access governance applied to any other privileged system.

What DevOps Practitioners Often Miss

A useful diagnostic exercise is to ask a DevOps engineer which security tools they use. A typical answer names the automation and infrastructure tools in their stack: Terraform, GitHub, Ansible, Kubernetes. These are delivery tools, not security controls—though they can be configured with security in mind.

What is often absent from that answer is any mention of access control, privileged identity management, secrets rotation, audit logging, or anomaly detection. These are the controls that govern who and what can reach sensitive systems—and they are frequently outside the scope that DevOps practitioners consider their security responsibility.

Closing that gap requires organisational clarity about who owns each security domain, tooling that enforces controls without requiring developers to become security specialists, and a shared understanding that the pipeline is as important to protect as the application it delivers.

Summary

These challenges did not disappear after 2018. Credential mismanagement, understaffed security functions, and ungoverned machine identities remain among the most commonly exploited weaknesses in modern software delivery environments. The principles outlined here—embed security in developer workflows, define clear ownership, and apply least privilege to every actor in the pipeline—are as applicable now as they were when these trends first emerged.

Enterprise DevOps: Past Barriers, Lasting Lessons

When analysts began calling a watershed moment the “year of enterprise DevOps,” survey data suggested roughly half of organizations had implemented some form of DevOps practice. Yet having a DevOps initiative underway is very different from having one that is mature, scaled, and delivering measurable business value. The barriers to meaningful adoption were — and in many organizations still are — real and varied.

The ten barriers outlined below were compiled from practitioner conversations spanning organizations at every stage of DevOps maturity, from early explorers to teams already attempting to scale. Understanding these barriers as a ranked list provides a useful diagnostic framework regardless of what year you are reading this.

The 10 DevOps Barriers, Ranked

10. Executive Buy-In

The barrier: Securing support, resource alignment, and budget commitment from senior leadership has historically been one of the first walls DevOps practitioners hit. Without executive sponsorship, DevOps efforts remain isolated, underfunded, and at risk of being deprioritized.

The trend: As IT-related initiatives climbed in priority among CEOs — with technology investment ranked among the top business priorities in Gartner surveys — DevOps initiatives that demonstrably balance agility with risk management gained a clearer path to C-suite support. The key accelerator: proactively educating business stakeholders using business outcomes language, not engineering jargon. Top-down sponsored DevOps programs became increasingly common as the practice matured.

9. Fragmented Toolchain

The barrier: The DevOps ecosystem grew rapidly, producing a sprawl of open-source and commercial tools that often did not integrate cleanly. Teams accumulated overlapping tools for CI, CD, monitoring, and configuration management, creating inconsistency across teams and slowing standardization.

The trend: Toolchain consolidation is a multi-year process. Governance frameworks and platform engineering practices have since helped organizations rationalize their toolsets, but fragmentation remains a real challenge for large enterprises with distributed teams and multiple lines of business.

8. Budget Allocation

The barrier: A common misconception — that DevOps was essentially free because many tools are open source — led to chronic under-budgeting. In practice, enterprise-grade support, skilled engineers, and the cost of non-standardized adoption added up quickly.

The trend: As organizations gained experience, the true cost of DevOps became clearer. Mature programs began budgeting explicitly for tooling support contracts, training, and deliberate experimentation — including the cost of controlled failure. Recognizing that “open source” does not mean “free at enterprise scale” is a prerequisite for realistic planning.

7. Skills Gaps

The barrier: DevOps expertise was scarce and often treated as a floating consultant overlay rather than an embedded organizational capability. Infrastructure and operations professionals needed structured upskilling, but training programs were inconsistent.

The trend: Structured training programs, standardized blueprints, and common toolsets began normalizing DevOps competency development. The emergence of internal DevOps champions — engineers who advocate for and teach practices across teams — proved effective. Specialized roles such as NetOps and ITOps developed focused DevOps literacy tracks. This barrier lowers over time but does not disappear entirely.

6. Application Complexity

The barrier: Legacy monolithic and three-tier applications are difficult to deploy using modern CI/CD pipelines. Application modernization — breaking monoliths into services, migrating to cloud-native architectures — is a prerequisite for many DevOps patterns, yet it is a massive undertaking.

The trend: Application modernization is a decade-long initiative at most large enterprises. DevOps practices themselves accelerate modernization by improving feedback loops and enabling incremental refactoring. Progress is real but necessarily gradual.

5. No Formal DevOps Plan

The barrier: Many early DevOps efforts were grassroots, bottom-up movements disconnected from formal planning processes, measurable objectives, or business goals. Without a plan, DevOps remained a technical experiment rather than a strategic capability.

The trend: As DevOps became mainstream, organizations began attaching it to formal program management structures — with budget, staffing, roadmaps, and KPIs tied to measurable business outcomes. Treating DevOps as a program, not a project, changes its trajectory significantly.

4. Managing Environment Complexity

The barrier: As applications became distributed across multi-cloud environments and accessed from diverse endpoints — including mobile and IoT — replicating and managing consistent environments across development, testing, and production became increasingly difficult.

The trend: Infrastructure-as-code, environment blueprinting, and sandbox automation addressed this directly. Automating the creation and teardown of environment replicas within CI/CD pipelines reduces manual configuration drift, improves governance, and increases both team productivity and release velocity.

3. Legacy Infrastructure (Technical Debt)

The barrier: Brownfield deployments — existing production systems running on on-premises infrastructure with proprietary tools and manual processes — create significant friction for cloud-native DevOps patterns. Physical infrastructure rigidity, long provisioning cycles, and accumulated technical debt all slow adoption.

The trend: Infrastructure automation platforms and as-a-service models provide a bridge. Tools that span both legacy brownfield and modern greenfield environments allow organizations to introduce new workflows without forcing a disruptive “rip and replace” approach. Protecting existing investment while incrementally modernizing is the pragmatic path.

2. Test Automation

The barrier: Organizations often implemented CI/CD pipelines while treating test automation — and security — as afterthoughts. Manual, ad hoc testing becomes a bottleneck as deployment frequency increases, directly undermining the value of a fast pipeline.

The trend: Continuous testing emerged as a recognized, critical component of the CI/CD pipeline rather than a phase that follows development. Automated test environments, sandbox-based testing, and shift-left security practices help break the manual testing bottleneck, improving both quality and release velocity at scale.

1. Culture

The barrier: Consistently rated the number one barrier to DevOps adoption — especially in enterprise environments — culture encompasses the willingness to collaborate across silos, embrace shared responsibility, tolerate controlled risk-taking, and treat failure as a learning opportunity rather than a punishable event. “Business as usual” attitudes actively undermine DevOps transformation.

The trend: Culture change does not happen by accident. Enterprises that succeed treat cultural transformation as an explicit program deliverable, not a byproduct of deploying tools. Executive sponsorship, the deliberate selection and empowerment of DevOps champions, and collaborative toolsets together create the conditions for a sustainable shift — both top-down and bottom-up — that breaks functional silos and builds genuine shared ownership.

The Bigger Picture: DevOps as a Continuous Practice

Taken together, these ten barriers paint a picture of an organizational transformation that is neither quick nor simple. DevOps is not an on/off switch. It is a set of recursive learnings — each improvement informing the next — applied iteratively as an organization discovers the right mix of culture, process, and tooling for its specific context.

Several important implications follow from this framework:

• No two organizations share the same barrier profile. Size, industry, existing infrastructure, and organizational culture all shape which barriers are most acute.
• Tool adoption without cultural change yields limited results. The top-ranked barrier — culture — enables or constrains progress on every other barrier below it.
• Budget realism matters from the start. Underestimating the true cost of DevOps (tooling, talent, training, experimentation) sets programs up for failure.
• Expectation management prevents disillusionment. DevOps adoption follows a maturity curve. Overpromising early outcomes creates backlash that can derail programs before they deliver value.

Understanding these barriers — and the trends that reduce them — remains as relevant for organizations planning DevOps investments today as it was when this analysis was first published. The specifics of tooling evolve; the organizational and cultural dynamics change more slowly.

One language keeps surfacing as a cornerstone of that toolchain: Python. Understanding why requires looking at what DevOps engineers actually need from a programming language—and why Python delivers on those needs better than most alternatives.

Python as the Common Language of DevOps

A survey published by Packt (the “Skill Up” survey, originally referenced by JAXenter) found that Python ranked as the primary language used by professionals working in DevOps roles. Notably, Python also dominated across adjacent disciplines—web development, security, and data science—which highlights its adaptability across the full software delivery lifecycle.

For DevOps practitioners, this cross-domain relevance matters. DevOps engineers rarely work in a single problem space. On any given week they may be writing infrastructure automation, building internal tooling, parsing logs, or integrating third-party APIs. A language that travels well across those contexts reduces friction and cognitive overhead.

Why Python Works So Well for DevOps

1. Accessibility and a Shallow Learning Curve

DevOps culture encourages polyglotism—the ability to work comfortably across multiple languages and paradigms. Python’s clean, readable syntax makes it an excellent first scripting language for engineers who come from a systems or operations background rather than a traditional software development track. The low barrier to entry means teams can onboard quickly without sacrificing capability.

2. First-Class Scripting and Automation

Automation is the beating heart of DevOps. Python is, at its core, an exceptional scripting language. It handles file I/O, process management, HTTP requests, JSON parsing, and system calls with minimal boilerplate. Compared to Bash for complex tasks, Python offers far better error handling, data structures, and testability—while remaining significantly lighter-weight than Java or C# for quick operational scripts.

# Example: simple Python script to check HTTP endpoint health
import urllib.request
import sys

endpoints = [
    "https://api.example.com/health",
    "https://api.example.com/status",
]

for url in endpoints:
    try:
        response = urllib.request.urlopen(url, timeout=5)
        print(f"OK      {url} — HTTP {response.status}")
    except Exception as e:
        print(f"FAILED  {url} — {e}")
        sys.exit(1)

3. Deep Integration with Core DevOps Tools

Two of the most widely adopted configuration management and orchestration platforms—Ansible and SaltStack—are written in Python. This has practical consequences:

• Custom Ansible modules are written in Python. If you need to extend Ansible beyond its built-in library, knowing Python is non-negotiable.
• SaltStack’s entire extension model—custom execution modules, state modules, returners—is Python-native.
• Cloud SDKs for AWS (boto3), Google Cloud, and Azure all have mature, well-documented Python libraries.
• Tools like Fabric, Invoke, and Paramiko make remote execution and SSH automation straightforward in Python.

When the tools your team relies on are themselves Python-based, fluency in the language multiplies your ability to debug, extend, and contribute to those tools.

4. Syntax That Rewards Clarity

Python enforces readable code through significant whitespace and a philosophy that there should be one obvious way to do something. In an operational context—where on-call engineers may be reading unfamiliar code at 2 AM during an incident—this directness is not a stylistic preference; it’s a reliability feature. Code that reads clearly is code that can be understood, fixed, and handed off quickly.

Python vs. Ruby: A Practical Comparison

Ruby is the other language most frequently compared to Python in a DevOps context. Both languages are dynamically typed, both are interpreted, and both have been used to build significant DevOps tooling (Chef, for example, is Ruby-based). For many tasks, either language is a reasonable choice.

The divergence appears in philosophy and syntax. Ruby prioritizes elegance and expressiveness—there are typically many valid ways to accomplish the same task. Python prioritizes explicitness and clarity—the language actively discourages “magic” and implicit behavior. For DevOps scripting, where the cost of a subtle bug can be high and the author of a script may not be the person who debugs it, Python’s directness tends to win out in practice.

Python’s growing dominance in data science and machine learning has also expanded its ecosystem dramatically, which benefits DevOps engineers working on observability pipelines, log analysis, or ML-assisted operations (AIOps).

Python as a Stabilizing Force in the Toolchain

One of the less-discussed advantages of Python in a DevOps context is its role as a lingua franca across teams. When developers, SREs, data engineers, and security engineers all have working Python knowledge, cross-functional automation becomes easier to write, review, and maintain. Scripts don’t silently live in one person’s head; they become shared team assets.

That said, Python is not always the right answer. Shell scripting remains appropriate for simple, POSIX-dependent tasks. Go has become a serious alternative for building long-running services and CLIs (tools like Terraform and Kubernetes are Go-based). The principle holds: use the best tool for the job. It simply happens that for a wide range of DevOps jobs—automation scripts, cloud API interaction, configuration management extensions, and operational tooling—Python is consistently the best tool available.

Practical Starting Points

If you’re looking to deepen your Python skills specifically for DevOps work, focus on these areas:

• Standard library modules: subprocess, os, pathlib, argparse, logging, json, http.client
• Infrastructure automation: boto3 (AWS), google-cloud-*, azure-sdk, Ansible module development
• Testing your scripts: pytest with mocking via unittest.mock to keep automation reliable
• HTTP and API interaction: requests or the standard urllib for webhook integrations and REST API calls
• YAML and configuration parsing: pyyaml and tomllib for working with the configuration formats DevOps tools use natively

Python won’t solve every DevOps challenge on its own—no language does. But as a foundation for automation, a bridge between tools, and a common vocabulary across engineering teams, its place in the DevOps toolchain is well-earned and unlikely to diminish soon.

The Myth That DevOps Is Only for Startups

Despite a growing list of large organisations successfully adopting DevOps practices, a stubborn misconception persists in the enterprise world: that continuous delivery and DevOps transformation are achievable only by technology-native companies like Google, Amazon, and Facebook—not by large, complex organisations with decades of legacy infrastructure and regulatory burden.

Gene Kim, co-author of The DevOps Handbook, pushes back hard on this view. Speaking to Computer Weekly ahead of the DevOps Enterprise Summit in London (June 2017), Kim pointed to regulated industries—public sector bodies and financial services firms—as some of the most compelling proof points that DevOps can work at enterprise scale.

“If HM Revenue and Customs can do it, if Zurich Insurance and organisations like Allianz can do it—which are all organisations that have a reputation for being conservative—it just gives us more evidence that it really can be done.”

— Gene Kim, co-author, The DevOps Handbook

Kim noted that before he can even begin making the case for DevOps, enterprise leaders often pre-empt the conversation with objections: security, compliance requirements, change management processes, and entrenched legacy code are the most common. Yet organisations operating under government regulation and statutory restriction have managed to overcome precisely these barriers.

Common Enterprise Objections to DevOps

Resistance to DevOps in large organisations typically clusters around a predictable set of concerns:

• Security and compliance: Regulated industries worry that the speed of continuous delivery conflicts with audit trails and change-approval processes.
• Legacy systems: Monolithic architectures and decades-old codebases are seen as incompatible with modern CI/CD pipelines.
• Organisational complexity: Large enterprises have more stakeholders, more silos, and more entrenched processes than startups.
• Cultural inertia: Changing how developers and operations teams collaborate requires sustained leadership commitment.

John Willis, then Director of Ecosystem Development at Docker and a fellow co-author of The DevOps Handbook, acknowledged that enterprise practitioners who have succeeded with DevOps are often treated by peers as exceptions rather than examples to follow.

“People say things like: ‘It’s different for my company. You don’t know how hard it is, and I do. I really do.'”

— John Willis, co-author, The DevOps Handbook

How Scaremongering Puts CIOs Off DevOps

Willis identified a second major barrier: the way DevOps is marketed and sold to enterprise decision-makers. Aggressive sales pitches and over-the-top evangelism have caused many CIOs to become understandably cynical about the entire movement.

“I’ve watched a lot of sales people over the years, on calls I’ve done, and they’ll go into enterprises and say—after just 10 minutes of meeting them—you’re doing it all wrong and you need to stop now and do it this way instead.”

— John Willis

Few experienced IT leaders respond well to that approach, especially when it is paired with doom-laden predictions about being overtaken by competitors. Willis described a pattern he has observed repeatedly: every two years or so, a new technology or practice is declared existentially important, and those who don’t adopt it immediately are positioned as dangerously behind.

“I spoke to a large financial organisation the other day and five years ago they were told they had to use Puppet. The world would be doomed if they didn’t go to Puppet. Then they started hearing that if you don’t do DevOps, you’re doomed, and then they’re told a year or so later that if you’re not doing Docker, you’re horrible and should be thrown in jail.”

— John Willis

The practical consequence is that CIOs develop a healthy—sometimes excessive—scepticism toward any new IT practice, even one with genuine, demonstrated value like DevOps. Willis’s advice: look past the hype cycle and focus on peer organisations that have made measurable progress.

Are You Ever “Done” With DevOps?

A question that surfaces frequently among enterprise IT leaders is whether there is a defined finish line for DevOps adoption. Kim argues this framing misunderstands what continuous delivery and continuous improvement actually mean—there is no completion state, because the goal is ongoing capability-building, not a one-time project.

That said, Kim is clear that progress is both measurable and rewarded. He pointed to specific organisations—Capital One in the US, ITV and Barclays in the UK—as examples of enterprises that, while not at 100% DevOps adoption, have made enough progress that the leaders championing those efforts are being given greater organisational authority as a result.

“My prediction is they will continue to be elevated to influence the practices in as much of the organisation as possible, and they can share their experiences about how to foster these initiatives without getting fired, or having it killed by the more conservative elements within the organisation.”

— Gene Kim

External Forces Beyond IT’s Control

Willis raised an important and often overlooked point: even organisations that execute a DevOps transformation correctly can be derailed by macro-economic forces entirely outside IT’s influence. A retailer that builds excellent CI/CD pipelines and a strong DevOps culture can still struggle if the retail sector itself is under structural pressure.

“I get this pain in my heart when I see a company that does everything right, but then they get off tilt—not because of anything they’ve done with IT, but because of the economics of the business they’re in.”

— John Willis

Kim echoed this with a widely cited example: no IT transformation could have saved Blockbuster from the structural disruption caused by streaming services. Technology capability is a necessary but not sufficient condition for surviving disruption.

“No amount of technology could have saved Blockbusters. Maybe they could have found a way out, but technology in and of itself could not have saved Blockbusters.”

— Gene Kim

Why DevOps Still Matters for Large Enterprises

Despite the caveats, Kim’s broader argument is that DevOps capability is increasingly table-stakes for any established enterprise that wants to remain competitive. Large brands in any industry vertical face a growing number of smaller, more agile competitors who can iterate faster and deliver value to customers more efficiently.

The practical implication for enterprise IT leaders:

• Treat DevOps as a long-term capability investment, not a project with an end date.
• Look to peer organisations in similarly regulated or complex environments for credible proof points.
• Be sceptical of vendor-driven scaremongering, but don’t let that scepticism prevent genuine modernisation.
• Measure progress, reward the people driving it, and expand successful practices incrementally across the organisation.
• Recognise that IT transformation improves competitive agility but cannot compensate for fundamental business model problems.

The organisations that have made DevOps work at enterprise scale—in regulated financial services, government, and broadcasting—demonstrate that the barriers most commonly cited are real but not insurmountable. The challenge is sustained leadership commitment and a willingness to learn from those who have already made the journey.