Recently I got a call from a recruiter who was having trouble finding applicants for a job posting that included the title “DevOps Engineer.” So I asked him to send me the job description.

When I saw it, my jaw dropped. The copy said nothing about what the person in this position would be expected to do or accomplish. It also said nothing about what challenges the company faced that necessitated them hiring someone.

When I called the recruiter to get some details, I quickly became even more flabbergasted. I asked for some background and the recruiter sheepishly replied, “To be honest, the hiring manager doesn’t know what the hiree would be doing.”

No wonder they didn’t have throngs of candidates lined up…

Turns out this firm really wanted to hire a “DevOps Engineer” (which in truth doesn’t exist) because they knew they wanted DevOps. But they weren’t sure what that actually meant in terms of day-to-day work. They also didn’t know what a “DevOps Engineer” actually needed to know to do whatever it was they did, so they just listed a bunch of skills and technologies that seemed to be related to DevOps.

To drill down into some useful information, I employed the well-known “5 Whys” iterative questioning technique from the realm of lean manufacturing. This is a great way to explore cause-and-effect relationships to get past symptoms to an underlying issue. You find out, for example, that what presents as a technical problem is actually a managerial problem or vice versa.

Here’s an example of how a 5 Whys conversation might play out in a revealing way:

  1. Why did that new release break a key customer-facing feature? Because server xyz failed.
  2. Why? Because an obscure subsystem was used in the wrong way.
  3. Why? Because the engineer involved didn’t know how to use it properly.
  4. Why? Because he was never trained on how to do so.
  5. Why? Because his manager feels the team is “too busy” to train new hires.

I’m no expert at this process by any means, but this seemed like a good opportunity to give it a shot. Here’s how my attempt at a “5 Whys” conversation went with the recruiter:

Q1: Why does this company want a so-called DevOps Engineer?

A1: Because they want to automate their processes.

Q2: Why?

A2: Because they’re having outages of production applications.

Q3: Why?

A3: Because they’re not able to spin up new services fast enough. So when something crashes customers are impacted.

That looked to me like a root cause-they couldn’t spin up infrastructure fast enough, which is why they needed automation.

So the person they need to hire isn’t a DevOps engineer, but rather an Automation Engineer. His or her job would revolve around building out tooling (one piece of the DevOps puzzle) to support automating the firm’s virtual infrastructure. While not always true, in this case appropriate automation should make spinning up new servers and applications much faster than doing it manually and/or doing it using processes that aren’t robust, thus removing some headaches for this organization.”

What the recruiter ended up with was a simpler, better-targeted, more informative job posting with a more marketable job title.

There’s a lot of pressure these days to find “DevOps people.” Being clear about what you really need, and why, will certainly make recruiting more productive for all concerned.

Are you looking to create a DevOps culture in your organization? To talk over what that means in terms of tooling, job roles and other changes, reach out to us. We understand DevOps and we love brainstorming about it.