How to build a trust with a remote team you don’t see every day?

Trust is the underpinning of almost any human relationship, personal or professional. It’s hard to run deep with someone -- develop their career, marry them, etc. -- if trust is lacking.

One of the biggest concerns people tend to have with outsourcing a function, especially a function as crucial as software development, is “How do I know I can trust the team I’m giving this work to? How can I trust them if I don’t see them every day in my HQ offices?”

Overall, trust is a complicated picture professionally. Global trust of colleagues in the workplace is only at 46%, and only 37% globally report their chief executive as trustworthy. Other research, from MIT, has shown that only 67% of senior managers in a company can name the priorities of their CEO (oftentimes they report to this person directly), and many view this priority disconnect as trust-eroding.

What is trust-building, then?

A good place to start is the research of Paul Zak, who focuses often on the neuroscience of trust. Some of his work is summarized in a recent article on the science of trust in the workplace, and this part applies broadly:

The best precursor to communication is to give people autonomy over their work. It sounds counterintuitive, but it shows employees that their managers trust them, and this sign of trust in the workplace also helps to keep people happy at work.

While that quote is specifically about employee retention in an organizational context, the idea of autonomy is important to trust-building.

Think about a relationship with a female. It could be seen as cool to order for her, control her calendar, etc. -- in the 1950s. Modern women typically do not want these things; they want emotional and physical connection, but also a degree of autonomy around their life, their career, their girlfriends, and more. Providing that autonomy will greatly increase the trust they feel in the relationship.

OK, so how does the whole deal with trust work professionally?

It works professionally, both ways -- if you’re going to bring on an outsourced team, show them trust in the beginning by allowing them room to operate. You did research on this team that you hired. You made a decision. Now see if they can take a project and run with it without much supervision. Let them be autonomous instead of instantly micromanaging the hell out of them. Build trust this way.

If they start messing up, yes, you talk. There is accountability. But in the beginning, let them work on the projects and guidelines you had discussed. See how the deliverables start to come together. Communicate often, but not in an overbearing way.

When someone trusts you and is comfortable with you, now you’ve built rapport. Rapport is usually the immediate precursor to business deals or a number of other life victories. The whole ecosystem fits together: you need to be likeable, have some form of influence or authority, but also foster emotional connections and trust. When you’re firing on all these cylinders, your path to success is clear.

Other tools for building trust with an outsourced team:

• Communicate: Consistently. Explain what you need, what you expect to see, and your processes.
• Have social events with them around the kickoff of a project: Happy hour or other ideas can help with bonding.
• Celebrate the wins: When they hit a big release, celebrate that, be it with days off or compensation or something of your choosing. Show them they are valued and truly members of the team.
• Work through issues transparently: Issues arise on any software project. Don’t be the bellowing boss in the corner or on Skype. Work through the issue openly and transparently. What happened? How can we fix? How can we prevent it from happening again?
• Be fair in your contracting: No “surprises” at the 11th hour in how the outsourced team will be compensated or evaluated. Keep everything on the level.
• Avoid shiny object syndrome: Don’t change the scope of the software project until the first sprints are completed. Changing the focus of the project mid-stream just ends up with both sides (company and dev team) frustrated and not trusting the other.

Now download our Guide - How to successfully manage a distributed software development team: