Difficult Conversations and DevOps


May 6, 2015 | DevOps | Andrew Racine


Successful DevOps has as much to do with culture as it does with the specific tools used to continuously deliver code.  While tools are easy to learn about, evaluate, and select, culture is a much more difficult beast to quantify. It is easy to say you are working to improve internal communication and collaboration but it is another thing to actually do it–especially when part of that necessary communication comes in the form of difficult conversations.  Based on the framework from the book, ‘Difficult Conversations‘, the goal of this blog post is to give you some structure as you tackle these communication challenges on your quest for DevOps supremacy.


As suggested in the book, every difficult conversation is essentially three different conversations: one that is spoken and two that are unspoken.  The spoken conversation is referred to as the ‘What Happened‘ conversation and will be the focus of this blog post.

In the ‘What Happened‘ conversation people tend to argue over who’s right, place blame, and make assumptions about each side’s intentions.  I’m sure you’ve been in a meeting where a post-mortem is being conducted and instead of going through a ‘5 Why’s‘ or taking a deeper dive into the project, the conversation jumps into a finger pointing session.  So, why does this happen so frequently?  Human nature?  Lack of structure?  Yes on both counts.  You can’t ignore some facts about how we humans come to create our inferences:

  • We often have access to different data than the others in the conversation.
  • We often select based on our own interests, assumptions, and biases.
  • We often interpret based on our own past experiences and implicit rules.
  • As a result we often come to different conclusions.

We see this chain of events occur more often than not in a developing DevOps environment.  With stakeholders from Dev, Ops, Security, HR, Finance, and the C-Suite involved there are a lot of agendas, assumptions, and interpretations that can negatively impact an organization’s ability to stay ahead of the competition and improve their internal processes at the same time.

During these difficult conversations we often end up arguing over who’s right and who’s wrong…however,the truth usually lies somewhere in between.  So, how do we move away from this vicious cycle and work towards a more helpful habit of solving problems collaboratively?  Here are 3 steps that will help you shift the conversation to facts and away from judgments, emotions, interpretations, and expectations.

Shift from Arguing to Inquiring

The first step is to stop blaming and start inquiring.  Instead of snap judgments, think about the questions you can ask that will get to the heart of the matter, the facts of the situation.  As you can imagine, we are looking for open-ended questions at this stage.  The goal is to be able to define their story as much as you can define yours.  By going through this exercise via open-ended questions you will better discover each party’s perceptions and interpretations of what ‘the truth’ is.

Here are some open-ended questions that should help facilitate this step in the process:

  • Would you tell me more about _______ ?
  • I’m not sure I understand, can you give me an example?
  • When you say ________, what do you mean?
  • Why is that important to you?
  • What kind of information do you need in order to move forward?
  • How are you feeling about all of this?

These types of questions will get you started, but beware, blame lurks below most of these discussions.  Blame is a dangerous and sometimes catastrophic variable that can plague organizations for long periods of time. It causes people to cover up information and mistakes, it permanently damages relationships, and it allows problems to persist for far too long because they aren’t accurately diagnosed.  The next step of this process sets its sights on blame and, once again, works to shift the conversation.

Shift from Blame to Contribution

To avoid the ‘blame game’ it is vital to move all involved parties towards actively contributing to a solution.  Contribution assumes a few things: everyone can contribute something to the solution, our purpose is to fix a problem, not assign blame, and by understanding contributions we will learn what to do differently going forward.

Contributions can come in all forms and should be heavily focused on facts not perceptions.  In a typical DevOps environment there can be a lot of innate perceptions that will work against contribution.  Devs are perceived not to plan or do due diligence, Ops are perceived to move too slowly and are usually a bottleneck, and security is perceived as too ‘outside of the process’ to be viewed as a primary stakeholder.  By re-framing the conversation around contribution and business goals, you increase the probability of aligning the team and moving the project forward.

Separate Intentions from Impact

Intentions can be a tricky matter.  It is human nature to make up attributions about other people’s intentions based on how they could potentially impact us.  If that isn’t dangerous enough, while making these attributions, we often assume the worst which can easily put two parties on opposite sides of the table during a difficult conversation.  What most of us fail to realize is that, although other’s intentions are usually invisible to us, they are often much closer to our own intentions then we realize.  Therefore, it is imperative that we begin to separate intentions from impact.

In this framework there are 3 steps to successfully separating intentions from impact:

  1. Observe Your Own Attributions:  What data is this based on?
  2. Understand that Intentions are Complex: People regularly act with good, bad, mixed, or no intentions at all.
  3. Don’t Assume Intentions: This is key but in order to avoid this trap you need to make sure you communicate potential intentions and share how they could directly impact you.

For DevOps to truly create trust between human and technical interactions there is a need for difficult conversations.  The ‘What Happened’ conversation will span across all departmental lines and be a true litmus test to see if your overall corporate culture can sustain a DevOps mindset and action plan.  As in any system, this framework is only as effective as its weakest link, so by having leadership not only buy-in, but also effectively communicate in this fashion, you dramatically increase your chances of sustainable success.

So the next time you find yourself in a ‘What Happened‘ type of meeting or conversation, remember to ask yourself these important questions:

  • What is my story?  What is their story?
  • What have we each contributed to this situation?
  • How can we fix things going forward?
  • What assumptions am I making about their intentions?
  • What is the impact on me?
  • How can I communicate this to them in an effective way?

This type of communication is contagious within an organization. Start today and master these essential, yet difficult, conversations.

If you’re interested in learning more about the cultural aspect of DevOps please click on the link below and answer a few questions.  Your feedback will allow us to continue to create helpful content for you in the future.





Keep up-to-date on security best practices, events and webinars.

Share This