Author: Chris Riley

“Culture”. Any time that two or more people get together to do anything  —  whether it’s DevOps, or marketing, or just eating lunch  —  they form a culture. Even if they pointedly ignore each other, it’s a kind of culture (just not a very good one). When we the preachers of DevOps say the word “culture” we are simply stating the fact that people are a big factor in DevOps success or failure.

There’s no point in trying to get away from it, even if you want to.

Cultures form naturally.The character of a culture is determined just as naturally by the people who compose it, and the conditions under which they operate. If a development team, for example, has the right mix of people, and they’re working in an environment that allows easy, ongoing communication, they’re likely to develop a culture with some very positive characteristics. If some of the key people on the team have personalities that clash, on the other hand, or if there are major barriers to communication, the culture that develops may be seriously weakened or dysfunctional.

If you are a manager with responsibility for a DevOps team, it will develop a culture, whether you actively participate in it or not. Either way, you’ll have to deal with the results. 

At this point, you may be thinking, “Wait a minute!” We’re using agile, and we’re fully committed to the process.  We’re also using the best tools available for DevOps implementation and management.  Shouldn’t a strong, all-encompassing process and a set of first-rate tools be able to override or even turn around a weak team culture? The long and the short answer to that question are both the same: You cannot separate process from culture, and you cannot even separate tools from culture.

Suppose, for example, that your development team is broken up into cliques with a minimum of communication between them, and that your operations team has long since become resigned to having almost no communication with development. You can have as many meetings as you want, but until you break down the cultural walls, they’re probably going to be very frosty and uncommunicative affairs.

The success of any process depends on the willingness of the people involved to participate; otherwise a process that requires cooperation is going to be blocked, if any of the key participants are unwilling to engage 

And it’s the same with tools. Tools can create processes for you, but when they do, they will own you, and not the other way around. Even the best tools are useless in the hands of a culture that has no interest in using them. You might, for instance, implement a well-thought-out, integrated set of DevOps tools, but if your individual team members go around singing “I did it my waaaaay!” and refuse to let go of their existing tools and practices, the new tools won’t amount to much. 

So what can you do? As it turns out, there’s a lot.

Culture grows from the top down as much as it grows from the bottom up. Managers can and do have a major influence (whether it’s by commission or omission) on the development of a team’s culture.

One of the best ways to foster communication, for example, is to be the communicator.  Speak honestly to your team members, listen to what they have to say, draw them out (in a friendly and supportive way) when they appear to be holding back, and when necessary, work with individuals to get them to communicate with each other.  If your team members know that’s what they’ll experience every time they go into a meeting, they will become more communicative  —  and it will show up in their level of day-to-day cooperation.

It’s the same way with tools. The truth is that people frequently become attached to their old tools. So much so, they disappear into their daily activities. They are often unwilling to give them up, even if those tools make their jobs more difficult. Giving up your existing tools can feel a lot like you’re giving up your independence, particularly if you’re being asked to shift over to a much more integrated and collaborative environment.

This is also part of a team’s culture, and as a manager you can, and often must, do a considerable amount to shift that culture from one that values autonomy above all other things to one that places a premium on cooperative use of tools. Another way to do this is to create shared objectives. Tangible motivators that cross the entire team, not part of a single one.

Tools won’t make a culture.  A culture makes use of tools.

So maybe the place to start is with your own understanding of the culture that is already in place. Are you clear on the nature and the current state of your team’s culture?  Do you have a clear understanding of what your team would be like if it were fully committed to DevOps culture?  How near or how far apart are those two visions?

Start from there, and take your team where they need to go.

DevOps tools without a DevOps culture does not create a DevOps environment. They are tools with DevOps capabilities waiting for a committed DevOps team to put them to good use.

If team members understand the value of having a DevOps culture  —  to them as individuals, and to your organization  —  they will be willing to commit to that culture.  But they need to see that value, and in order for them to see it, you as their team manager must have a clear vision.