Foundation of Trust

Trust is one of those things that we don’t discuss a lot in the work environment, but I guarantee it affects you daily. Who do you reach out to when you experience frustration? Who do you have to help you solve a problem? Who are you most likely to admit to making a mistake? How about when you have a big win? It’s probably the people you trust the most. Who don’t you go to in those same situations? The people you trust the least. 
If trust is so important, why don’t we do more to nurture trust at all levels of our organizations? While there is no one answer, I think one significant reason is that trust is hard. Trust requires vulnerability. Trust takes a two-way commitment. Trust must be earned every day. It can be lost in an instant. It is a high-effort, high-reward activity that you may only realize you have after you have had it for a while. There is no certificate for passing the trust test. However, I would argue that the cost of not continually earning trust is far higher in terms of time, work, and emotional toll.

Here are some of the ways we expend unnecessary effort when we don’t have trust:

• Over-scrutinizing information we share to avoid it being used against us.
• Choosing safe, established solutions over potentially new and more efficient ones because the new approach might fail, and we don’t want to be blamed.
• We do precisely what is asked (nothing more or less) even though we know it won’t meet the requestor’s needs, and we will be asked to change it.
• Spending a lot of time hiding our failures or calling out others instead of learning and improving. 
• Viewing the mistakes of others that negatively impact you as intentional.

What would your day look like if you could just stop doing all those things? How much better could you do things? How much less decompression at the end of the day would you need? It would be amazing.

Here are some things I have done to build trust in my teams. 

Celebrate mistake

​You don’t need to buy a cake. While it rarely feels like a celebration, you should keep the conversation as positive as possible. Try phrases like, “Now we know that won’t work. That’s something new we learned.” “Thank you for being bold.” and “I would have thought that would work, too.” 

Group Work 

I usually try to generalize my descriptions, but this is one where I think it applies incredibly well to software development. However, it should resonate anytime individual work streams converge for a single deliverable.

I have vivid memories from my time as a software developer. At times, I was terrified of a technical problem I was tasked with solving alone. I pulled many all-nighters working on those problems. The elation of eventually finding the answer kept me going for a long time, but it came at a high cost.

I had been intrigued by paired or mob programming for years. When I finally got to try it with a team, there was a lot of resistance. Everyone assumed that working individually and in parallel was faster. It turns out that in all but the most routine tasks, individual silos were slower. Why?

• Poor choices were made because the person making them had only their own limited perspective. This led to rework.
• The added time it took to explain and combine work.
• Not realizing someone else already knew how to do something.
• Individuals would become paralyzed and overanalyze what they were being asked to do.
• Fear of admitting that you don’t know something and remaining stuck.

It took a few months to work out how to do it. Although not linear, we went through all of Tuckman's stages of group development again (forming, storming, norming, and performing). See my post on facilitating real change. Once we did figure it out, the impact was significant. Work (code) reviews could hold up the team for days. When everyone was involved in doing the work, they were almost instant. Rework was virtually eliminated. Testing and development ran in parallel. In many cases, we were working up to 75% faster. All those metric improvements are enormous, but trust made the difference.

Everyone realized everyone else had insecurities, too. They stopped trying to hide them and just worked together. Great ideas from quiet team members began to surface much more frequently. There were no more heroes. In time, everyone on the team understood most of everything we were responsible for. Time off and sick days were no issues, as anyone would pick up almost any work. The trust grew to include Product Management and IT operations. Over the course of a couple of years, they grew from a team that found any excuse to avoid trying something new to a team that would commit to the unknown and just work the problem together. 

I recently had a member of that team comment on how much the psychological safety of that team made all the difference in their work life—and I suspect their personal life, too.

Psychological Safety

The main thing that all these activities have in common is fostering a sense of psychological safety. There is a ton of research over the past 50+ years on the positive (and some negative) impacts of a sense of psychological safety. It was a core component of how we chose to work. We used to measure psychological safety, among other things, at the end of every two-week development cycle. It was a simple, anonymous rating on a 10-point scale. We tracked the results from cycle to cycle. Allow people the space to learn and grow. Sometimes, you'll need to push people out of their comfort zones, but I promise that doing the work to earn trust has payoffs in virtually every measure of happiness and success.

Rebuilding trust

Rebuilding trust after it's lost takes time. One phrase I consistently use to remind me of the best approach is “Curious, not furious.” Very rarely is malintent involved when trust is broken. So, taking time to understand the intent of the parties that broke the trust and helping them understand the impact on those for whom the trust was broken is an excellent way to start. In the software world, many teams will do a retrospective at the end of a development cycle. If done well, that retrospective can be a mechanism to continually exercise the impact and intent muscles so that when you do have a larger breach of trust, the activities you need to go through to regain that trust are something that the team is familiar with and has become part of their core identity.

​This recently happened to me when I instructed the team to take a completely different technical approach to the solution. They had spent a lot of time rationalizing an initial approach. I knew some information at the organizational level that made the original approach very risky, but I chose not to share that information with the team at the time. When the time came to measure psychological safety, it became clear something was wrong. The team shared with me the impact of my decision, I shared my intent, and apologized for making a mistake. It was a hard and humbling conversation, but after that point, the team was much more aligned on the alternative approach and why we needed to take it.

Final thoughts

​I put the team in a situation where they had to learn trust to succeed. I had the runway to take the time to ensure it worked. It worked beyond my wildest dreams. To reiterate an earlier point, there was no point where we all got a certificate of trust. We worked on this daily. There were some tough conversations when trust was broken or strained. Many times, it was my direct actions that caused that break or strain. But every single time, we were vulnerable and honest, and we came out stronger.

You can be great without trust. Why would you want to?

<< Facilitating Real Change

Collective Accountability and Quality >>