Why “DevOps Engineer” as a Job Title is Misleading

I’m often asked why I dislike the job title, “DevOps Engineer” so much. It’s not that I begrudge anyone a great title, which that clearly is (if you’re a nerd). It’s that applying DevOps to a job title can be a red herring, and make companies think they’re “doing” DevOps, when in fact they’re not.

My favorite site for explaining what DevOps is is DevOps Topologies. This site explicitly recognizes what DevOps truly is: an org chart. If you’re “doing” DevOps, then you’ve created an org chart for your organization that looks a lot like one of the successful variations presented on that site. That’s because DevOps is ultimately about?delivering products to their consumers,?meaning it’s about?how you conduct yourself. DevOps is about processes, and org charts engender processes.

Consider a company that manages software projects for a living, and who specializes in Agile project management. You might imagine the company employing a number of project managers. And you might imaging those project managers needing some tools to support their processes. Perhaps, for example, they rely on Microsoft Project Server. Cool. Project Server will likely need to be installed and maintained by someone. Is that person therefore a “Project Engineer,” or are they simply an IT person with some needed product knowledge? Is Project Server the company’s value-add, or is Project Server merely a cog in the company machine? Is Agile what the company is really selling, or is?project management the company’s actual “product,” with Agile merely being their methodology?

Consider a company that helps produce software products for a living, and who specializes in DevOps for software delivery. You might imagine the company employing a number of coders and IT people. And you might imaging those people needing some tools to support their processes. Perhaps, for example, they rely on Team City for their build pipeline, and Git for source control. Cool. Team City and Git will likely need to be installed and maintained by someone. Is that person therefore a “DevOps Engineer,” or are they simply an IT person with some needed product knowledge? Is Team City and Git the company’s value-add, or are they merely cogs in the company machine? Is DevOps what the company is really selling, or is?software the company’s actual “product,” with DevOps merely being their methodology?

Hopefully you can see the parallels. I do understand that the technologies and techniques which support a DevOps organization – especially a large one – are varied and complex, much more so than a shrink-wrapped product like Project Server. And so the person responsible for implementing and maintaining them might have a full-time job on their hands, and so calling them a “DevOps Engineer” is probably nicer than “Technician Who Installs and Supports the Tools and Technologies that Support our DevOps Processes,” which would likely not fit on a business card of reasonable size. “DevOps Tooling Engineer” might be more accurate, if less sexy. It’s not the job title?per se I worry about; it’s that companies can (and do) apply that title to people?without actually adopting the DevOps processes.?So they fool themselves into thinking they’re “doing” DevOps, and then wonder why they don’t get the commensurate benefits.