7 Essays on Async Work Worth Bookmarking

Async work is easy to do badly and hard to explain. Everyone agrees remote teams should not live in meetings, and then the calendar fills up anyway. Most of what teams actually know about doing it well lives in a handful of essays that keep getting passed around in Slack and never quite stick. Here are seven worth saving for good, with a note on what each one gives you and when to reach for it. Read them in order or jump to the one your team needs most this week.

They range from short and sharp (Paul Graham) to long and practical (the GitLab Handbook). None of them require buying anything. Together they are close to a full argument for why writing beats talking on a distributed team, and how to make that switch without turning into a documentation factory.

1. "Maker's Schedule, Manager's Schedule" by Paul Graham

This is the essay that named the problem. Makers, the people writing code or designs, need long unbroken blocks. Managers slice the day into hour-long meetings and barely notice the cost. Graham's point is that a single mid-afternoon call does not cost one hour, it splits a maker's whole afternoon into two useless halves. Read it when you need to explain to a well-meaning colleague why "just a quick sync" is not quick for everyone, and why protecting focus time is a real decision, not a preference. paulgraham.com/makersschedule.html

2. "What the heck is asynchronous communication anyway?" by Amir Salihefendic

The clearest plain-language definition of async you will find anywhere, from the founder of Doist and Twist. It lays out what async actually means in practice, why real-time chat quietly punishes deep work, and how to shift a team toward answers that do not demand an instant reply. It is also fair about the tradeoffs, admitting that some things really are urgent and that async is a default, not a religion. Read it when you need to bring a skeptical teammate along, because it makes the case in ordinary words instead of ideology. async.twist.com/asynchronous-communication

3. "Distributed Work's Five Levels of Autonomy" by Matt Mullenweg

Mullenweg runs Automattic, one of the largest fully distributed companies, and here he lays out a maturity ladder for remote teams. It runs from level one, where a team just recreates the office over video, up to the higher levels where written decisions and deep autonomy make the office irrelevant. Read it to get an honest measure of where your team really sits, because most land a level or two lower than they assume. ma.tt/2020/04/five-levels-of-autonomy

4. "The 37signals Guide to Internal Communication" by 37signals

A set of blunt, concrete rules for writing to each other well, from a company that has run remote for two decades. It includes lines you will end up quoting, like the reminder that if a thing can be interpreted in more than one way, it will be misinterpreted. Read it as a checklist your team can actually adopt this week, not a philosophy to admire and forget. 37signals.com/how-we-communicate

5. "The Future of Work is Written" by Juan Pablo Buritica

Buritica makes the case that writing, not talking, is the core skill of a distributed team, and then shows how to build a culture where that is normal. He is honest that good writing is work and that it does not happen by accident. Read it if your team is sharp and fast in meetings but falls apart the moment one person is offline, because that is the exact gap it addresses. increment.com/remote/future-of-work-is-written

6. The GitLab Handbook on asynchronous communication

Not an essay so much as an operating manual, written by a fully-remote public company that had no choice but to make async work at real scale. It is specific in a way most writing on this topic is not: how to phrase a request so it does not need a follow-up, when a meeting is genuinely warranted, how to keep decisions findable. Read it when you want concrete practices to copy rather than theory to nod along with. handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous

7. "Was E-mail a Mistake?" by Cal Newport

Newport reframes the whole async debate through computer science, comparing how distributed systems coordinate with how human teams do. His argument is that constant messaging created what he calls a hyperactive hive mind, a state of always-on back-and-forth that feels productive and quietly taxes everyone. It pairs well with the Paul Graham essay: one explains the cost of a single interruption, this one explains the cost of a thousand small ones. Read it to see the hidden price of being reachable all day, and why fewer, clearer messages often beat more of them. newyorker.com/tech/annals-of-technology/was-e-mail-a-mistake

What runs through all seven

Read together, these essays keep circling one idea. Async work only holds up when the answer to a question already exists somewhere a person can find it, in writing, without pinging the one human who happens to know. Meetings, quick syncs, and always-on chat are what teams reach for when the written record is thin. The writing is what lets people stop waiting on each other. Every author on this list is really arguing for the same thing from a different angle. Graham and Newport show the cost of interruption. Salihefendic and the GitLab team show the practice. Mullenweg, 37signals, and Buritica show what a team looks like once it takes the writing seriously.

That gap, between "the answer exists" and "someone can actually find it," is the one StandIn works on. You write one short brief at the end of your day, and while you are off, it answers your teammates from what you wrote, with a source under each answer. When the answer is not there, it says so instead of guessing. The essays make the case for writing things down. The harder part is that written answers still sit unread until someone goes looking, and by then the person who wrote them is offline. Bookmark the seven above for the why. Then make sure the answers your team needs are somewhere they can reach without you.