Over the last six years, working remotely for companies all over the map, I’ve realized one fundamental truth: remote work isn’t just about moving your laptop to your living room. If I had to summarize successful remote communication in one word, it would be: asynchronous.
Just like in open-source projects, we rarely have people working on the exact same task at the exact same time. In my experience, distributed workflows yield much better results than traditional office setups, and as a result, the everyday quality of life is just vastly better for everyone involved.
Async communication through tools like Slack threads or Google Docs eliminates that toxic “you had to be there” aspect of office life. It drastically reduces the administrative overhead needed to capture and move information across different teams.
Company culture is notoriously hard to define, but over the years, I’ve noticed a few unspoken “rules” that make or break remote teams, regardless of your industry or the tools you use:
1. Default to asynchronous communication
Knowledge workers are only productive when they have large blocks of uninterrupted time. A solid two-hour block of deep work is not the same as four 30-minute chunks sandwiched between meetings.
Every time your focus is broken—whether it’s a Slack pop-up, an unavoidable meeting, or a “hey, got a sec?” message—there is a massive context-switching cost to get back into the zone. Think of it as the geek equivalent of having to put on your gym clothes, fill your water bottle, and drive to the gym every single time you want to do just one push-up. It’s exhausting.
2. Reserve high-fidelity channels for what truly matters
Synchronous, high-fidelity tools like Zoom, Teams, or Meet are incredibly valuable when used correctly. The problem is that in many work cultures, live meetings become the default. I’ve seen teams use sync calls just to share updates or, worse, make decisions—two things that are much better handled asynchronously.
What are the latest sales figures? Write an internal blog post. Which architecture design should we choose? Put it in a document where we can debate it in the comments. Save the live video calls for complex, nuanced discussions that actually require real-time human interaction.
3. Be ruthlessly protective against noise
A “quick” email or a comment on a Jira ticket might take you 20 seconds to read. But think about the chain reaction: the notification pops up, the screen loads, the reader has to gain context, and then decide if they need to take action. If 50 people are subscribed to that thread, you just burned 15 minutes of collective company time. Was it worth it?
Think twice before giving unsolicited opinions on topics outside your core expertise, especially if you lack the full context and aren’t willing to roll up your sleeves to do the actual work.
Only comment if you are adding real value to the discussion. Adding a basic ”👍” reply to a thread that already has ten thumbs-up emojis doesn’t move the project forward; it just adds to the noise.
4. Keep discussions logically separated
The beauty of async tools like forum threads (as opposed to messy email chains) is that you can easily branch out when topics diverge.
This keeps conversations strictly focused on one thing at a time. In the teams I’ve worked with, keeping discrete topics in their own separate threads minimizes unnecessary noise and speeds up decision-making. It ensures that only the relevant people are involved, letting everyone else get back to actual work.