The Race to “Do” DevOps

The purpose of this post is to really share an observation and something that I’ve been thinking about as a consultant. I interact with a lot of customers, folks in the different communities and other consultants both internally at Microsoft and in partner organisations, something I find interesting is seeing how quickly everyone seems to want to claim they “do the DevOps”.

Over the past 2 years I have seen companies restructuring their whole IT Organisation; putting in a DevOps hierarchy, giving folks “DevOps Lead” and “DevOps Engineer” titles overnight, almost in the hope that if we say we are doing it enough, we will be. A “fake it till you make it” approach, or perhaps for some “fake it till you become it” (nod to Amy Cuddy). I’ve seen Consultants promise to implement a new system “using a DevOps approach” by which they actually mean “we will do your Infrastructure as Code” or indeed “Infrastructure as Policy” (nod to Don Jones). I have seen this happening knowing that these folks actually have no firm grasp on what they are now claiming to be able to do, but they are instead seemingly relying on the folks they are talking to to have an equal or lesser understanding so that they do in fact pull it off. Blinding you with the science …

It’s not that these folks have entirely no idea about it, not at all, they’ve read some books and whitepapers, seen some tools, met some people and are on the right path, but they are by no means ready to offer anyone a DevOps transformation. I find this happens with a lot of other IT buzzwords as well. Cloud, for example, how many people and companies did “cloud” to death? I think we are taking DevOps the same way. It seems to happen because we rush to use these buzzwords and make these claims without really stopping to first understand what we are saying (perhaps taking Richard Bransons lead “If someone asks you to do something and you don’t know how to do it, say yes and figure it out later”).

If you ask any two people what DevOps is, you’ll get 3 different answers. None of them are usually wrong, they are just not articulated the right way as the folks articulating it haven’t spent the required time to research, understand, discuss and refine their message. Rather, they have gained just enough knowledge to be dangerous and in this race that all of us in the IT world seems to be in, we’ve slapped a sticker on it and continued.

This is what I personally find to be a problem, because it runs the risk of diluting and devaluing what DevOps is, often by pursuing the wrong goals. The perception of DevOps is that you’re doing it if you’re moving fast and getting ahead of the competition, deploying systems faster, speed, speed, speed is the underlying theme. This seems to apply even to the claims of adoption. Independent research will show you that most organisations that claim to be doing DevOps are actually getting it quite wrong.

What I have learned that DevOps is from my research, interactions, community interactions and so on, is that at its core, DevOps is about quality. Speed is just a bi-product of quality but quality is at the core (though speed is what most folks get hung up on). Ironically, how you achieve quality is by first slowing things down. Probably the fastest way to get to the point where you really can say you’re using DevOps is by taking a beat, reflecting on your culture and how that needs to change, reflecting on your teams skills (soft skills just as much if not more than technical skills), reflecting on your understanding of what you’re trying to do and really understanding your work, workflow and bottlenecks in your processes. And you can start doing all of this without so much of a mutter of “DevOps”. I’ve encouraged folks I work with to do this and they have inevitably come back saying “wow! DevOps is HUGE, really what we need to offer is Infra-as-Code to plug into the whole process”. Couldn’t agree more.

Being able to claim that you are using DevOps or being able to offer a customer any kind of DevOps transformation is much more credible when you have taken the time to really understand what you’re talking about. You can be doing different things that make up DevOps without having trying so hard to fulfil everything that this label implies. My hope is that more folks in the industry realise this and focus more on what they are doing and the quality of their work, rather than chasing the minimum bar to claim they are “doing DevOps”. Practicing one element of a DevOps cycle really well, for example, Configuration Management for a single service, will be far more rewarding than implementing a whole DevOps pipeline poorly just to say you are doing it. If you go this route, you’ll probably land yourself in no better position that when you started and waste a ton of money and time along the way.

If the goal is to genuinely improve the quality of what you’re doing rather than slapping a label on it, Slow and Steady wins the Race. By taking your time to understand, research, gradually improve and you’ll get far more from these changes than a check in the box because the word DevOps appears on your org charts or in your Statement of Work.