Switching to Asynchronous Remote Work: Challenges and Best Practices

Someone recently mentioned to me that they've gone back to the office for two days each week, and it gave them a huge productivity boost — "we get so much done in those two days — stuff that we can't otherwise get done in a month".

Remote work doesn't suck. Attempts to shove in-office meeting HiPPO culture into a remote medium sucks.

People seem to confuse asynchronous trust-driven remote work and office culture inspired remote work. Remote makes many things so much easier, but some things become very challenging. Meeting time becomes an expensive luxury.

So if to get anything done you need a synchronous meeting with several people to discuss a thing, and then another meeting to make a decision, and then yet another meeting to tell other teams about that decision — you're royally screwed. Everyone on your team will be burned out and exhausted after several months of that clown fiesta.

That's why teams who figured it out stress that communicating in writing with extreme clarity is so important. You do that thing called actually reading and writing. A document about why you need a decision and what you're leaning to, inviting others to collaborate. A Slack message (on a public channel, please). An email, if you feel like a fossil today. Bonus points for including a diagram or a Loom video.

That mode of work requires everyone to trust each other and treat each other like adults. It requires people to be engaged, have the same goal, and be excellent in their communication. Hence, it is difficult to switch to — and I get why larger companies who had to go remote 3 years ago are now going hybrid. All their previous lives they've trained their teams and leaders to work in a certain way, rally their teams around the whiteboard.

Embracing asynchronous work

When leaders (and all teammates, really) start working remotely, a few things are usually new to them. They would try and do things just like they used to in the office, replacing a meeting room with a Zoom window. But it doesn't work well. That approach doesn't play to the strengths of the remote environment.

If you like snowboarding and surfing, you wouldn't try and surf wearing your full winter snowboard gear, right? The same applies to async remote work.

Here's the list of things that I highlight to people that I mentor, and how I explain the pros, cons, and reasoning behind each of them.

Communicating with radical transparency

Whether you're making a decision, or just asking where in your codebase a certain feature is, please, try to have all work project-related conversations in the open channels with clear naming, instead of direct messages.

Here's why:

• You're not the only person with that question or decision, I promise. Others will try to look for that information soon. They'll try and search for it, and they will have to ask the same question in DMs it wasn't shared publicly in the first place.
• If you have multiple DM conversations about the same thing, you can easily get into a situation where people will have dangerously different and conflicting ideas of what you actually decided to do.
• When people have work conversations in the open channels, it feels like everyone is engaged.
• It's faster. Async work treats Slack like email. If you DM an engineer who is in deep flow, you won't get an answer quickly. But someone on the channel might know.

Here's how to coach people to talk in the open:

• By example. Do your part — instead of DMs, work in the open. Loop people into conversations — tag and mention people who you know will need this information.
• When someone asks you a question — it's absolutely necessary to post your answer into the open channel, and comment that "Hey folks, @xyz asked about this, and here's what I think. Am I missing anything? Does it look correct to you?". In DMs, politely explain why you prefer to answer this way, and ask that the person posts their questions in the channel and mentions you, instead of a DM next time.

  You will have to do this many times with many people on your team. Some people get comformtable posting in the open quickly, but others might take several nudges to change their ways.

Making and documenting decisions

In the office, you can just sit down with the team that you need and make the decision in a meeting quickly. Working remotely, you can still run a meeting (and it has its own pros and cons), or you can drive to a decision asynchronously.

Working asynchronously requires you to communicate in writing instead of video and voice meeting, and that has tremendous advantages!

• You can easily review and untangle the logic of why a certain decision was made if it's in a document with threaded comments.
• Everyone on the team will learn to communicate clearly, and structure their thoughts, if they have to write them down.
• You have time for a thorough review and debate. Not everyone is comfortable raising their hand and speaking up in a meeting. Some folks need calm time to review, think, and write their questions and ideas down. Asynchronous discussion makes it easier for them to open up, and contribute.
• You get better documentation. Some people like reviewing information by reading text. Others prefer videos or diagrams. Maybe there are folks who actually love voice messages, but I have yet to find them. And so, people learn to record video summaries (thanks, Loom!), use diagrams (GitHub Flavored Markdown renders Mermaid btw), or work in Miro.

But, async decisions may feel slow. Some decisions are straightforward, and you expect that most or all people on the team will agree with them. Some decisions so small that an RFC-style document is an overkill. Some decisions feel so urgent that it feels like there's no time to have a discussion.

How to help your team get better at async, documented decision-making (ugh, that's a separate post worth of stuff):

• By example. Write notes where you outline the problem you need to solve, the ideal successful state, a couple of possible approaches, and the approach that you plan to take.

  • Set the timeline: communicate how much time folks have to contribute.
  • Set the expectation of who should contribute. If you expect certain people to comment, approve, or add suggestions — ask them specifically.
  • Set the expectation about following through on the decision. Who is going to drive the discussion forward? Are you delegating it to someone, or will you return and wrap it up?

• Help others write their proposals, notes, and documents. Especially true if you support software engineers. Help them learn how to communicate their work better, and they will push your whole organization forward.

• Help others make their voices heard. Remote is great at surfacing who is very engaged, and who seems to be shy and just get their own work done. Check-in on them, and make sure you support people who have a lot to contribute, but who shy away from it.

  Set a clear expectation that participating in discussions is a big and important part of their work, and it's okay to spend time on it. Maybe they're drowning in work on their projects (your job to help them, btw), or perhaps they didn't get the memo (your job to help them, btw), or they don't have anything to contribute (unlikely, but your job to help them level up, or level out, btw).

• Normalize prototyping and discarding work if the decision changed. When a decision is urgent, you can ask the team to start working in a direction before it was confirmed. Normalize that style of work — that will help you remove the perceived slowness of remote. Show the team that you know there's a trade-off, and that you deliberately ask them to start working, knowing we might end up discarding some of their early work if we choose to go in a different approach.

Links

• Remote team health check.