Should “DevOps” be a job title? Are DevOps teams an anti-pattern? Can you do DevOps within a single team? Were the moon landings staged in the Arizona desert? These are the sort of questions you’re never more than 5 feet away from at any DevOps conference or meetup. The answers, of course, are:
- Yes and no
- Don’t be silly
Everyone seems to have an opinion on the whole “DevOps Team/Job Title” question, and I’m no different, except my opinion is this:
I passionately don’t care
Let me explain:
If you have a devops team, and their job is to encourage and develop a devops culture within the organisation, then that’s perfectly fine, surely? If that team is successful and a devops culture blossoms, then you’re definitely winning. Maybe that team could subsequently change its name, but that just seems a bit pointless and overly hung-up on semantics. In this case, I don’t care what the team is called, because it doesn’t matter.
If you have a devops team, and they don’t encourage or foster a devops culture within the organisation, then you’re doing devops wrong, as simple as that. If you’re doing devops wrong then it doesn’t matter what you call a team, you’re still doing it wrong. In this case, I don’t care what the team is called, because it doesn’t matter.
I do understand the opinions of the anti-pattern crowd. Setting up a separate silo responsible for “doing devops” is completely wrong. It discourages other teams and individuals from adopting a devops attitude, as they’ll see it as someone else’s responsibility. But the problem isn’t with the existence of the team, the problem is the purpose of the team and the fact that whoever decided the team should “do DevOps” clearly doesn’t understand what DevOps is.
At the very core of the issue is an understanding of what DevOps actually is. If your CTO, (or Head of Technology or whoever calls the shots within the technology division) thinks that DevOps just means automating builds and deployments, treating Infrastructure as Code, or adopting Continuous Delivery, etc then you’ve already got a problem. DevOps is about these things (and more), sure, but it’s about everyone understanding the importance of them, and absorbing them into their culture.
I’ve previously posted about the dangers of having an obsession with Ownership and Responsibility and I think these factors can also contribute to a failed adoption of devops. Drawing up clear lines of ownership and responsibility is risky – if you get it wrong, you’re going to struggle. For instance, if you draw a clear line of ownership around “devops” and place it firmly in the domain of the devops team, then you’re not going to do devops. A single team cannot own and be responsible for a culture, it just doesn’t work like that. The lines of ownership need to be blurred or wiped out entirely. Nobody and everybody should be “responsible for” and “own” the devops culture.
Conclusions On The DevOps Team
Anyone who thinks that you can get something ingrained into an organisation’s culture by setting up an isolated group of people who are solely responsible for doing those things, is flying in the face of conventional wisdom. Even my experience suggests that this doesn’t work (and I always fly in the face of conventional wisdom, coz I’m stooopid). By all means create a DevOps Team, but don’t make them responsible for “doing devops”, that’s just wrong. Instead, give them the challenge of spreading the DevOps gospel, evangelising DevOps within the organisation and training everyone on the benefits of devops, as well as some of the tricks of the trade.
On The DevOps Job Title
Everyone’s a devops engineer these days. I’m a devops engineer, my wife’s a devops engineer, even my dog’s a devops engineer. It’s a booming industry and everyone wants a piece of it. I’m afraid we don’t have any control over this anymore, we’ve created a beast and it’s consuming everything!! Luckily it’s not the end of the world. Sure, sysadmins the world over are now rebranding themselves as devops engineers, but does it make any difference at the end of the day? If you’re hiring, you don’t just hire someone on the strength of their previous job title do you? No, you actually read their CV and interview the candidate. Good candidates will always shine through. Working out if someone’s a sysadmin or a build engineer is just a bit more hassle for recruitment agents, that’s all!
In a way I’m thankful for the devops job title. I honestly think it has helped to make the whole devops thing more popular and opened it up to a wider audience.
Should there really be such a thing as a “DevOps Engineer”? Probably not, but we’re far too late to stop it, and trying to stop it seems a bit of a waste of energy to me. Eventually “DevOps Engineer” will come to mean something more specific, but for now we’re just going to have to read a few more lines on CVs.
I wholeheartedly agree with what you’ve written here. The place where it gets interesting though is when the CTO doesn’t get it beyond automation, infrastructure as code, etc.
This common tooling has some virtuous impact on culture even when cultural change was not the explicit goal. Automate deployments from development to production, and you at least get developers and ops guys talking about the same thing using the same language. Do that with monitoring, builds, tests, etc and you have the foundation for cultural change. Some of that can happen organically.
Other times, you’ll have that big, can’t fail application that requires rapid change come down the pike (see Project, Phoenix). The organization will have both the tools and language in place to come around and deliver.
I don’t want to say “put tools in place, and culture follows.” While possible, it’s not something I’d bet the company on. At the same time, I’ve watched countless organizations tell me that they didn’t want continuous integration, just a consistent build process. Drop a CI tool in there, and setup up a nightly build and it isn’t long before someone suggests a couple times a day, then hourly, then continuous. The dev team’s culture changes a little bit in response to their tools. The same accidental shifts will happen with broader DevOps tooling, just slower and more fitfully.