(c)iStock.com/George Clerk

I have been seeing job ads more and more frequently that heavily emphasise the requirement for ‘current skill sets’. The fact that these ads are putting such emphasis on the importance of skill sets being current signals to me a trend within the DevOps landscape: the ever-widening gulf between technological innovation and those who have exposure to it.

There are two core reasons why this problem exists and is growing. Firstly, maintaining employees with ‘cutting edge’ skill sets for cloud-based development requires either the IT budget of a large corporation or a team small enough to maintain an environment of rapid prototyping and experimentation. Needless to say, these extremes limit the number of candidates with the required abilities.

The traditional rules for filling tech vacancies do not apply equally in the world of DevOps

Secondly, if tech workers spend time out of work for whatever reason, their skills rapidly become out of date. A period of time without work is punishing for anyone searching for a new job, but this has a particularly detrimental effect on technical people working in areas such as DevOps with formal skills requirements that are changing all the time.

A technical staffer does not even have to spend a few months out of work to be slapped with the ‘out of date skills’ label. Traditional career progression pathways mean that the more seniority a person gains in the workplace, the less likely they are to be working on the ‘coal face’ of the problem.

As a result, technical managers lose their tech chops and when applying to other positions often face the prospect of starting again as a junior engineer to regain their technical credentials. This problem is compounded by hiring managers often opting to reject more seasoned “over-qualified” candidates in favour of new-to-market and cheaper hires with more current skillsets. Within DevOps these problems are more apparent because the technical skills required for the job are evolving at breakneck pace.

This is important background information when we consider the problems faced by startups when it comes to hiring technical talent. It is very difficult for non-technical people to go about hiring a technical employee, and this can be exacerbated by overemphasising specific certifications in narrow areas. This will dramatically – and unnecessarily – limit your candidate pool, and very often candidates have equivalent experience that only an expert would be able to identify. For example, someone with strong experience with Ubuntu Linux will likely not have difficulty with Red Hat Enterprise Linux after a brief acquaintance period.

Startups often hire people who have only ever had experience working with AWS or other cloud providers. As a result, the world beyond the virtual machine is a total mystery to them. For example, while they may have the specific skills, qualifications and certifications you’re looking for, they have little experience of organising cables and racks of equipment.

Certifications are all well and good, but in my opinion they should only take an application to a certain point. There is no substitute for genuine work experience: while certifications give a candidate credibility within a narrow area, ‘on the job’ experience is a far better indicator of future job performance. In my time as a manager some of the most gifted engineers I’ve worked with are those who started out as hackers and rogues, not ivory tower academics. In many areas of tech, it is far better to learn by doing, and sometimes doing it wrong, than it is to learn in the abstract.

In many areas of tech, it is far better to learn by doing – and sometimes doing it wrong – than it is to learn in the abstract

This divide is something that will become more and more apparent as companies shoulder the burden of ever-increasing layers of legacy systems: what skills are best for building, and what skills are best for maintaining. In my view, these same hackers and rogues, those who learn by doing, are far better suited to rapid prototyping, to building new things and coming up with new ideas. By contrast, employees with more formalised learning and specific codified experience also have significant value, however they’re better placed in roles requiring them to maintain existing things.

The key takeaway from all this is that the traditional rules for filling tech vacancies do not apply equally in the world of DevOps. A candidate being a few steps behind the curve should not disqualify them from the job, and by the same token a candidate who has the perfect blend of qualifications for the job should not be given a free pass. In today’s rapidly moving environment, having precise qualifications for self-contained skillsets is not as important as having a flexible, adaptable and cross-functional approach. Before you begin searching for that ideal candidate, make sure you know what you’re actually looking for.