What is in a name?
Who am I? What am I? What do I do? Does it matter? Last autumn a colleague and I were asked to do some research around our job titles, it had become clear that our day to day work had changed significantly and we no longer considered ourselves classic system administrators but if this is true, what were we? Coupled with interesting job titles like DevOps Engineer, Site Reliability Engineer (SRE) and Infrastructure Developer emerging in the market, we were eager to see who we were. So, we set off to investigate the desirability and suitability of a title change.
I’m writing this to try help you understand how you can navigate through a sea of new job categories, where titles pop up and grab attention within our industry then are replaced by the next hot thing. This is unlikely to stop anytime soon. New technology brings with it new work and so new categories of worker with new job titles. Within the many new titles at any time, some are cosmetic dressing up of old roles and others are designed to target more specifically a subset of skills in the market. All of this can be off putting and disheartening at first, when you to learn your career/role is vanishing or less than desirable any more. In the worst cases entire job families have disappeared and people can be out of work. It is a complicated issue and I will not cover it all but I’ll have a stab at it at least.
So, is there a point in job hoping to get one of these new titles, especially if you merely end up doing the same work with a different title? This depends, some job titles in the market felt aspirational and others felt like they were designed to attract applicants, while others were clear copy/paste from other roles out there. It was an interesting bit of research.
First thing we did was review jobs currently being advertised with the new titles. Our objective was to get a level set of the state of market and to collect a few of the job descriptions that were out there. There were a wide-range of roles labelled DevOps. We really needed to drill down into the specifications to get to what they were looking for. Some SRE roles were clearly looking for a System Administrator, the job specs were identical to Unix Admin or Network Admin roles from a few years ago, but they had been dressed up as SRE because well that sounds cooler, it is more desirable to the recruits. I might be getting cynical but if these really were SRE roles they didn’t put the proof into the job spec. Likewise some of the DevOps roles seemed to be Build Engineer roles, or heavily focused on the platform rather than everything that DevOps is, I don’t want to get into that one at this point… Still running build servers and maintaining Bamboo or Jenkins alone is not DevOps (not to say it is entirely unrelated).
I tried to educated myself by reading what industry commentators were saying about these new roles and the changes in IT. Specifically I kept hearing the DevOps was not a role and so DevOps teams should not exist. If DevOps is a movement, a culture and you can’t have a DevOps engineer role …. you’ve likely heard it before. I think I’ve alluded to why I think the market is calling roles SRE and DevOps already, I believe a lot of this is marketing for the candidates. You will struggle to get someone excited with the role of System Administrator these days, you will likely get fewer applicants, or if you do, will they be clinging to the older ways of working and less likely to change to code first ways of working. It is a tricky one. It was a point of view I had not initially considered, that of human resource or talent teams, they need to be able to advertise for open roles with the team. They want to get the best applicants, the likely want to move the team forward and bring in new skills, not just replacing existing ones.
There is also the practical side that they want to have a benchmarking/relative payscale for people, is the new job worth more money or is it just rare? Will they literally be doing the same work as people hired as Sys Admins or will they be forging a new era of Site Reliability expected to bring with them the concept of outage budgets and anti-fragility. These are the real question you need to try answer when looking at all the shiny new roles. Like a lot of things, it comes down to knowing what you want to do and intentionally moving towards it.
So, my advice is not to worry too much if you are not an SRE or a DevOps engineer, first ask yourself if you know where you are trying to get to, and then ask if the work you are doing now is helping you get there or not. If not then sure consider a change, but look deeply into the role specification and have specific questions ready. Ask why was this role created, if they are replacing someone who left then you should know that, if they are spinning up a new team and do not have the skills necessary, that important too.
Thanks for reading, Conor.
Thinking-Out-Loud SRE DevOps