DevOps Engineer isn’t a job title, except it is..

~ kmugrage ~ Leave a comment

A consultant’s most important responsibility (other than stealing your watch, telling you what time it is, and sending you a bill) is to give opinionated advice where it is held.

Most of the time this advice should fall into the “this is my opinion, but going against it is perfectly valid” category. Advice which matches the only reasonable action isn’t advice at all, it’s an observation.

“Don’t use DevOps Engineer as a job title” checks both of those boxes.

Tweet about DevOps Engineer as a job title

I originally wrote my definition of DevOps in less than 30 minutes while waiting for a plane. I had just come from an event where questions afterwards made it clear that I needed to clarify what I mean when I use the word. I didn’t publish it for weeks out of fear of alienating people, or worse, gatekeeping new folks who are quite reasonably responding to the market.

I’m sure that people in an audience during a talk, watching a video online, or reading a blog post feel personally attacked or judged when I say this and it haunts me.

The indisputable fact is this; DevOps Engineer is a valid, accepted job title in the market.
Alt Text

Individuals

Do the right thing for your career.

If you’re trying to find a job in automation or platforms the majority of job listings may well be looking for this as a job title. Search for it.

Recruiters will be searching for people with this title on websites like LinkedIn. Add it to your profile. Also add a description of your responsibilities that demonstrates you understand this is not a sole contributor role (if you agree that it’s not).

After you get the job, try to influence your organization into understanding that DevOps is a way of working. Just like someone with a DBA background will most likely be more knowledgeable about the database, you may be more knowledgeable about the platform or automation, but you both should contribute to the team’s shared understanding. This will make both you and the organization more effective.

Organizations

When filling roles which require automation or platform expertise, feel free to use and advertise the title DevOps Engineer. Qualified candidates will be searching for it. Make it clear in the job description that while they may be a subject matter expert, a large part of their responsibility will be creating and maintaining a shared understanding of areas.

I still recommend that you avoid actually giving people the title of DevOps Engineer. Not because I don’t like it, but because it implies individual ownership. If your people believe (even subconsciously) a part of your system is solely someone else’s responsibility they won’t learn about it. This is not because they are lazy, it is because they are focused.

When people with more experience writing code understand the deployment platforms where that code will be running and the automation that will get it there they will create better code. When people with more experience in platforms and automation understand the code that is being developed they will create better platforms and automation.

I said above that a consultant’s most important responsibility is to give opinionated advice. The second most important is to understand that the advice is just one data point, and the person receiving it should receive your full support for choosing not to follow it.

Using your pipeline to enforce corporate rules

~ kmugrage ~ Leave a comment

I just took part in a discussion about Continuous Delivery fundamentals at a conference. During the conversation different questions came up about security and compliance, with reactions varied from “well of course you have to do that” to anecdotes about shadow IT where corporate polices are ignored.

It wouldn’t have been appropriate for me to point this out in the conversation, but this is one area where the differences between a CI tool and a CD tool really stand out.

I talked about the ability to run things like security pipelines in parallel with other pipelines in a blog from a couple years ago ( https://www.gocd.org/2016/02/08/not-done-unless-its-done-security ) but I may not have pointed out of one the most powerful options…

The folks responsible for designing and maintaining the security and compliance checks don’t have to be on the product team.

This diagram represents a single pipeline fanning out into two pipelines and then back into one. It’s important to note that these are not just parallel jobs, but entirely different pipelines.

It’s possible in GoCD to have the security / compliance pipeline be under the care of a dedicated team. As much as I’m a fan of cross functional teams, it’s not always reasonable to have all the knowledge you need on a product team. It’s also possible that you would want the work verified by another team for other reasons.

It’s this possibility of parallel pipelines that came to my mind first when I read the new “trust teams but verify” theme for the latest ThoughtWorks Radar. I think it’s a great way to make sure you’re following all the corporate rules (which are there for a good reason) without slowing down your development.

More information:

Is it time to give up on what DevOps isn’t?

~ kmugrage ~ Leave a comment

We recently completed DevOpsDays Seattle. The feedback for the event was overwhelmingly positive in most areas. The exception was some feedback that there weren’t enough technical sessions. This is fairly common with DevOpsDays events, because DevOps isn’t about technology.

Fast forward to this morning… I volunteer to do some mentoring. I was on a Slack channel about DevOps, when someone starting asking Tomcat configuration questions. Again, a technology question. Because in this person’s mind DevOps is what system administrators do.

The problem; most people think DevOps is about technology.

DevOps is about culture. It’s about getting the people developing and operating the software to work together. This shows itself more in organizational structure that any specific technology. I even went so far as to write my own definition of DevOps which I share before doing a talk or workshop so people know what I mean when I say it.

When I was growing up and made a point which may have been correct but didn’t actually help anything, my father would say “That and $5 will get you a six pack”. 

My job is to teach people about Continuous Delivery (which is technical) and DevOps (which isn’t). If people are coming to DevOps events that I’m helping organize and not getting the information they need, am I failing at that job?

Words change meanings over time. Every year the folks who create dictionaries add “new” words which have to make English professors shiver. Maybe DevOps doesn’t mean what it was supposed to mean anymore.

I’m not quite ready to wave the white flag.

All of this said, I’ll still try to teach people what DevOps truly means, because without the culture change the rest of it is doomed to failure. But maybe it’s ok to let a little more technology in the door to meet people where they are.