Yes, DevOps Is a Role: You Just Do It Wrong.

AKA: What DevOps Really is.

If you have read any articles/books/etc about DevOps, you have probably heard the phrase, “DevOps isn’t a role, it’s a culture!”. There are even some articles/papers/books, that go as far as trying to say that by making DevOps a role, you prevent your company from ever having a DevOps culture.

If you have ever wondered what DevOps IS, you have probably noticed that people seem to have a difference of opinions. (If you are reading this because you yourself are wondering what DevOps is, keep reading) This article is my explanation for why DevOps is a role, which I will explain by very thoroughly explaining what DevOps is. The main reason people say that DevOps isn’t a role, is because they don’t understand what DevOps is, or more accurately, they apply the label loosely to what DevOps isn’t.

Let us start by discussing the origin of the word DevOps. Sometime before 2009, some people came together to discuss the cross-section of Developers and Operations. A lot of organizations had the two things as two completely different departments. Developers wrote the code, while the operations people put the code on servers and maintained the servers. The problem was that this way of working, is actually opposite of how companies like Google and Amazon function. Discussions happened over time about bridging the gap, and in 2009, Patrick Deboi essentially coined the term DevOps when he created a conference to discuss these ideas, called DevOpsDays. DevOps, in this context, means the merging of Developer and Operation departments. Developers now do ops, and Ops people now do development. The main thing to note here, is that when people say, “DevOps is a culture”, they are correct. DevOps is essentially like agile. It’s more of a culture than a specific practice. You can’t just “practice agile development” by hiring “agile developers” or scrum masters, it requires a whole different way of working for the entire company.

As DevOps as a culture started gaining traction, certain technologies and companies started marketing themselves as “DevOps tools.” Essentially, they were saying “This tool can help you implement a DevOps culture.” Which is about as silly as marketing a task tracking software as “agile process management app”. But, before I digress, that is what happened. So here we are, with a bunch of devops tools such as CI/CD, docker, metrics, tracing, etc. Basically, any tool that helped Developers do more ops, or Ops do more development. (Quick side note: It’s actually funny that docker is considered a DevOps tool now, considering its entire premise was to increase the separation between ops and dev, not decrease it.) Many, many articles and books speak about this culture, so I am purposely not going into much detail here on what DevOps culture really is. (I recommend the book “Accelerate” if you want to read up more on what DevOps culture really means). As these DevOps tools started to be more common, so did the need for roles of people who had a skillset working with these tools. For lack of a better term, people started calling these people DevOps engineers (The rule of thumb in business is if you want to attract smart people, throw the term “engineer” at the end of the job title). Also, on a completely different vein, similar to how people who build frontend applications are called “Front End engineers”, software developers, who build devops tools, sometimes, for brevity, call themselves DevOps engineers. For those who are lost, essentially, we now have two definitions for the term “DevOps Engineer”, one for those who use DevOps tools, and one for the developers who build those tools.

Now that we have that quick history explained, I am going to teach you an entirely new term. DevOps. But what is DevOps you ask? So glad you asked. To explain, lets leave the land of software engineering for a bit.

A lot of companies like to make money. A common way to acquire new sources of cash, is to hire people who find customers and convince them to pay you. If you have a team of people who do this, they are often called a “Sales Team”. Also sometimes referred to as a “Sales Floor,” a “sales organization,” or even just “sales”. Sometime around 1970, companies started to organize and optimize their sales team more. Roles were created for a new kind of job, which responsibilities included whatever allowed the sales team to be even more effective. Essentially, the premise is, “what if you treated your sales team as if it was an entire organization?” Can you optimize it to the extreme? This concept is called Sales Operations. The operations around how you run sales.

Because “Sales Operations” is a mouthful, and because T9 texting convinced our society to shorten everything, even IRL spoken conversations, this is often referred to as just “Sales Ops”.

