This article is based on a piece originally sourced from InformationWeek (c. 2016). The core arguments remain relevant to organizations evaluating DevOps adoption today.
DevOps — the practice of combining software development, testing, deployment, and operations into a unified, collaborative workflow — has become one of the most discussed topics in modern IT. With that discussion comes a predictable side effect: myths. Some of these myths discourage organizations from exploring DevOps at all; others lead teams to adopt it in ways that are unlikely to deliver real value.
Here are five of the most common DevOps myths, along with practical advice for thinking past them.
Myth 1: DevOps Is Only for a Certain Type of Engineer
A common narrative around DevOps paints it as a movement driven by a new breed of engineer — someone young, startup-flavored, and steeped in the latest tooling. The implication is that existing staff are unlikely candidates for DevOps roles, and that organizations need to hire fresh talent to make it work.
This framing misses the point entirely. Many experienced engineers already embody the DevOps mindset: they understand infrastructure deeply, write code fluently, and care about production resilience. The real barrier is rarely individual skill — it is the organizational structure that forces people into rigid silos, preventing cross-functional knowledge from being applied where it is most useful.
Practical advice: Before searching for DevOps talent externally, audit the skills already present in your teams. Look for operations engineers who think like developers and developers who understand operational concerns such as reliability, observability, and capacity. Pair that talent audit with an honest review of the cultural and structural constraints that may be stopping those skills from being used effectively.
Myth 2: DevOps Replaces All Existing Best Practices
A vocal segment of DevOps advocates treats the movement as a clean break from everything that came before. Frameworks such as ITIL and COBIT — which provide structured guidance on IT service management, governance, and change control — are sometimes dismissed as incompatible with the DevOps philosophy.
This is a false choice. DevOps is grounded in Agile thinking, continuous delivery, and rapid iteration. But the IT service management processes that support stability, auditability, and risk management do not disappear in a DevOps environment — if anything, they become more important as the pace of change increases. The goal is to make those processes leaner and more automated, not to abandon them.
Practical advice: Rather than asking whether DevOps competes with your existing frameworks, ask how they can complement each other. For example, change management processes can be streamlined and partially automated within a CI/CD pipeline without being eliminated. Service management disciplines such as incident management and problem management remain essential in a high-velocity delivery environment.
Myth 3: DevOps Is Primarily a Technology Problem
There is a large and growing ecosystem of tools associated with DevOps — infrastructure-as-code, configuration management, container orchestration, CI/CD platforms, application performance monitoring, and more. It is easy to conclude that adopting these tools is what DevOps means in practice.
But tooling without process improvement delivers limited value. Automating a broken workflow produces broken results faster. A team that ships frequently but ignores customer feedback, or that monitors production without acting on what it learns, is not practicing DevOps in any meaningful sense — it is just moving faster in the wrong direction.
Practical advice: Evaluate your current toolset not just for what each tool does in isolation, but for how it could support collaboration across teams. For instance, application performance monitoring is often treated as an operations-only tool — but giving developers access to the same data allows them to instrument code more thoughtfully, simulate performance behavior before production, and make more informed capacity decisions. Tools should serve collaborative workflows, not reinforce existing silos.
Also, build in feedback loops with real users. Accepting that a finished product may look significantly different from the original specification is not a failure of planning — it is a sign that the feedback loop is working.
Myth 4: Our Industry or Business Model Makes Us Immune
Organizations in government, manufacturing, or other traditionally non-software sectors sometimes conclude that DevOps principles simply do not apply to them. Some have outsourced IT operations entirely; others have no internal application development function. The reasoning goes: if we are not a software company, DevOps is not our concern.
This reasoning is increasingly hard to sustain. Across virtually every sector, software now mediates the customer experience, enables new business models, and differentiates products in the market. A consumer goods company that offers a connected device or a companion app is, in a meaningful sense, a software business — whether or not it identifies as one.
Practical advice: Start the conversation about DevOps from a business perspective, not an IT one. Ask how software — whether internally built, externally sourced, or embedded in products — affects your ability to serve customers and respond to market changes. The specific practices may vary depending on your delivery model, but the underlying principles of iteration, experimentation, and learning from failure apply broadly.
Myth 5: DevOps Will Automatically Transform Your Delivery Outcomes
The volume of DevOps success stories can create unrealistic expectations. It is tempting to treat DevOps as a silver bullet — a set of practices that, once adopted, will reliably improve delivery speed, quality, and team satisfaction.
The reality is more nuanced. Software project outcomes have remained stubbornly difficult to improve across the industry over many decades, and no methodology has fully resolved that challenge. DevOps provides tools and cultural patterns that can help — but only if the underlying conditions support them.
Practical advice: Before investing heavily in DevOps tooling or restructuring teams, examine the culture, incentive structures, and metrics that currently govern your engineering organization. If operations teams are historically rewarded for preventing releases rather than enabling them safely, no amount of automation will fix that tension. If developers have no exposure to how customers actually use the software they build, technical improvements alone will not close that gap.
DevOps, at its core, is a people and culture challenge. Technology and process changes are the mechanisms; the goal is a shared sense of responsibility for outcomes across development, operations, and the business.
Key Takeaways
- Skill exists in your current teams. Look for it before hiring for it.
- Existing frameworks are not the enemy. ITIL, COBIT, and similar bodies of work can coexist with and complement DevOps practices.
- Tools accelerate good process. Invest in tooling after you understand and improve the underlying workflows.
- Software relevance is nearly universal. Most organizations are affected by software quality and delivery speed, regardless of industry.
- Culture is the hardest and most important part. Incentive structures, team norms, and leadership behavior determine whether DevOps practices take hold.
Approaching DevOps with clear-eyed skepticism about these myths — rather than uncritical enthusiasm — is the best foundation for a transformation that actually delivers lasting value.