Does Devops engineer job title mean something
Devops is the new buzzword in human resources of tech companies. Jobs are popping up all over the place with the title “Devops engineer”. It shows that organizations are now interested in the subject of company end-to-end agility, and that is a good thing.
The problem is that Devops is not a job. Funny thing, assigning the responsibility of Devops execution to a job is by definition anti-Devops. Is this Devops job title a faux-pas of badly informed recruiters? Or does it hide a deeper question? Let’s have a look.
A light review of Devops
We will not detail what is Devops in this article, it would be far too long. We will do it for sure, but this will require its own set of articles.
For now, let’s just resume Devops in the following key elements:
- - It aims at fluidify the exchange between the different functions working at creating and maintaining software artefacts. Mainly DEV-QA-OPS, but as well some other functions like management. It is a company-wide transformation
- - It has in core increased collaboration and automation
- - Devops proposes to implement a number of processes, like continuous deployment, continuous testing or continuous monitoring, that all going into Devops direction
- - Some technical choices like infrastructure as code can help to migrate to Devops
A first opinion: why ''Devops engineer'' does not exist
As explained above, Devops is not a job, a function nor a process. For this reason, we can doubt that the “Devops engineer” job title actually means something.
As with Agile project manager, a Devops engineer job looks a lot like a company trying to attract people into OPS jobs by using a buzzword that they do not fully understand.
Sadly, this is confirmed by reading some job descriptions: it is a job of OPS, potentially with some recent technologies like containers, with little to no relationship with the actual Devops movement.
No, Devops does not mean that one guy has to write release pipelines or “Dockerize” the application for the development team. In a truly devops organization. These tasks are typically handled by Developers with a strong support or coaching from the operation teams.
To implement Devops, it is common to build porous organizations to encourage knowledge sharing. It is inadvisable to assign to a new person the work of implementing operational aspects of the code produced by others.
Second thought: Devops transformation
So far, we have been looking at a working Devops organization. If all is put together to be Devops in the company, no need for extra people: development, operations and other relevant functions heavily collaborate to reach the best quality of service for their users and customers.
But what about on-going transformation?
The typical starting point for a company starting a Devops transformation is hermetic Dev and OPS organizations, strict and slow deployment processes, and contradictory objectives (innovation VS stability).
In this context, Devops will transform heavily these two citadels to make them unbreakable allies towards the business objective of stable innovation. Transformation that can be complex to implement.
How this can be done? A possible answer is to recruit specifically Devops experts that will help both organizations to reconciliate. That is the Devops team concept. These guys can even play a role of intermediary at first, then progressively rollout new ways of working when people are convinced by the added value little by little.
This would better be called Devops coach.
Third thought: Distinguish “Devops-ed” OPS jobs
We discussed a first possible Devops engineer job, the one of coaching and temporary intermediate between development and operations.
With a Devops transformation, let’s be clear: the most impacted job is the one of OPS (I personally believe that QA job comes short second but more on this later).
In a Devops organization, an operator does less clicks and commands and much more coding, less manual stuff and much more automation. He is less a sentinel and more proactive in the development cycle.
For old school OPS this can be frightening. For young engineers this is a lot more attractive.
Now here is the question: as a recruiter, how do you distinguish the Devops OPS job from standard OPS? There is a vast difference in the day to day activities, and it is already difficult to staff operators. It is key to show which job you offer.
This is for me the second usage of the Devops engineer job title. It is wrong, but still probably the best way to advertise that you offer a job in an organization implementing Devops or in the processing of adopting it.
Now the job description should allow to see if we are looking at such job or a standard OPS job. It should focus less on tech stuff and more collarobation stuff. You should feel that the job is about collaborating with other roles and not taking responsability after development as finished coding. If the description does not give a clue, use the interview, here are many questions to ask.
The first time I saw a Devops job title I was horrified, just like most people would be by knowing what Devops is about. After some though, I consider that the job title “Devops Engineer” is either:
- - Designating a Devops coach job (and should definitely be called like that)
- - Designating a Devopsed OPS job (and I do not see a better way to call it)
- - Wrongly used, it is an OPS job trying to look better but still implementing ideas like taking care of all operational aspects of the product being built in isolation of the dev team
Carefully reading the description, or asking questions during the interview, should bring the information needed to distinguish the cases.
Devops is a brilliant movement, and at Stenusys we hate to see its image degraded by companies using the term badly. It happened to Scrum and agile in general, pity if Devops falls in the same pitfall.
Recruiters, use the term wisely.
Candidates, read the job description to see if this is a coaching job, an OPS job in a Devops organization or a standard OPS job with some new tech.
But please, if a mismatch happens, don't blame Devops !