I've wanted to write this article for a while now. Because I often see the saying "Devops is not a role" all over the place, and every time I see it I have a visceral reaction.
Ironically, I'm reading the book "Team Topologies" right now, which seems like the ultimate "Devops is not a Role" book. But I want to unpack my thoughts for a second. I've often noticed that when I'm presented with a new idea, my impulse is to argue against it, play devil's advocate. Partially this is for the same reason most people do. I'm afraid of change; don't move my cheese, and this reaction is usually not helpful. Playing Devil's advocate without a strong purpose in mind is an anti-pattern.
But I do have a strong purpose in mind. I find it most useful to approach problems this way. Start with the no case. We don't to change. Then start to open up the pieces bit by bit and ask, but what would it look like if we did? What might we do first? What's the smallest step we could take to get there? What am I most wrong about?
The thing we're doing now works. Why change it? No really. Why change it? What are the reasons? What will this new thing do better? What do we want to make sure we're preserving from our current patterns?
The second is similar, maybe compatible: What are the reasons for this new thing? We can't understand why we do this new thing, unless we understand it in contrast to what it's replacing, both the good and the bad. There's a reason you've been doing things the way you've been doing them, and you're likely to lose something. What are you going to lose? And how do you ensure you can sell this to people, without understanding what benefits they're getting from the current thing.
So in that vein, the root of this question is. If devops is not a job title, it's a culture. Why does this need to be argued so hard? i.e. why are people treating dev/ops like a job title instead of a culture, what are they getting out of it?
Ops + IaC is good, actually.
I think one of the core things people say when they talk about devops is not a role, is to then sort of add, just adding IaC to ops doesn't make you devops. But if you take a team that was doing most of their changes manually, say by clicking in the console, and get them to start making their changes using Terraform. That's good! Act as if. Start to get a feel for what that pattern is like. Start to understand the problems of working that way.
You can't make culture change if you don't have the skills to get there.
If you take a bunch of operations engineers who've never touched IaC or a code base before, and tell them to break down barriers and embed themselves with Software Engineering Teams. That is destined to fail. To add on to the above: Develop the skills in IaC so that when you do maybe embed with a team, or try to make the culture change, you have the skills in the tools needed to respond quickly.
Devops is a constant effort.
I think that the devops culture is sort of the fudge of the sundae. It's not just the cherry on top, it's more deeply integrated than that. But most of the work your teams do will be done by "devops engineers" on an "ops team". Ops will deploy and manage infrastructure, somewhat tangentially to your developers needs.
Devops is not a role; is not really actionable.
Devops is not a role, it's a culture is directionally correct, it's the right way to view the problem, and if you get deep into it, there's alot of value there. But if you're just getting started "Go change the culture" is not really useful advice, and lots of short linked in posts or blog posts amount to summarizing the frustration on the part of the writer, and not real deep advice.
Conclusion
What would I suggest people take away from this? And how does this impact the way that I work?
"Devops is a culture" is a good long-term vision to have, but per above, it may not be actionable. Go into it with some skepticism. Be honest with where you're at on your journey, and that certain organizational patterns may prevent you from really adapting the culture whole hog. To do devops right, you need to be bought in pretty high in the organization, and if you aren't, I think there are still ways to take advantage of some of the learnings of devops. Don't let perfect be the enemy of good.
If you're just looking for small things to do, you can hire someone with IaC experience, or introduce Terraform and that's an ok step to take, you're not failing at running an ops team. You can hire some folks, call them "devops" and then slowly find ways to build bridges between your team and dev, rather than solely petitioning the svp of engineering to enable "culture change". In fact, you may not be doing things all that much differently from teams that say they're doing "devops" for real. Then I'd say use your "devops engineers" to create interest, move towards an enablement team that gets your customers pushing for the cultural changes that devops inspires rather than pushing for them yourselves.
