No, You Are Not a DevOps Engineer

Ask five IT people what the term DevOps means, and you will likely get five completely different answers. Go to any online job board, search DevOps, and look at the job descriptions, and you will see great disparity in the desired skillsets and responsibilities, as well as job titles. Go to LinkedIn and search for people using DevOps, and you will see thousands and thousands of people calling themselves DevOps engineers. Some of them may even claim having up to ten years of experience. I find it quite amusing that nobody can define what it is; very few companies are actually doing it and doing it well, yet we are all experts at it.

What is DevOps?

Let’s get one thing straight. DevOps is not a person; it is not a job; it is not a role. I have written this many times, but my definition of DevOps goes like this…

DevOps is a culture shift or a movement that encourages great communication and collaboration (aka teamwork) to foster building better-quality software more quickly with more reliability.

Let’s break this definition down. The first key phrase is “a culture shift or a movement.” Notice this does not say a person or a role. The next phrase is “communication and collaboration.” Again, we are not talking about a person or a role, but a mindset for getting teams to work more closely together with common goals in mind. The final component is the end goal: “better, faster, more reliable.” DevOps is all about getting to market faster with products that meet the businesses requirements and run without constant hand-holding and fire-fighting.

DevOps is the progression of the software development lifecycle (SDLC) from waterfall to agile to lean. DevOps goes beyond agile and focuses on removing waste from the SDLC. Often, the waste or bottlenecks are found in the forms of inconsistent environments, manual build and deployment processes, poor quality and testing practices, lack of communication and understanding between IT silos, frequent outages and failing SLAs, and whole suite of issues that require precious IT resources to spend significant time and money keeping the systems running.

What I am seeing in the enterprise

Enterprises are struggling with DevOps. They all want DevOps even though many do not know what it is. In many cases, I see infrastructure teams who are calling themselves DevOps leading a grassroots initiative. When I ask them where the development team is, they often say either “we did not invite them,” or even worse, “we don’t talk to them.” This is where I want to interject and say, “no, you are not a DevOps engineer.” A better consultative approach, however, is to take them through a few slides showing them how DevOps evolved, what the business benefits of DevOps are, and how the organization needs to change to achieve those benefits.

Another reoccurring pattern I see is that a “DevOps” team’s first step is often to figure out if they are going to use Chef or Puppet (or Salt or Ansible or whatever else is hot). They have not even defined the problems that they are setting out to solve, but they have the tools in hand to solve them. Often these teams wind up building thousands of lines of the scripts, which raises the question, “are we in the business of writing Chef scripts or in the business of getting to market faster with better quality and more reliability?” Too often, these teams code themselves into a corner with mountains of proprietary scripts that actually add more waste to the system, instead of removing waste from the system, which is what the driving forces behind the DevOps movement are all about.

In essence, the old bottleneck of procuring and installing new hardware becomes replaced with a new bottleneck of creating tickets for the “DevOps engineer” to create new Chef scripts to create the necessary environments for the app dev team. Had the teams worked together in a collaborative fashion instead of in silos, they could have a created a framework for self-service provisioning that provides the operations team with the proper controls and the application team with the tools to get their job done faster.

What I often see is that the operations teams enforces what makes sense for operations and creates a very restrictive environment for the application team. This can lead to a bottleneck where the app team must stand in line to wait for changes, or even worse, the application team goes around the operations team and starts doing its own thing on AWS totally ungoverned. Too often, I have seen companies approach DevOps from only an operations perspective and build a bunch of nice tools and processes that nobody uses because they never involved application team in the process.


DevOps is not a person, a role, or a title. You are not a DevOps engineer, even though you may call yourself one. DevOps is all about getting better-quality, more reliable products to market faster by being more inclusive and improving communication and collaboration within the enterprise. Most enterprises do not need to mimic what web giants like Facebook, Netflix, and Etsy are doing. But to stay relevant in the fast-moving world of mobile and cloud, enterprises need to replace old, slow, high-touch processes with a modern approach to software development and operations.

Posted in Transformation & AgilityTagged , , , ,

Leave a Reply

14 Comments on "No, You Are Not a DevOps Engineer"

newest oldest most voted

[…] my latest post at the Virtualization Practice, I discuss the struggles that enterprises are having with […]


This is one of the best articles I have read on defining what DevOps really is. The author nailed it with this: “DevOps is the progression of the software development lifecycle (SDLC) from waterfall to agile to lean”. YES! We started this movement in 2009 and it has been tremendously successfully. We created a team composed of Architect or Lead Developer, Developer(s), Project Manager, Business Analyst, QA tester and Operations\Platform Engineer. The results have been that we deliver value to the business faster and with far less issues than with the waterfall approach with team silos.

First, thanks for the article. I agree with your definition of what DevOps “is” as a practice, but I disagree with this: >>DevOps is not a person, a role, or a title. You are not a DevOps engineer, even though you may call yourself one. What do you call someone who’s role is to enable the DevOps practice at a company? This person might do everything from getting the company on git, helping build unit/acceptance tests, enable CI/CD with jenkins, setup and maintain configuration management with puppet, help developers spin up environments with Vagrant+puppet, maintain the deployment scripts, and own… Read more »

Thanks a lot for the author for explaining brief about DevOps term.


[…] people, including myself, have written endlessly on this topic with a unified message that DevOps is not a role or a person. Instead, it is an approach geared towards building better software, faster, and more […]

I’d like to expand a little to what Jason mentioned. In my view, the DevOps role is two fold. The first is what Jason mentioned…helping to set up the infrastructure to enable a lean operations process. The second role (which I’d say is more crucial) is having someone open up the lines of communication. You need a person who can “talk the language” of developers, operations, QA and release teams. Without this, you will not build up enough trust to change the culture. There’s a perception that the developers and operations teams have opposing goals. The developers want to push… Read more »

[…] On a larger scale, Mike Kavis, VP/Principal Architect for Cloud Technology Partners, puts it quite bluntly on a post titled No, You Are Not a DevOps Engineer. […]


[…] I gave last night at our monthly Tampa Bay Cloud Computing meetup. The first article was called No, you are not a DevOps Engineer and the second was titled The Value of DevOps in the […]


[…] things got really ugly. For those who have followed my DevOps writings and my rant called “No you are not a DevOps Engineer“, what I am about to describe is the basis for my position on […]


[…] I talk about that article, I want to clarify the meaning of DevOps. I am going to use the definition by Mike Kavis , which […]


[…] –      No, You Are Not a DevOps Engineer […]

Top 5 ways DevOps gets IT done |

[…] Kavis (an industry thought leader) describes it this way “DevOps is a culture shift that encourages great communication and collaboration (aka teamwork) to foster building […]

Thanks for your post … I have removed DevOps from my title because what I am seeing exactly what you are seeing but it goes something like this “When I ask them where is the operations team is, they often say either “we did not invite them,” or even worse, “we don’t talk to them.” I am seeing DevOps being more NoOps there is a great event called DevOps Days but the funny thing was it felt like Developers are now expected to do what operations did. Now that we have the Cloud adoption widespread there is mutiny going on… Read more »