How to change existing policies in an organisation?

Question

I assume that an organization wishing to do a DevOps transformation has some problems and policies it is interested in changing. This interest can come from top managers, middle managers, or even from bottom up. One of the biggest factors impeding this change is making other people buy into doing the change.

For example, in many cases pushing "new" ideas such as Agile, often fails. People resist change, and it seems like a wall that stops good things from happening. Yet there is a mandate for good things to happen.

What methods can be used to affect employees in an organization starting its DevOps transformation? Especially specific techniques and ways that are found to work. Specific as-in more Engineering, less hand waving.

Answer 1

You have to understand that processes change people who follow them. As people learn, internalize and get better at a process, it changes the way they learn how to solve a particular problem. A set of similar processes reinforce each other into a mindset the person uses to solve a category of problems and eventually form a set of values that guides decisions and new solutions to new problems.

Even if you change the process, without the change to the mindset and even more crucial to the values, the person will simply adapt the new process to conform to the same values, same mindset or even same solution as in the original process. At a certain point, it is not possible to divorce this person in this position from the mindset acquired or change the underlying values.

To institute a change, you have the following two options:

1. Bring in a person who will already have the right values and mindset and in best case scenario, understand the process that needs to be followed without your help.
2. Bring in and empower new employee, either recently hired, a new hire or a transfer from a different team in the organization and train him in the new process, hoping to instill the new mindset, hoping the new set of values will emerge.

If the change is local, you might prefer an internal transfer as that person would already share the global company wide values which you want to retain. In case of a larger change, you need to bring in someone from outside to have a fresh perspective and to not share the company wide values which you might be trying to change.

The important part is to empower the person, team or business unit to follow the processes and insulate them from the old team, other teams or the rest of the company, respectively, which might still follow the old set of processes. As it is very hard to insulate such change agent from management above, if the change is to be larger, it often needs to follow all the way up the management chain or come all the way from the top of it.

Note: It is hard to bring change to more than just your team without the support of management. Even inside your team it is difficult if others are already set in their ways. For a new team in a new company a successful evangelist can often affect the forming policies even without the support of management simply by being a leader or creating the path of least resistance for others to follow. But in established company, see above.

Answer 2

Hack your Team

Bringing about change in your organisation is hard. People have habits, they resist change, and they are often comfortable with the status quo. To bring about change, in no particular order, here are a few tools you can use.

1. Cause others to experience the problem that DevOps solves. Many times the benefits of DevOps is only understood on a theoretical level by your team. Most of the problems that happen during deployment are hopefully and rarely experienced by the rest of the development team or management. To fix this, make sure that you are vocal about issues when they arise and mention how this problem wouldn't have happened if the team was using a continuous integration solution. Another possibility is to be sure you ask developers to fix problems that their code caused during deployment instead of fixing it yourself.

2. Find the leaders. It is common for people to follow the leaders, be they management or just the most popular/commanding person in the group. Get those leaders on board with your desire to move to a DevOps culture, and devise public ways in which they can be seen using or advocating best practices.

3. Build Trust. We are more likely to agree to things from people after we have already agreed with them once or twice before. Ideally, you can find small improvements that can be made without a shift in culture and build upon that success. However, if that isn't an option, ask them simple questions and offer simple suggestions so they get into a habit of saying yes or agreeing with you.

4. Don't be ashamed to repeat yourself. Repetition works and eventually sinks in. Whenever possible mention how great things would be if the team was using DevOps. However, this only works if you have first built trust within your team.

5. Make it pleasurable. If you are allowed to build a proof of concept for your DevOps situation, use cute emoticons and cheerful colours in the reports and notifications. Post funny gifs when a build fails. Make sure you aren't annoying with your updates.