Six Ways that Team Members Build Trust with Each Other
Six Ways that Team Members Build Trust with Each Other
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
Building trust may seem mysterious—something that just happens or grows through some unknowable process. The good news is there are concrete actions that tend to build trust (and concrete actions that are almost guaranteed to break down trust).
First, let’s agree on a definition of trust in the workplace. We all know that trust is the foundation for teamwork. But to hear some people talk about it, you’d think team members were getting married, not creating software together. What we need in the workplace is professional trust. Professional trust says, “I trust that you are competent to do the work, that you’ll share relevant information, and that you have good intentions towards the team.” Taken broadly, that’s trust about communication, commitment, and competence.
0. Trust Other People
The zeroth step in building trust is to display trust. One way to do that is to make a generous interpretation when someone else makes a mistake or disappoints you in some way. People who always jump to the worst conclusion about others’ competence and motivation inspire wariness, not trust.
Most people don’t set out to be evil or stupid, so give the benefit of the doubt until you have data that proves you wrong.
1. Address Issues Directly
Ruffled feathers come along with close collaboration; it’s bound to happen that one person will rub another the wrong way. Maybe it’s the way your cube mate chews his gum or listens to voice mail on speaker phone. Maybe someone used your laptop and changed all the preferences or broke the build and then left for lunch.
When someone on the team is bugging you, speaking directly to that person builds trust. It says, “I value our working relationship, and I’m willing to have an uncomfortable conversation to make it better.” It says, “You’ll know where you stand with me; I won’t be talking behind your back.”
These conversations aren’t always easy, but the alternatives are worse.
Some people avoid the uncomfortable discussion and let their anger and resentment build until it explodes. That almost always leads to damage that’s more difficult to repair than the original irritation.
Another way people avoid the conversation is to tell their managers about the problem. If you really want to damage trust with coworkers, play tattle tale and complain to the boss. (As with everything, there are exceptions. If the situation involves sexual harassment, an ethical breach, or physical safety, tell your boss).
When people don’t know how to have difficult conversations or think it is someone else’s job to navigate working relationships, trust erodes. And that’s why people need a framework to talk about interpersonal feedback.
2. Share Relevant Information
Knowledge is power, but it’s more powerful when it’s shared. When someone on the team withholds an opinion or concern on a topic and comes back later to say, “I thought it was a bad idea from the start,” other team members feel blindsided. That breaks trust. If you don’t support an idea or approach, say so. (Of course, there are more effective and less effective ways to do this.)
Relevant information is about the task, but it’s also about you. People tend to trust people they know as individuals and can identify with. Shared experience, shared interests, and identification form solid ground that people can land on when there is friction and conflict. You don’t have to share your deepest secrets, but letting other people on the team know something about life outside work makes people “real.” It’s hard to trust a cipher but much easier to trust and be generous with someone who shares some of the same challenges and interests that you do.
3. Follow Through on Commitments, or Give Early Notice When You Can’t
In order for teams to function, team members need to believe that their coworkers are reliable. Without the confidence that others are reliable and will carry their share of the load, few will commit to a shared goal.
No reasonable person expects that every person can meet every commitment all the time. Sometimes a piece of code turns out to be more complex than anticipated, or we discover we didn’t fully understand the task when we made our estimate. But when you wait until the moment the task was due to let people know it’s going to be late, you appear unreliable. So let people know as soon as you know, and renegotiate.
4. Say No When You Mean No
Sometimes you just can’t take on another task or do a favor that someone asks for. Most of us are programmed from an early age to please other people, so we’re afraid of being labeled selfish or “not a team player” if we say no. But if you really can’t do what’s asked, it’s more respectful to say no and let the other person have his need met elsewhere.
Saying yes without follow through leads others to doubt your word. If you can’t say no, your yes won’t mean anything.
5. Share What You Know and What You Don’t Know
Be generous in sharing your knowledge (without inflicting help). But also be willing to hear other people’s ideas, build on them, and help others shine. Admit when you don’t know the answers. There’s nothing worse than a know-it-all who is wrong.
It may seem paradoxical, but building competence trust—i.e., your coworkers’ trust in your capabilities—sometimes means admitting that you don’t have all the answers. Asking for help helps others see you as a real person, and people generally like to be helpful.
Most people enter a new situation with a basic level of trust. That level may be high or low, depending on their outlooks and life experiences. But from there, every interaction is an opportunity to increase or decrease trust. With the techniques I’ve listed above, you are now armed with several ways to build a strong foundation of trust for your team.
Published at DZone with permission of Esther Derby , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.