Vulnerability and DevOps

Something you don’t hear about often in the DevOps world is the importance of vulnerability. From what I have seen in the DevOps world, collaboration is overstated, empathy is next, but not being vulnerable. Probably because it is one of the most difficult things to do.

This is actually kind of surprising to me. Everyone talks about the issues between Dev and Ops, how collaboration and how empathy is so important. But how do we get to collaboration and empathy? Cross-function teams? Better Scrums? Agile Spaces?

I believe that none of these techniques is the answer. Certainly, all of these things help and there is a place for each of these techniques, but like any technique, they work best in a given environment. Without the proper conditions DevOps, scrum, cross-functional teams, kanban and agile itself are all superficial.

The foundation of every one of these techniques is trust. Trust makes a cross-functional team work because the team members know that they can rely on each other. Trust makes Scrum work because the team feels comfortable and safe enough, to be honest with one another. In my opinion, trust makes any form of any organizational technique work.

Without trust, nothing works. Without trust, kanban can’t work because people may hide their ideas and incomplete, or false data, is added to the board. Cross-functional teams won’t work because each team member will protect themselves over protecting the productivity of the team. Scrums won’t work because people will take on tasks that will benefit themselves and not what’s best for the project.

But how do we get to trust one another? Most of the literature around building trust says something along the lines of, “be vulnerable.”  If we do not show vulnerability we cannot have a foundation for trust. I think that building vulnerability between co-workers is the first place we should start.

We see examples of the importance of vulnerability all over the place. One of the most common team building exercises is trust falls.  A trust fall puts one’s physical self at the mercy of your team in hopes that you can build trust in them and know that they will keep you safe. In the Phoenix project, the CEO character had all of his IT leaders sit in a room and say something personal with one another. It wasn’t until this vulnerability exercise that they started to work together to and really begin their transformation. At the end of the audio series Beyond the Goal by Eliyahu Goldratt, he talks about how important the decisions makers discuss with one another the details of their areas and what their goals are.  Once vulnerability and openness are in place then people really begin to be open for change.

Yet I almost never hear of any company starting with vulnerability or trust. Companies and consultants, in my experience, almost always introduce some kind of framework and prescribe some set of steps that supposedly lead to success. And I personally have not seen the success that the frameworks promise.

This is not to say that I am writing off any of these techniques, they work and any one of these techniques I have mentioned can lead to building trust. It’s hard not to get to know someone when you are sharing a desk in an Agile space. It’s hard not to gain a better understanding of different areas in a cross-functional team. It’s hard not to understand why someone else is so busy when you can see their to-do list on their kanban board. Understanding leads to vulnerability, which leads to trust.  So as a by-product, trust forms.

I think, however, that trust should not be a by-product of these techniques. Trust amongst team members should be the first goal of an organization, at the very least it should be defined as a goal. Trying to build teams that can be vulnerable with one another takes time, but that vulnerability also accelerates change. The vulnerability and trust create fertile soil for openness that brings collaboration and trust. From collaboration and trust comes the bridges between teams, for example, Dev and Ops.

It’s challenging to be vulnerable, the passage in the Pheonix Project where they had trust building meeting was a difficult portion of the book. Each one of the characters said very personal things that triggered powerful emotions. Anyone who has a had to vulnerable with someone else knows how painful it can be to open up, especially in environments where people have been hurt by others in the past. Even writing this piece makes me feel a little uneasy at the thought of opening up, especially with my coworkers who I want to think well of me.

But it takes courage and humility to vulnerable. Will it be hard to open up? Yes, but will there be benefits from it? Definitely!  Vulnerability means stepping out on one’s comfort silo (my new word for comfort zone). The vulnerability may mean recognizing that way we measure each other and ourselves may be wrong. Vulnerability means risk.

But how does the saying go? “No risk, no reward?”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s