Finessing the DevOps transition - hiring and skills tips from Jason McKay of Logicworks

Logicworks moves fast. Since I last talked with Jason McKay, SVP and CTO, they've already launched two new tools: an AWS cloud security automation framework, and an AWS cost management solution. But then, that's the whole point of DevOps: automate the mundane and get cool stuff done faster.

Logicworks sees itself as addressing a key problem: the cloud, for all its touted benefits, is not auto-configured to meet every business requirement. Logicworks' aim is to build cloud automation tools that help companies get more out-of-the-box cloud benefits without getting lost in the technical weeds. One key part of their niche? Helping companies in heavily-regulated industries automate cloud processes. Of course, these automation services are steeped in an internal DevOps culture.

But it wasn't always that way. Logicworks has been around 22 years; they discovered the value of DevOps after initial resistance. When I talked with McKay, he was transparent about their own DevOps forays, and why he thinks DevOps has reached critical mass. Now that DevOps has gone from hard sell to must-have, the question of skills moves to the forefront. I asked McKay to share his tips on how they hire the best DevOps talent.

The impact of DevOps - from threat to core competency

You can't become a DevOps shop overnight. So how did Logicworks get from DevOps skeptics to pros? The story goes back to 2009, when McKay's team perceived AWS as a potential threat:

For us, it was mostly prompted by the shift to Amazon Web Services as a platform of choice. I remember attending the Linux Plumber's Conference in Portland, Oregon and being very surprised at the number of mentions of Amazon Web Services at that point. At the time, we were looking at it as a threat. A lot of our competitors were thinking the same.

But as Logicworks transitioned to AWS, the potential of automation took hold:

Once it was on our radar, we start looking more carefully at it... Over the next couple of years, we realized that the automation capabilities on the AWS platform were so powerful.

McKay could see their clients would need support to take advantage:

There were enough knobs and levers that needed turning to getting everything working correctly. That required somebody with real expertise. And we saw an opportunity to have value there.

That provoked a shift in business model, and hiring:

We shifted the focus of our business primarily away from legacy hosting and into running complex work loads on Amazon Web Services, which meant that we had to retool our engineering team to be a little bit less on the hardware side. Through training and hiring, we started bringing in more automation and DevOps folks. The nature of the talent on the team we're building here changed pretty drastically over the the next few years.

Automation isn't just a new approach; it's a change in mindset:

The majority of our senior engineering team are focused on automation and DevOps at this point. We still need our subject matter experts in certain tactical areas like database administration. But everybody is thinking in terms of tying things together with automation.

McKay told me that automation also applies to their own efforts to manage growth and scale:

As a business, we need to be able to focus on automation to handle all the business growth that we're dealing with. If we can automate it, then we can get much more throughput from our engineering team.

Another key to the power of automation: reducing customization. McKay learned these automated tools are viable for repeatable deployments:

It became very apparent that not only do you have more throughput, but your deployments were repeatable. If you ironed out the errors in the development of the tooling, you didn't have errors at deployment time. And you had much more supportable deployments. A few years ago, we really started focusing on building tooling and automation frameworks that could be used by all of our clients, and then extended for each individual client when necessary to accommodate something custom to their environment.

DevOps hiring and skills assessment - four tips

McKay shared four tips from Logicworks' DevOps hiring:

1. Good DevOps hires come from two main backgrounds.

DevOps in a title is very much in demand. The hiring for it is tough. Because it is fairly new, the agreed-upon standards of what makes a good DevOps engineer isn't quite there yet. In my experience, [the good ones] are coming from one of two backgrounds. They're either a developer who was working in an environment where they had to do their own operations, or they are modern sys admins. This group were formerly on the administrator side, but they were early adopters of automation, early adopters of configuration management. They are admins who saw the value in coding away the repeatable, uninteresting work.

McKay looks for a "good kind of lazy" engineer:

What we always look for in engineers is the good kind of lazy. The engineer that doesn't like to do something uninspiring and uninteresting, and so has simply automated that job away.

2. Now that every techie lists DevOps on their resume, discretion is needed. DevOps is hot enough that self-described "DevOps" pros are everywhere. McKay doesn't see this as any different than other hot skills areas, but he did offer some warning signs:

We've seen this from hiring folks that come out of really large enterprises. Some of them may do shell scripting; they haven't really moved into the tools. They don't really understand configuration management. Sometimes, we'll have to push people to come up to speed on those sort of things because they haven't discovered the virtues of it themselves. But it's not all that common, thankfully.

3. There is a great opportunity to hire ambitious "juniors" who are already well-versed in DevOps tools:

It's very interesting to see a huge DevOps uptake in the number of what I would consider junior folks, in terms of age and tenure in IT, who have embraced the tooling and the automation. Folks that probably otherwise would have simply got into development were it not for this opportunity to now get into both. Which is kind of an outstanding opportunity that makes for a lot of relatively raw, but ambitious talent. I'm getting a lot of those folks.

4. Open source community involvement is a good indicator of a desirable hire. McKay:

That's usually a very good sign. If they're contributing to a project, that means that they're perfectly open to visibility of work. It means they're going to work well with others. Rather than duplicate the effort of others, they're willing to work collaboratively. We're very much a fan of folks who come from some type of open source background.

McKay had more to say on how their own customers are using DevOps and the value achieved. I'll get to that in a future installment.