"Did You Really Mean 'DevOps Engineer'?"

Look out on any popular job search app or service and you are bound to find a nice little “DevOps Engineer” (or “DevSecOps Engineer”) role nestled in the mix of open tech jobs. DevOps is becoming more than just a buzzword. Although many of the concepts are not new, DevOps is about applying Agile & Lean manufacturing principles, processes, and philosophy that have been proven over decades of efficient manufacturing to modern software delivery with the primary differentiator being the capabilities of available, scalable public cloud infrastructure. This DevOps approach is a real thing, rapidly becoming ingrained in IT culture and especially in heavy software and IT product development industries.

One thing is certain in today’s economy - businesses are being forced by market competition and user demand to deliver high quality services faster than ever before. Businesses are driven to modernize their service delivery through software. Our economy tells us that speed to value wins in the business world to deliver outcomes. What is the most effective way for a business to achieve faster software delivery? One word: DevOps. Yep, that’s the answer. With this paradigm shift birthed new role families. 

One of the more apparent, yet loosely defined of these is the DevOps Engineer.

There are key factors that help distinguish what a business is typically looking for when they post jobs for DevOps (or DevSecOps) Engineers. I find that most job postings for DevOps Engineers are either aimed towards a Continuous Delivery Engineer, a CI/CD expert, or even someone with an infrastructure and operations focus, like a Site Reliability Engineer, all of which have critical roles in the value chain to support the delivery and operation of reliable, high-quality software. Senior leaders and executives must recognize how every role in IT plays an important part in evangelizing the practical benefits of DevOps, which I will touch on in subsequent posts.

Although I am happy to hold the title myself, I have a fundamental problem with the title of a DevOps Engineer in that IT organizations attempt to accomplish too much in one position. Most DevOps purists may cringe at the actual title of DevOps Engineer simply because the title tends to be oversaturated and oversold in the market where there are varieties of interpretations. An important concept of DevOps and Agile delivery is the careful breakdown of functional silos, tearing down arduous process boundaries and bringing together cross-functionally skilled resources (development, operations, management, business, etc.) to rapidly achieve common business goals as a well-oiled team. As a caution, I find when a role family of DevOps Engineers is created at an organization, that organization may inevitably, and even subconsciously, create yet another functional silo called “The DevOps Team” (if I had a dollar every time I heard that phrase…). The role then becomes contradictory to that which it tends to eliminate - functional silos! 

If IT organizations insist on hiring DevOps Engineers, they should be more focused on architecture that supports software delivery, creating low-level technology, process, and skills roadmaps to achieve the rapid delivery goals of their business. These resources must be embedded with product teams, empowered to influence decisions, encouraged to reduce technical debt and toil, free to automate development pipelines and software infrastructure, and have hotlines to senior leadership within their organization. In this context, a DevOps Engineer should not only understand their respective technology stack well, or know how to script an automated deployment using IaC concepts, or have heard the word ‘Kubernetes’ before, but they should show evidence that they are proven evangelists of DevOps culture at ALL levels inside and outside their organization, even if (and arguably more importantly) in different roles in the Value Stream. This point gets to the heart of DevOps. Much like IT Security, DevOps philosophy and principles must be fundamentally ingrained in the way we deliver software.