It’s an industry truism that DevOps is about culture change rather than products, but tools can very much lead a culture change and we shouldn’t underestimate their role.

CloudBees hosted a customer panel at the DevOps World | Jenkins World Conference in August. The group fielded a question about how to drive DevOps culture change within an engineering organization, and George Swan from Autodesk shared a particularly compelling response. Adopting GitHub as Autodesk did, for example, can very much drive a change in working practices.

Swan observed many people attempt to implement DevOps practices by aiming for culture change first, which then impacts how the company adapts/creates processes which supports their tool selection.

This narrative of the importance of culture is supported by many of the foremost thinkers in the DevOps space. By way of a brief sampling, in her excellent book DevOps For Dummies, Emily Freeman writes:

DevOps is a philosophy, one that prioritizes people over process and process over tooling.


As you continue in this book, you’ll notice that I deprioritize technology. Why? Because technology is the least complicated and least critical aspect of creating a DevOps culture. Improved technical practices are the result of a DevOps transformation, not the journey itself.

Liz Fong-Jones explained how no tool is a silver bullet that can fix a broken culture.

Bridget Kromhout channeled The Princess Bride and reminds us that DevOps is not a SKU that can be purchased.

As Swan correctly noted, culture tends to dominate discussions about DevOps transformations. But in Swan’s experience, “culture change” was too abstract a concept to resonate with most people. Tangible changes, like changes to tools and technologies, can serve as important drivers that help people achieve culture change. He therefore hypothesized that people should consider approaching culture change from the opposite direction suggested above: changing tools to change processes to change culture.

I’ve spent a couple months noodling on these various perspectives. They seem to be at odds with each other, and yet I also believe both have merit.

If you are trying to drive organizational transformation with procurement alone you’re in for disappointment. Tools cannot fix a broken culture. You can’t buy your way out of a culture issue. Tools can’t save you if you’re ignoring underlying issues like internal power struggles, lack of trust across teams, siloed communication, etc. There are no silver bullets.

But that said: tools can very much lead culture. For example, part of AutoDesk’s transformation journey was moving the team to GitHub; that tooling change was a huge underpinning to all the subsequent changes to collaboration and communication in the organization.

Tools can be critical to changing people’s mindset. It’s hard to practice the right behaviors without the right foundational toolset. Tools can enable new ways of working and collaborating.

In the end, this is not an either/or. Technology supports culture change, but technology alone is insufficient to drive a culture of shared ownership and accountability. Tools are not magic, but they can be a tangible pivot point around which the organization can transform.

Disclaimer: CloudBees is a client and paid my T&E to DevOps World | Jenkins World. GitHub is also a client.