This article is based on a commentary originally published on devops.com. The analysis and structure below are our own editorial rewrite for a DevOps engineering audience.
The Gap DevOps Was Supposed to Close
In theory, DevOps exists to bridge the cultural and operational divide between software developers and IT operations (ITOps) teams. Shared tooling, shared pipelines, shared responsibility — that is the promise. In practice, however, the conversation around DevOps culture often tilts heavily in one direction: ITOps engineers are encouraged to write more code, learn programming languages, and speak the language of developers, while comparatively little pressure flows the other way.
This asymmetry is not just a cultural nuisance. It is a structural problem that undermines the core goals of DevOps: faster, more reliable software delivery through genuine collaboration.
Why Developers Receive More Recognition Than ITOps
The IT industry — and broader society — tends to celebrate creators over maintainers. Software developers are frequently portrayed in popular media as near-magical problem solvers. Coding boot camps have proliferated across every major city. Developer salaries consistently rank among the highest in the technology sector.
ITOps engineers, whose core responsibilities include deploying, monitoring, patching, and sustaining production systems, receive comparatively little of that recognition. Help-desk and junior operations roles are often among the lowest-paid positions in IT. There are no boot camps specifically designed to train the next generation of infrastructure operators. No one is making prestige films about an engineer who prevented a production outage at 2 a.m. by applying the right kernel patch.
This is not a pattern unique to IT. Across many industries — architecture, automotive, construction — the people who design things are held in higher regard than the people who keep them running. Architects outrank roofers. Car designers outrank mechanics. The IT world simply mirrors a much wider social norm: creation is glamorous; maintenance is invisible.
DevOps Is Exacerbating the Problem
The cult of programming would likely exist with or without DevOps. What DevOps sometimes does, however, is give that bias a formal framework and a job description. Beneath a great deal of DevOps advocacy is an implicit assumption: if ITOps engineers just wrote more code, everything would be faster, higher quality, and easier to automate.
Infrastructure-as-Code tools, configuration management frameworks, and CI/CD pipelines are all valuable — but the way they are sometimes introduced to ITOps teams can feel less like empowerment and more like a requirement to become a developer or become irrelevant. The message, spoken or not, is often: learn to code or fall behind.
Contrast that with the expectation placed on developers. Very few DevOps advocates actively push developers to spend meaningful time provisioning infrastructure, responding to on-call incidents, or managing the operational health of systems in production. When that suggestion is made, it is often met with resistance — the argument being that requiring developers to perform operational tasks is a distraction from higher-value engineering work. There is a revealing double standard at work here.
The Risk: Erasing ITOps Expertise
The danger in this imbalance is not abstract. When organizations treat ITOps engineers purely as developers-in-waiting rather than domain experts in their own right, several things can go wrong:
- Loss of operational expertise: Deep knowledge of networking, storage, security patching, and system performance does not come from a coding boot camp. Devaluing that expertise means organizations lose institutional knowledge that is hard to replace.
- Morale and retention problems: Operations teams that feel undervalued or pushed toward roles they did not sign up for are more likely to leave. Turnover in ITOps can directly degrade system reliability.
- False confidence in automation: Automating operations tasks without the input of people who truly understand those tasks leads to brittle pipelines and missed failure modes. Good automation is built on operational expertise, not in spite of it.
- Shared responsibility becomes one-sided accountability: When incidents happen, the implicit bias toward blaming the operations side rather than the development side undermines psychological safety — a prerequisite for effective post-mortems and continuous improvement.
Where Workflow Automation Fits In
One of the most compelling arguments for workflow automation in DevOps is that it can reduce the need for either side — developers or ITOps — to become fluent in the other’s core discipline. Well-designed automation abstracts the operational complexity without requiring ITOps engineers to become software engineers, and without requiring developers to master infrastructure management.
For ITOps teams specifically, automation platforms can:
- Codify runbooks and operational procedures into repeatable, auditable workflows — without requiring deep programming knowledge.
- Integrate monitoring, alerting, and remediation into a single automated loop, reducing manual toil.
- Surface operational data in ways that make it easier for developers to understand and account for production constraints during design.
- Enable self-service infrastructure provisioning, freeing ITOps from repetitive tickets while maintaining guardrails and governance.
The key distinction is that workflow automation, when implemented correctly, should amplify ITOps expertise rather than replace it. The engineer who understands why a particular service requires a specific firewall rule or memory allocation is still the person who needs to design that automated check. The automation just executes it consistently and at scale.
Toward a More Equitable DevOps Culture
Sustainable DevOps practice requires genuine parity between development and operations — not just in tooling, but in culture, recognition, and organizational investment. That means:
- Recognizing operational work as engineering work. Designing a resilient deployment pipeline, writing runbooks, and maintaining production SLAs are engineering tasks that deserve the same organizational respect as feature development.
- Creating reciprocal expectations. If ITOps engineers are expected to understand code and pipelines, developers should be expected to understand — at least at a meaningful level — what happens to their software after it ships.
- Investing in ITOps career development on its own terms. Not every ITOps engineer needs to become a software developer. Organizations should create career paths that reward deep operational expertise alongside paths that reward cross-functional development skills.
- Measuring shared outcomes. Deployment frequency, change failure rate, mean time to recovery, and availability are team metrics, not individual metrics. Tying both developers and ITOps to shared reliability goals is a structural way to rebalance incentives.
The Bottom Line
The promise of DevOps was collaboration between equals. That promise is undercut when ITOps teams are implicitly asked to assimilate into development culture while developers remain largely insulated from operational concerns. Workflow automation has real potential to accelerate DevOps delivery — but only if it is built with ITOps expertise at the center, not as a mechanism for rendering that expertise redundant. Getting the culture right is a prerequisite for getting the automation right.