This article is based on commentary originally published on computerweekly.com, featuring insights from Chris Carlson, Vice President of Product Management at Qualys, a cloud security, compliance, and information services company.
DevOps Is More Than a Development Methodology
Every transformative process or technology goes through a hype cycle — complete with growing pains and vocal detractors — even as it becomes mainstream. DevOps is no exception. But according to Chris Carlson, the scope and potential impact of DevOps sets it apart from narrower methodologies like Agile.
Where Agile primarily addresses how development teams plan and execute work, DevOps spans a far wider organisational surface. Its influence reaches into:
- Operations — the most obvious extension, reflected in the name itself
- Business and competitive strategy — accelerating time-to-market as a strategic lever
- Financial planning — aligning release cycles with budget and investment decisions
- Product management and release planning — tighter feedback loops between roadmap and delivery
- Customer service — faster defect resolution and feature delivery
- HR and talent strategy — attracting engineers who value modern, collaborative workflows
This breadth is precisely what makes DevOps powerful — and what makes shallow, tool-first adoptions so likely to fail.
“Being Cool with DevOps” Is Not a Strategy
Carlson is direct on this point: adopting DevOps because it is fashionable or externally mandated — without genuine organisational buy-in — creates failure cases that unfairly discredit the approach itself. When a DevOps initiative collapses, the question should not be “does DevOps work?” but rather “was the cultural foundation actually in place?”
For DevOps to deliver sustained value, all stakeholders need to have genuinely committed to the approach. That means alignment across:
- Agreed-upon processes and tooling
- Shared metrics and monitoring standards
- Continuous feedback mechanisms
- A culture of incremental, ongoing improvement
Without these foundations, even well-resourced DevOps programmes struggle to sustain early wins.
Top-Down vs. Bottom-Up: Both Matter
A common assumption is that DevOps transformation must be driven by executive mandate. Carlson challenges this framing. Successful DevSecOps implementations can emerge from either direction:
- Top-down: Leadership defines the vision, funds the tooling, and sets expectations for cross-functional collaboration.
- Bottom-up: Practitioners identify friction points, experiment with improvements, and gradually shift team culture through demonstrated results.
Crucially, even top-down initiatives still require genuine cultural transformation to succeed long-term. An organisation can achieve an impressive first DevOps project without a cultural shift — but sustaining those results becomes significantly harder without one.
Tie DevOps Metrics to Business Outcomes
One of the more actionable points Carlson raises is the importance of grounding DevOps metrics in business strategy rather than engineering efficiency alone. A development team that reduces build times by 40% in isolation may save modest departmental costs — but a DevOps programme aligned to a business objective can drive measurable revenue growth and competitive differentiation.
The implication is clear: DevOps teams should be working closely with product management and business stakeholders to define success in terms that matter at the organisational level — not just deployment frequency or mean time to recovery in isolation.
Why DevOps Makes Security Harder — and Why DevSecOps Is the Answer
Perhaps the most critical technical point Carlson raises concerns information risk management. Traditional development models — even Agile ones still using waterfall release processes — preserve natural checkpoints where IT security teams can assess, evaluate, and approve code before it reaches production.
DevOps, by design, accelerates the path to production. This is its competitive advantage. But if security controls are not embedded in the pipeline itself, that speed can completely bypass security assessments — introducing vulnerabilities faster than any manual review process can catch them.
This is the core motivation behind DevSecOps: not slowing DevOps down to insert security gates, and not bolting security checks on after the fact, but integrating security into the people, processes, and tools of the DevOps workflow from the start. In practice, this means:
- Static application security testing (SAST) embedded in CI pipelines
- Dependency and container vulnerability scanning as part of build steps
- Infrastructure-as-code policy enforcement before deployment
- Automated compliance checks tied to release gates
- Security engineers participating in sprint planning and architecture reviews
The goal is to make security a shared responsibility across development and operations teams — not an external audit function that slows delivery.
Key Takeaways for DevOps Practitioners
- DevOps failure is rarely a technology problem — it is almost always a cultural or alignment problem.
- Sustainable DevOps requires buy-in across the entire organisation, not just engineering teams.
- Measure DevOps success against business outcomes, not just internal engineering metrics.
- The speed gains from DevOps create genuine security risks if security is treated as a separate, downstream concern.
- DevSecOps is not a constraint on DevOps — it is what makes DevOps safe to scale.
As organisations continue to mature their DevOps practices, the conversation is increasingly shifting from “how do we ship faster?” to “how do we ship faster and more securely, with measurable business impact?” That is a question DevSecOps is designed to answer.