Turning Cynicism Into Hope

If you’ve ever led a DevOps initiative, this may sound familiar. When you walk down the hall, people avoid making eye contact with you, fearing they might become your next target. Colleagues you approach to discuss improvement ideas accuse you of trying to eliminate their jobs. Project managers refer to you as “the person everyone loves to hate” — to your face.

The paradox is that although people desire change, they resist change. And DevOps is a BIG change, one that involves organizational culture, practices, and tooling.

You may also enjoy:  DevOps Mentality

Change introduces risk and uncertainty, and it forces you to get out of your comfort zone. There is also an unspoken accusation that what you’ve done until now is not good enough, and there’s shame and loss of face associated with that.

Dickens’ famous opening to The Tale of Two Cities, “It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness,” could’ve been written about a DevOps transformation. On the one hand, DevOps teams are carrying out brilliant, innovative work that enables significant improvement in deployment lead times. On the other hand, those benefits are not seen clearly by the business because the optimization is only local.

Worse still, teams are often mired by over-governance of change control, pulled into countless meetings and hamstrung by infrastructure changes. Not only is there mistrust between IT and the business, but the DevOps teams can also feel powerless to drive real organization-wide change due to all the red tape. Cynicism simmers beneath the surface, and a further reluctance to put oneself out there creeps in.

Here are some tips for converting cynicism into hope, or, even better, preventing it in the first place.

Take a Chapter from Middle School

Not Just for The Cool Kids

When you’re doing an experiment, you start small. A single team runs a DevOps experiment to learn if there’s value before attempting to scale it to the rest of the organization.

But there’s a danger in positioning your DevOps initiatives as something just for the “cool kids,” i.e., the digital products. It makes everyone else feel left out and increases the disparity between the teams working on new product lines and those managing the rest of your portfolio, including all the legacy stuff.

While it’s great to talk about accelerating delivery, deploying in the cloud and automation techniques, if the message is that this only applies to some areas or people, others may not understand how it benefits them. As a result, they are going to feel left behind.

The message, therefore, needs to be that if you really want to change culture and influence people’s mindset, you need to demonstrate that you are invested in all of your associates. You need to show them that you’re willing to help them develop the skills they need to be a part of the transformation.

In practical terms, try to make your experiment as inclusive as possible. Spread the experiments around so that everyone gets a taste and has the opportunity to participate. Make DevOps something for the entire organization, and not just for a few cliques.

Prepare for Both Fixed and Growth Mindsets

In her groundbreaking psychological study of middle school girls, Professor Carol Dweck documented two mindsets in the approach to talent and success that influence a person’s entire life.

In a fixed mindset, people believe their basic qualities, like their intelligence or talent, are simply fixed traits. In other words, their value is derived from what they already know.

In a growth mindset, people believe that their most basic abilities can be developed through dedication and hard work — brains and talent are just the starting point. Simply put, your value is based on what you can learn, so naturally you are more open to the challenge of getting better.

When you’re trying to get people on board with your DevOps initiatives, make sure you have a story for each mindset. It’s fair to assume that many people in your organization will be of a fixed mindset for whom change is very threatening, so make the journey as non-threatening as possible. Don’t be overly critical of the current state, rather emphasize how their experience is important and valuable to the new initiative.

Take a Chapter From the Sea

Empower Teams to Captain Their Own Journey

Too often we forget that the people doing the work are in the best position to determine which changes and improvements to make. We hire external consultants to tell us all the things we’re doing wrong, when really the teams themselves should charter their own transformation journey.

As a start, provide the team with metrics that reflect their current performance. For example, calculate the Flow Time for a feature or defect (how long it takes to do the work, from start to finish, from accepted to done). Don’t use the metrics to compare them with other teams, just make them available for their own consumption.

Next, give them the license to be creative and experiment. You will be amazed at what they’ll come up with. Being empowered to drive change does amazing things. The quietest people start to speak up. Contractors, who rarely have a say in anything, start piping in with their experiences at other companies.

After your experiments, celebrate even small improvements and reward participation. Rewards don’t have to fancy or expensive. Tip: People love laptop stickers.

Don’t Knock the Wind out Of Their Sails

There’s nothing worse than getting people all excited about an experiment or a change, and then putting up myriad barriers to their progress. And then doing it again and again. If you do it three to four times, you’ve killed their motivation.

No one wants to feel like a Ferrari surrounded by a herd of sheep. Make sure that your experiments are not blocked by red tape and slow approval cycles. That’s a recipe for cultural disaster. Instead, make sure leaders keep up with the energy their people have. Let those engines roar.

Take a Chapter from the Kitchen

Don’t Throw out Ideas Just Because They Aren’t Ripe

Not every good idea can be completely implemented today. However, that doesn’t mean it’s not a good idea.

Here’s an example: When DevOps started to become “in vogue” circa 2013, a software delivery organization at a Fortune 100 enterprise had the idea that it needed to focus on accelerating delivery all the way across the value stream, from customer request through deployment.

At the time, leadership was not convinced that there was a true business need to go faster and didn’t really endorse the effort. Undaunted, the DevOps transformation team decided to find one business area that was interested in going faster, and they worked with them to experiment with providing this type of capability.

Several years later, when the entire business felt the urgent need to respond faster to the business and accelerate delivery capabilities, this enterprise already had a tremendous head start. It was able to then build on top of this experiment.

So be very careful not to dismiss good ideas, just because the organization or environment are not quite ready for them today. Instead, experiment where possible and create a backlog of good ideas to return to when the environment is ripe.

Don’t Let Perfect Be the Enemy of Good or Better

Software development in the modern organization is vastly complex. Progress can be slow, which can lead to frustration. After implementing changes, people feel they should be doing better, delivering faster.

Make sure your teams can appreciate how far they’ve come, by reminding them how it used to be six, 12 or 18 months ago! Granted there is more to do, but there is still value to all that’s been achieved. And at large, complex organizations, progress will come from a continuous series of baby steps, not from a big bang.

After all, your company has got to where it is by getting more things right than wrong. It is this current state where you can focus on how you got to where you are, and working with people — the business and IT teams — to help you get to where you want to go. A coming together to create a tale of only one prosperous and hopeful city.

Further Reading

DevOps Starts With Leadership and Culture

DevOps Business Value and Advantages