This is part 2 of my blog series, ‘You can’t buy DevOps but you may need to sell it’. In the previous post, we looked at some industry statistics and anecdotes that can be used to convey the effectiveness of adopting a DevOps culture. While these are important to have and understand, by themselves, they won’t change people radically. To create a lasting impact, you have to drive change in a way that makes sense to individuals.

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.

I saw a group several years ago who decided to switch from waterfall to agile methods. They went through fairly extensive training in things like user stories. For those that aren’t familiar, most successful agile organizations use stories as “conversation starters”, not detailed requirements.

At least one group in this organization took their massive waterfall requirements document, split it on paragraph markers and then proudly presented a spreadsheet with hundreds of smaller pieces of text they called user stories.

They got compliance, they created user stories. There was no commitment to real change.

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 how middle managers are instrumental in propagating change.

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, which I personally, found very useful.

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

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

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

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

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

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

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

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

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

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.