DevOps engineers are often described as the people who build deployment pipelines. That is part of the job, but it undersells it. Their real work is bridging the gap between the people who change software and the people who keep it running, so that a business can ship changes quickly without breaking what customers depend on. The pipelines, automation and cloud templates are tools for that goal, not the goal itself.

That raises a practical question for business and IT leaders: how do you know whether your DevOps investment is working? The most useful answer comes from a decade of research by the DORA program, now part of Google Cloud, which found that a small set of delivery metrics predicts both technical and organizational performance. This article explains what DevOps engineers do, how to measure it, and where the common traps are.

What a DevOps engineer actually bridges

In a traditional setup, developers write code and hand it to an operations team to deploy and run. Developers are rewarded for shipping features; operations is rewarded for stability. The handoff between them becomes a queue, releases get bigger and riskier, and each side blames the other when something breaks.

A DevOps engineer removes that queue by building shared systems both sides can trust:

• Continuous integration and delivery (CI/CD) pipelines that build, test and deploy every change the same way, every time.
• Infrastructure as code, using tools such as Terraform or the cloud providers’ own templates, so environments on AWS, Azure or Google Cloud are reproducible and reviewable rather than hand-built.
• Observability: logs, metrics and traces that let developers see how their code behaves in production, not just in testing.
• Security checks in the pipeline, the practice often called DevSecOps, so dependency scanning, secret detection and configuration policies run automatically on every change.

The cultural part matters as much as the tooling. Blameless post-incident reviews, shared on-call responsibilities and small, frequent changes are what turn automation into better outcomes. For a broader look at the role itself and how it developed, see The Rise of the DevOps Engineer.

Measuring DevOps: the DORA metrics

The DORA research program, whose early findings were summarized in the 2018 book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim, identified a small set of software delivery metrics. The current set, as documented by DORA, has five measures in two groups.

Throughput measures how quickly changes move:

• Change lead time: how long it takes a committed change to reach production.
• Deployment frequency: how often the team deploys to production.
• Failed deployment recovery time: how long it takes to recover when a deployment causes a failure. DORA renamed this from “mean time to recover” in 2023 to separate deployment failures from outages caused by external events.

Instability measures how often changes go wrong:

• Change fail rate: the share of deployments that cause a failure needing remediation.
• Deployment rework rate: the share of deployments that are unplanned fixes for problems in production, added by DORA in 2024.

The key finding across years of DORA research is that speed and stability are not a trade-off for well-run teams. The highest performers tend to deploy more often and fail less, because small, well-tested changes are easier to deploy, easier to diagnose and easier to roll back. That is the strongest argument for DevOps practices: they are not about moving fast at the cost of reliability.

Common traps when adopting DevOps

Renaming the operations team. Giving the existing sysadmins a new title without changing how development and operations work together produces a “DevOps team” that is simply the new handoff queue.

Tooling before practice. Buying a CI/CD platform does not help if releases are still large, infrequent and manually approved by a committee. The pipeline should encode an improved process, not automate a broken one.

Gaming the metrics. Any metric used as a target can be distorted. Deployment frequency can be inflated with trivial changes; change fail rate can be hidden by not recording incidents. Use the metrics to spot trends and start conversations, not to rank teams or individuals.

Assuming AI tools will fix delivery. DORA’s 2024 report found that increased AI adoption among respondents was associated with a small estimated decline in delivery throughput and a larger decline in delivery stability, even as individuals reported productivity gains. The researchers’ interpretation was that AI makes it easy to produce larger changes, and larger changes are riskier. The fundamentals of small batches and strong testing matter more, not less, when code is easier to generate.

Security as a late gate. A security review that only happens before a major release undermines everything else. Moving checks into the pipeline catches issues when they are cheapest to fix and keeps deployment frequent.

A practical starting plan

For a business beginning or restarting its DevOps journey, these steps give the best early return:

1. Baseline the metrics. Even rough numbers for lead time, deployment frequency, change fail rate and recovery time show where the biggest constraint is.
2. Put everything in version control. Application code, infrastructure definitions, configuration and pipeline definitions.
3. Automate one path to production. Pick one application and build a reliable pipeline with automated tests before expanding.
4. Make changes smaller. Break work into pieces that can be deployed independently, using feature flags where needed.
5. Add security scanning to the pipeline. Start with dependency and secret scanning, then add infrastructure policy checks.
6. Invest in observability and blameless reviews. Faster detection and honest learning from incidents drive down recovery time and repeat failures.

Frequently asked questions

Is DevOps a role or a culture?

Both. DevOps began as a set of cultural and technical practices, but in practice most organizations need people who specialize in building the platforms, pipelines and automation those practices depend on. The title works best when those engineers enable development teams rather than becoming a separate gatekeeper.

How is DevOps different from platform engineering or SRE?

They overlap. Site reliability engineering, which originated at Google, applies software engineering to operations with a focus on reliability targets. Platform engineering builds internal self-service platforms so developers can deploy without deep infrastructure knowledge. Both can be seen as specific ways of implementing DevOps principles.

Do small businesses benefit from DevOps?

Yes, often more than large ones. A small team cannot afford manual, error-prone deployments or long outages. A simple, reliable pipeline and infrastructure as code let a few people manage systems that would otherwise need many more.

Ship faster without breaking things

Delana Technologies helps businesses modernize delivery: CI/CD pipelines, infrastructure as code, cloud architecture and DevSecOps controls that satisfy auditors. Learn about our cloud modernization services and cybersecurity and compliance services, call 239.414.5126 or contact us.

---

Sources: DORA, “A history of DORA’s software delivery metrics” and “DORA’s software delivery performance metrics” (dora.dev); Google Cloud, 2024 Accelerate State of DevOps Report; Nicole Forsgren, Jez Humble and Gene Kim, Accelerate (IT Revolution, 2018).