Over a million developers have joined DZone.

The Curious Relationship of Culture and Tools

DZone 's Guide to

The Curious Relationship of Culture and Tools

· DevOps Zone ·
Free Resource

We surround ourselves with things that look like us, and can even be shaped by those things. Individuals look like their dogs and their cars. Meanwhile, Conways law tells us that they are constrained to build systems that mirror their organizations. The reverse is also true. The selection of a more modular architecture tends to result in an organization with more (smaller) teams.

Organizational culture is also shaped by their tools. I first observed the link between tool and culture years ago when selling continuous integration tools. CI tools integrate with a ton of stuff, and so if you’re trying to figure out your tool is a good fit for an organization you ask about source control, bug tracking, and testing tools. What I learned quickly was that knowing the source control tool an organization uses told a great deal about what they value. A Perforce shop (setting aside game studios) was one where the developer was king. Meanwhile a Harvest shop valued control over agility. Where Subversion was used by development but changes were then exported into a system of record SCM like ClearCase, you knew the organization had the silo challenges we now call a “DevOps problem.” Often, knowing the source control tool told you who in the organization you had to sell and how to do it with alarming accuracy.

Finding tools changing culture

This insight was handy in sales, but not generally interesting. What brought this back to mind was @OnCommit’s presentation at IBM Innovate 2014. There, he argued against conventional wisdom that you can change culture by implementing tools. The argument is that culture within IT is basically our norms of how we act, and our shared language. When we change a process radically by implementing new tooling, we change some behavior and the language. When everyone can clearly see that version 1.2.3 is in QA, we ask testers about the state of that version. We speak about promoting that version to UAT rather than “the latest”. In turn, we think in terms of versions rather than “the latest” and come to value versioning more. When considering infrastructure as code in a years’ time, the argument that we can version infrastructure will be more compelling because our values will have changed. An information radiator nudges culture.

Similarly, many of the companies who valued control over agility when selecting those CI tools did so because they were looking for correct, managed builds. Continuous building was either seen as undesirable or irrelevant.  It was amazing to visit this companies over the years. While still valuing control, build frequency would pick up over time, and developers would act a bit more Agile. Many of these shops are in a water-scrum-fall mode now. Part of this is simple economics, as the price (effort) of something falls, demand for it picks up. Maciej Zawadzki suggests in this video the heuristic that automating a previously manual deployment process generally results in ten-fold increase in deployment frequency.

Use tools to drive change

In Jurgen Appelo‘s book “How to Change the World” he calls out Infrastructure as one of five pillars of changing an organization by manipulating its environment. This may mean sitting people closer together to improve collaboration, or it could be changing tools. The key is to surround people with guidance pointing them in the right direction.

Tools have a sneaky way of reforming the organizations that implement them. Organizations will often come to value what their tools value, so long as the tool is effective at what the organization selected it for. Individuals and teams who are looking to drive cultural change should be aware of this relationship.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}