Whoever gets too hung up on this must've never had to hire people to do what the DevOps culture they so want to implement needs.

If your plan is to just hire software engineers, you're going to have confused applicants, if your plan is to hire sysadmins, they probably will have a different skillset than you need. Most real companies hire DevOps engineers because that's the way to get the people with the skillsets you need.

Being so purist about this sounds to me like useless debate, but maybe you have better suggestions.

At my current place we stopped hiring DevOps and started hiring SREs + software engineers for specific internal teams, but for a few years there between 2010-2020, good luck getting people with DevOps skills without actually advertising DevOps roles.

You can certainly advertise a DevOps culture in a listing that isn't for a DevOps engineer, it's not mutually exclusive.

What's DevOps skills in your opinion?

I think that it's less important to make the distinction nowadays because systems engineers use developer tools and modern practices. 25 years ago when I was a "Junior Linux systems administrator" my peers kept their vast collection of shell scripts on a file server if you were lucky - some hoarded their own "craft" and kept them on their personal workstations. Scripts got copied onto machines and executed. There was no CI/CD because in most places, systems folk didn't use version control. The best we had back then was a PXE boot server + kickstart files + custom packages. Married to virtualization, this gave you a pretty flexible way to roll out big changes without having to run around with CDs and then manually install and configure software. If you were really lucky, some bright spark put the package source files in CVS, and maybe even triggered RPM automatically, so newly built or rebuilt servers were in an almost ready state from the start. But system state would begin to drift immediately, and you could almost guarantee that the Apache config in one box wouldn't match the next. While frequent automatic server rebuilds were the gold standard, few shops actually implemented that. That meant that systems engineers needed to be able to fix anything. Manually. This required intimate familiarity with the content of system files for GRUB, PAM, dhcpd, init scripts, if-scripts, LDAP, NFS, Apache, SendMail... In fact, the ability to manually hack on those things were the skillset for a systems engineer. Look at the RedHat 6 RHCE exam curriculum!

If you could write complex shell or perl scripts, and you knew how to dig into performance metrics on the fly, you were a god. (Yeah, capturing and displaying system metrics was in its infancy, and most shops simply didn't know how to do it)

While some systems were built to be "horizontally scalable", you were lucky if you worked with systems that weren't SPOFs. You were happy with redundancy via active/passive failover (and that was probably a manual affair). Maybe if you were really lucky, you worked for a SaaS that served a monolithic website via a fleet of webservers behind an F5 loadbalancer. "Wooooah!". But you still set up those F5 VIPs and pools manually.

The modern systems engineer rarely has to do anything like this, even though the underlying technology is similar. These days everything you care about is in git, and is mostly testable on git push. Modern companies, including tiny 4-person SaaS startups, can have infrastructure-as-code, configuration-as-code, packer configs, dockerfiles, container orchestration, CI/CD, metrics collection, USE/RED metric graphs for every system with alerting, pager, incident handling runbooks...

At some point over the last 25 years, the term Systems Engineer could mean that you're an expert in the old ways or the new ways. When you advertised for a DevOps engineer, it left no doubt that you were looking for the modern variety and expected that experience and skillset.

I supposed instead of saying DevOps has lost its meaning it has been co-opted from it's original meaning to something else. Problem is just that it isn't well defined. I like a definition like this, but as an earlier comment talked about a DevOps role is about facilitating the DevOps culture values, which is quite the different thing.

On another note, how amazing it is to define our systems so we can more systematically iterate on them and improve. I love it when developers get integrated into the process as well.

The general consensus where i work is that everyone does DevOps, you develop the app, you make sure you deliver the app, if there's any issues you debug. You ain't done until your ticket is in production, and you can't point to other to solve it for you, only help you.

Where does the DevOps engineer fit in there?

> where does the devops engineer exist there

Improving pipelines. Dealing with downtime on the CI. Improving performance of the CDN. Writing better tooling for the devs to deliver value even faster.

You can also advertise for zookeeper or chef, but if you want people doing X, a good bet is to advertise for X.

I asked for alternative suggestions and offered what we use. If you have suggestions of alternative titles you've successfully used to hire without slowing things down I'm all ears.

> What's DevOps skills in your opinion?

The most important skill is knowing to not fall for the bait that is this question so that you can actually work.

But if you want Software Engineers that will take up DevOps skills and responsibilities, surely you'd want to advertise this DevOps culture instead of a role? Advertising this as culture is likely to attract people that want to work in a place without a DevOps/SE stratification.

I think the only reason to advertise for it as a role, is when your tooling is too complex and you've given up looking for Software Engineers that could do it on the side. Which is fair enough, I guess, though providing a Golden Path nowadays is probably more popularly done by hiring Platform Engineers.

I'm all ears when you're on brake.

Generally, in my experience, an individual who says, "DevOps is a culture, not a title", does not know what DevOps is. It can be both, and exclusive, at the same time.

https://link.medium.com/tC5p4nfYCib

I think there's a point to the blog article itself, but i think you miss a vital point in the conclusion. The way a DevOps position that is described in the blog post is a valid position that could have DevOps in the title. But that's not usually how the DevOps role is used. This can be easily seen in many listings of the job title.

The analogy with agile is pretty good here. Sure you could have an Agile Engineer, that works primarily with making sure the agile process is actually used and help facilitating that. Normally that would not be a position itself though, especially not an engineering one.

> you miss a vital point in the conclusion

Never had someone tell me I dont understand my own conclusion to my own article before. Thats a first.

You can certainly misrepresent your own article. But in this case you're arguing different things as far as I interpret your text.

My argument, in both cases, is that devops can be a title, and that the blanket statement "Devops isnt a role", is incorrect. Sure, maybe some job postings are still wrong, but that doesnt mean they are all wrong.

"DevOps is great, but it's not a title."

If you are out there interviewing for a DevOps job and you hear things like this: run. Every meeting you have with this person will be a living hell. Endless debates on semantics and definitions while your project is due today.

So you think the issue is semantics and not understanding? Being due today and having 5 developers thinking the end goal is different and working against each other is way worse then spending some time building consensus and work toward the same goal

In many way the adoption of DevOps has many similarities with the larger adoption of agile development. It just looses it original meaning in a world of little reflection and just surface level knowledge.

Those who can manage to surpass that though can get great productivity from it though.