anchor.diff:  
   The lesson I learned was that top-down change seldom works.  You can’t just  say, "Okay. CEO, CIO, CFO, CTO said we're gonna do the DevOps", and expect results. . Pauly Comtois from Hearst Media [did a great talk](https://www.youtube.com/watch?v=zMsi5zQ9wp8) how middle managers are instrumental in propagating change.
   
  -## Patterns for gaining acceptance 
  +## **Patterns for gaining acceptance** 
   
   As an engineer, I'm a fan of patterns - things that are repeatable. I am going to introduce you to some patterns from [Linda Rising and Mary Lynn Manns’ book Fearless Change](http://www.fearlesschangepatterns.com/), which I personally, found very useful.
   
  -### 1. Become an evangelist
  +### **1. Become an evangelist**
   
   A technology evangelist is a person who builds a critical mass of support for a given technology and then establishes it as a technical standard. If you want to drive a DevOps cultural change, you need to go around to teams and get support from different groups of people. It’s an ongoing process, which means that you are never done. 
   
  -### 2. Tailor your message
  +### **2. Tailor your message**
   
   It’s important that you communicate differently depending on who you are talking to. For example, It’s very unlikely that your Chief Financial Officer cares how many times a day you can deploy. It’s very likely that they do care if you can quickly address issues which are blocking your customers from buying your products and services. 
   
  -### 3. Lunch and learn
  +### **3. Lunch and learn**
   
   Make lunch and learns effective by being creative about the food & the format, making it interactive, having clear takeaways and promote the session. This is another place where you should tailor the message. “Come learn how we’re working to respond faster to security risks” is better than “check out our new deployment tool”. 
   
  -### 4. Leave hints
  +### **4. Leave hints**
   
   Collect things like  stickers, flyers, and white papers. Leave them behind where people can pick them up to read them later.  People will be curious and might take some to read at their own time if you put a stack of DevOps or state of DevOps reports somewhere in the office. Build the curiosity. 
   
  -### 5. Find innovators to help
  +### **5. Find innovators to help**
   
   Find people who are identified as *early adopters* in your organization. These are the people who will be waiting in line for the newest iPhone, or always upgrade their laptop as soon as a new version of the operating system is released. Get them excited, so then they tell their friends and then their friends continue to spread the word.  It's really good to get help from innovators as early as possible. Keep in mind that this is useful for building excitement early, but not as a long term strategy. This group will be off chasing the next new thing soon.  
   
  -### 6. Ask for help
  +### **6. Ask for help**
   
   Don't hesitate to ask for help. This could be introductions to other teams, access to software or systems you don’t normally use, or just about anything else. I believe most people really want to be helpful, but they don’t want to seem presumptuous and often won’t offer if not asked. 
   
  -### 7. Say thank you 
  +### **7. Say thank you** 
   
   Spell it out, something like “I really appreciate that you introduced me to that other team. They knew more about the deployment tools and it saved me a bunch of time”A sincere thank you is more effective than a gift card. Avoid hollow gestures.
   
  -### 8. Celebrate your little successes 
  +### **8. Celebrate your little successes** 
   
   It’s hard  to push an organizational change. There will be lots of challenges. There will be people that don't care. Internally, acknowledge your successes. One of the things that I often speak about is burn out in the technology industry. There's others here that do as well. Not acknowledging when something goes right is a really good way to letting yourself down that road. 
   
  -### 9. Be honest with yourself and seek feedback 
  +### **9. Be honest with yourself and seek feedback**
   
   If you do the lunch and learn, if you do the presentation, don’t just see how many people showed up, ask feedback and act on the feedback. If they enjoyed the selection of food but didn’t find the content useful you may need to adjust in the future.
   
   ---
   
  -## Summary 
  +## **Summary**
   
   In this post, I talked about some strategies to drive changes in a way that makes sense to your people and hopefully cleared some misconceptions as well.  In our next post, the final one in this series, I will elaborate on some of the actions that one can take to actually propagate change. 
   
  
positive.code: author: Ken Mugrage
  excerpt: "In part 2 of the series, You can’t buy DevOps but you may need to sell it, we’ll look at some of the most commonly held misconceptions about driving change. We’ll also explore some patterns that you can use to help gain acceptance of your ideas."
  title_tag_of_header: "Misconceptions and Patterns to drive DevOps Adoption | GoCD Blog"
  meta_description: "In part 2 of the series, You can’t buy DevOps but you may need to sell it, we’ll look at some of the most commonly held misconceptions about driving change. We’ll also explore some patterns that you can use to help gain acceptance of your ideas."
  meta_keywords: "Gocd, gocd open source, devops, drive devops adoptions, devops adoptions, convince your team to adopt devops, driving change, devops misconceptions"
  summary_image: "/assets/images/blog/driving-change-devops/part-2-cant-buy-devops.jpg"
  tags: You cannot buy DevOps but you may need to sell it
  draft: true
  
negative.code: 
  In this post, we’ll look at some of the most commonly held misconceptions about driving change. We’ll also explore some patterns that you can use to help gain acceptance of your ideas.
      
  ## **Common misconceptions** 
  
  Before we get to the strategies to implement change, I want to highlight what I see are the most common misconceptions about implementing new ideas. These are highly opinionated, but I will explain why I believe so. 
  
  ### **Ideas are judged 100% on merit**
  
  Those of us that have been in technology for a while know that there are  a lot of successful products in the market that might not have been the best idea. Ideas actually aren't judged 100% on merit. If they were, betamax would've beat VHS. Good ideas need to go together with implementation to create a lasting impact. You can not just do a session to introduce it. Implementing change means that there's work to be done and it’s an ongoing process.
  
  ### **Top down approach is effective for changes**  
  
  It’s very common for companies to attempt top-down culture change. A quick web search would turn up many examples of organizations who “went agile” and failed. Quite often a deeper dive reveals that they never actually changed behavior.
  
  