How often do you look at a job description and question the title’s relevance? How often do you find yourself at a crossroads when trying to summarise a job in a title? Why do we face these dilemmas and what can we do to navigate our way successfully through the myriad, endless stream of job titles?

How often do you look at a job description and question the title’s relevance? How often do you find yourself at a crossroads when trying to summarise a job in a title? Why do we face these dilemmas and what can we do to navigate our way successfully through the myriad, endless stream of job titles?

 

One common challenge within the field of DevOps occurs when a client, looking for a new employee, struggles to reach the right person with the right skill set, specifically needed for a specific role.

 

A lot of companies stuff their job specs with buzz words and eye-catching titles in the hope of seeing their next employee burst through the door and shout, “Here I am”. The intention – to be both exciting and precise - is clearly there, but, through this strategy, clients run the risk of blocking out potentially talented future employees because of a miscommunicated job title/description.  This misunderstanding is not one-way:  candidates quite often tend to fall short when visualising themselves in the position being advertised.

 

To overcome this problem is to successfully bridge the gap between client expectations and candidate qualifications. It is the recruiter’s task to facilitate the communication between the two parties by placing themselves in this conceptual grey-zone where a job title may mean one thing to the client and another to the candidate. A recruiter can therefore be understood as someone with the ability to translate the client’s requirements to the candidate and understand the candidate when they (unintentionally) express their needs and expectations ambiguously.   

 

It’s probably best I take you back a few months, ten months to be exact, when I started a fresh new career in recruitment. I remember the first time I, myself, was contacted by a recruiter, sprayed with job roles that were not remotely connected to my degree, experience or interests. He asked if I’d meet in their London office for a ‘chat’. A chat? About what? 

 

I fortunately started my digital patch in DevOps – the most sought-after space in digital recruitment - thousands of jobs, candidates and opportunities, with one major puzzle: “What exactly is DevOps and what does it mean to you?”. There’s no formal career track for becoming a DevOps Engineer. They are either developers who get interested in deployment and network operations, or sysadmins with a passion for scripting and coding who move into development side where they can improve the planning of test and deployment. Naturally, this uncertainty in defining what exactly the field of DevOps is adds another challenging dimension to the potential for misunderstanding I’ve already outlined.   

 

One of the first clients I worked for was a FinTech platform, who believed DevOps was first and foremost a software engineering discipline. (Now you’ve really gone and thrown a spanner in the works. Why can’t you just get a Software Engineer?). Should I advertise a Software Engineering role or DevOps? Or did I just need to understand that what this client wanted was someone who had a broader focus which included software development, how it is deployed and operational support through cloud while the software is continually functional? 

 

It quickly became clear to me the challenge when dealing with the not so tangible nature of DevOps was the lack of agreement on which job titles capture the many disciplines within the field of tech (I could be here all day going over the various DevOps abbreviations).

 

All parties (client, recruiter and candidate alike) play an active role in shaping the job titles within DevOps. I have identified four key aspects, central to the recruiter’s task:

 

  • Firstly, one must understand the client’s journey, their platform and end-product
  • Secondly, one must understand the client, their culture and ‘ecosystem’ - their current employees’ backgrounds and what typical skills they have
  • Thirdly, one needs to understand the market, and competitors of the client. How are they targeting their future employees? What titles are typically creating more interest?
  • Lastly, understanding in depth the candidates, their background, experience and skill set helps a great deal when trying to meet client/candidate needs.  What one client calls a Site Reliability Engineer another client – or candidate – might call a Platform Engineer

 

As recruiters, it is our job to really take information apart, understand it and present it in a form that resonates with what the client wants, and the candidate seeks.  We undeniably hold a major responsibility in facilitating this connection and good recruiters understand this crucial aspect of our role.

 

Nevertheless, candidates and clients can help smooth this process significantly by keeping one key fact in mind.  At the risk of sounding a bit too keen, here is one banal, but significant, piece of advice: don’t be afraid to open up to your recruiter! Let us get to know you, your mindset, your skills and professional wishes. This goes for both candidates and clients.

 

At the end of the day, we are here to help you navigate the confusing web of job titles and role specs …. to help you play the name game right.