Trust is the foundation of DevOps

[DirkLehmann]

[tl;dr]

• Organizations going through a DevOps transformation must review their culture, to evaluate whether it is meeting the requirements of a true DevOps organization


• An absence of trust is the root cause of many organizational problems


• Trust can turn slow organizations into high performing organizations


• Team size matters, as to foster trust, effective communication is essential for a high performing culture


• Diverse and collocated organizations foster trust


• People must feel psychological safety to build trustful relationships


• Like watching videos more than reading blogs? See my Keynote on Trust as foundation of DevOps from DevOpsDays Kiel 2018

 

Culture - The hardest part of CALMS

Since quite a while I observe that more and more organizational transformations which try to apply DevOps methods get stuck as they're focusing too much (or exclusively) on the technical aspects of DevOps. Looking at the famous CALMS model (Culture, Automation, Lean, Measurement, Sharing) those initiatives often focus mainly on automation (e.g. by speeding up their deployment pipeline) and measurement (e.g. by adding monitoring/telemetry capabilities to their services).
But implementing tools is the "easy" part of DevOps, as it is the manageable part. "It will take <x> days for <y> persons to implement a new/better/fancier/... <whatsoever> which will ease the software delivery."

Don't get me wrong. Adding automation (or monitoring) capabilities is great! But the point is, sooner or later (mostly later) they realize that they might have implemented the most sophisticated/fast/reliable/... CI/CD pipeline which enables the team to put their stuff out into production within a few minutes, if only the organizational processes would cope with the technical possibilities the team now has.
As those organizations often still work in a command and control mode, each change to the productive system must be change-approved by at least one high-payed person, plus they need to file some documents which once more describe the changes they aim to make to their productive system.
In short: Processes are too slow, people spend too much time on toil rather than solving real customer problems. Latest at this point they realize that they've missed the culture part in DevOps. ...Or they just boldly go ahead and tell everyone that this DevOps thing was just overhyped (they knew it from the start, right!?) and it just doesn't work (in the enterprise world).

Changing organizational culture is hard and maybe that's already the explanation, why it's easier to focus on automation and monitoring tasks first. Changing culture is the not manageable part of a DevOps transition. You need to work with humans who potentially need to change their habits, which they've cultivated over years or even decades. Habits which work for them. Habits which brought them into their respected position they are now in.
Changing habits, so that a new organizational culture can form based on autonomy and empowerment, will take some time. Yes, most likely you cannot even tell upfront how long exactly it will take, or whether it will even finish...

