Chapter 4
Persuading Colleagues to Try DevOps
IN THIS CHAPTER
Understanding the human aversion to change
Persuading your peers
Gaining executive buy-in
Responding to pushback
When I’m on the road a lot, talking to engineers, they often ask where they should start. “DevOps sounds great,” they say, “but what’s the first step?” or, “My boss has decided we should ‘do the DevOps,’ and has reorganized us into a DevOps team, but what are we supposed to be doing?”
Everyone’s DevOps journey is different —unique to you as an individual, to your team, and to your company. You will pick and choose (to a certain extent) which aspects of DevOps will benefit you most and apply those aspects to your team. One thing is certain, however: You can’t go it alone. Your DevOps transformation will fail if you attempt to force the new way of thinking onto your team without first persuading them. You must sell your colleagues on the benefits of DevOps and energize the organization around new possibilities.
In this chapter, you dig into why humans loathe change, work on perfecting the art of persuasion in order to effect change, practice explaining DevOps to leadership, and see how to respond to doubting minds.
Fearing Change
Humans don’t like change, and the reason is based in our brains. Habits are powerful because they’re efficient. Your brain can think less and still achieve the same amount of productivity. Your brain is extremely proficient at processing information.
Psychology offers information on why people resist change so strongly. Inertia is powerful and change is expensive. People are likely to stay on the path they’re already on because shifting that path takes quite a bit of effort. Staying the course is much easier. When you do decide to climb your way out of your current groove, persisting at it takes an extraordinary amount of brain energy. (Ever notice that you’re a little more hungry when you’re learning something new?)
In addition to the inertia aspect of change resistance, two other key aspects make people fear change. Keep both these things in mind as you go through this chapter:
- Past experience: Every single person in your organization comes to their job with years of history that have chalked up successes, failures, and fears. Some people within your company have likely watched changes made in their past workplaces succumb to failure. Failure stings. Some of your colleagues may have even lost their job over a massive failure. Fear of repeating such experiences doesn’t just disappear.
- Uncertainty: Your brain is more likely to categorize uncertainty as a threat rather than an opportunity. Evolutionarily, this tendency was important to keep humans, well, alive, and that tendency persists even though most of us aren’t chased by lions these days. Also, change usually doesn’t happen overnight, which forces people to take a wait-and-see approach although their brain desires to know the outcome now. This situation creates conflict. Sometimes the conflict is internal as someone weighs their fear of failure against new possibilities for success. Other times, the conflict surfaces between people. You may adapt to change more quickly than your colleague, and that delta in time required to transition can introduce interpersonal friction.
Despite the natural fear of change, the capacity for change is critical to the survival of any business. Examples abound of businesses whose internal resistance to change sealed their eventual fate. To cite just one example: Remember Blockbuster? (My family had a Friday night tradition of hopping in the car and heading toward the royal-blue sign down the road. Each of us would spread out over the store, pick our individual favorite, and then have it out over which one or two we should rent.) At its peak, Blockbuster had nearly 10,000 stores. In 2000, Netflix offered Blockbuster a deal to acquire Netflix for $50 million. The Blockbuster CEO declined; Blockbuster wasn’t interested in the “niche business.” You know how that story ended.
The leaders of Blockbuster weren’t idiots — far from it. But they, and many others, failed to see the writing on the wall and correctly predict where the market was headed. They also failed to communicate with customers and, ultimately, failed to change their business to conform to what the market wanted.
Persuading Those around You to Shift to DevOps
Empathy is a powerful tool, and showing true understanding of the fears and doubts that people around you experience can help your DevOps transformation succeed. Simply acknowledging the potential fears of your colleagues can go a long way toward assuaging their anxiety and persuading them to get excited about the new possibilities that DevOps provides.
One way of working with the natural human resistance to change is, first, to understand and expect it (see the preceding section, “Fearing Change”) and then to hone your skills at persuasion. I like to think of persuasion as tailored messaging. It’s presenting an idea in a way your audience can understand. That doesn’t mean that you have to build separate arguments and pitches for every person with whom you come in contact. Instead, keep in mind the four most common styles of leadership that people embody in problem-solving. Basing these styles on the Myers-Briggs personality types, you can group people as visionaries, strategists, administrators, or counselors. (Obviously, these categories oversimplify people, but they enable you to ensure that your arguments for DevOps persuade even the most stubborn.) Keep in mind the four personality types when you talk about DevOps to your executives, peers, employees, and business stakeholders. Each of these personality types will relate best to the following approaches:
- Hope and imagination for visionaries: The thinkers are intellectually curious more than anything else. They want to see the data. But they also want to hear about a world of tech that doesn’t exist yet — a world that they have the chance to build themselves. How has DevOps improved the processes at other companies? What are the big advantages? After you’ve given them enough information to get over their initial hesitation, you can think of them as mental petri dishes. All you have to do is prime them and they’ll inquisitively dig in further — growing your argument for you.
- A high-level plan for strategists: You don’t need to dig into the details for these people. These quick-witted folks are creative problem-solvers. They are also your risk-takers, which makes them some of the easiest to persuade. They’ll find the change to DevOps exciting, and their natural curiosity will energize them to your side. Just be sure to have room for them to contribute. They’ll likely want to know how the transformation is progressing and how they can be called on to energetically persuade others.
- Detailed direction for administrators: The worker bees keep the hive buzzing. These people do the work diligently and will be responsible for carrying out the strategy set before them. They are meticulous, dependable, and organized. Use the fact that DevOps is an incredibly practical way to ensure that the system runs smoothly, from determining requirements to shipping software.
- People-centric pathos for the counselor types: Pathos — emotion — will be the most effective persuasion tool for people who tend toward being caregivers. They put people first, no matter what. Understanding how DevOps helps to smoothe communication, reduce interpersonal friction, and increase collaboration will soothe this group’s fears.
In addition to knowing how to approach the various personality types, it helps to have a clear sense of the three main groups within your company that you’ll need to win over to the DevOps philosophy: executives, managers, and engineers. Figure 4-1 represents these three groups. The hourglass shape with managers in the middle isn’t meant to suggest that the managers in your organization aren’t important to your mission; quite the opposite: They’re critical to full adoption. But they can be the most difficult group to persuade, so I suggest that you tackle them last. (They’re the last to come out of the hourglass either way you turn it.)
FIGURE 4-1: Persuading each group in your organization.
The reason I focus on executives and engineers first is that managers sit between a rock and a hard place, constantly facing scrutiny from executives and mutiny from engineers. As a result, they are naturally conservative decision-makers. They are comfortable within the status quo because they know that any change will ripple through them and cause strife somewhere along the chain of command. If you can get buy-in from executives and support from engineers, managers will have zero reason to protest. Finally, if engineers float DevOps to their managers and expect the manager to relay the message to executives, the purity and passion of the argument is easily lost. Direct contact between engineers and executives prevents miscommunication and unnecessary friction introduced by fearful managers.
For executives and engineers, you have a choice of which group to approach first. If you’re effective, either will provide a great groundswell of excitement. Executives will provide clout and affirmation around your vision. Engineers will provide a massive amount of people who are more than willing to explain why they need smoother development processes to produce better software faster. Just be careful to focus your energy.
Earning executive support
Of the main groups that you need to get on board with DevOps, executives may be the most important to your cause. A DevOps transformation is nearly impossible without their buy-in. Other groups can subvert your efforts and quietly create friction, but executives are the only group that can squash the project altogether — and in just a few sentences.
In Chapter 3, I talk about the various types of waste in engineering teams and about identifying bottlenecks along your process. This information is crucial to executive support for your DevOps transformation. Executives often focus on vision, the big picture, but they also love data. You can hook them with your enthusiasm and then finish selling them with data, analysis, and a plan. As Brené Brown says, “Maybe stories are just data with a soul.”
Gaining the support of your executive leadership is a big win. You will be Sisyphus without it. Executive leadership gives you key advantages that will help the transformation process go more smoothly. They control budgets and team head count (the number of people allocated to a project). They can also lend quick fixes to conflict. Also, if you managed to convince one or two executives that DevOps is a worthwhile cause, they will help you persuade the others from inside the boardroom.
You need more than vision to convince these folks. You also need to tap into their dreams for the company, as well as their fears. Think of the pressure your executives are under from a public perspective. Your CEO can’t be the one to lose the company. Your CTO can’t afford to lose out to your competitors. You can acknowledge those fears and use them to tap into executives’ emotion and hook them. Then you can provide the supporting evidence.
Every year, DevOps Research and Assessment (DORA) releases the State of DevOps Report (https://cloudplatformonline.com/2018-state-of-devops.html). It provides diligently collected and analyzed data from the tech industry and provides rich data for you to use in your argument for DevOps. According to the report, elite performers — companies who deploy on demand and generally recover from incidents in under an hour — outperform companies that have low DevOps adoption by significant amounts.
In 2018, Elite DevOps organizations
- Deployed code 46 times more frequently
- Had a 2,555 times faster lead time from commit to deploy to production
- Recovered from incidents 2,604 times faster
Creating a groundswell in the engineering group
I like the word groundswell because it embodies the imagery to think about as you advocate for DevOps within your organization. A groundswell is a series of tightly grouped waves — adored by surfers — that last more than 15 seconds and are caused by a storm thousands of miles away.
Imagine sitting on a calm beach and then seeing a slow momentum building in the water, eventually rushing toward shore. It’s unstoppable. That is the power your team of engineers will give you if they adopt your view of DevOps and buy into the culture, the philosophy, and the approach. I use three tactics when approaching (sometimes doubtful) engineers about a DevOps transformation:
- Ask questions. What are your engineers struggling with right now? Find out where their pain points are, and then discuss how DevOps may be able to address them. If they’re already doing well with code management, releases, and production deploys, talking about continuous integration and continuous delivery won’t get you the traction you need. Instead, talk about how annoying it is for developers to go through an operations person to get certain log files and application performance data. Or how frustrating it is that a handful of ops folks are on call and engineers don’t contribute to maintaining the applications and services they build. (See Chapter 19 for how those issues are handled, or don’t even occur, in a DevOps system.)
- Offer concrete suggestions. Engineers like evidence. They also like to see you’ve thought about how to address issues before talking about them. If you go to the engineers with a bunch of lofty ideas and no execution strategy, the conversation might not go the way you expect it. Instead, think through which challenges you want to tackle first. If you’ve identified waste in your development process (explained in Chapter 3), you have a good idea of where the low-hanging fruit is. If you haven’t taken the time to look at potential bottlenecks, take a good guess and come up with a few DevOps approaches to improving the current situation.
- Encourage your engineers to experiment. The best part of persuading your company to adopt DevOps is that you don’t always have to do it with words. Instead, you can simply start practicing the philosophy and approach. Allowing engineers to experiment through small projects allows them to experience the visible difference firsthand. Sometimes it’s best to beg for forgiveness instead of asking for permission. Just do it. Keep it small and be sure to brag about how awesome your little experiment went.
Managing the middle managers
Middle managers often comprise the most difficult group of people to convince that DevOps is a smart approach to software development. They were promoted to their current position because of their prior work, so getting them interested in shifting directions from the path that has brought them success can be a tall order.
Kodak serves as a great example of this challenge. Before it became a dinosaur, Kodak was a highly inventive company. It consistently adopted new technologies quickly, including digital technologies in photography. Part of Kodak’s problem, though, was that its advances were too spread out through the market. People — even employees — simply couldn’t see how innovative Kodak was because the company’s small, yet impressive, innovations were hidden in a vast web of products. The company lacked focus and an organized strategy.
When George Fisher came on as CEO at Kodak, he moved everything into a single division whose sole purpose was to launch new products. Internally, Fisher faced pushback for his “aggressive” strategy. Middle management never got on board. They fundamentally didn’t understand that the industry was shifting and Kodak was quickly losing market share. The situation was urgent and needed quick action to mitigate. Yet the Kodak middle managers felt threatened by the changes, and their resistance was one of the last nails in Kodak’s coffin.
Middle managers matter. A lot. They’re the individuals who will pass the vision of the executives down to the engineers who are closest to the keyboard. They’re also the intermediaries who help executives understand what is and isn’t possible from an engineering perspective, so getting them on board is important. Still, I suggest that you work on persuading this group last. The process of convincing them will flow much more smoothly if you take advantage of the peer pressure from the other groups. Get executives and engineers excited about the potential problem-solving that DevOps brings to your organization and then capture the attention of managers. After you have everyone else on board, it will be an easy sell.
Persuading the stubborn
So, how do you persuade the executives, engineers, and managers who remain stubbornly resistant? I once read about a sales approach that involved identifying two people in any room you enter. One of those people is your advocate — the person who will pull for you, speak for you, and protect your point of view in meetings to which you won’t be invited. The other is the person who is the least impressed with you. That person will quietly argue against your suggestions.
I try to apply that technique, and although I don’t always get it right, it’s an interesting exercise to try it. Some of your colleagues are likely to be on your side immediately. They’ll be thinking, “Wow! Fewer ineffective meetings and stressful deploys, less downtime, more cooperation, and faster development? Where do I sign?”
Others, however, will be extremely slow to come around to your way of thinking. They’ll drag their feet and suggest alternatives. They’ll wonder how your suggestions are any different from the thousands of approaches they’ve seen companies adopt before — approaches that have either failed miserably or not produced impressive improvements.
Look at the situation from their point of view. What’s the point of putting in all this effort for minimal results? From their perspective, the company might as well keep going in the direction it’s currently headed, and keep doing things the way they’ve always been done. After all, the company’s situation is not that bad. It deploys good software. It has bugs, sure, but doesn’t everyone? The customers are mostly happy. What’s the impetus for changing?
Well, you can supply them with all the facts you’ve learned after you’ve completed this book.
Or you can choose not to do that. Seriously, at some point you may have to decide to abandon your persuasion efforts and simply get on with implementing changes, adopting new practices, and automating manual tasks. Where that point is, exactly, will depend on you and your company. But you’re likely to know when your ideas have gained enough of a foothold to make turning back the tide impossible, such as after you’ve convinced 70–80 percent of the key influencers in your company. But you’ll know. You won’t be able to get everyone excited about these ideas, and that reality has nothing to do with your presentation or the merits of DevOps. Some people are simply stuck in their ways, and no amount of groundswell or data will change that fact.
Understanding the Adoption Curve
Sociologists use adoption curves to model how people adopt new innovations. Though adoption curves have been adapted for many industries and purposes over the years, the clusters of adopters were first grouped by agricultural researchers George M. Beal and Joe M. Bohlen in their 1957 paper The Diffusion Process on how innovative farming practices are adopted.
The original curve clustered people into five groups: innovators; early adopters; early majority; majority; and non-adopters. The original names were meant to associate the groups with the overall adoption by the larger population. For example, “early majority” refers to the group that sits at the cusp just before the majority of the population has adopted the innovation.
After the work of Beal and Bohlen, Geoffrey Moore popularized the adoption curve for tech by in his book Crossing the Chasm. The numbers at the bottom of Figure 4-2 refer to the percentage of the population. Trendsetters and early adopters represent about 30 percent of total adoption, whereas the late majority adopter group represents almost 80 percent adoption.
FIGURE 4-2: The DevOps adoption curve.
For Figure 4-2, I’ve tailored the adoption curve to DevOps to show you how you can expect your colleagues to warm to DevOps as you persuade them. The early innovators, trendsetters, and trailblazers in your organization will dive head first into DevOps without a care in the world. Others will follow them soon after. Later, after you’ve built some momentum with your new system, you’ll see the early and late majority join the club. At that point, you can feel confident that DevOps will embed itself in your company regardless of whether the curmudgeons get on board.
Pushing for change
Gartner, a technology research firm, created the graphic presentation of what it calls the hype cycle, representing the stages of maturity and adoption of specific technologies.
You can see a version of Gartner’s hype cycle displayed in Figure 4-3. Though the hype cycle is generally used to describe the public’s perception of a technology, I believe that it also applies to what you may feel during the first few months of introducing and implementing DevOps. The cycle has five main phases:
- Trigger: The project kicks off. You’ve made no major changes yet and haven’t received feedback.
- Peak of Inflated Expectations: You’re beginning to talk to some people and have generated excitement. Everyone seems to love the impact that DevOps could have on the team, and you’re expecting a relatively frictionless cultural transformation.
- Trough of Disillusionment: Curiosity and excitement begin to wane. The reality of implementation complications and failures are beginning to weigh on you, and you’re receiving more executive pushback than expected.
- Slope of Enlightenment: The realities and hardship of transforming your organization into a DevOps culture are leveling, and the team begins to have a clearer vision of what needs to be done. You’ve received some excellent feedback and know how to get the team to work together to iterate and improve.
- Plateau of Productivity: Production and emotion level off into a steady state of continual improvement. You’re on your way and can see small but important changes taking place.
FIGURE 4-3: My version of Gartner’s hype cycle, applied to the initial phases of DevOps adoption.
Expect a surge of excitement at the beginning of your mission. If you can get through the trough of unexcited (and often messy) conversations about what exactly is needed, you’ll begin to see the progress you want. By then, you’ll have the executive buy-in, engineering groundswell, and management adoption needed for your DevOps transformation process to enter a steady state.
Don’t give up. Feeling frustrated is natural. You might even think about quitting, which is also normal. Going with the flow and allowing inertia to determine your future are so much easier. But making your job awesome is your job, and I believe in your ability to transform your organization in a meaningful way for you, your colleagues, and your customers.
Responding to pushback
Pushback will be a natural part of taking on the challenge of transforming your organization’s culture into a DevOps organization. Sometimes the pushback is quiet; at other times, it’s loud. No matter how the pushback happens, expect that people will push back against the idea of DevOps from all departments and groups of the company: sales, marketing, engineering, business stakeholders — you name it. The reasons will vary. Some people will have valid concerns; other reasons will be absolutely outlandish. Most will be rooted in fear.
Navigating the chasm
Earlier in this section, I present an adoption curve (refer to Figure 4-2). Geoffrey Moore popularized the adoption curve and highlighted the most vulnerable portion of the innovation adoption life cycle in Crossing the Chasm. The chasm is a portion of the adoption curve between the early adopters and the early majority. This is where you’ll experience a tipping point of adoption just as you reach the Trough of Disillusionment in the Hype Cycle (refer to Figure 4-3). Dealing with this chasm, depicted in Figure 4-4, is perhaps the most challenging portion of DevOps adoption. At this point, you experience either full executive support or a groundswell of engineering excitement but have yet to hit majority adoption.
FIGURE 4-4: The chasm in the DevOps adoption curve.
Early adopters enjoy being first, and because of that added advantage, they don’t care as much about the details. On the other hand, the folks in the early majority want to know that DevOps actually works. They may need some additional evidence. If you get stuck in this chasm, I recommend that you take your small band of innovators and early adopters and start practicing DevOps yourselves. Encourage engineers to experiment with the possibilities. Show them how much DevOps can improve productivity and collaboration. Most of all, don’t get discouraged. Rely on the information this book arms you with. Part 2 looks at the entire software delivery life cycle linearly to equip you with what you need to inject DevOps along every stage of software development. In Part 3, you see how to connect the circuit and transform that linear pattern into a cycle of continuous improvement focused on the customer. Along the way, you discover everything you need to move from the persuasion phase to the implementation phase of a DevOps transformation.
Asking “Why?”
You may have heard about a technique known as the 5 Whys, an exercise to uncover the root cause of a problem. This exercise was — surprise! — developed at Toyota. It’s often seen in kaizen, lean manufacturing, and Six Sigma — all of which are approaches to project management. Although the “root cause” concept is an antiquated approach to post-incident reviews (refer to Chapter 18), the 5 Whys technique is still a useful way of thinking through problems.
For an example of using the 5 Whys technique, imagine that someone expresses doubts over DevOps. Here are some “why” questions to ask, followed by possible answers (you’re not restricted to just five):
- Why are you hesitant to adopt DevOps? Because I’ve seen Agile fail. What’s the difference?
- Why did Agile fail? Because we went through the motions but never truly embraced an agile approach to software development.
- Why did your team struggle to become agile? Because sales and marketing determined the release schedule and we had no insight into customer feedback.
- Why couldn’t you talk to other departments or customers? The product owners acted like gatekeepers and everyone stayed in their silos.
- Why couldn’t we learn from that failure and invite sales and marketing to our team meetings? That might help them get insight to the challenges of engineering.
- Why don’t we use feature flags to ensure that products are released at a regular cadence for sales engineering but that we can adopt for continuous delivery? That might actually work. (Refer to Chapter 11 for more information on continuous delivery and feature flags.)
Rarely do problems present themselves in an obvious way. Instead, someone may appear to be hesitant about DevOps but is actually worried about automating themselves out of a job. Or they don’t want to put energy into something, only to have a manager tell them “no.” Digging into the underlying fears that buttress your opposition gives you insight into how to best address the concerns and unify the team.
If you come up against someone who is vehemently against DevOps — either subverting your efforts or openly challenging you — don’t take those reactions or challenges personally. They’re most likely driven by fear: of the unknown, of failure, of success, of becoming irrelevant. Showing empathy for that person’s fear and gently trying to discover the root of it can persuade all but the most cynical engineers on your team.