Last year I tracked my calendar for two weeks straight. The result was embarrassing. I was spending roughly 23 hours a week in meetings. That's more than half a standard 40-hour week — just sitting on calls, waiting for people to finish their thoughts, and staring at a grid of faces.
Something had to change.
I started shifting to an async-first way of working, and honestly, it's been one of the best professional decisions I've made. But it's not magic. There's a real learning curve, and if you do it wrong, you just end up with a different kind of chaos — a never-ending flood of Loom videos and voice notes nobody watches.
So let me walk you through what actually works, based on what I've tested myself and what I've seen work for distributed teams that have been doing this for years.
What Async Work Actually Means
Async work just means you're not expected to respond instantly. You do your work, communicate updates, and give feedback — but not in real time. No one's waiting for you to be online at a specific hour.
This is different from just "working remotely." Plenty of remote teams are still running fully synchronous schedules where everyone's on Slack from 9 to 5, expected to reply within minutes. That's remote work, but it's not async.
Companies like GitLab, Automattic (the folks behind WordPress), and Basecamp have built entire operating systems around async communication. GitLab's handbook — which is public and over 2,000 pages — literally documents how they make decisions, run projects, and communicate without requiring everyone to be online at the same time. It's worth reading even if you're not at GitLab.
Why Most Teams Fail at Going Async
The most common mistake I see is treating async as a meeting replacement without changing anything else. You can't just cancel your daily standup and call yourself an async team. The underlying communication structure has to change too.
If your team has no documentation culture, no shared context, and no clear decision-making process, removing meetings just creates confusion. People start pinging each other constantly because they don't know what's happening. You trade Zoom fatigue for Slack anxiety. Neither is good.
The other big failure mode: leaders who say they want async but then reply to messages within 30 seconds at all hours and expect the same from their team. That sets the tone. If the boss is always online and visibly impatient, nobody's going to feel safe actually going async.
The Psychological Piece Nobody Talks About
There's a real anxiety that comes with not being visible. If you're used to a traditional office — or even a synchronous remote job — async can feel like you're disappearing. You wonder if people think you're slacking. You check Slack more often than you should, just to feel present.
I spent way too long figuring this out. The fix isn't better tools. It's building trust through good written communication and consistent output. When people can see what you're working on and that you're delivering, the anxiety fades.
The Tools That Actually Hold an Async Team Together
Let me be specific here because vague tool recommendations are useless. Here's what I've actually used and what I think is worth paying for.
For Written Communication
Notion is where I'd start for documentation. It's $10/month per user on the Plus plan, and the combination of wikis, project databases, and inline comments makes it genuinely good for async teams. The free plan works fine for solo users or small teams just getting started.
Basecamp is $15/user/month and is arguably the most opinionated async tool out there. The company literally wrote a book called Remote about how to work this way. Their Hill Charts feature for tracking project progress is genuinely clever. I don't use it daily anymore but I recommend it a lot for teams that want a single place for everything.
Slack Pro runs about $7.25/seat/month (billed annually). If you're using Slack, the async trick is turning off notifications by default and training your team to write full context in every message — not just "hey" followed by silence.
For Video That Isn't a Meeting
Loom is probably the async tool I recommend most often. Free plan gives you 25 videos capped at 5 minutes. Paid is $15/month per creator. Being able to record your screen and face while explaining something, then share a link — it sounds simple, but it genuinely replaces a lot of meetings. A two-minute Loom walkthrough beats a 30-minute call nine times out of ten.
Zoom Pro is still useful for the meetings that do need to happen ($13.32/month). But in a real async culture, you're using it maybe twice a week max, not five times a day.
For Project Visibility
Linear has become my favorite for engineering and product teams. It's $8/user/month and the speed of the interface is genuinely impressive. Asana (starting at $10.99/user/month) is better for broader teams with less technical work. Both let you see what everyone's working on without needing a status update meeting.
"We treat internal communication like open source code — write it so anyone can understand it without needing to ask you follow-up questions." — Automattic's approach to async documentation, from their public engineering blog
How to Actually Structure Your Async Day
This is the part most guides skip. Having async tools doesn't mean you know how to use your time well. Here's the structure I've landed on after a couple of years of experimenting.
Protect Your Deep Work Window First
Block the first 2-3 hours of your workday for focused work before you open Slack or email. I know that sounds obvious, but almost nobody does it consistently. I use 2 hours of hard focus every morning — phone in another room, notifications off, one task at the top of my to-do list.
Cal Newport calls this "deep work" and I don't love how much that phrase gets thrown around, but the core idea is right. Your most cognitively demanding work should happen when you're freshest, not after you've already burned half your mental energy on other people's requests.
Batch Your Communication
Instead of responding to messages as they come in, pick 2-3 windows per day for communication. Something like 10am, 1pm, and 4pm. Respond to everything that needs a response, then close it back down.
This feels weird at first if you're used to being always-available. But it's actually more respectful of everyone's time once you set the expectation clearly. I put mine in my Slack status: "Checking messages at 10, 1, and 4 CEST."
End Each Day With a Written Update
This is one habit that's made a bigger difference than I expected. Before I close my laptop, I write a short update — three or four sentences — about what I finished, what I'm blocked on, and what I'm starting tomorrow. I post it in a team channel.
It replaces the "checking in" that managers tend to schedule meetings for. When people can see your daily output in writing, they don't feel the need to pull you into a call to find out what's happening.
The Meetings That Should Stay
Here's something I want to be honest about: not everything should be async. Some people in the async community are almost religious about this, and I think they go too far.
There are situations where a real-time conversation is genuinely better.
- Conflict resolution — text is terrible for this. If there's tension between teammates, get on a call.
- Brainstorming sessions — real-time energy and quick back-and-forth can produce ideas faster than a shared doc.
- One-on-ones — relationship building with direct reports or your manager matters and shouldn't be fully async.
- Onboarding new people — new hires need context fast, and async is slower for getting someone up to speed quickly.
The goal isn't zero meetings. It's intentional meetings. Every meeting should have a clear reason it couldn't be a document or a Loom.
What Teams in Different Time Zones Get Right
If you've got teammates spread across multiple continents, async isn't optional — it's survival. And honestly, the teams that do it well have figured out something important: written communication quality matters more than anything else.
When a developer in Lagos and a designer in Berlin and a product manager in Manila are collaborating, they can't afford lazy communication. "Can you look at this?" doesn't cut it when the other person won't see your message for six hours. You have to write messages that contain full context, clear questions, and enough information for the other person to actually act without a follow-up.
This is a skill. And honestly, it makes you better at communication overall — not just in async contexts.
The "One Overlap Hour" Rule
A few distributed teams I've talked to use a rule where all teammates are expected to be available for just one shared hour per day. Everything urgent goes into that window. Everything else is async.
It's a clean, practical compromise. You get the benefits of async for most of the day but still have a real-time window for things that need it. Shopify, after going "digital by default" in 2020, has used similar overlap windows for cross-timezone teams.
Writing Better Async Messages: A Few Things That Help
The number one async skill is writing clearly. If your messages regularly require follow-up questions, you're creating synchronous dependencies even in an async system.
A few things I've picked up:
- Lead with the ask. Put what you need at the top, not buried in paragraph three. People skim.
- Give context but don't bury the point. Explain why you need something, but briefly.
- Set a response deadline. "I need this by Thursday EOD" is more useful than "whenever you get a chance."
- Use numbered lists when you have multiple questions. It makes it easy for the other person to respond to each one clearly.
- Record a Loom when text would take too long to explain. Don't write four paragraphs when a 90-second video would do it better.
None of this is complicated. But it takes discipline to do it consistently, especially when you're busy and just want to fire off a quick message.
The Culture Change Is Harder Than the Tool Change
I want to end on this because I think it's the thing people underestimate most. You can set up Notion, Loom, Linear, and Basecamp in a week. Changing how a team communicates takes months.
If leadership keeps scheduling meetings for things that could be written down, nothing changes. If people feel pressured to respond immediately, nothing changes. The tools are just infrastructure. The real shift is cultural — it's about trusting people to do their work without watching them do it.
GitLab has been at this for over a decade. Automattic has employees in 96 countries. They didn't get async right in a quarter. It's an ongoing process that requires constant adjustment.
Start small. Pick one recurring meeting and replace it with a shared document. See what happens. Then do it again. Over time, you build a team that's better at written communication, better at managing their own time, and honestly — at least in my experience — happier at work.
That's worth the awkward transition period.