Why is DevOps Recruiting so hard?

Now cross-posted on Medium.

Disclaimer: Many practitioners of DevOps would call this question out on its face -- DevOps is like Agile: something that an organization, not a person, does. That said... the market treats DevOps as a job title -- and a particularly hard-to-fill one at that... so please forgive the colloquial usage here.

The other day a recruiter asked me about hiring for DevOps. I was a reasonable person to ask because I worked with the team that built DevOps-enabling tools in an organization that practiced DevOps. It isn't the first time I've discussed the subject with recruiters (having been recently on the market), so I decided to write my reply in a public forum. In the rest of this article, I'd like to tell a brief story about how we got to "DevOps" and claim that seeking out DevOps engineers is a bad way to find engineers to do DevOps.

DevOps is a portmanteau of development and operations, which are historically distinct careers. Recently, a lot of things in the realm of operations have become software-defined, which has enabled developers to start controlling big parts of traditional operations territory with code. This is a big theme in development, but a tectonic shift in operations.

Network and system administrators form the core of the group called "operations". They might work in a NOC [1], design systems for load-balancing and redundancy, plan maintenance, monitor systems, live their lives on call, etc. Perhaps related to that last point, "automate the hell out of everything" is the hallmark of a good operations philosophy.

Automation has its dangers, however... If you move to "the cloud" you may want to understand sub-nets and DMZs, but fewer and fewer people need to know how important this command is:

copy running-config startup-config

Even fewer need to know how to test power supplies and replace SAS drives when the LBL starts up. (Don't know what some or all of these terms mean? The point is that it doesn't matter anymore because you don't need to.) [2]

All this made a lot of old operations skillsets irrelevant, and the cloud decimated the old operations personnel budget as a result. Many operations groups shifted their terminology to "DevOps" to duck the axe, stay on-trend, and reflect the reality of a greater emphasis on code-based infrastructure.

Not everyone was a loser. Operations folks who embraced the "automate everything" mentality are in high demand. Many software engineers cherish their new ability to control "operations" solutions and behaviors related to their projects. These are the "ops" and "dev" groups the term is referring to, and uniting these groups is a focus on systems, a devotion to end-to-end quality, and interest in exciting, new technologies.

BUT, what recruiters and hiring managers don't seem to realize is that even as these groups converge... that does not mean they are the same! These are two vastly different cohorts of people with distinct skillsets:

• Operations folks who are skilled at automation and heavy configuration
• Developers who are interested in writing services for software-defined infrastructure

Jobs are being envisioned with no demonstrable awareness of this fact, making this more complicated because candidates don't trust the descriptions. That is where you (if you are a recruiter or hiring manager) and this article come in. If you finish reading this article and are still looking for "DevOps" candidates, then we have both failed; I promise that what you are really looking for is something more specific and definable.

DevOps is not a magical word, and if you want someone who can do everything change the title to "architect" and prepare to pay. You are looking for a high-performing individual with a system or integrator mindset; but when you write out that job description, think about the day-to-day role and use precision. Target your language toward someone who was doing a more traditional role before "DevOps" became a thing.

If you recruit with this knowledge, you have a leg up on the competition:

1. If you need a wizard Linux/Ruby candidate, you can be the one recruiter actually gunning for System Administrators who script, instead of the stampede of folks attempting to make matches for this role with enterprise Java engineers (real example).
2. If you actually need someone to write software, you can make this clear in your recruitment efforts. The number one message Software Engineers interested in DevOps need to hear is: "This really is a position writing software (not scripts, not configuration, not templates -- software)". When I talk to my friends who are all-star, unicorn candidates, this is their #1 complaint by far -- and that's why they don't respond to you.

In addition to improving your persuasiveness once you contact candidates, tailoring job descriptions to the real professionals using the skills you are after lets those candidates find your job and encourages them to contact you.

To directly answer the titular question of this article: recruiting for DevOps is so hard because the term "DevOps" as it is being used doesn't describe anything--it describes everything. Recruiting for DevOps is hard because it is hard to fill imprecise requirements. If the hiring manager and the recruiter can get on the same page (and a realistic page based on what the candidate will be doing) the challenge will become drastically easier.

---

[1] NOC stands for Network Operations Center

[2] I'll tell you what they mean anyway though: (a) a sub-net is a networking concept that roughly means "where you can go without asking a router for permission", (b) a DMZ (from geopolitics) is a De-Militarized Zone -- you can put your public-facing servers here so you don't have to let anyone into your private network space, (c) the copy command is just how you save what you are doing on a Cisco router, (d) SAS is just a standard for connections to hard drives -- kinda like USB, (e) LBL means "little blinking light" -- yes, that is a technical term.