On the idea of a devops team

A few months ago as an experiment I decided to take all mentions of the word "devops" off my LinkedIn profile, rephrasing a few things and changing my current job title from "Devops Engineer" to "Operations Engineer". In a turn of events that surprised no one, the number of recruiters trying to get me to join their "DevOps team" dropped dramatically. Awesome, right?

Except I still get those messages from people, and even if most of them aren't looking at me anymore, they're still out there spamming everyone else who hasn't made this kind of change, and the fact that companies are still creating "DevOps teams" is getting on my last nerve. The idea of devops came about because organizations realized that having development and operations completely separate was causing problems, for both products and people, and maybe having those two teams be completely isolated silos wasn't the best organizational structure for what they wanted to accomplish.

So all these places that are trying to solve this problem of silos by adding another silo? You are Doing. It. Wrong.

This can range from just rebranding one of your existing teams as the devops team (no) all the way to adding a completely new team (WTF). Oh, the two silos of dev and ops weren't playing nicely together? Let's add a third silo, because silos were so awesome to begin with, AMIRITE? Even places that don't have a dedicated devops team but claim that they have X number of engineers who are "dedicated to devops work" are missing the point. Devopsing isn't a thing that you do in isolation like that.

In my quest to become a Certified DevOps Thought Leader, I'm going to say that it's a mindset, not a job description. You want more communication and collaboration between developers and operations? Great. If you need an entire new team of people to facilitate that communication, you've probably made some bad choices along the way. Maybe you fostered a culture that made it impossible for those two groups of people to work together, or maybe you hired too many Rockstar Ninja Wizards with me-versus-them attitudes who see success at your company as a zero-sum game. We're all ostensibly adults here. We should be able to figure out how to get two somewhat different groups of people to work together without bringing in a third group whose only job is to do that. (Because if you have a dedicated DevOps team, what else are they even supposed to be doing?)

And if only some people in the organization are "doing" DevOps, then what is the rest of the company doing? Are they sticking to those good ol' tried and true methods of throwing stuff over the wall at each other? In between developers and operations sure isn't the only wall in an organization that stuff gets thrown over, and a culture that's still okay with those other walls is probably still somewhat missing the point.In addition to not being a team, devops is also not a tool. The cloud is not DevOps. Configuration management is not DevOps. Shiny new virtualization tools and containers and frameworks are not DevOps. MongoDB in all of its webscale glory is not DevOps. Automation is not DevOps. These things can be (and frequently are) awesome when used appropriately, but all of the tools and config management and automation in the world cannot fix a broken culture or a broken mindset.

(Join me next time for another rant on fixing culture and what you should be saying instead of "DevOps".)