DevOps: Tools Can Lead The Culture Change

Alt + E S V

DevOps: Tools Can Lead The Culture Change

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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.


  1. An AnswerHub community can be a catalyst to bring about this culture change for internal dev teams.

  2. Hi Rachel, I’ve explored similar topics based on my experience bringing tools like GitHub, Slack, Travis CI, etc. into IBM. I summarized some of my learnings in this 2017 article: “Tools as a Catalyst for Culture Change.”

    I’d be happy to discuss these topics with you—I’m sure you have many novel insights.

  3. Love this article, as I think the relationship between technology and culture is increasingly and incredibly important right now.

    Aristotle and Heidegger thought so, too, and interestingly enough, there’s a lot from these philosophers that I believe we can learn and apply to better understand this relationship in today’s setting. Credit due to Brian Behrenshausen for turning me onto this connection.

    Heidegger reminds us that technology comes from the Greek words technikon and techne, which refers to both the science and art of manufacturing some thing. In particular, techne is a kind of ‘know-how’. ‘I know how to paint a portrait’, for example, is techne.

    Technology happens when we crystalize ‘know-how’ into a tool. A modern camera has the technology ‘know-how’ to use f-stop and depth of field and bokeh effect to create a portrait, for example. It has crystalized the kind of know-how that has been established by the habits and customs of great painters — making it more accessible, even making it the default behavior, for the users of the tool.

    In this way, technology makes it easier to adapt habits, when those habits are crystalized as part of the ‘know-how’ in that tool.

    These habits can be good, or they can be bad — so choose your tools wisely! When a group shares a set of habits, and practices them over time, it becomes their culture.

Leave a Reply

Your email address will not be published. Required fields are marked *