Previously I spoke on how you can’t hire a DevOps role, and some very interesting conversation came out of that article.
The core response was that if the skills are present, does it matter what the role is called? If the work is being done, does it matter where those people are? Don’t DevOps teams exist, and we just call them SRE?
The difficulty with hiring a DevOps team, or DevOps Engineers as a role or title, is the problem of context.
The Context of Organisations
As businesses, we already sort by skills, and name them our various departments. IT skills go into the IT department, different IT skills go into software development.
By sorting skills by pre-existing department, we sort our people into different reporting lines, into groups with their own objectives and goals, goals which may or may not align.
By leaning on existing business structures for this sorting, we constrain how hiring decisions are made. This results in technical staff ending up in one of a couple of departments, Operational IT or Software Development.
On the surface, this seems fine.
History Binds Us
And it being fine is the mental model we have when we start hiring for DevOps skills, and by naming it as a dedicated role we need to declare what skills are needed for that role, what expertise and background. When we do this, we naturally compare those skills to the skills of the departments and team members we have, to what we think the work looks like.
My own journey aside, many people in New Zealand have come to DevOps from systems administration backgrounds, which, when we compare to the existing skills and backgrounds and how we think of the work, means we naturally want to put them into the IT or Operations departments, doing the same system administration work.
By naming the role we name the skills, by naming the skills we, as humans, need to categorise, and we categorise by what we know.
This critically impairs our culture being able to change, because we treat the skills as nothing but an extension of a previous skillset, bringing all the history and baggage along for the ride.
Culture
This impairment condemns a DevOps role to being seen by other parts of the organisation as the same limiting, controlling, and impeding IT department that has always been.
It prevents the new tools and techniques of DevOps from being useful, as there will be no space to experiment with the new tools and discover new process. Why would there be? A DevOps role fits into our existing IT strategy, why would there be a need to change?
When we consider those orthogonal goals, where DevOps in an IT department are required to adhere to a classic IT structure, we see that other business departments have no need to engage with IT or have open conversations.
We see that decisions are made without considering how IT can and should be involved from the get-go, that the shift-left philosophy of DevOps is free to be ignored.
Why involve IT? They just get in the way. They just say “no”. No organisational change has been made to support or include the feedback loop of DevOps.
We’ve just renamed a role, calling a rose by another name, and that can never work.
Other Teams
I’ve talked about DevOps predominately being placed in the IT or Operations departments, but this effect happens regardless of where roles labelled “DevOps” are placed.
By matching the skills to an existing set of skills within an organisation, we put the people into roles that are different only in name. Instead, we focus on the least transformative part of DevOps — the technical tooling and technical skills — instead of how the process and mentality will help us.
DevOps as Culture
Instead, It’s critical to consider DevOps as a cultural ideal or a practice, much like Agile Development.
Operations, or IT, should be a communicating partner in project conversations, helping guide roadmaps and working to ensure ongoing project success. IT should never be considered to be the group that just says no, but a valuable partner.
Where developers are enabled to participate in project direction and client conversations, where QA or Helpdesk are consulted on their needs.
To achieve this, we all must think about DevOps as a culture, to build on the internal ideas of empathy, mutual respect and communications in order to dismantle silos and improve outcomes.
By naming DevOps as a role we prevent that culture from being able to take root, or being able to grow.
We may use the new words, but our actions are the same as they were before.
To avoid falling into this trap, we instead need to think of DevOps as multiple people across different teams are working together to achieve a new practice, without naming any group the “DevOps people”.
This requires making everyone responsible for the success of DevOps, not just one person or one team. By choosing to see DevOps as a practice, we choose to change how we view ourselves, how we view how skills and communication exists within our business.
Instead of the same actions with new words we have new actions, words to match, and the culture to change.