Trust is an Essential Component of a Successful Development Team

Published: 2021-01-11

“Trust” sounds like a pretty touchy-feely subject, but without it teams and their members can’t reach their potential. If you wan’t to get more out of your development team don’t just look at improved ticketing and defining product owner roles. You need to do the hard work of building a high-trust environment.

What is a culture of trust?

Simply put, a culture of trust is an environment where employees and management feel comfortable being honest with each other. Employees in this environment don’t “call in sick” to get a mental health day, they tell their boss they’re feeling stressed and need a day to recover. They tell their team lead that the deadline they set is unrealistic. They talk to their teammates about a bug they committed. They let their manager know they’re overloaded with work.

It’s easy to be honest about the positive things, like the great feedback your users gave you. It’s a lot harder to be honest about the bad stuff, like the code you pushed that caused an outage.

Workers in a culture of trust are able to be honest about the hard stuff because they know that their colleagues, and especially their manager, will react with empathy. This empathetic response allows a team to work together to solve problems.

Why trust is important

A culture of trust leads to happier and more productive employees.

People are happier because they don’t have to feel guarded at work. They can be honest with their boss and colleagues about any troubles they’re having, relying on them as a support network. This results in tighter social bonds within the group. People have a much higher opinion of their job if they enjoy the people they work with.

People are more productive because they are happier. People who like their job are going to be more productive.

But even more directly, people are more productive when they are in a culture of trust because it allows them highlight mistakes made by themselves and others. If a team knows that bugs reported in their code are going to hurt their chances of a raise or promotion, then you are going to get a team that reports remarkably few bugs. Sharing your mistakes with others is how engineering teams grow, but that learning is lost when engineers are fearful of sharing their failures.

A lack of trust doesn’t just mean a team loses out on these moments of learning from failure. It also means that management fails to get critical feedback from the experts it pays to do just that. When a product owner comes to a developer with an amazing new feature that they want developed the product owner needs honest feedback to be successful. An honest developer may say that the timeline is too optimistic, or that it’s doubtful it could be implemented at all. But without a culture of trust, the developer is fearful of critiquing others and so the product owner only hears positive things about an initiative doomed to failure.

Why establishing trust can be so hard

Trust is hard earned and easily lost. A culture of trust is not just something you can declare in a mission statement and consider it done. It needs to be proven through action.

There will come moments where colleagues will be vulnerable: asking for feedback, providing negative feedback, or admitting mistakes. Every time that happens the entire team must respond with empathy.

If people open up about a mistake they made and get chewed out for it, then there’s a good chance that employee will never be open about their mistakes again. But if every time a team member opens up they receive compassion and constructive advice, they will continue to open up. Trust is built on each one of those moments.

How to develop trust

An environment of trust is won by team members being vulnerable, and others responding positively to that vulnerability. If these moments of vulnerability aren’t happening with your team, then you may have to take the lead and hope others reciprocate. There is no shortcut.

Moments of vulnerability don’t have to be some grand revelation about your inner child. They can be as simple as describing a bug in your code that you almost didn’t catch. Or explaining about how you misunderstood a requirement on a recent project. Signaling that it is ok to talk about failures will allow the team to open up to each other.

Responses to these moments of vulnerability must be genuinely empathetic. Managers must understand that mistakes happen and a developer coming forward with a mistake is a benefit for the team, not a point of concern about a developer.

As mentioned above, the entire team must respond empathetically to their teammates. If a team member is being demeaning or rude in response to another team member’s moment of vulnerability the manager must make it clear that the behavior will not be tolerated. A developer that writes excellent code but can’t respond with empathy to their teammates is a drag on the whole team, no matter how individually productive they are.

Conclusion

Trust enables honest feedback, improved learning, continual improvement, and identification of problems. If you want to unlock these features on your team, then you must develop a culture of trust.