Señor Pinky

Community Manager

CONNECT or FOLLOW ME:

Señor Pinky Señor Pinky
Don’t Get Hung-up on Job Titles

Don’t Get Hung-up on Job Titles

Date: 2015, Nov 14

Is DevOps a buzz word of the moment? Why is there so much hype around DevOps? Tons of job postings, but I mean TONS galore such as DevOps Engineer, Senior DevOps Engineer, DevOps Architect, DevOps this, DevOps that and the list goes on and on…

I’m not trying to place the blame on the recruiters, because it’s not their fault they are getting bombarded by employers specifically requesting these job titles or have not had a chance to review this DevOps 101 for Recruiters slide deck (that I highly recommend they review when they have some free time). Because it is insane the amount of emails and calls I am receiving from recruiters who are not understanding the position they are trying to fill.

DevOps is really not a buzz word of the moment, because it’s been around for many years as illustrated in the timeline below you may have already seen in the past. Watch “The (Short) History of DevOps” video embedded below that is narrated by Damon Edwards.

It’s like a speaker (can’t remember the name) I heard at ChefConf 2015 says:

"Oh so that's what DevOps is!
So it looks like we've been doing DevOps before there was even a name for it..."

The real reason why DevOps is such a buzz word and everyone is using it in job titles, is because it’s becoming a commodity in mainstream business. The key stakeholders and decision makers of these so called dinosaurs, elephants, horses, and mules companies want to be as agile and lean as the unicorns. They are just now realizing that DevOps is not just for unicorns, but there are many cases studies that have demonstrated that enterprises that practice DevOps improve IT performance exceeding their goals of profitability, market share, and productivity.

Recently I read an article from Jason Hand at VictorOps on “The top 10 DevOps myths debunked” and I would like to thank him for inspiring me to write this post. Because 6 months or even a year ago, I would have agreed with him 100% on all top 10 myths debunked he mentions. But times are changing, is not to say that Myth #9 regarding certifications if obtained that you are now a guru in DevOps. It’s a simple acknowledgement that at least we all have some basic understanding of the DevOps cultural movement and it’s values. Also like Jason mentions in Myth #4 about having DevOps in the title, it unfortunate but it’s businesses driving this behavior. Because similar to Amazon who paved the way last year by releasing AWS Certified DevOps Engineer - Professional certification, there are going to be more and more companies in the DevOps space releasing certifications that are specific to their products and/or platforms. Once again, all this really means is that you have a basic understanding of those specific products and/or platforms. Which leads me to the main topic of this posting…

Don’t Get Hung-up on a Job Titles:

  • Read the job description from beginning to end. Because employers are always going to include a laundry list of skill they would love candidates to have, but if you have 50-80% of those skills I’m sure you can at least get past on getting an initial phone screen.

  • If there’s a particular job skill you’re noticing the majority of employers are requesting, invest your time in learning that particular skill by setting up a lab environment and practicing over and over again. Practice makes perfect.

  • Have a heart to heart talk with the recruiter or human resource person so that you’re not wasting their time and they’re not wasting your time. A lot of times translation meaning get lost in email, don’t be afraid to ask for a callback to have a thorough understanding. Remember, communication is key in DevOps.

  • Be open, honest, and transparent with the recruiter. Tell them what you truly know, what you don’t know and what you’re ideal job description looks like.

Always remember, that DevOps is a cultural movement to help foster communication, collaboration, and integration which is not solely meant to improve the technical interaction and relationships between developers and operations but also of all the IT stakeholders.