Stop Hiring DevOps Engineers

Overview

The video argues that “DevOps” has drifted from a cultural/process movement into a misleading job title—and that hiring “DevOps engineers” (and forming DevOps teams) has caused companies to recreate silos instead of improving collaboration and reliability.

Main points and analysis

• DevOps originally meant breaking down “the wall of confusion.” The speaker recalls the classic split where developers rapidly build code and “throw it over the wall” to operations, which then has to deploy, stabilize, and maintain it. DevOps was coined to connect these groups and build empathy and shared responsibility.

• Early DevOps success stories got misread by corporate leadership. Talks like “10+ deploys per day” and later Amazon’s extreme deployment frequency created hype. The speaker believes leadership focused on the tooling/visible outputs rather than the hard-to-sell cultural change, assuming the “secret sauce” could be purchased.

• Tool vendors accelerated the misunderstanding by selling partial solutions. Instead of adopting DevOps principles (shared ownership across the value stream and cross-boundary autonomy), companies bought tools like Jenkins, Puppet, Docker, Terraform, and YAML templates. The speaker describes this as the “McDonald’s of DevOps”—standardized, shallow implementations rather than transformation.

• Hiring for DevOps created a new silo. Companies formed DevOps teams and posted “DevOps engineer” roles, leading to a mismatch in incentives:

  • joining internally could mean extra responsibility without pay increases
  • external hires might get premium pay due to the “new shiny” label

• SRE emerged as a corrective—then got rebranded and diluted. The video frames Google’s SRE (2016) as treating operations like a software problem: eliminate toil via automation, define reliability via SLOs, and balance speed vs stability using error budgets. However, most companies rebranded DevOps as SRE without matching the depth—resulting in “on-call for application errors” roles rather than true SRE competencies.

• Shifting left led to overloading developers. As cloud, containers, CI/CD, and Kubernetes spread, teams “shifted left” by moving testing/scanning and more operational responsibilities into the development process. This aligned with the idea “you build it, you run it” (attributed here to Werner Vogels/Amazon). The speaker argues this went too far: developers ended up managing infrastructure details (e.g., Terraform state, networking, proxies, observability tools), leaving less time for application work.

• Current “best practice” is platform engineering as a balanced evolution. The speaker claims the industry has evolved to platform engineering, where specialists build self-service platform components (with logging, metrics, and reliable “golden paths”) so developers can deploy frequently without needing deep operational knowledge (e.g., how specific proxies/load balancers work). The platform team may still require on-call coverage, but ideally not for the developers’ entire application stack—only for the platform components they provide.

Conclusion

DevOps should not be a job title; hire for platform/domain expertise. The core recommendation is to stop hiring “DevOps engineers” as a catch-all. Instead, organizations should staff domain experts for the platform components developers need so developers can focus on code, not the operational glue.

Presenters / contributors

• Jez Humble (referenced as a key source on DevOps)
• Patrick Debois (credited with coining the term “DevOps” and hosting DevOps Day)
• Paul Hammond (gave the “10+ deploys per day” talk at DevOps Day)
• Werner Vogels (referenced for “you build it, you run it”)
• Google (credited with introducing SRE / defining it as operations-as-software)