Transformation Requires Change Tolerance
When it comes to DevOps transformation, success, or failure, ultimately falls on the desks of the executive suite. It’s tempting for the average worker or IT team to place blame on leadership, but in reality, when a DevOps initiative fails, 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.
Failure Alert
You can catch warning signals that the DevOps initiative is falling off the rails, and put processes in motion to get it back on track. You might see pockets of success of the DevOps adoption. 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 has 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, in order to measure and track the success of the initiative.
Fix-It Steps
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. Restate the ‘why’ clearly 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 that 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. Most companies feel that it is 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.
People First!
DevOps, for better or worse, will always be ‘people over process.’ They 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, and it takes a village to succeed!
Read more tips in this InformationWeek article which includes some of our additional DevOps recommendations. Then, read this paper to see how you can prepare for maximum velocity on your DevOps journey.
