Why we talk Culture with DevOps

This one's been brewing for a while and I needed to dump the ideas onto a page. I might come back and edit this, I might leave it just as stream of consciousness as it is. enjoy

It's not uncommon as a DevOpsDays organizer to receive feedback that an event might be "too culture focused" or "not technical enough." And I've heard people complain about the consultants that come into an org promising DevOps success and blaming "the culture" for a failed implementation. And, you know, I get it.

It can feel like there's this huge emphasis on the Culture of DevOps rather than on the actual technical changes taking place or even the technical skills. And it's hard to measure and implement. Sometimes you just want to know about the latest and greatest advancements in Kubernetes. But there's reasons that all this emphasis exists.

For one, there are simply so many tools out there where largely the choice is, "it's up to you" how you want to implement everything. We could have a deeper discussion on Infrastructure code, but do we really need to spend time on stage discussing the finer points of Terraform v. Cloud Formation? We could spend time on how to do X cool things in Docker but... I mean I guess it's all in Kubernetes now? or do I need a service mesh? The tool landscape is constantly changing, but the mindframe of DevOps and the organizational practices are similar. Learning Kubernetes will help you right now, but learning how to break down communications silos between teams will help you wherever you go forever.

Adding another reason, the advent of as-a-service delivery and firm support for the "buy it" half of the "build v buy" discussion, many new tools to the market are highly opinionated and make assumptions about how our teams interact throughout the software development/delivery process. You can't simply walk back into a highly siloed organization with massive (real and metaphorical) walls between software developers and testers and the actual operations teams and expect to implement automated CI/CD pipelines, highly flexible release management and deeply meaningful observability without massive organizational change. DevOps tools assume collaboration and communication across functions, that cultural step MUST happen to be successful.

Finally and quite frankly, the cultural work that needs to be done, the organizational shifts are the hard part. From entrenched power structures to difficult personalities shifting from silo'd command and control structures to highly collaborative teams takes a lot work. Especially in organizations used to putting up strict guidelines and careful process, being told things like, "give them admin access" and "trust your employees" seems completely against everything you've done up until now. But this is the real magic of what DevOps enables.

DevOps brings with it processes of automation and incredible tools that help alleviate the toil and burden of actually getting our awesome software ideas out and available to the world, but stopping right there, at the tools, misses the massive shifts in culture and practice happening. It's about building collaborative environments that help us align our goals and benefit from shared knowledge. Mistaking the tools and dressings of DevOps for DevOps itself is the exact type of cargo culting that's given us "water-scrum-fall" style Agile and other abominations.

So, can you just learn the tools of DevOps and be successful? Yeah probably. You could probably be quite successful, whether you lean towards Dev or Ops, learning the tools (picking up a little bit of process and culture along the way naturally) and just focussing on doing what needs to get done to deliever your $product. I think as an individual contributor to an organization that's totally possible. But if you're thinking about your org as a whole system (and really to reach that Principal IC level, you should be) you start to care about all those human interactions and how teams are organized and how information flows and knowledge gets transferred and who decides when deploys are live and who answers the pager on call... you simply cannot ignore the culture.