Leading a DevOps Movement

Nearly every conference I attend (DevOpsDays included) makes me feel like a kid in a candy store. I get a sugar rush being around all these sweet new tools, techniques, and methodologies - things that promise to solve a headache or two of mine. Actually - Willy Wonka hits the nail on the head:

If you want to view paradise, simply look around and view it.

Anything you want to, do it;

You want to change the world? There’s nothing to it!

Candy!

With all these new ideas and tools the conference has brought to my attention, I’ll very likely go searching for problems that this new tool will solve with ease. Someone said they needed their build fixed!? Ooh! I’ll fix it up right quick with this new hammer of mine!

But with all this excitement I quickly find myself in trouble. Some examples I’ve encountered:

Stuck.

But the situation takes an even further turn for the worse: the half-integrated tool, technique, or method now starts being abandoned by co workers because the old way “works better for them.” Instead of having just the mess I had before the conference, we now have that mess plus a shiny new mess and I have to maintain both. Because let’s be honest: “I touched it last.”

Then, as I’m taking a break for lunch one day, I see a an article from one of those DevOps Unicorns I met at the conference. Good, I think to myself - they probably have some useful advice to give me in my current state of affairs. But the article is about how they’re now deploying rainbows thousands of times a day! What!?

Rainbows! Unicorns!

How can this be!?

What did they do differently from me? I’ve tried the same tool but got totally different results. I’ll need some serious help to get out of this mess now.

My team at ReadyTalk, affectionately known as the DevTools team, is notorious for poking and prodding at various “unsolvable” problems. We pride ourselves in the ability to get our engineering teams at ReadyTalk out of the serious ruts that they sometimes get into.

Another way to think of the DevTools team at ReadyTalk is…

If there’s somethin’ strange in your neighborhood…

If there’s something weird and it don’t look good…

Who ya gonna call!?

Ghostbusters!

Consider us the Ghostbusters of ReadyTalk Engineering.

You want in on how we got to be so cool? You want to know how we get improvements and change to really stick? I’ll bet you do.

Here are 5 principles we’ve found useful in reducing ruts and driving improvements at ReadyTalk:

Run a Pilot Program

 Principle #1: Run a Pilot Program

 (or: don’t try to fix everything at once)

A few years ago I was consolidating a lot of Ant build logic that should have been in a shared library of sorts. To roll out the new shared build logic into master, I figured the best time to change something was when no one was in the office: Christmastime. Though the builds worked great on the CI server, needless to say, there were many steaming Christmas presents on peoples’ workstations when they came back to work in the New Year.

Since that time, we’ve gotten better at working with individual feature or product teams alongside their development iterations to slowly introduce new conventions or functionality. If something goes wrong, we see it first hand and the problem only affects a small group. As we rotate to work with each engineering team in ReadyTalk this way, the teams also get the chance to learn how to contribute to these libraries and tools so we’re not the only ones advancing our development tooling.

 Additional Resources

Continuous Delivery (Jez Humble and David Farley) this is funny, because CI/CD/etc is my claim to fame… but sometimes I forget the principles during my day-to-day.

Toyota Kata (Rother) in the same vein as the Continuous Delivery book above, but this is a bit more of a study on Toyota and how they not only perceive their problems but how they manage the people around the problems.

Angry Child

 Principle #2: Change is an Emotional Process

 (and feed people ownership and hope)

While changing things out from underneath people, you’re bound to make people displeased… ok downright angry. Most people are upset when things change for a few reasons:

Since change is required to improve anything (a necessary evil) I attack the emotional backlash by feeding people. “Feeding people” has three aspects for me:

  1. Raising peoples’ blood sugar will always work to your advantage. Take a lunch hour, a quick coffee session, or happy hour with people that you can tell are frustrated and close to punching you in the face.
  2. Use this conversation time to listen to their problems. This is the DevOps empathy bit. Reflect their problems back to them so that they know you heard them.
  3. If they are frustrated by something you are working on, own it and offer hope by delivering a portion of your vision that explains why the change is necessary. The goal though is to make sure that they know you have a grand plan and are committed to making the changes a success.

 Additional Resources

Driving Technical Change (Terrence Ryan) a software engineering pattern spin on how to interact with different types of people well

