How do you build trust with someone you have never met in real life? A friend of mine who’s just started to onboard his first remote employees called me recently to ask exactly that.
Video Transcript
A couple of days ago, I got a call from a friend of mine. And he called me up with a question: How do I build trust in a remote environment?
Give full code repository access to a remote worker
So this friend is building his own software startup. He has a few in-office employees here in Switzerland. And he just recently decided to add a freelancer that sits several hundred kilometers away in a foreign country, and they’ve never met in person. And now he was about to give full code repository access to that remote worker. And he has some fears: Now that he’s going to give code access to this remote employee, he’s a bit worried about that employee potentially taking all the code, everything that they’ve worked on so hard for the past year or so. And just take that and run with it and do his own thing.
An issue that is specific to remote
And I thought he was interesting. And I asked back, well, how do you know that’s not gonna happen with someone that’s already with you in the office setup? And I could hear through the phone how he was taken a bit aback. He clearly did not think about the problem in this way. He quickly realized that that’s not an issue that is specific to remote, but something that he will probably have to address with his whole team. Nevertheless, the remote setup and the fact that he had never met this person in real life, even though they had worked together on previous projects for a few months, it kind of elevated his fears, and that’s what led him to make the phone call.
Openly discuss trust and values with the team
So I shared a few ideas with him on how I had approached the topic in the past. Number one, I always openly discussed trust and values with my team. I think trust is something that’s a two-way street. So while I might be worried about my employee, stealing or copying or otherwise carelessly treating a core asset of the company, that might be my fear, but vice versa, that employee also might mistrust me paying him on time, paying him accurately or any other potential issue that might come out of our collaboration.
Address trust and values upfront
So for me personally, it’s always important to address trust and values upfront. For example, with Sendtask, which is a completely distributed team, we always made sure to talk openly about this and ask what your expectations are? What are my expectations? What are some reassurances and measures we can put in place to make sure both parties feel comfortable working with each other? One thing that I’ve learned is that the team has a lot of good ideas. So for me, as far as I took charge of bringing the topic up and creating a place where we could discuss it, a lot of great ideas were shared by the team. And very often, the problem solved itself within less than a day of open discussions and brainstorming.
Your team and the processes you have
Number two learning that I shared with him is that while you might think that as a software startup code is your biggest asset, and you have to protect your codebase at any cost, I personally believe that even far for more important than your codebase is your team and the processes you have in place. Because let’s be honest. In the early days of a startup, I’ve never seen one that developed code in the first two years and still uses it in day three and four. It’s so common to constantly rework things, constantly refactor and reinvent part of our systems, that code becomes outdated very, very quickly. So what’s really important is the team that speaks to the customer, that understands what we’re building towards, that has processes in place to efficiently prioritize features and put them into code. And those things can never be stolen from you if it’s you that’s in control of building the company culture, and you have spent all the time identifying the right employees for your team.
Create reassurances
And then three, while I’m certainly not a fan of big long contracts full of legalese that are hard to understand and create usually more fears than they create reassurances. I am a fan of putting expectations on paper. Why? Well, because it’s hard to avoid misunderstandings in the real world when we sit in the same room and talk to each other every day. So it’s even harder to avoid them in a remote setup where we often deal with less than perfect communication channels. And that’s why I think it’s super important and useful to write down what your expectations are both sides and then sign a paper, even if that paper might not be legally enforceable, I think it still adds a ton of value to have your expectations, black on white, and a paper to go back to and refer to. So those are the learnings that I shared with him. And while this might not cover everything and anything that you will need to create trust, it might be a good start to try these.
Just to summarize, number one, trust is a two-way street. So make sure to discuss it with your team and involve them in how they think you can create an environment that’s safe for everyone. Second, think about what’s really your biggest asset in the company, and very often, you will not be code or some sort of product sketch or documentation, but you will learn that it’s really your team and the processes that you have built. And then third, last but not least, put expectations in writing and make it a symbolic gesture to sign them and give each other the actual paper version so that you have something to go back to and to avoid misunderstandings.
And with that, thanks so much for watching. Have a beautiful day, and stay curious.
