A consultant's most important responsibility (other than stealing your watch, telling you what time it is, and sending you a bill) is to give opinionated advice where it is held.
Most of the time this advice should fall into the "this is my opinion, but going against it is perfectly valid" category. Advice which matches the only reasonable action isn't advice at all, it's an observation.
"Don't use DevOps Engineer as a job title" checks both of those boxes.
I originally wrote my definition of DevOps in less than 30 minutes while waiting for a plane. I had just come from an event where questions afterwards made it clear that I needed to clarify what I mean when I use the word. I didn't publish it for weeks out of fear of alienating people, or worse, gatekeeping new folks who are quite reasonably responding to the market.
I'm sure that people in an audience during a talk, watching a video online, or reading a blog post feel personally attacked or judged when I say this and it haunts me.
The indisputable fact is this; DevOps Engineer is a valid, accepted job title in the market.
Individuals
Do the right thing for your career.
If you're trying to find a job in automation or platforms the majority of job listings may well be looking for this as a job title. Search for it.
Recruiters will be searching for people with this title on websites like LinkedIn. Add it to your profile. Also add a description of your responsibilities that demonstrates you understand this is not a sole contributor role (if you agree that it's not).
After you get the job, try to influence your organization into understanding that DevOps is a way of working. Just like someone with a DBA background will most likely be more knowledgeable about the database, you may be more knowledgeable about the platform or automation, but you both should contribute to the team's shared understanding. This will make both you and the organization more effective.
Organizations
When filling roles which require automation or platform expertise, feel free to use and advertise the title DevOps Engineer. Qualified candidates will be searching for it. Make it clear in the job description that while they may be a subject matter expert, a large part of their responsibility will be creating and maintaining a shared understanding of areas.
I still recommend that you avoid actually giving people the title of DevOps Engineer. Not because I don't like it, but because it implies individual ownership. If your people believe (even subconsciously) a part of your system is solely someone else's responsibility they won't learn about it. This is not because they are lazy, it is because they are focused.
When people with more experience writing code understand the deployment platforms where that code will be running and the automation that will get it there they will create better code. When people with more experience in platforms and automation understand the code that is being developed they will create better platforms and automation.
I said above that a consultant's most important responsibility is to give opinionated advice. The second most important is to understand that the advice is just one data point, and the person receiving it should receive your full support for choosing not to follow it.
Top comments (8)
Ya, it's kinda funny and I agree (even though I have benefited from the funny). We don't have agile engineers or an agile team that does all the company's agile for the other engineering teams, yet we do for DevOps. I think it's because management looks at DevOps as a bolt-on rather that than the application of lean manufacturing to the software delivery context ie org change... but is it a problem unique to DevOps? We often have all these other engineer titles that put us in a box, data engineer, frontend engineer, ML engineer, integration engineer, cloud engineer, etc.
When building an engineering team at the last startup I worked for the titles were Software Engineer with pay grades 1-7. What might set one engineer apart from another is working on a different context of business that may or may not use different tools & tech but everyone was a software engineer first (or at least aspiring to be an engineer).
Well, some orgs need a bridge between dev and ops just like you often have a bridge between devs and sales. As long as communication still flows between the departments, I don't see a problem with having a "DevOps Engineer" position.
That's reasonable, but I disagree. The goal of DevOps is that there should not be separate dev and ops. I strongly believe one team should be responsible for scoping, building, and running the software.
They aren't separated though; I work with devs to address current and potential ops issues at the root. It might sound a bit dysfunctional but it still follows the "second way" from the Poenix Project AFAIK.
How about "DevOps Architect".
By "Architect", I mean the person who organize the environment so that the people who live in the environment have a uniform knowledge of 4w1h to solve their concerns efficiently.
It is similar to when you "architect" the application code so that developers who write the actual code know which code should be where.
For example, developers don't ask an architect to write code for, says, a controller. They ask "what is in a controller and what is not". Architect can create a "framework" to accommodate and ensure that a controller written by any developers satisfies the definition of a controller and does not miss any concerns.
Similarly in terms of DevOps, an architect create a "framework/pipeline/process" to accommodate and ensure satisfaction of what the team may deem of DevOps concerns such as 4w1h of CI/CD, monitoring, logging, automate testing, security scan etc. No one should ask a DevOps architect to do the deployment or checking the application log files, but the architect should tell them how to do it, in the way that utilize automation to minimize silos and maximize productivity among team members.
This is where I get fairly pedantic (perhaps overly so) about the definition of terms. The way I define DevOps Architect wouldn't fit. In my opinion, there's no such thing as a "devops pipeline" or "devops platform".
That said, I'm a strong believer in platforms in general, especially when the teams creating them are acting as a product team in a DevOps (cross functional, value based) culture. As I think you are getting at, this team could architect something like a continuous integration platform which enables other product teams to define their own pipelines.
Side note, but something to be aware of; In some organizations the term architect has come to mean an ivory tower department of no, with heavyweight controls like change review panels and such. I don't think that's what you're suggesting, just something to be aware of when creating role titles.
Maybe a better title should be "DevOps Facilitator" as the real issue in DevOps it that it's often hit-or-miss, and usually only after some catastrophic failure. Much like "Security Facilitator".
It's a hard problem(tm). I like the message of what you're saying, wondering if people would think of "facilitator" as a trainer / meeting organizer.
To be completely honest, this whole thing also falls into another thing I like to avoid, advising someone not to do a thing but not having a great alternative. I sort of wish everyone's title could be "team member" and you could somehow magically staff with the right balance of knowledge.