Building trust in a software team is a waste of time. Here’s what you should do instead

Let’s start with the basics. There’s a wrong assumption that trust has to be built over time, or that you have to prove yourself to “work for it”. What if, instead of spending time, money and energy in the early trust-building phase, you could start your new project with a team that fully trusts one another, admits when they make mistakes and is brave enough to speak up when needed?

Wouldn’t it be great, if instead of awkward trust-building activities, you could focus solely on fast delivery of high-value products with your software outsourcing team right from the very beginning?

Thinking how to build trust in a team? Stop and change tactics!

It’s important to understand that trust doesn’t result from the number of team exercises you conduct but rather from the team culture you create. And creating a trust culture is more important and easier than you might think. All you need to do is to give trust to your teammates right from day one as if you worked with them for years, and instead of trust-building, you should focus on trust maintenance.

We usually assume that trust should be slowly built over time and the transition from regime and micromanagement to growing freedom is slow. I suggest you reverse the order.

Start with full confidence and a lot of freedom for your team of software developers. Now one might think: “Wait! I don’t know them, what if something goes wrong”.

I hear you, and there’s a method for that. If there’s a big problem, someone uses your goodwill in a non-cool way, then it’s time to introduce restrictions and stricter control.

It’s not only about saying to your team that you trust them but also expressing it. If you sincerely show your team your trust, they’ll repay with their own. To give you a full picture, here are a few examples of how I try to show my team trust. I tried and tested my methods over the years, so I can assure you – they totally work. 

Micromanagement doesn’t build (trust in) a team

In TSH we have flextime and flexplace work culture, however, there’s a rule of thumb that you should consult each case with your project manager first. Honestly, as long as developers deliver what needs to be delivered and fill their monthly quotas, why should I ever worry where, when and how long they work?

They know best when and where they are the most efficient and as long as it’s transparent for everyone, there’s no value in micromanaging people’s work habits. I trust their guts.

Be humane

Developing an IT project always involves some risk. There might be a situation when someone can’t meet obligations they agreed on. While it is important to talk it through and draw appropriate conclusions, there’s rarely a need to show disapproval or look for punishments.

We trust each other that we all strive to deliver our best but we’re also humans that sometimes fail. And if something doesn’t go as expected, we shouldn’t assume ulterior motives straight away.

It’s more important to look for improvements than to play a blame game.

Make cookies not excuses

There was a situation when one of my developers simply didn’t show up to the meeting. We’ve decided to reschedule and texted the MIA person that when they come back, they need to bring some cookies for everybody, no further investigation. And guess what – a similar situation has never happened in that team again.

I know that your instincts might kick in and the first thought would be to demand a detailed explanation. But assuming it doesn’t happen regularly, does it really change anything?

The team will benefit more from “even though we were surprised by your absence, we trust you and assume that something unexpected has happened, let’s just make sure we avoid it in the future” message, instead of “hey, explain yourself!”.

Of course, if the meeting was exceptionally important, I wouldn’t approach the situation as lightly. I never had to, though – nothing of sorts has ever happened to me.

It’s just another confirmation that by trusting your software development team straight away and not treating them like babies, the crucial and important things are always taken care of with the utmost respect and the highest priority by everyone involved. 

Trust also means being vulnerable

The ability to say “I need help”, “I don’t know how to do it” or “I’ve made a mistake and I need your support” is extremely important. The best way to maintain this type of trust is by just being vulnerable yourself.

Speak openly about your weaknesses, failures, and shortcomings, never hide it.

When your team sees you are open with your vulnerabilities, they will instinctively be more open with their own. A team that is not afraid to talk about their imperfections can reach the highest levels of performance. Some might now think of a saying that “a strong leader should never let others see them sweat”.

I’ll tell you a secret – your team sees you sweat way before you do. So you can play pretend to hide it away, but you’ll fail.  

So how do you achieve mutual trust in your software team?

The answer is simple, only by fostering a culture where trust is a foundation and not something that is built over time, or worse – “deserved”.

Does this mean you shouldn’t work on expanding trust within the team altogether? No, but instead of spending time pulling ropes or playing “backward falls”, use it to get to know your team better on a personal level.

Learn about their dreams, problems, hobbies, passions and try to build stronger bonds with them – you’ll get better feedback from casual conversations than from most trust-building activities, which btw. are mostly cringy and people bond over criticising them. So by following my advice you basically skip the cringy part.

Of course, you still have to keep the balance. You can’t blindly overlook every single misdemeanour – this is not what trust is about. Also, sometimes people might try to take advantage of that, so be cautious. However, you’ll be better off assuming the best intentions from the very beginning and then changing your approach, than instantly assuming bad motives.

How to build trust? Don’t.

So next time you start a new project, trust your team and be vulnerable from the very beginning as if you’ve worked together for years.

While you shouldn’t trust blindly in everything, the benefits of starting strong, skipping “trust-building” and going right into high-trust, high-performance mode vastly outweigh potential risks. After all, can you really afford not to trust your teammates?