The simple version
Asynchronous communication means you don’t need the other person present when you send a message. Distributed teams figured out this constraint is actually a feature, not a bug.
Why the open office got focus backwards
The open office was sold on collaboration. What it delivered was interruption with better acoustics. Benched seating and no walls didn’t make ideas flow faster. It made people put on headphones and pretend they were somewhere else.
The underlying assumption was that proximity equals productivity. If you can tap someone on the shoulder, communication is frictionless. But friction isn’t the enemy of good thinking work. Interruption is.
Research on cognitive load has consistently shown that knowledge workers need somewhere between 15 and 25 minutes to reach deep focus after an interruption. Not to get back to the task, but to get back to the depth of engagement they had before. A quick question from a coworker, a Slack ping, someone leaning over your monitor: each one resets that clock. In an open office, many people never accumulate enough uninterrupted time to do their best work at all.
The office optimized for the appearance of collaboration. Distributed teams, forced to be deliberate about every interaction, accidentally optimized for the reality of it.
What async-first actually means
Async-first doesn’t mean never talking to people in real time. It means that real-time conversation is reserved for things that genuinely require it, and that the default assumption is that you don’t need an immediate response.
Think of it like the difference between a function call and a message queue. A synchronous function call blocks execution until it gets a return value. Your program sits there, waiting. An asynchronous call sends the message, moves on to other work, and handles the response when it arrives. The system stays productive in the meantime.
In human terms: instead of walking over to ask a question and expecting an answer in the next thirty seconds, you write the question down carefully (because you know the person will need context to answer it without back-and-forth), send it, and go do something else. They answer when they’ve thought about it. You get a better answer. Neither of you lost an hour.
The writing-it-down part is crucial. It forces you to clarify what you actually need before you ask. A lot of questions that felt urgent dissolve when you try to articulate them precisely.
How this changes what “available” means
Traditional office culture equates availability with presence. If you’re at your desk, you’re available. If you’re not answering Slack within five minutes, something is wrong.
Distributed teams that work well have broken this link. Being unavailable for two or three hours in the morning isn’t a red flag. It’s the job. It means someone is writing code, designing something, thinking through a problem, drafting a document that will save everyone else an hour of meetings.
GitLab, which has operated as a fully distributed company with hundreds of employees across dozens of time zones, documents this philosophy explicitly in their public handbook. They describe it as defaulting to async as a first instinct, using real-time communication as an intentional escalation for things that genuinely need it, and treating documentation as a primary artifact rather than a secondary record.
The practical effect is that the record of decisions, context, and reasoning lives in writing. New people can read the history of a decision. Nobody has to ask “why did we do it this way?” and wait for the one person who was in that meeting two years ago. The organization’s knowledge compounds instead of walking out the door with every departing employee.
This connects to something worth calling out directly: your most productive hour is the one you keep booking over. Protecting that time isn’t selfishness. It’s the work.
The real cost of synchronous default
When real-time availability is the baseline expectation, the entire organization starts to schedule around presence rather than output. Meetings multiply. You hold a kickoff meeting, a check-in meeting, a sync to discuss the thing that came out of the sync. Each one is easier to justify than it is to cancel, and each one fragments the day into slots too short for serious work.
Calendar Tetris is the symptom. The disease is treating every coordination problem as one that requires a meeting to solve.
Async-first teams handle this differently by raising the bar for what warrants a meeting. Does this require real-time back-and-forth with multiple people to resolve, or does it just feel that way because scheduling a meeting is the path of least resistance? If you can write a document that gives people the information they need and lets them respond in their own time, you probably should.
The meetings that remain tend to be better. They have a clear purpose. Participants have read the pre-read. Decisions get made. Nobody leaves wondering what they were there for.
What offices can actually borrow from this
You don’t need a distributed team to use these principles. The core moves are accessible to anyone:
First, treat writing as a first-class output. When you finish a decision, a design, or a plan, document it in a place others can find it. Not a meeting notes document buried in someone’s personal drive. Somewhere canonical.
Second, default to not requiring a response. “Just keeping you informed” and “I need this in an hour” are different messages. Label them differently.
Third, protect some part of your day from synchronous interruption. Block it, honor it, and don’t apologize for it. Focus time isn’t a perk. It’s how the actual work gets done.
The distributed teams that work well didn’t discover some exotic productivity hack. They had a constraint imposed on them (you can’t tap people on the shoulder across nine time zones) that forced them to be deliberate about something most offices never had to think about: the difference between communication and collaboration, and the cost of confusing the two.
