“Ryan, what type of DevOps engineer should we hire?”, is a question I’ve been asked by customer after customer. As much as I want to flippantly respond “A good one”, I know, this isn’t helpful. When a customer raised this question a few weeks ago, I decided to get our conversation down on paper, in the hopes that sharing my perspective, benefits others asking this same question.
Those DevOps unicorns, they don’t exist…
I start by laying the baseline, “OK, let’s just cut to the chase. That unicorn DevOps engineer you thought you were going to hire? That one with all the certifications and within your budget …sorry to burst your bubble but they don’t exist. Yes, I know, these unicorns exist in Silicon Valley and I, too, have seen them on InfoQ, but we’re not in the valley, and we’re not creating content for InfoQ. We’re at your established organization and while you have some, let’s just say, interesting-but-not-that-interesting work to be done, we need to be pragmatic about hiring.”
Forty-five minutes later, after we’ve discussed “this thing called DevOps”, whether DevOps should even be in the job title, pipelines, all things cloud, Kubernetes and then a bit more on pipelines, we start to zero in on what problems they need to solve. It’s from here that I can generally guide them to a persona that’s realistic for their needs.
As the CTO and Cloud/DevOps Solution Lead for SingleStone, I’ve hired many DevOps engineers and worked alongside hundreds more of our customer’s engineers. While some may argue that “there’s no such role as DevOps engineer”, the reality is that in the technology industry labels stick — for good and bad. A quick search on LinkedIn will show that DevOps Engineers are amongst the fastest-growing jobs (we’re hiring too!). It’s a thing…companies want to hire DevOps engineers.
Pick One: DEVops or devOPS
Step 1: Start with the problem – “What problems are we trying to solve that we hope this person(s) can help us with?”. Hiring is one of the most expensive investments any firm can make, so being clear on the problems they will solve is imperative.
Often by the time I have this conversation, customers have already posted a job description for the unicorn DevOps engineer, and not surprisingly they are having a hard time finding good candidates. I share that based on my experience; the vast majority of DevOps engineering candidates can be grouped into one of two personas. Choose one of them as a starting point for your DevOps engineer role:
- DEVops engineers fundamentally understand software development, are passionate about automation, are lazy like a fox and enjoy making their team’s lives easier. These are generally the cheerful / glass-half-full folks who think everything’s possible. These engineers almost always start their careers as software developers and are passionate about “doing it right”. They are naturally curious about how code flows and this often leads to building pipelines that automate the building, packaging, testing and deploying of applications. Setting up code quality reports, dashboards and feedback mechanisms for the team often falls in their purview.
- devOPS engineers fundamentally understand physical and virtual infrastructure including networking, compute, storage, monitoring and operations. These are often the mildly surly folks with sarcastic senses of humor and a higher propensity for piercings. They may have started their career as a glass-half-full person, but over time they’ve often been beaten down by developers and management. These engineers generally started life as system administrators or network engineers and today should have experience with virtualization and likely the cloud. These engineers naturally gravitate to building environments, application stacks, monitoring and other resources required to safely run applications.
To help them choose, I’ll ask my customer questions like, “Is your development team constantly challenged to get shippable code released? Is building, deploying and testing your service a black art? Do you often roll back releases?”. If so, then start with a DEVops engineer.
Alternatively, I may ask “Are your customers the first to tell you that your service is down? Does a step in your disaster recovery runbook include saying a prayer? Is self-service provisioning something you only hear about at conferences?”. If so, then start with a devOPS engineer.
If you are having all of these problems, then consider a pair of engineers — one closer to DEVops and the other devOPS — and have them work together. When Google hire’s Site Reliability Engineers (SRE’s) — roughly analogous to a DevOps engineer — they hire about a 50/50 split in DEVops and devOPS engineers. At SingleStone, when we deploy DevOps engineers on a customer engagement, we send DEVops and devOPS engineers, because we’ve found that they are able to solve more problems in less time.
In the beginning, let the problem guide you to a DEVops or devOPS engineer persona. You’ll be more efficient in recruiting, interviewing and hiring. And, you’ll set appropriate expectations with your existing team on what this role will help (or not help) with. If you have lots of problems — consider a pair — one from each persona.
Now that we’ve identified the hiring options, in my next post I’ll share my Six Traits of a DevOps Engineer.
Have you hired a DevOps engineer? Are you a DevOps engineer? How do you go about defining when to hire a new team member?