6 Change Management Pro Tips for DevOps Implementation

LiSuan Poh

I have attended several DevOps sessions lately, which triggered the re-reading of many Change Management books. I reflected on the major shifts over the last two decades, my own work, and the things that did and didn’t work. In the last 20 years, there has been a steady cadence in the evolution of software development and delivery— from Capability Maturity Models, Five Nines, Continuous Availability, and Continuous Service Availability to Agile and on to the world of Continuous Delivery/Continuous Integration and DevOps.

Today, both front liners and middle managers are responsible for actualizing the increasing pace of digital transformation and clearly demonstrating its value. Yet, the question still looms: how do you convince others in the enterprise to undertake change?

The challenge for this level of management is to convince up the management chain using a different language— the language of business. The business case must be used across the organization while balancing the workload of actualizing technology.

With that in mind, here are six simple Change Management ideas for driving change.


This is a big one. In John Kotter’s The Heart of Change, he explains that when creating a sense of urgency, you should attempt to choose things that influence how others feel — a “burning platform,” or especially urgent sense of change.

For the technical folks reading this, it probably feels counter-intuitive to how we operate. We tend to be logical and structured. When we put together a case to argue for change, it’s most often intellectual and fact-filled. However, people rarely change that way. Instead, change happens when we impact people emotionally. Effective mechanisms of change are obvious, physical, and real. In the age of distributed people and virtual meetings, a great way to bring home a point is through video. Consider the emotional impact of a video of an angry customer, or a partner that talks of how the slowness of deployment has a real chain-effect from supply chain to advertising — something up close and personal, and to the point.


Any change requires vision. More than that, it requires a clear picture of that vision for everyone involved. Provide teams and people with a vision of the new reality that provides guiding principles. Paint the future, the impact on customers, partners, competitors, and internal technology organizations and operational teams. This step shouldn’t be taken lightly — it is what creates movement and passion behind a vision. It’s what helps people capture the importance and see it through.


The people willing to step up are those that will be most passionate about the work. Just ensure that these people have the bandwidth, support, and commitment of leadership to carry it out. These people will have the opportunity to contribute to the vision and are those who already understand Continuous Delivery/Continuous Integration/DevOps. They will be your champions for your first project.


Debate this carefully. Your first project should be one that is simple enough to achieve and can showcase results in a visible manner that can be extrapolated to the enterprise. Choose something small but impactful and something you can win with, and that you can garner adequate support to achieve. It should be a “mini version” of your bigger vision. Track and document everything – this is an important step to building a success story and  the foundation of a business case.

Build a Q&A for your team members, and track the Q&A, as it will come in handy as you gather momentum. Being able to address all sorts of questions shows preparation and thoughtfulness.


Work on the first project or tweak it until it demonstrates adequate results. The results do need to be visual and impactful, something that can influence others to change their minds. Then, evaluate the results. Was it where you hoped for it to be? Is there strength in the results to build up a business case and a convincing argument to spread the adoption across the enterprise? If the answer is yes to these questions, then build a business case. The business case should be one that people and teams across the organization can get behind. Consider if budget and funding are required to accelerate adoption of the change. An important part of the equation is the benefit in dollars of adopting this change.


As you find the right sponsor and begin spreading the story of the change, the principles laid out above apply. Prepare information that is both visual and powerful— a “what’s in it for me” to each executive matters. Showing the vision, and guidance of what it could be, the potential structure for change, the ability to answer Q&As, and a potential structure to answer the unknowns are all important to show a path towards adoption across the enterprise.

The same material used to present up and across the organization can be used by each of the core group team members to share in their organization. They can be advocates and champions of this change in their own groups.

Classic techniques of change management will help you on your DevOps journey. Over the last decade, they have helped me through various organizational culture changes, and allowed me to arrive at the point of showcasing a prototype. Should it become a large-scale change (with executive and organizational buy-in in place), the principles remain similar. However, scale changes dramatically, requiring more people and a much more structured approach such as vision, charter, structured team, program lead, multiple project teams and work streams, results, document management, roles, responsibilities, timelines, and budget. I hope you get there!