Tag: DevOps hiring

I was talking to some friends about hiring the other day, and a common thread seems to run through all of their hiring activities: It is hard to find “good” DevOps people.

This thought got me thinking that we assume a lot in DevOps, and that we should stop assuming and openly discuss those things. For all the streamlining and shift left it can do, DevOps could use some streamlining and shifting left, itself. So, this is the first of what I think will grow into a series of blogs about DevOps assumptions we make and openly discuss them. At least if we acknowledge our assumptions and the realities that we try to ignore, we can adjust.

Today’s blog is about finding “good” people. I put good in scare quotes because while there are common threads, the definition of good is definitely dependent upon the organization and even on the team. If a team needs someone with Azure chops to rev up their work and help the rest of the team become more proficient in Azure, then a GCE expert, no matter how great they are, is not “good.” This is true of every field of endeavor, but we in DevOps often pretend it is not true for us. Particularly the pundit class, but management is also severely guilty of “It’s DevOps, everyone is everything,” which any active practitioner will tell you is not true. There are still specialties, we just hand wave and blather about “It’s all DevOps.”

Unfortunately, there is often a disconnect here. DevOps roles are not well-filled by filtering on technology and they’re not well-filled by just using “DevOps” in the job title. That leaves HR struggling to find candidates to interview that techs will find appealing. How does HR filter on “can learn on the job, and do so rapidly”? Simply put, they don’t. That’s what interviews are for. But if HR filters on “must know Jenkins,” that is diametrically opposed to “must learn on the job.” Which is it? Must know certain skills and have X years of experience in them, or must be able to pick up new things on the fly? Because filtering on already having the skill would seem to imply you don’t really care about the ability to learn fast, would it not? Because there are great fast learners that have never worked in a Jenkins shop, but they could, if they’re truly fast learners, pick up Jenkins.

So ‘good’ is relative, but beyond that, what I hinted at above is also impactful. We are–nearly all of us–on-the-job trainees. There are certifications and universities are starting to catch up, but most of us? We learned either on the job or on our own time, trying to do some pet project. This, too, hurts HR filtering. Demanding a four-year degree is something that HR can measure. Demanding on-the-job training? Not so much. So, if HR gets filters they can measure, they will not be filtering based upon reality.

This is how we get things like, “Must have 30 years of Rust experience,” even though Rust is 20 years old if you count from inception. Far less if you count from the start of its usable life. HR is not an efficient or effective filtering system for DevOps, and we are somewhat flailing. Until we have improved systems and processes, I would suggest having HR send too many applicants through, and DevOps engineers or managers–those who will have to work with (and count on) those new hires–do more of the filtering than normal. There are honestly people out there with no relevant degree and no certifications that are better than most of us. Project work is the only way to gauge that measure, but project work cannot be effectively evaluated by HR because they’re not technical specialists. I know—the org is hiring people because they need help, so offloading some of HR’s duties on the team that needs the help is not a great solution. It is better than going through an entire outreach/interview/hire process only to settle for ‘good enough’ (or, worse, ‘not good enough’) because the process is flawed based upon the current environment.

This brings us to the scenario we see today–where more technical people have hit the market than in recent history, but hiring managers are still struggling. Have the DevOps team take a more active role in the process until new standards can be settled on that suit the needs of your organization. You’ve worked hard to make an astounding infrastructure and build apps that can handle the needs of your organization, make sure the people you put next to you are the best you can find and the organization can afford.

And keep rocking it. Teach them about the systems you shepherd and learn from them what they bring to the team.