When it comes to DevOps transformation, success, or failure, it may ultimately fall on the desk of the executive suite. While it’s tempting to place blame on leadership when a DevOps initiative fails, in reality, all of us need to first look in the mirror.
Companies tend to approach a DevOps initiative as solely a technical transformation. This completely glosses over the fact that the organizational change tolerance is a huge component of success, along with changing the way people work and communicate, both internally and externally. If the organization does not tolerate change well, the perceived value of DevOps is undermined and ultimately directly or indirectly sabotaged.
The executive suite could be doing a great job of meeting, planning, strategizing and looking at what they perceive to be the beginning of enthusiasm in the initiative. But true victory, or change, has to take into account how people in the larger organization feel about shifting DevOps to a new model.
You can catch warning signals that your DevOps initiative is falling off the rails and put processes in motion to get it back on track. You might see pockets of success, however, when it is evident there is no major shift in how people are collaborating — only the tools that are being used are changing — this is a sign that major success is not on the horizon.
When the tools, or platforms, become varied, and teams start enacting a “do whatever you want” approach to the DevOps initiative, you’re bound for chaos and failure. Sorry, Baskin-Robbins, 31+ flavors of toolset variety is a recipe for initiative disaster. There have to be some team-level decision points on process and how the team best works, but it should not be an ice-cream store-sized menu. You need to refine the approach and enact standardization to the level possible, to measure and track the success of the initiative.
Change tolerance is a fancy phrase but really, at the heart of it, is that your organization will be more receptive to change if they see the benefit behind it. Clearly restate the “why” of the initiative. Everyone needs to have a clear line of sight to “why” this will make the company better and how. Get people to invest back into that first! They will begin to see how they personally can contribute to the success. Then show where progress is being made and sound a trumpet around those wins. With transformation of this scope, ultimate success is the destination, but you also need to celebrate the incremental successes along the way.
In your fix-it mode, don’t go right back to the drawing board if the initiative appears to lack buy-in. One of the biggest things that companies miss is learning from a mistake and figuring out how to fail faster but at smaller impact, so learning can be accelerated and applied. Many companies go back to the drawing board too quickly. Have confidence in your vision!
Also, don’t add to the 31-flavors toolset dilemma by adding another tool, thinking it will save the day. Many executives feel that they are only a tool away from success. So, they prematurely buy something new or optimize/scale bad process in tools to see if that will fix things. This is a flawed approach with a sure recipe for failure.
DevOps, for better or worse, will always be “people over process.” People drive the success of DevOps transformation, and if they are not on board, no amount of meetings or toolsets will help. By understanding the “why” of an initiative and by participating actively in its success, we can become more receptive to change. It takes a village to fail, but it also takes a village to succeed.