Hi,
Welcome to Remotely Inclined, a newsletter about running a business remotely. If you’d like to sign up, you can do so here. Want to share your feedback? Respond to this email (or send me one) Or just read on…
First: My book is live in paperback! If you know any freelancers (or are one yourself), I hope you enjoy it.
Today: We’re talking remote salaries, documentation, and more with remote work consultant Rhys Black.
Rhys Black started his career managing remote teams before starting his own multi-national, all-remote company helping government trade agencies connect with entrepreneurs. Now, he runs Delocate, a consultancy based in London, UK, that helps companies plan their remote work strategies.
In this interview, Rhys shared his insights on how remote companies can better use documentation to encourage autonomy in employees. From there, he sounded off on what he thinks the remote salary debate is really going to be about.
Remote leader to remote entrepreneur
→ Rhys started his career leading remote product teams, engaging with developers, marketers, and designers all around the world.
→ His first foray into entrepreneurship was a company called Trade Nations, which helped government trade promotion agencies connect with entrepreneurs and level-up their marketing. He built a distributed team across Europe and Latin America.
→ His friends started asking him for advice on how they could run their remote teams more efficiently. Soon, he had too much demand on his time. He moved on from Trade Nations to found Delocate, his consultancy focused exclusively on helping companies set up the backend processes and culture frameworks to make remote work successful.
Asynchronous is king
→ When working remotely, particularly with team members in multiple time zones, Rhys advocates for becoming as asynchronous as possible (asynchronous basically meaning that you don’t expect an immediate response to a message).
→ Asynchronous communication starts with documentation. When companies build “lean documentation” - treating any internal document like a product intended to solve a problem (or answer a question), you can train people to build a muscle memory that they should always check the documentation and do some of their own research first before asking another team member for help.
→ From there, leaders have to encourage and promote a culture of non-immediacy. This means reminding people who are always jumping from question to question that they should be focused on their own deep work and to let people’s questions sit for a bit. Part of this, of course, is having nomenclature or a tag for truly urgent issues, since sometimes you really do need an answer right away.
Tools mentioned in this episode
The final word
“I think that it [salaries] become a bit of a land grab by some of these larger tech companies. They are happy to continue to pay San Francisco salaries. So they’ll do it to suck up the best talent around the world in the short and medium term.”
Remotely Inclined Chats with Rhys Black
Transcript edited for brevity and clarity.
Stefan: Welcome, Rhys! Tell me more about your work with Delocate
Rhys: Yeah. My background is in the tech industry, predominantly in London, UK, and a bit in the US, as a program manager. I was managing teams of developers, designers, testers, and marketers. Those teams were usually some form of remote. Not necessarily fully distributed, but a mix.
Then I started my own company previous to Delocate called Trade Nations, which was a fully distributed company with employees in Europe and Latin America. We were working with governments, specifically trade promotion agencies.
Delocate kind of spun out of Trade Nations. I started helping some friends who had businesses and were running remote teams. They were having a lot of similar challenges, and I’d made all of the mistakes already. So it was telling them what to do and what not to do. It evolved from there.
What were the top three challenges you noticed on remote teams?
The first thing would probably be the basics of collaborating and communicating together. Especially when time zones are involved.
One of the things we work on with clients is helping teams become as asynchronous as possible. That’s a big part of it when time zones are significant - you can’t be waiting on someone for 10 hours. So the first thing is to create an environment where people can answer their own questions and get to work.
The other thing is creating an environment that is as distraction free as possible. When you’re working synchronously, it’s easy for teams to end up answering everybody else’s questions more than focusing on their own work.
How can a founder or team leader create distraction-free environments?
One of the most important things is to create a culture where hyper-responsiveness is not tolerated. If people see it happening, it should be cracked down on pretty quickly. If you don’t breed that culture in a remote company, it can wreak havoc. You need to be pretty staunch on that and make sure your team realizes that we don’t expect you to respond immediately.
We don’t want you to respond immediately because we want to create a work environment that allows you to get into flow. It’s a much more enjoyable experience as an employee to be more productive and focused as opposed to pinging you left, right, and center every couple of hours.
Does that mean leaders should punish people for responding quickly?
No I don’t mean cracking the whip on people, but I mean being proactive in creating that culture. A lot of the time culture is just left up to chance. It’s about being proactive so people know it’s very clear. Then it’s a case of nudging a little bit and creating habit formation. Eventually, it becomes second nature and the team starts to moderate everybody else.
Should leaders remind people they don’t have to respond to everything immediately?
Yeah. I did that in my own company. I regularly had team members that I could see they were messaging too much in the evenings and things like that. I’d tell them that I was not expecting a reply that moment. It’s just about setting the expectation.
Can over-documentation reduce creativity?
Documentation has a pretty bad rap. It’s thought of as this thing that gets written and then never really used. That certainly shouldn’t be the case in a remote company.
In my eyes, documentation has been created wrong - or suboptimally - for quite a long time. There’s a balance between documentation and spontaneity. In a young company, you don’t want to kill the best thing a company has which is agility and being flexible.
I approach documentation like any product, since documents are the productization of knowledge. You can create a document in a very lean way - it doesn’t need to be a 10-page thing on a particular topic on day one.
What I usually tell clients is to link all these individual pieces of information in Notion. Add a blurb or context about what it’s for, and then let that be the seed of the documentation. If it starts to get traffic and traction, then maybe it’s worthwhile to take that information and consolidate it a bit.
But documentation is useless if you don’t use it. You have to build that muscle memory where instead of pinging someone on Slack, first look in the documentation. Then comes the balance point: if you’re looking for 20 minutes, maybe it’s time to call it quits and message someone you know has the answer. So it shouldn’t get in the way of asking questions.
What’s your opinion on setting remote salaries - should it be done by location?
It’s an interesting topic. How do you price Thailand in a global market, for instance? It’s not something I typically advise our clients on, since there are some good salary calculators out there.
I think that it will become a bit of a land grab by some of these larger tech companies. They are happy to continue to pay San Francisco salaries, since pretty much anywhere else in the world is cheaper than San Francisco. So they’ll do it to suck up the best talent around the world in the short and medium term.
Amazing, thank you for your insights!
You can get in touch with Rhys via email.
Share this post