However, the good news is that most people in a workforce like to work autonomous. They like to be empowered to make their own decisions. They like to improve their skills and they like to see a purpose in their work (see also Dan Pink's talk at the RSA on what motivates people)
So the question is how do we get there? How do we transform our organization's culture so that it is aligned with the challenges of today's businesses?
This is where trust comes in as an enabler for your cultural DevOps transformation.

Why trust?

Let's see what happens if we don't have trustful relations in an organization:

In his book "The five dysfunctions of a team" Patrick Lencioni puts an absence of trust as the root cause to many problems organizations face:



With an absence of trust, people avoid going into conflicts. They don't take part in difficult discussions and decisions, as they are afraid of raising their voice. As a result, people who didn't actively take part in the decision process won't commit on the agreed goals. You will often hear phrases like: "They decided...", rather than "We decided..." as an indication of the lack of active participation in the decision process. And for sure people avoid any accountability for things they aren't committed to ("It was their decision..."). In the end, people don't care about the organization's
performance as they neither were involved in its decision nor in the actions that resulted from that.

Organizations that work without trust, essentially burn money. They hire smart people, pay them high wages but are not able to leverage the full potential of their complete workforce.

“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” - Steve Jobs

 

Speeding up organizations by leveraging trust

There is another reason, why organizations that don't foster trust, burn money.

In my example above, I described a team that fully automated their CI/CD pipeline, enabling them to do deployments super-easy and super-fast. Unfortunately, due to their organization's culture they are not allowed to make any changes to their productive system without satisfying some kind of control process, which completely vanishes the improvements in speed and simplification that the high degree of automation brought them.

Such control processes often come in a combination of two flavors:

• Filling out forms/excel sheets/papers/... putting in information, which is in another -often more technical- format, already available. Making that information redundant and soon out-of-date as it is derived from a fast and often automated process


• Decision workflows that neither add value to the product nor to the customer. Often, higher-payed persons are involved in these workflows, where the primary reason for involving these persons is of informative type.

Trying to automate the formal procedures from flavor one, is often seen as a mitigation to the problem. However, this requires time and resources while it's often bound to high maintenance costs, keeping the forms and processes in sync.

The second flavor given above, can only be adressed with by simplifying or discarding the decision workflow, making information flow easier and faster.
Making decisions faster is one of the fundamental reasons why organizations should foster trust.

Stephen M. R. Covey's book "The SPEED of TRUST: The One Thing That Changes Everything"
gives great insights and examples on how trust accelerates decision making.

New technologies accelerate our daily businesses. Organizations must be able to perform faster to leverage the possibilities those new technologies offer, or these organizations will become obsolete.

Courtesy of John Cutler (@johncutlefish)

 

What is trust?

Before we look into the details on how trust can be fostered in an organization, we first need to understand what trust is.

One of the best definitions of trust, that I subscribe to, comes from Dr. Duane C. Tway, Jr.:

"[Trust is] ...the state of readiness for unguarded interaction with someone or something" - Dr. Duane C. Tway, Jr, "A Construct of Trust", 1993

According to Dr. Tway, trust is constructed from three elements:

• The capacity for trusting
  Remember the first time you entered a plane? Chances are high that you felt a bit nervous and you were not quite sure whether you should have trust in a safe travel.
  You could say your trust account on aviation was 0 and it needed to be loaded first.
  Every successful flight you take, pays in to your aviation trust account, so that you gain more and more trust in flying.


• The perception of competence
  However even if all your past experiences in flying were positive, you might still not feel trust when you enter a plane, as you also need to perceive competence.
  If you think the plane's crew is not able to fly the plane, you won't have trust in a safe travel, no matter how many times before everything went well.


• The perception of intentions
  If all your past experiences of flying were positive and you perceive the plane's crew as competent flying a plane, you might still not trust the crew if you have doubts on their good intentions.

Having trust defined, we'll now see how trust could be cultivated in an organization.

 

How to foster trust?

Based on my observations from various occasions, I think the following three elements can help fostering trust in an organization.

Team size

The size of a team or organization plays an important role, as good and effective communication is important to gain trust.

In his 1975 bestselling book "The Mythical Man-Month" Fred P. Brooks Jr. describes general problems in software project planning. One key element of his observations is often quoted as:

"Adding manpower to a late software project makes it later." - Fred P. Brooks Jr.

What seems mythical, but so well known to people in the software industry, is the result of ineffective and bad communication, according to Brooks. The more people need to communicate, on e.g. one software component, the more time the communication will take, making it likewise less effective.

Intercommunication Formula:

n(n-1)/2

 

The question, is what is a good max. size of a team or organization so it's communication is still effective and trustful?

Robin Dunbar, an anthropologist and evolutionary psychologist can help us out. Dunbar studied social groups and recognized patterns among the sizes of those groups:

• Villages of stone age man accommodated about 150 persons living in one village


• The smallest tactical unit of the roman army was the "maniple", literally meaning "a handful", which had a max. size of 150.


• The hutterites - a religious group living in so called "Bruderhof" Communities in northern America - split their communities once they constantly exceed 150 persons.


• The company that produces the waterproof, breathable membrane Gore Tex splits their organization at the size of about 150 employees, to prevent bureaucracy and hierarchies.


• ...

This finding became famous as "Dunbar's number":

"[Dunbar's number]...is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships” - Wikipedia

But Dunbar's studies even showed clusters of group sizes:



According to Dunbar, the average person has

• 5 intimate friends


• 15 trusted friends


• 35 close friends


• 150 casual friends

Interesting here is the 15 trusted friends, as we're seeking for an ideal size of trustful groups. An optimal team size should not vastly exceed 15 persons, which is pretty in-line with the common practice to create teams of ten or two pizza teams.

"If you can’t feed a team with two pizzas, it’s too large" - Jeff Bezos, Amazon

Important here is to understand the implications that a large team or a large organization has. It does not mean that you need to cut each organization down to 150 employees and each team down to 15 persons to be successful. Simply knowing the above-named effects on team communication and team trust helps to create trustful organizations.

Diversity

Collocation is an important trust enabler for teams. Every human is a social being and people seek personal interaction with one another. If you ever had an evening beer with your team mates you know what I'm talking about.

Putting team mates miles and miles apart does not only block this pursuit for social interaction, it also fosters group separation.

Henri Tajfel, a social psychologist, worked on theories on social groups. How is a social group created? How and why do people feel involved in groups?
One of his findings became known as the minimal group paradigm.

„...simple categorization into groups seems to be sufficient reason for people to dispense valued rewards in ways that favor in-group members over those who are 'different'" - Henri Tajfel, Social Identity and Intergroup Behavior, 1974

Tajfels experiments, which have been repeated over and over again, revealed that meaningless distinctions between groups, such as preferences for certain paintings or the color of their shirts can trigger a tendency to favor one's own group at the expense of others.
If you create two random groups on arbitrary meaningless criteria and you give each person the chance to distribute rewards across all people so that either

a) they give everone in their group and the other group 100€

