DevOps Engineer is the new SysAdmin
If you’re not doing dev… you’re just doing ops
DevOps Engineer seems to be a job title that causes a fair amount of confusion. Perhaps this is because it’s an anti-pattern. Apparently, a lot of companies think they can hire someone and suddenly become DevOps. They want to “change” without actually changing anything! (except to change the title of “SysAdmin” to “DevOps Engineer”). ;-)
The reality is that DevOps is not a job title. It is not something one person does or a team does. It is a cultural transformation on an organizational scale. It is the practice of development and operations engineers working together during the entire software lifecycle, hopefully on the same team, following lean and agile principles that allow them to deliver high-quality software stably and continuously. It starts with learning how to work differently and embraces cross-functional teams with openness, transparency, and trust as pillars. If that doesn’t sound like your company, then you are probably not practicing DevOps.
How does this happen?
This is a sad reality for a lot of companies. I see job postings for DevOps Engineers that describe what is essentially a system administrator job with the added responsibility of running CI/CD pipelines or automating infrastructure deployments. Here’s a hint: If you apply for a DevOps job and your team is not doing Development, it’s not DevOps because DevOps is Development+Operations. i.e., “you build it, you run it”. If someone else built it and you are running it, then you are just doing Ops (or Site Reliability Engineering). There should be no separate development and operations team in a company that is truly practising DevOps, there is just one team that is cross-functional and driven by one set of metrics that is focused on providing value to their customers.
DevOps is about breaking down the silos, not adding a new one.
Part of the confusion is because a lot of practices came together all at once to form the DevOps movement back in 2009. The culture change was at the centre of the movement. You had influences from Lean Manufacturing, Agile Development and Planning, Continuous Integration and Continuous Delivery, Test-Driven Development, Behavior Driven Development, Cloud Native Microservice Architecture, Infrastructure as Code, Immutable Runtimes, etc., and with all of these new practices and methodologies came new tools and technologies to support them.
Tools won’t fix your broken culture
When companies create job postings for DevOps Engineers, they mostly want operations people who understand these new tools. The company doesn’t understand that tools won’t fix their broken culture. They are actually content with someone managing pipelines for the developers when it would be far more productive for developers to learn how to set up their own pipelines and manage them. So instead of the devs throwing their broken code over the wall to ops, they now throw it at the poor DevOps Engineer who tries to make working pipelines out of it and then hands something that works over to ops. Good for devs… good for ops… bad for DevOps Engineers.
If a company wants to adopt DevOps, and they think that the developers will keep on working the way they have been for years, then that company will never become DevOps. Because DevOps requires devs to change the way they work, and ops to change the way they work. The last thing it needs is a new team to shelter dev from ops while they continue working in their silos.
Break down the silos
One of the primary reasons for adopting a DevOps culture is to break down the silos. So, if the company you work for still has silos with hand-offs, (or even worse, they have created a 3rd silo between development and operations called the “DevOps Team”) they are not practising DevOps. DevOps squads have end-to-end responsibility for what they commit, build, test, deploy, maintain, operate, everything! Of course, there are different ways to accomplish this, but the “you build it, you run it” mantra is at the core of DevOps.
Conclusion
The job title of DevOps Engineer has little in common with the DevOps movement. I think you’ll find that if you change any of these DevOps Engineer job titles to System Administrator and read the description, it probably still fits perfectly. Perhaps they should be looking for an Automation Engineer. But don’t confuse automation with being DevOps. Automation is part of the DevOps philosophy but it’s only one piece. Adopting automation without changing your culture to a DevOps mindset of trust, transparency, and fast feedback loops, it’s still just implementing automation. I have found that the DevOps Engineer job title is almost always a pure Ops position with no Dev.
I say this with all due respect to those who hold “DevOps Engineer” job titles. The work you do is critically important, and the skills you possess are infinitely valuable and sought after, but the company you work for is not practising DevOps if they put you on a DevOps Team. Remember, DevOps is about breaking down the silos, not creating a new one.
