Does Your Team Have Problems with Trust?

[Part 2 of a three-part series.]

In my last post, I discussed the importance of trust in software development. So if a lack of trust is causing problems on a team, how can you establish that trust?

Before answering that question, let's back up: How do you even know that lack of trust is causing problems?

One way to identify trust issues is to look for the underlying fears that produce them. Kent Beck and Martin Fowler once wrote: "Unacknowledged fear is the source of all software project failures. If these fears are not put on the table and dealt with, then developers and customers each try to protect themselves by building walls. They refuse to share critical information."¹

Building walls and refusing to share information are behaviors indicating mistrust. Being afraid of what someone else might do is practically synonymous with lacking trust.

Common fears by project sponsors show a lack of trust in the development team. For example:

• "The developers are going to slack off."
• "The team will deliver software that won't work."
• "The project will run over budget and behind schedule."

Developers often have their own fears revealing a lack of trust in the business:

• "The sales guys will force impossible deadlines on us."
• "We'll be asked to cut corners in order to deliver on time."
• "If we work hard, they'll only add more to our workload."

What is your tech team afraid the business might demand? What are the product owners afraid developers will do? If fear of others is a significant motivating factor on your teams, you'll see a corresponding lack of trust.

Another common sign of mistrust is imputing malign hidden motives to others on the team. For example:

• "He never listens to us because he just wants to hear things that stroke his ego."
• "She spends way too much time refactoring. She's just trying to pad her hours to increase her billing."

It is understandable to want to understand why someone else would behave in an annoying or counterproductive way. But imputing hidden motives goes beyond that: It means not trusting the other person to give an honest answer when asked about their motives.

If you believe that mistrust is playing a role in your team dynamic, find out if others agree with what you're seeing before setting out to build trust. Are you correct that you've identified a trust issue, or is there some other explanation for what's going on? Do those you see as lacking trust agree that that they mistrust others? Do the ones who aren't trusted agree that the first group doesn't trust them? People don't always acknowledge their fears or mistrust, but if they do, you have something you can work with.

If others don't acknowledge a problem that you're convinced exists, you have something to address before you can work on building trust. There is no blanket answer that covers how to address these cases. One thing to consider, however, is the possibility that you may be part of the problem: Maybe the people involved don't wish to acknowledge the problem to you because they mistrust you. You may need to see if you can find someone else people trust who can start things moving in a positive direction.

In my last post I promised that the topic of this article would be how to re-establish trust on a team where it has eroded. What I've just discussed is Step 1: Have the team identify and acknowledge the ways in which lack of trust is undermining their work. I'll discuss a few more ideas in my next post.