or

b) they could distribute 60€ to everyone in their own group, while everone in the other group gets only 40€

The vast majority of people will choose option b), which favours the own group even if that means their own group get less overall.



 

Imagine what happens if you put a team or organization which must work together miles and miles apart. Not only the communication will be distracted and the social interaction is blocked, but also you foster a separation of the people as they start creating their own social groups, which excludes "the others" (the people in "the other location"). It's the source of all "They vs. Us" conflicts in separated teams.

One solution for this, is creating collocated teams, consisting of people that must work together. Avoid any segregation of duties across locations. Each team or organization in one location should work autonomous, and should be empowered to make its own decision. Empowered teams are often diverse and heterogeneous, as you need the skills of everyone to fully make use of the team's potential. Basically, every successful team is heterogeneous. Think a second about successful teams!

Whatever team came to your mind, it was a heterogeneous team, whether it came from sports, entertainment, super hero comics, ...

Psychological safety

People must feel psychological safety to establish trust. If they are afraid of any kind of punishment from another person, it'll be hard for them to create any trustful relationship.

People must experience that it's ok to fail and that failure is part of any learning process. To succeed it's necessary to make failures from which one can learn.



Creating a learning environment, is a key skill for team and/or organization leaders.

Thomas J. Watson was the first CEO of IBM, and in the early years, the company was involved in a 10 million dollar business opportunity, which was one of the largest potential deals for them at that time. They assigned a new hired sales representative on that opportunity, and on one of his first days, he ruined the opportunity, so the potential deal was all gone.
On the next day the new hired sales rep. was ordered into Watson's office, to report on the lost deal. As the sales rep. entered Watson's office, he had everything prepared for his termination, but surprisingly Watson's reply on that was: “You are certainly not leaving after we just gave you a $10 million education.”

Leaders can create an environment of psychological safety better than most other people in an organization.
How important psychological safety is, was also shown 2012 in a Google team research project ("Project Aristotle"). Aim of the research was to find out why some teams at Google stumbled while others soared. After investigating all kinds of team parameters, the researchers accidently found out that psychological safety was more critical than any other parameter to make teams successful.

The research also revealed that psychological safety can be fostered by showing personal vulnerability. The more vulnerable a person appears to another, the more likely the other person will feel psychological safety. Tell people that you struggle, that you need help, that you don't know. Statements like these help to create trustful relations in your team or organization.

Summary

DevOps transformations require cultural awareness and an organization based on trust. The above given motivations, as well as the proposals on how to foster trust will hopefully help you in your DevOps journey.

If you're further interested in the above given topic, please see my Keynote from DevOpsDays Kiel 2018, on exactly this topic.

 

About the author

Dirk is a DevOps evangelist and Continuous Delivery expert at SAP.

Since 2001 Dirk worked in various roles at SAP including Development and Operations.
Together with his former team "TwoGo by SAP" he established the first Continuous Delivery implementation at SAP, delivering value daily to their customers.

In his current role, Dirk is a Cloud Quality Coach at SAP with focus on Continuous Delivery and DevOps practices.

Dirk is a frequent speaker at international conferences on DevOps and Continuous Delivery.

Contact:
Twitter: @doergn
LinkedIn: https://www.linkedin.com/in/dirk-lehmann-7712bb125/

 

We have taken all measures possible to make this post as accurate as possible but things sometimes fall through the cracks. In case you find any errors or inconsistencies please let us know.