I’m often asked how to create a DevOps Culture and there is no single answer to this question. The focus initially for me in any cultural movement is to understand how the organization incentivizes and what its core beliefs are. When it comes to DevOps, I am normally looking for ways to bring these two teams together from a fundamental aspect first. One method I have found that works well when I’m consulting with these two teams is a Culture Session.

Teams often end up with a subculture that incorporates aspects of the macro culture. These subcultures can evolve into the silos that DevOps is designed to break down. A Culture Session is one where you bring these teams together en masse and work on defining a new unified subculture.

Culture Session

The session starts before we even meet, with buy-in from the leadership. There will likely be detractors that will not want to attend or contribute. Having leadership not only broadcast the meeting, but support the change will be critical to success. We want to address this issue from the top down as well as from the bottom up.

With both teams in the same room we will begin to address the culture we want. Language should focus on the fact that the team is made up of all engineers. Creating a sense of a single team spanning Development and Operations is a key focal point in DevOps. In order to build a unified new culture, we must discover the core beliefs of the new team. Ask the team what they consider our core beliefs of their culture is. Don’t restrict the statements that come out of this part of the session, everything has merit and should be included.

It can be difficult sometimes to get a team to think in terms of beliefs. If we are greeted with blank stares or eye-rolls when asked what we believe in, try a different tactic. Ask the team what would be an ideal company to work for and build beliefs off of these statements. Here are some examples from my sessions, converted into beliefs.

Once you have a fair number of items (based on the number of participants) we can begin to order the list. It’s acceptable to write these on yellow sticky notes as well if you don’t have a whiteboard. The ordering is accomplished via a process similar to voting in Lean Coffee. Everyone gets three votes; dispersed any way they desire. I tend to use dots on the cards and then add up each card. List the top 5-10 cards from highest to lowest, and these are your top cultural values. Discuss the results with the team, are they surprising?

Aligned Goals

I believe that aligned goals create a more comfortable work environment and encourage the building of trust. Your teams goals should not only be aligned with the business, but also with your culture. This will make introducing and reinforcing the proper behaviors easier. Some of the highest performing teams I’ve worked with had alignment on all three fronts: Business, Behaviors and Culture.

Behavior and Community

Now that you have a core set of beliefs, it is time to begin talking about the behaviors we wish to see that drive those beliefs. The leaders at all levels must continuously encourage the community to reduce behaviors that are not aligned with core beliefs, while encouraging those that do. Over time the community will govern its own members, solidifying the positive culture and beliefs. The ability of the community to manage its own members requires the alignment I spoke of earlier.

DevOps Language

What I call DevOps Language is key to building and maintaining a strong community. A major component to DevOps is a culture that is accepting, open, honest, collaborative and trusting. We tend to get defensive when we feel that our abilities or intentions are being called into question. The following shifts may appear simple and non-significant in the beginning, but these simple changes in how we communicate greatly enhance our ability to clearly get our message across.

Why to How

Moving from “why” to “how” is a great first step in adopting a DevOps Language. Often we are faced with a lack of understanding that we desire to fill. Perhaps you are looking to get a better handle on the design or structure of a block of code or infrastructure. Maybe you are attempting to learn a process on a new team you’ve just joined. Regardless of the scenario, you are going to have questions. Like many “trigger” words, “why” tends to send some people into defense mode. Why can (and tone of voice is crucial here) make people feel as though you are questioning their intelligence and intent or even implying that you would have done it different (aka better). Moving the language from why to how you did something invites the listener to share their reasoning and experiences, not defend their position.

I Know to I Agree

Another simple change that I have found and adopted into my DevOps Language is “I agree”. I had a bad habit of saying “I know” when someone would tell me something I… well that I already knew! Again, the issue here is subtle, but with all things subtle they build over time. Saying “I know” sounds condescending at times and can be seen as an attempt to exert your superiority. In other words, this is not an collaborate language tactic. When we say “I agree” instead, we are saying that we are aligned in our thinking. This is including all parties and doesn’t shut the conversation down.

Should’ve to Will

DevOps is all about collaborating to make our future better. We often need to review events of the past to identify how to create a better future. The key to this review is to not focus on counter factuals rather we use forward thinking language. Concentrate on moving from “we should or could have” to “we will”. Over time this will help the team to maintain a forward thinking bias rather than dwelling too long on the past.

Closing

Creating systemic long term positive change within your organization takes time, effort and alignment. Creating a unified culture and belief structure through collaboration and inclusion paves the way for your DevOps future. Focus on the language and behaviors that reinforce your culture. Encourage members of the community to help govern and guide the culture, using the agreed upon beliefs. Include the beliefs and DevOps language in the interview and hiring process, in order to include new employees early and often.

Let’s collaborate! I am always looking for ways to learn and grow. How have you aligned your teams around culture? How can I make this exercise more effective?