<p>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.</p>

<p>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.</p>

<p>To institute a change, you have the following two options: </p>

<ol>
<li>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.</li>
<li>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.</li>
</ol>

<p>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.</p>

<p>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.</p>

<p><strong>Note</strong>: 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.</p>

CC BY-SA 3.0
2017-03-01T05:16:32.317Z
And the power to do these two things would normally require some kind of managerial position, correct?
Evgeny Zislis
CC BY-SA 3.0
2017-03-01T05:23:11.367Z
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.
Jiri Klouda
CC BY-SA 3.0
2017-03-01T05:11:30.553Z
2017-03-02T22:59:36.897Z
2017-03-02T22:59:36.897Z
Jiri Klouda
<h2>Hack your Team</h2>

<p>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. </p>

<ol>
<li><p><strong>Cause others to experience the problem that DevOps solves.</strong> 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.</p></li>
<li><p><strong>Find the leaders</strong>. 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.</p></li>
<li><p><strong>Build Trust</strong>.  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.</p></li>
<li><p><strong>Don't be ashamed to repeat yourself.</strong> 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.</p></li>
<li><p><strong>Make it pleasurable</strong>. 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.</p></li>
</ol>

CC BY-SA 3.0
2017-03-02T16:18:31.527Z
It seems that "Trail Blazer" would be a fitting term for some of those hacks.
Evgeny Zislis
CC BY-SA 3.0
2017-03-01T09:26:36.783Z
2017-03-01T09:26:36.783Z
avi
<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-02-28T17:06:40.907Z
there are whole book shelves written on the subject of influencing organizational change. I suspect introducing devops falls under that category and probably isn't too "special" in this regard. My own impression is that appeals to emotions are the strongest drivers of change.
Assaf Lavie
CC BY-SA 3.0
2017-02-28T17:08:51.327Z
@AssafLavie how about distilling this information into actionable steps and putting those as an answer (or answers / community wiki). I don't believe this is covered in any of the other StackExchange sites, and this is a perfect place to ask such a question - as it is especially relevant to DevOps transformation going around as a buzzword.
Evgeny Zislis
CC BY-SA 3.0
2017-02-28T17:14:02.580Z
I've read some stuff about this, but am no expert and it's not in my cache. Sorry. People get university degrees about this stuff, you know... it's a little like asking a non-doctor "how do I stay healthy? please give actionable steps ;)" so, no, I don't have an answer-worthy reply I guess.
Assaf Lavie
CC BY-SA 3.0
2017-03-02T04:57:35.140Z
Please stop over-moderating. Those questions are important part of DevOps. We need culture and process related questions.
Jiri Klouda
CC BY-SA 3.0
2017-03-02T06:34:56.187Z
Also notice you are trying to close one of the most upvoted questions.
Jiri Klouda
CC BY-SA 3.0
2017-03-05T12:03:26.603Z
Added one narrow version that is discussing just feature flag toggles at http://devops.stackexchange.com/questions/341/how-to-persuade-developers-to-start-using-feature-flag-toggles
Evgeny Zislis
CC BY-SA 4.0
2019-12-25T12:19:52.930Z
@JiriKlouda reopened
030
<culture><transformation>
How to change existing policies in an organisation?
Evgeny Zislis
# How to change existing policies in an organisation?

(Asked by: username_0 on 2017-02-28)

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 wusername_4ng.

**Tags:** culture, transformation

> **Comments:**
> **username_1**: there are whole book shelves written on the subject of influencing organizational change. I suspect introducing devops falls under that category and probably isn't too "special" in this regard. My own impression is that appeals to emotions are the strongest drivers of change.  
> **username_0**: @AssafLusername_4e how about distilling this information into actionable steps and putting those as an answer (or answers / community wiki). I don't believe this is covered in any of the other StackExchange sites, and this is a perfect place to ask such a question - as it is especially relevant to DevOps transformation going around as a buzzword.  
> **username_1**: I've read some stuff about this, but am no expert and it's not in my cache. Sorry. People get university degrees about this stuff, you know... it's a little like asking a non-doctor "how do I stay healthy? please give actionable steps ;)" so, no, I don't have an answer-worthy reply I guess.  
> **username_2**: Please stop over-moderating. Those questions are important part of DevOps. We need culture and process related questions.  
> **username_2**: Also notice you are trying to close one of the most upvoted questions.  
> **username_0**: Added one narrow version that is discussing just feature flag toggles at http://devops.stackexchange.com/questions/341/how-to-persuade-developers-to-start-using-feature-flag-toggles  
> **username_3**: @JiriKlouda reopened  

---

## 2 answers

### Answer by username_2 on 2017-03-01. Score: 7

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.

> **Comments:**
> **username_0**: And the power to do these two things would normally require some kind of managerial position, correct?  
> **username_2**: 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 by username_4 on 2017-03-01. Score: 5

## 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.

> **Comments:**
> **username_0**: It seems that "Trail Blazer" would be a fitting term for some of those hacks.  

---