Fearless Change (Linda Rising, Mary Lynn Manns) similar to Driving Technical Change, but goes way deeper into specific principles instead of “people buckets.”

Stamina

 Principle #3: Leadership Takes Serious Stamina

 (which Takes Time And Consistent Personal Growth)

A lot of people think that leadership requires intellectual prowess. It really doesn’t. Leading people through change demands significant emotional stamina and stability from the leader - skills that help care for and inspire people.

Emotional stamina - stamina that’s required to lead an initiative takes time to develop. I like to compare a lot of our attempts to drive change like this:

Consider a baby who’s at the stage where they’re still a bit wobbly. Now imagine that’s you. Someone hands you a RedBull and you down it. Being all hopped up as you are, you go and try to deadlift 400 pounds. Not going to work, is it?

You’re going to have to work - over the course of years, growing in mental maturity, emotional stamina, and physical endurance in order to complete that task.

Put in consistent time toward your own personal growth. Keep doing reps. Keep working on your weak points.

 Additional Resources

Failure of Nerve (Edwin Friedman) This book has changed my life the most. Friedman picks apart traditional ways of thinking about leadership and meticulously delivers his approach in its place.

Surprising Purpose of Anger (Marshall B. Rosenberg) One of the first books I read on having a non-anxious presence, this is a quick read to start you thinking about how you might be unknowingly contributing to the interaction problems around you.

Walk Your Cat

 Principle #4: Get Out Of Your Own Rut

 (or: challenge certainty and routine)

Though I’m going to bet that a lot of us consider ourselves to be agents of change in the world, we’re in our own unique ruts. We need to challenge certainty and routine. If we don’t, we might not see how other people view the world. And if we don’t interact with people who perceive the world differently we’ll easily fall into thinking we know it all.

Consider working at a food bank, participating in a Habitat For Humanity Build Day, taking a class that you wish you could have taken in college, or learn how to shred on the guitar.

As Albert Einstein noted:

We cannot solve our problems with the same thinking we used
when we created them.

Even though it rings so true, we so often forget it. Interesting how that works, isn’t it?

 Additional Resources

Necessary Endings (Henry Cloud) To get out of a rut I’ve found that you need to learn how to say “No” more often. This book explains exactly why that is and how to start to do it.

Codependent No More (Melanie Beattie) We in the software industry are famous for flying in at the last second and saving the day. Other circles around us would call this rescuing behavior or “codependence.”

Logic of Failure (Dietrich Dorner) I read this on my honeymoon. :-) Explains why humans have a hard time wrapping their head around systems that contain many interconnected variables (i.e. computers). Really deep. Have read it a couple times since.

Essential Deming (W. Edwards Deming) This book is the perfect book to skim as you’re on the bus or train headed to work. There’s a decent amount of repetition of content in here, but it changes your focus on how to build high quality software products.

Ermahderg

 Principle #5: Regularly Reflect On Your Progress

 (or: let your history of success push you further)

This is the hardest principle for me. When you set out to change the world into the paradise you wish it were, you jump right into enacting your force of change. Since change usually happens very slowly over the course of time, you’re likely to forget where you started and how your journey to radically transforming the organization you’re apart of twisted and turned. When you’re a few years down the road you’ll wonder if you’re actually making a difference.

We’re already creating compelling stories.

Let’s document them so we can share them more often.

Let’s use our stories to propel us further.

 Additional Resources

Ted Talks Spend part of your lunch once a week and watch a video or two from the vast archive of fantastic and inspiring talks. Many of them are oriented around people telling great stories to reflecting on how they got to where they are today.

Start With Why (Simon Sinek) The title says it all. As engineers we commonly start with “what” and “how” but we forget that we are internally driven by the “why” (building awesome stuff).

Made to Stick (Chip and Dan Heath) Also an easy title to grasp. How can you change your message to improve your idea evangelism?

Communicate to Influence (Ben and Kelly Decker) One of my coworkers attended a Decker Communications training and this book provides an inspiring charge (imagine that) to change the way you verbally communicate in order to see people come alongside you in your visionary endeavors.

 
21
Kudos
 
21
Kudos

Now read this

Feature Branching

I recently made some waves on Twitter (and other circles) regarding my dislike of “Feature Branching.” The bigger the apparent reason to branch, the more you shouldn’t branch @jezhumble Feature branching is a poor man’s modular... Continue →