DevOps is a big buzzword in the world of enterprise technology nowadays. I won’t get into the history and methodology, so you are unfamiliar with DevOps, you can read all about it here. As with all subjects I discuss on this blog, I will be looking specifically at the leadership aspects of DevOps.

Why do we need DevOps?

Well, DevOps is basically about Development and Operations working well together. Who wouldn’t be in favor of that? Why is that such a revolutionary concept? The term almost elicits a sort of a kindergarten “play nice with others” vibe. Do we really need a new movement to do that? Can’t we get along without it?

The reason we need DevOps is because historically Developers and Operations have had different, and diametrically opposed goals. Development is incented to ship code (new features) while Operations is incented to protect the running production environment from any potentially-destabilizing change. Over the years, this has resulted in Development throwing code “over the wall” to Operations to implement; usually with poor documentation, few system requirements, little notice, and all the blame for whatever results follow.

Nothing documents this struggle as effectively as the famous novel, The Phoenix Project. When I read this book, it was so incredibly relatable, I felt like someone had followed me around my whole career, taking notes, then writing a novel and changing the names to protect the innocent. I am the protagonist, Bill (although I’m still waiting for parts of the super-happy ending to come to fruition). I’ve mentioned before that I read audio books on my commute. This is usually a relaxing experience. The Phoenix Project just stressed me out like I was reliving some of my worst days at work.

Are we DevOps yet?

Fundamentally, DevOps is a much-needed alignment of Development and Operations to mutual accountability for technology product success. It’s common for folks to look at their own practice and come to the conclusion that “we aren’t DevOps” because they haven’t achieved some panacea nirvana state of DevOps-bliss. Others would take a more aspirational look at things and identify any and every little thing that is DevOps-ish and proclaim “we’re DevOps!” Who’s right? Both! DevOps is a journey, not a destination. I would credit any initiative that is putting energy toward better Development and Operations alignment and accountability to be a DevOps initiative. Why not? Sometimes aspirations and small wins can be inspirational for the teams.

What’s in it for Ops?

Development loves DevOps because it’s the last mile of the Agile journey. It removes that last constraint that bogs them down. But what about Operations? Is this yielding too much control to Developers? Maybe, but not if we do it right. I think the key is creating the Continuous Delivery hosting environment, then exposing our common infrastructure tasks associated with application hosting as APIs, so Development can bake the requirements into the app package with Infrastructure as Code. So, doesn’t all of this mean that Developers could potentially do everything without involving Operations? Yes, and I’m ok with that. I’d argue that anything that can be easily automated with Continuous Delivery and Infrastructure as Code isn’t particularly interesting engineering work when done manually. I’ll give that up any day. What’s left to do? Plenty! Who’s going to build the Continuous Delivery hosting environment? Infrastructure and Operations. Who’s going to build the instrumentation and orchestration layers for the infrastructure stack? Infrastructure and Operations. Who’s going to build the governance models and workflows so we maintain production control and compliance? Infrastructure and Operations.

There’s a ton of work to do. If you are far enough ahead that you’ve already got that done in your area, look around you, because there are likely plenty of platforms around that need the same thing. Some look at DevOps as a cloud-thing. Cloud represents less than 10% of the workload for most enterprises, with the rest being mature applications in traditional or colocation data centers. I’ll argue that DevOps thinking can be brought to every technology platform.

Leadership is critical for DevOps

We need to empower our teams to self-organize and make decisions that are best for the business and technology products. It doesn’t end with empowerment. Many professionals on our teams have been used to doing things the old way for a long time. Some may have even had their hands slapped by previous managers when they went off-script. We need to provide a pathway, build a roadmap, and look for the incremental next steps that will make it possible to continuously improve during this journey. Old turf wars and blame games need to go away. What replaces that is not just collaboration, but continuous feedback on what is working and what is not working. DevOps is a mindset, not a toolset or process framework.

Is DevOps just a fad that will soon go out of style? Perhaps. But alignment, empowerment, collaboration, continuous improvement, speed, agility, and automation will never go out of style. This is the new way we work. It’s more valuable for the business and more enjoyable for everyone involved. Any leadership insights you’ve learned on your DevOps journey? Please share your thoughts in the comments below.