Original research cited in this article was published by Seattle-based MSP 2nd Watch and reported by Channelnomics in June 2018.
Most Enterprises Are Still Not Practicing DevOps
Despite years of industry buzz, DevOps adoption among mid-to-large enterprises remains surprisingly low. A survey of more than 1,000 IT managers and directors — all from companies with at least 1,000 employees — conducted by Seattle-based managed service provider (MSP) 2nd Watch found that the vast majority of organizations are not structured for DevOps, and many are not even moving in that direction.
According to 2nd Watch EVP Jeff Aden, the data reflects a classic 80/20 split: just over 20 percent of respondents were genuinely leveraging DevOps practices. That leaves roughly 80 percent of the enterprise market operating in a way that is either incompatible with DevOps or only superficially adjacent to it.
What 2nd Watch Means by “True” DevOps
2nd Watch defines DevOps as the practice of operations and development engineers working together throughout a common service lifecycle — from application design through development, production, and ongoing support. Crucially, 2nd Watch distinguishes this cultural and organizational model from merely adopting individual tools or techniques.
In other words, using Terraform, Kubernetes, or a CI/CD pipeline does not automatically mean a team is practicing DevOps. The tooling has to be supported by integrated, cross-functional teams and shared ownership of the full application lifecycle.
Key Findings from the Survey
- 78% of respondents have separate, siloed teams for infrastructure/operations and application development — the organizational structure most antithetical to DevOps.
- ~60% are using infrastructure-as-code (IaC) tools such as Kubernetes, Terraform, or configuration management platforms — a positive signal, but not sufficient on its own to indicate DevOps maturity.
- 38% are still managing infrastructure manually, which 2nd Watch characterized as not only non-DevOps, but actively incompatible with any future DevOps adoption.
- ~75% perform some form of consistent testing when writing code — a practice that would support a DevOps pipeline if other structural elements were in place.
- 70% use some form of automated pipeline for application code deployment and management — another positive indicator for organizations looking to mature toward DevOps.
The Gap Between Tools and Culture
The survey data exposes a common misunderstanding: organizations often equate DevOps with specific tools rather than with the organizational model those tools are meant to support. You can instrument an entire CI/CD chain and still have operations and development functioning in separate silos with conflicting incentives, different on-call responsibilities, and no shared accountability for production systems.
The 38% who are still managing infrastructure manually present an even starker challenge. Without automated provisioning, repeatable infrastructure definitions, and version-controlled configuration, the foundational prerequisites for DevOps simply do not exist. These organizations face a multi-stage transformation — not just a cultural shift, but a technical one.
The MSP Opportunity — And the MSP Problem
The survey’s findings point to a significant commercial opportunity for managed service providers that can offer genuine DevOps enablement — not just cloud migration or infrastructure monitoring. As Aden explained in an interview with Channelnomics:
“It is a big opportunity for MSPs to provide a higher level of service and a value-add for clients. However, many traditional MSPs are not equipped or structured to provide these services to clients who are moving to the cloud because of old operating models and lack of skills.”
— Jeff Aden, EVP, 2nd Watch
The core tension is this: the very organizational patterns that make DevOps hard for enterprise customers — siloed subject-matter experts in networking, databases, storage, and compute — are also common inside traditional MSPs. An MSP built around ticket-based, reactive, domain-specific support is poorly positioned to offer the integrated, cross-functional services that DevOps engagements require.
What MSPs Need to Do Differently
To genuinely serve enterprises trying to adopt DevOps, MSPs need to rethink their own operating model. Based on the 2nd Watch analysis, this means:
- Cross-stack engineering capability: Engineers who understand the full technology stack — from infrastructure and networking to application deployment and observability — rather than domain-specific technicians.
- Integrated delivery teams: Internal teams that mirror the DevOps model, with shared ownership of outcomes rather than handoffs between departments.
- Automation-first service delivery: Using IaC, CI/CD pipelines, and automated testing as core delivery mechanisms, not optional add-ons.
- Advisory and enablement services: Moving beyond operational support to help customers build internal DevOps capability — training, process design, toolchain selection, and platform engineering.
Positive Signals to Build On
While the headline numbers are sobering, the survey does reveal meaningful foundations. The fact that 75% of organizations conduct consistent code testing and 70% use some form of automated deployment pipeline suggests that many enterprises already have the technical building blocks in place. What they often lack is the organizational restructuring, cultural alignment, and institutional knowledge to connect those tools into a genuine DevOps practice.
That gap — between having tools and knowing how to operate as a DevOps organization — is precisely where a well-positioned MSP can deliver lasting value. The 30% without any automated deployment pipeline will need more foundational investment, but the majority are reachable with targeted enablement.
Bottom Line
DevOps adoption in the enterprise remains substantially lower than the industry conversation might suggest. 2nd Watch’s research paints a picture of a market where tooling investment has outpaced organizational transformation, and where most companies lack the integrated team structures that define genuine DevOps. For MSPs willing to retool their own delivery models, this represents a high-value service opportunity — but only if they can credibly offer what their customers are missing: cross-functional expertise, automation maturity, and hands-on enablement at scale.