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. 

​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.” 

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.

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 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.

​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?

Raise your hand if you have ever been through organizational change training. I have been through at least five during my career, and while they all have something to offer, I have yet to see any of them effect lasting organization-wide change. This process is deeply personal. It involves a level of introspection that can be uncomfortable. It's entirely reasonable to want to avoid discomfort. So, as soon as the focus is off, most of us return to what is comfortable. Organizational shift is possible, but not as an end goal by itself. You must continually enable a culture that embraces change and discomfort.

More on that at the end.

I decided to go to grad school in Communication after I discovered that music education wasn't for me. When I told a class of young elementary students that my name, Mr. Syme, rhymed with slime, it was a clear sign that I might have other strengths to focus on. Communication is an interdisciplinary field of study. It borrows heavily from other academic fields and often focuses on understanding how communication affects behavior. In academic article after academic article, I kept seeing a pattern like this used to describe the stages of behavior change:

​While different studies have more or fewer steps, I took this as the essence of how people progress through change. This view of behavior has framed a significant portion of my professional career.

Understanding almost always comes right after awareness. You can tell you have reached this stage because the person will look at you and ask, "Why?" After you tell them, you are done—mission accomplished. If only it were that easy. What they are asking for is the external why. They are asking, 'Why do you think this is important? They haven't begun to figure out if it is important to them.

Remembering that importance to you, the team, the company, or the planet may not translate to vital to them. This stage's point is to convey why you feel this is important, not necessarily to gain their agreement.

This is the point where they believe you. In a conversation, you may get some head nods or an “Okay, I get it.” Again, it is essential to recognize that understanding something doesn’t mean it holds any relevance. It might, but that’s not something you can assume at this point.
​
Avoid the temptation to think that because you made a PowerPoint or sent an email, the job is done. Each situation will require differing levels of evidence to convince people of acceptance, but until you do, all you are doing is lecturing. It may take several different ways of presenting the need to get acceptance. Resist the urge to say, “Because I said so.”

Finally, if the internal "why" makes sense to them, they will incorporate the new behavior into their lives. Congratulations—mostly. Unfortunately, adoption does not necessarily mean that they like or agree with the behavior. All you can assume is that they understand why they should do it. How many times have you made a change because failure to do so would jeopardize your job? Most behavior modification programs end here. The problem is that there is no reason to continue the behavior once the "internal why" isn't relevant. 
​
The bad news is that if you haven’t laid the proper groundwork, this may be as far as you can get, which is why many programs end here.

​This is the goal. At this point, they have fully internalized the value of the change and believe it holds value for others as well. A significant challenge often preventing advocacy achievement is asking for a change that doesn't benefit them. If you haven't figured it out, top-down directives can't get you here. So, what's a growth mindset advocate to do? It involves trust, accountability, autonomy, and experimentation. More articles are coming, so I won't leave you hanging for too long.

As evidenced by my feature flag stories, this is usually not a linear progression, and rarely are all members of an organization at the same stage simultaneously. Ideally, I would have worked on getting a sense of ownership from the team far earlier in the process. It would have saved me so much work. Remember, I said change is deeply personal. This makes the process complex. The support needed to move to each stage will be different. 

If your goal is advocacy, as I believe it should be, then you will need to find a way to support every individual you are asking to change at every stage you are asking. You need to be aware enough to know if someone skips a stage or backtracks and help guide them appropriately. Fortunately, you don't have to do this alone if you have created a culture that embraces change and discomfort through trust, accountability, autonomy, and experimentation. 

​This takes time.