DevOps Engineer isn't a job title, except it is

Ken Mugrage — Wed, 09 Dec 2020 20:25:01 +0000

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.

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.

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.

My Definition of DevOps

Ken Mugrage — Tue, 08 Dec 2020 16:09:12 +0000

I'm new to Dev.to, and will probably post about DevOps, so thought it was important to share what I mean by the phrase

DevOps: A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system.

The term DevOps is more than 10 years old now, but if you ask 10 people for a definition of the term you'll get at least that many answers. I wrote my definition a few years ago so that people would know what I mean when I use the term in talks and writings.

A culture

You can’t “do” DevOps.

… where people, regardless of title or background …

A lot of people think of DevOps as Developers and Operations. Thought of this way, the term DevOps leaves out of a bunch of groups involved in the process. Trying to add everyone involved to a single term is an exercise in futility, and would be silly even if it wasn’t. Nathan Harvey explained this quite well in his talk “Rugged Enterprise DevSecNetQAGovOps”. (Spoiler alert: If you mix Sugar, Flour, Cocoa, Salt, Baking Soda and a few other things together, you don’t get SugFloCocSalBak, you get a cake.)

It’s about developing and operating a system. They are verbs.

A variety of backgrounds is every bit as important. This is why diversity (in all of its varieties) is so stressed at good DevOps events. If everyone has the same experiences and viewpoints, your chance of creating something with wide appeal is pretty darn low. To say nothing of the fact that it’s just the right thing to do.

All of this as a very long way to say it means the whole team.

… work together to imagine, develop, deploy …

There was a project at ThoughtWorks around 2006 that spurred much of our work on Continuous Delivery. The team developed a Java application on Windows, and when it was “done” they deployed it onto Solaris. It didn’t work.

What if the people who really knew how to run the Solaris systems and would end up being responsible for the application for years to come had been on the team? Better yet, what if they were pairing with the people creating the code? Better even still, what if that whole team was responsible for the application for the rest of its life?

Dev: I’m gonna do it like this
Ops: If you do it that way it will blow up when we try to use NFS on Solaris
Dev: Oh, what if we did it this way?
Ops: That would work, but still could be flaky and result in us both getting paged at 3AM.
Dev: I don’t want to get paged at 3AM, what do you suggest? (slides over pairing keyboard)
Ops: Let’s do it this way.

Lots of rework avoided.

Note our fictional alteration of history did not include the Ops person learning advanced Java. It also did not involve the Dev person getting certified on Solaris. It involved a team with a broader knowledge of how the system would be run. (Oh, and as a result the Dev person learned a bit about Solaris and the Ops person learned a bit about Java. Happiness.)

I’m sure you can think of similar interactions between all types of roles.

… and operate a system.

System is the word I’m least comfortable with in this whole thing. I couldn’t think of a better one sitting here in an airport, but feel free to let me know if you do.

The key here was actually hinted at in the previous section. If the system goes down at 3AM, a team member on call gets paged. Not the person.

As Amazon CTO Werner Vogels says; “you build it, you run it”.

Platforms play an important part

It’s important to note that with the definition (and the evolution of my understanding of DevOps since originally writing this) I don’t mean to imply that the team creating the system is the only one who controls any part of their infrastructure.

I’m a huge fan of making a platform available to the organization. A proper platform can enable teams to be self reliant while also ensuring important factors such as security and compliance are accounted for.

I was planning on adding another post describing what I mean when I say platform, but my ThoughtWorks colleague Evan Bottcher has already done a much better job than I would on Martin Fowler’s site at https://martinfowler.com/articles/talk-about-platforms.html.

DevOps is definitely not a role.

A job title of “culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system engineer” would be pretty silly. I believe “DevOps Engineer” is just as bad.

Hire the skills you need to fill out your team, not catchy titles.

DEV Community: Ken Mugrage