If you can take a sales team, and make them significantly more effective, why not do it to all of your departments? Well, most really great companies, do. In fact, the title COO — Chief Operations Officer, is all about that. How can we get the core of the business to work even more effectively. You will notice that COO has nothing to do with servers, deployments, docker, CI/CD, etc. It is entirely about the business’s ability to work effectively. So, what do you call someone who does the same thing as a Sales Operations team, but for developers? They would be called Developer Operations, or, if you have been following along, DevOps. While I can’t definitively say, I would venture as to say the term DevOps existed in this capacity before the term DevOps was coined. At least google trends on the term DevOps (https://trends.google.com/trends/explore?date=all&geo=US&q=devops) claims that it was searched for at least once in 2005, many years before “DevOps was born” in 2009.

Hopefully by now, you are as confused as ever. The term DevOps is conflated. The reason why people can't agree on what DevOps means, is because it literally means different things, kind of like the difference between wind and wind, bat and bat, object and object, desert and desert, lead and lead. Basically, everyone is right and wrong at the same time. Some might argue that the conflation of terms is precisely why we shouldn’t have a role called DevOps. These people usually prefer a title such as Site Reliability Engineer. But Site Reliability Engineering (A term google invented) is known as a specific implementation of DevOps (similar to scrum vs agile). Which means, these very people are still calling themselves DevOps Engineers. If you say DevOps is a culture, and SRE is an implementation of said culture, then SRE is a culture not a role. The fact that SRE is _not_ conflated with Developer Operations makes this statement even more true. Fun fact: Google, the creators of the SRE term, don’t even have “Site Reliability Engineers”, but they do have “Systems Engineers” and “Software Engineers” in the Site Reliability Department.

If your concern is the conflation of terms, I feel for you. It really is confusing. The real culprit, however, is the term “Operations”. The term operations was used in business well before computers and servers existed. I am not sure why the IT department started calling server management operations, but I assume they did because it was a generic business term that made sense for an IT centric business whos main product was a website. With good intentions, the term operations now means different things. If you would like to fix the confusion around DevOps and the different meaning, perhaps a better place to start is with the term Operations. Another term, which is equally understood is the term Infrastructure. Now, if you work in a business that has something to do with construction or renting office space, that term might also be conflating, but for technology as a whole, infrastructure is more widely seen as servers. Go ask your local “not-a-tech-guy” what “operations” vs “infrastructure” means if you would like to verify my claims.

If we call server management “Infrastructure”, then the correct term for DevOps culture would be something along the lines of InfraDev, or DevInf. (Noted: it doesn’t roll off the tongue the same) However, the term DevOps would now be more clear, as to only be about developer operations. Now, we still have conflation between what an InfraDev Engineer is, so here is a proposal (I thought about using terms other than “engineer”, which actually makes thing make more sense, but it seems that every role in a company has engineer in it these days, so I stuck with that):

• InfraDev Engineer — A person who primarily works with InfraDev tools.
• Infrastructure Engineer — A software developer who works on infrastructure as their main platform. (Builds InfraDev products). Think: Backend Engineer, Database Engineer, FrontEnd Engineer, Mobile Developer.
• DevOps Engineer — A person who focuses on Developer Operations. Responsibility is about making the development teams themselves more productive.
• SysAdmin — The person who's main responsibility is the management of the servers. This role doesn’t need to go away, but due to cloud computing (NOT the devops movement), this role is not necessary in all companies. Cloud platforms can often serve this role instead of actually having it as a full-time position.

Now that we have non-conflating terms, at least for the scope of this article, lets re-advise what people are really saying.

“DevOps is a Culture, not a role”

If the above was rewritten with our new definitions, would be “InfraDev is a Culture, not a role”, which is true. The title InfraDev Engineer above, is actually the heart of this phrase. If you have a InfraDev role, or even an InfraDev team, you are likely doing something wrong. The idea is for developers to be able to “self serve”, and the tooling is only there as an enablement for the culture. If you have people who specificaly set up and manage all the InfraDev tooling, and the developers can’t function/deploy/etc without that team, you are not doing InfraDev.

Should Infrastructure Engineer be a role? Yes! Why not allow another specialization. If writing backend code is different than front end code, and front end code is different that mobile code, why cant we accept that infrastructure code is different as well? People who write tooling for infrastructure need a correct title to specify their strengths, and no, SRE is not it.

Shoud DevOps engineer be a role? Yes. Absolutely. In fact, I would go so far as to say if its not, you are failing. You can call it whatever you want, but if you don’t have at least one person focusing on developer operations, then you are not a high performing team. More on this at the end.

But wait, it gets worse.

Earlier, I recommended a book, Accelerate, which talks more about the DevOps Movement, I mean, InfraDev Movement. This book talks about metrics and things you can do help understand if your team is high performing. You will notice that this book is talking about high performing teams, or, in other words DevOps, but it itself, is very narrow focused on specifically the Delivery aspect of software development. The book even explains that the Lead Time metrics is measured in “from code commit to production”. It has zero focus on time it takes to actually get work done. In other words, the things the InfraDev movement is interested in is a subset of what Developer Operations is about. Not only are the terms conflated, but they actually have a lot of overlap. InfraDev should be a major focus of any Developer Operations team, but InfraDev itself is a single component. If we reference our Sales Operations picture way above, you see that in this image, they have 4 main responsibilities. InfraDev would be one of the smaller bubbles. Or, to put this back into confusing words:
DevOps is always DevOps, but DevOps is not just about DevOps.

DevOps as a role, while often called different things, is vital to a technology organization.

As a fun excercise, go interview some Sales people you know, or even some VP’s. Ask them what happens when you run a sales team, but dont have someone dedicated to Sales Operations. They will likely talk about how individuals optimize for the short term, and if no one is focusing on the big picture, you are likely to get caught in the weeds. Without sales operations, 3 things are possible: 1) a sales team will remain mediocre indefinitely, which actually means slowly getting worse as the team grows. 2) The team will stumble upon greatness for a small period of time. 3) The team will optimize for the short term, think it is making improvements, but is actually getting worse. The same applies to a software engineering team. So many things are important for improving developer effectiveness. This is also often called “developer experience”, because developers are usually happiest when they can focus on the actual code, and get everything else out of the way. Improving developer experience and effectiveness, are the same thing.

I have found that in a lot of organizations that do focus on developer experience, but dont have a DevOps role, the responsibility is typically handled primarily by the CTO. But if the CTO is the only one working on this, you will hit a point where developer experience just falls by the wayside. A healthy, highly effective organization needs people whos main focus, is developer productivity and experience. This includes eliminating every single bottleneck that isn’t in-and-of-itself, writing code or gathering requirements. Things such as build time, testing, logging, deployments, user feedback, debugging, metrics, documentation, etc.

In conclussion, no, I do not expect people to start using these new terms such as InfraDev, etc. I mainly needed to name these terms so that the nuances between the different definitions can be discussed. That being said, when you do talk about DevOps as a role, please know that yes, it is a role, it just depends on what that role actually does. Developer Operations is critical in a software organization, just as Sales Ops, People Ops, COO, are important. Also similar to how agile coach, or scrum master, are still roles in an agile culture. In reality, you can call this role what you want, titles already are not representative across organizations (like what does “Senior” mean in Senior Engineer), but certainly dont judge a company by the titles it has; perhaps you are the one who doesn’t fully understand DevOps.