New tools won't change old culture

I don’t know who needs to hear this, but buying a new treadmill won’t make you a runner.

It’s a mistake we’ve all made at some point. We’ve all decided, “This is the year! I’m going to spend lots of money on new equipment, on gear, on clothes, on cool shoes, and I’m going to <fill in the blank here>”. And we’ve all been rather disappointed when said shiny items find themselves collecting dust, and the treadmill/rower/elliptical are expensive clothing racks.

The same thing holds true for development and DevOps. Organizations invest in new tools, see everyone get excited, only to discover the new habits weren’t adopted. As it turns out, solely investing in new equipment isn’t what brings about change. We need to change our approach, our attitude, our habits.

So, how do we do this? Here’s four big lessons I learned as I became a runner and actually got the return on investment I made in my gear, and how they can be applied to your DevOps journey.

Identify the why

I started running about 10 years ago after my body wasn’t in the shape I wanted it to be and I was generally feeling lazy. I had a desire to improve my health, both mental and physical. Running was the perfect fit as it got me out of the house, gave me goals I could build towards in races, and was rather portable - you can run anywhere! I didn’t want to run just to run, I wanted to run to better myself.

When implementing new approaches for managing development and DevOps, it can’t solely be done for the sake of DevOps. If people don’t understand why changes are being made, what goals are trying to be achieved, it makes it very hard to make the necessary changes, if not impossible.

The first step is to identify why you’re changing our approach, why you’re trying something new. Maybe it’s to increase reuse across your codebase, reduce the amount of manual tasks required for deployment, or improve the security posture of your organization. Typically it’s not just one thing, but they should be clearly defined, identifying where you currently are, where you want to get to, why you want to make the changes, and how you’ll go about doing it.

Start small

My first “run” was barely a run. It was 4 miles on a flat route, but I walked for at least 80% of the time questioning everything. When I actually ran 4 miles from start to finish I felt both accomplished and completely drained. I didn’t build up to it, I just laced up some shoes and went for it. Fortunately I stuck with it, but I wish I would have spent more time ramping up to longer distances.

If you force everyone into a new issue management system, or force migrate everyone over to a new automation server, there’s going to be resistance. Change is hard, learning new tools takes time, and new “muscles” need to be built.

It’s best to find smaller projects with teams who are excited to embrace the new approach. Make incremental updates, giving people time to feel out the new systems, to explore how to migrate their skills, and figure out how life looks. This provides an easier onramp, ensures early successes, helps create internal advocates, and builds momentum for the bigger challenges and updates in the future.

Make it part of the routine

Changing habits can be challenging, and oftentimes the best thing to do is to just keep doing the thing. When I first started, I committed myself to lacing up my shoes and going out the front door three times a week. What I did after that didn’t matter; I was sticking with the routine and forming a habit. After a while it became part of my normal cycle; it’s now just what I do.

The primary reason organizations wind up with shelfware is they purchase new tools, licenses or software which don’t become part of people’s routines. Tools which are out of sight and out of mind don’t get used. Your teams need to develop new habits and routines which involve the new tools.

Using issue management as an example, work with your developers to make updating their items part of their schedule. This might be implemented as part of your regular stand-ups where everyone takes a few minutes to update their issues and review them with the team. Gamifying the process can also be helpful, where team members build credits towards gifts, lunches or a day off, by using the tool every day for a month.

Embrace the journey

Des Linden, one of the greatest American marathoners, once tweeted:

Some days it just flows and I feel like I’m born to do this, other days it feels like I’m trudging through hell. Every day I make the choice to show up and see what I’ve got, and to try and be better.

My advice: keep showing up.

There are struggles in running - setbacks, injuries, bad runs and disappointing races. It’s part of the journey. Learn from mistakes, celebrate the victories, and work to get better tomorrow.

Regardless of how well the initial launch goes, there will be failures in the future. Some developers will reject the new processes. Items will slip through the cracks. Unforeseen challenges will cause problems. DevOps isn’t something which is simply flipped on and is perfect, it’s something which will continue evolve over time.

Just as you monitor your software, you should monitor your teams. Have a feedback process for your developers. Allow them to provide input on what’s working, what’s not working, and how you can best meet everyone’s needs. Document the journey, allowing you to learn from the past which can help guide you to improving your DevOps processes.

More than the tool

Finding the right tool is important, but it’s only the right tool if it gets used. This typically requires a change in philosophy and approach. If you identify why you want to make changes first, then find the tool to support those changes. From there work with your teams to make the updates part of their routine, to start small, and embrace the journey.