Has DevOps Outgrown Being a Job Title?

Ask ten companies what a “DevOps Engineer” does and you’ll get ten different answers. In some places it means writing Terraform. In others it’s owning CI/CD pipelines, or managing Kubernetes clusters, or being the person developers throw tickets at when something doesn’t deploy. The title has become a catch-all — and in becoming everything, it’s started to mean nothing.

I’ve held variations of this title. I don’t use it to describe myself anymore.

Where It Started

DevOps emerged from a frustration. Development teams were shipping code; operations teams were responsible for running it. The wall between them created slow releases, blame culture, and systems that worked in dev but fell apart in production.

The response — championed by people like Patrick Debois and the Velocity conference talks of the late 2000s — wasn’t to create a new team. It was to change how existing teams worked. Break down the silos. Share ownership. Automate the repetitive stuff. Measure what matters. Ship faster, more safely.

These were practices and principles, not a role definition.

What Happened

The industry did what the industry always does: it turned a philosophy into a job title.

Suddenly organisations were hiring “DevOps Engineers” to sit between development and operations, and in doing so, recreated exactly the silo they were supposed to tear down. The DevOps team became the new operations team — except now they also wrote YAML.

The practices — continuous integration, infrastructure as code, observability, automated testing, blameless postmortems — got attributed to a person rather than embedded into how everyone works.

The Practices Live Everywhere Now

Here’s the thing: the practices didn’t die. They matured and spread across disciplines — and the job market is reflecting that shift in real time.

1. Platform Engineer

Platform engineers build Internal Developer Platforms (IDPs) that product teams use to ship faster. They don’t manage servers directly — they build the layer that makes servers invisible. The tools have moved well beyond shell scripts and Ansible: Backstage for developer portals, Crossplane for infrastructure abstraction, Kubernetes Operators and custom controllers for encoding operational knowledge. If you’re still hand-writing YAML for every team, you’re already behind this curve.

These are DevOps practices applied at scale, with engineering rigour. But the role isn’t called DevOps.

2. Cloud Platform Engineer

Companies now average 2.6 cloud providers. The Cloud Platform Engineer operates at the intersection of cloud architecture and the practices DevOps popularised — building infrastructure that spans AWS, Azure, and GCP rather than going deep on one. Multi-cloud IaC with Terraform or Pulumi, cross-cloud networking, cloud-agnostic patterns. One-cloud deep is no longer enough, and the demand for engineers who can think across providers reflects that.

3. Infrastructure Reliability Engineer

The evolution of SRE. This role combines reliability engineering with infrastructure automation and predictive observability — advanced Kubernetes, service mesh (Istio and Linkerd), chaos engineering, and increasingly AIOps for getting ahead of incidents rather than reacting to them. It’s everything the original SRE movement called for, pushed further by the complexity of modern distributed systems.

None of these are “DevOps Engineer.” All of them are built on DevOps thinking.

Security engineers now work in the same CI/CD pipelines, shifting left on vulnerability scanning and policy enforcement. Data engineers automate their own infrastructure. Backend engineers own their services in production. The practices have permeated.

DevOps worked. It just didn’t work by creating a “DevOps Engineer” — it worked by influencing how every engineer thinks about their job.

I’m Just an Engineer

I don’t call myself a DevOps Engineer because the label doesn’t describe what I actually do, and more importantly, it carries baggage about where responsibility sits.

When I work on internal platforms, I’m doing platform engineering. When I’m improving reliability, I’m doing SRE work. When I’m building pipelines or automating infrastructure, I’m applying DevOps practices — the same way a carpenter applies joinery techniques. The techniques don’t become the job title.

Calling myself just an “engineer” isn’t false modesty or vagueness. It’s a deliberate rejection of a label that implies these concerns belong to a specific person rather than being shared across a team.

What This Means in Practice

If you’re hiring, think carefully about what you actually need. A “DevOps Engineer” job spec usually describes either a platform engineering role (building internal tooling and infrastructure) or an SRE role (owning reliability and production operations). Name it accurately — you’ll attract better candidates and set clearer expectations.

If you’re an engineer who’s been handed the “DevOps” title: the practices are genuinely valuable, and you probably know things that the rest of your organisation needs. But push for those practices to be shared. The goal was never for one team to own the pipeline. It was for everyone to care about it.

The cultural shift DevOps called for is still happening. It just doesn’t need its own org chart box to do it.