Where the Confusion Began

Originally, DevOps was a cultural and process movement, not a job description. In 2009, Patrick Debois coined “DevOps” to bridge the chasm between development and operations. Its goal:

✅ Break down silos
✅ Automate delivery
✅ Share responsibility for running systems

DevOps was intended as a collaboration pattern, a practice, and a set of principles — not a role to hire for.

“DevOps is not a team, DevOps is a way of working.”
— Jez Humble, co-author of The DevOps Handbook (Humble et al., 2016)

Why “DevOps Engineer” Became a Title Anyway

As cloud-native tools exploded — Docker, Kubernetes, CI/CD pipelines — companies scrambled for engineers who could build automation and infrastructure.

Instead of upskilling developers and operators together, orgs tried to shortcut the transformation by hiring a “DevOps Engineer” to carry the entire practice alone.

It was a convenient pattern. But it contradicted the original movement.

The Problems with “DevOps Engineer” as a Role

1️⃣ Reinforces a new silo
Instead of removing the wall between dev and ops, companies put DevOps in its own box, creating yet another handoff.

2️⃣ Undermines shared responsibility
If “the DevOps Engineer” owns CI/CD, monitoring, and infra, then developers no longer feel responsible for operability — exactly the opposite of what DevOps intended (Forsgren, 2019).

3️⃣ Ambiguous expectations
Ask ten companies what a “DevOps Engineer” does and you’ll get ten wildly different answers — some mean SRE, some mean cloud engineer, some mean traditional sysadmin with Terraform. That makes hiring, evaluation, and skills growth a mess (Gartner, 2020).

What DevOps Should Actually Look Like

✅ Cross-functional teams
Small, empowered product teams that own their code from build to production.

✅ Platform engineering
Central teams build paved roads, golden paths, and reusable platforms so dev teams can self-service infrastructure — without losing product ownership.

✅ SRE practices
Instead of a “DevOps Engineer,” apply Site Reliability Engineering, where ops skills are productized and reliability engineering is taught to devs as a discipline (Google SRE Book).

Voices from the Field

Kelsey Hightower (Kubernetes pioneer):

“There is no such thing as a DevOps team. There are developers who care about operations.”
(Twitter)

Gene Kim (DevOps thought leader):

“DevOps is the outcome of applying Lean principles to the IT value stream. It cannot be reduced to a job title.”
— The Phoenix Project

Examples in Practice

✅ Spotify uses cross-functional “squads” that own their entire delivery lifecycle, with centralized platform support, not a “DevOps” silo.

✅ Google uses SRE principles to teach devs about reliability, while platform teams manage reusable services like Kubernetes clusters.

✅ Airbnb invested in a dedicated platform team to provide CI/CD tooling and infrastructure as a service, rather than tasking a “DevOps” role to own every product’s deployment pipeline.

Academic Perspectives

A 2021 paper published in Communications of the ACM noted:

“DevOps, like Agile, is a cultural and organizational shift, not a staffing category.”

It emphasized the risk of assigning DevOps to a separate team, repeating the exact silos it set out to dismantle.

Final Takeaway

DevOps was never meant to be a job title. It is a culture and a set of principles that every product team must absorb.

When you make “DevOps Engineer” a single role, you risk:

✅ Reinventing a silo
✅ Diluting shared responsibility
✅ Confusing skill sets and hiring

Instead, invest in platform engineering to empower product teams, teach devs operability, and truly embed DevOps culture into the entire engineering org.