DevOps is becoming more and more popular in the tech industry over the last decade, giving us powerful mentalities around rapid rebuilds, reliability through automation, and shifting away from the idea that meeting our SLAs meant long change management cycles.
We’ve had these ideas for a decade, and they’ve grown with us as the Cloud has grown. We have a generation of software developers and reliability engineers who have never thought outside of DevOps or Agile, who live and breathe the Cloud.
Unfortunately, with the popularity of DevOps we’ve also seen a marked rise in misunderstanding what DevOps is, and one of the most common examples that we’ve seen is job listings for a DevOps Engineer role.
DevOps Isn’t A Role
To understand why a DevOps role is a fundamental misunderstanding of what DevOps is, we need to look at the underlying goals of DevOps. Our view1 is that DevOps is cultural, a mindset of dismantling barriers between developers and systems administration, between IT and the business as a whole.
Because DevOps positions the skills of deployment and reliability and maintenance as integral to the software development process, it requires that developers understand and have internalised those concepts, that their entire approach to developing software includes those concerns.
By treating DevOps as a separate role, we’re not hiring developers who understand these requirements, who care about more than just the code. Instead, we’re doing what we do today, we’re insulating our developers, as we always have. We’re retaining, reinforcing the barriers that DevOps is meant to break down, we’re ignoring everything new that we could be doing.
This isn’t hiring DevOps skillsets. It’s hiring traditional systems administrators, and it’s not practicing DevOps.
DevOps is a Practice
Instead, we need to approach DevOps for what it is, an organisational pattern for delivery of projects and products.
We need to see DevOps for what it is, an extension of the Agile methodology, of using rapid failure and rapid recovery as the core axioms of building reliable and sustainable products and services.
We need to use DevOps as what it is, a technique to break down organisational silos that unnecessarily separate developers from operations, that empathy and collaboration to drive a broader understanding of reliability concerns.
By treating it as a role and not a practise we actively exclude those who understand DevOps and would bring the greatest value to our teams, because their skills of collaboration and shared mindsets will be disregarded as they are slotted into the same unnecessary and harmful silos that we have today.
By treating it as a role, the technologies of DevOps are useless. Without the culture of collaboration, communication and the gradient of skills, how can developers know what is truly required to run the service? Without the culture, how can operations know the tradeoffs and security concerns that drove development?
By treating it as a role, how can it break down barriers?
Be Different
Don’t try to hire DevOps as a role. Hire developers who understand that running software in production is an integral part of writing software. Hire systems people who understand that they must be a part of every development conversation, that there is no barrier between “developer” and “operations”.
Hire for the collaborators, hire for the communicators, hire for those who want to go further. Hire for the practice of DevOps and Agile.
But don’t try to hire as a role.