Async by default, not by exception
When a live meeting is the default way decisions get made, anyone outside the meeting's time zone is structurally disadvantaged — they find out after the fact, or they're awake at 11pm to participate. We design our own internal workflows the same way we design client systems: assuming async first, with live conversation as the exception for things that genuinely need it.
In practice, that means most discussions happen in writing, with enough time built in for someone in a different region to read, think, and respond before a decision is finalized — rather than decisions being made in the room and communicated to everyone else after the fact.
Why we write things down
If a decision only exists in someone's memory of a call, it effectively doesn't exist for whoever wasn't on that call. Decisions, scope changes, and open questions get written down somewhere persistent, not just discussed and left to be remembered correctly by everyone involved.
This is the same discipline we bring to client SOPs and documentation — we don't ask clients to do something internally that we don't also hold ourselves to.
Handoffs across time zones
Work in progress crosses time zones constantly: someone in one region finishes a piece of work as someone in another region is starting their day. The handoff has to carry enough context that the next person isn't reconstructing intent from scratch — what was tried, what's still open, what the next concrete step is.
Tools are secondary to habits
It's easy to assume distributed teams succeed or fail based on which software they use. In our experience, the software matters far less than the habits around it — whether people actually write the handoff note, whether a decision gets documented the same day it's made rather than "whenever there's time." A well-chosen tool makes good habits easier to sustain, but it doesn't create them.
What this costs us, honestly
Async-first isn't free. Some things genuinely move slower than they would in a same-room conversation, and writing things down clearly takes more upfront effort than talking them through informally. We think that tradeoff is worth it — clearer documentation and less dependency on any one person being available — but it is a tradeoff, not a pure upgrade.
What this means if you're building a distributed team
The most common mistake we see teams make when going remote for the first time is keeping a meeting-first culture and simply moving the meetings onto video calls. That preserves the time-zone disadvantage it was supposed to solve. The shift that actually helps is treating async written communication as the default operating mode, with live conversation reserved for the cases that genuinely need real-time back-and-forth.
Key takeaways
- ›Async-first means assuming written communication by default, not treating it as a fallback for when meetings aren't possible.
- ›A decision that only exists in someone's memory of a call effectively doesn't exist for anyone who wasn't there.
- ›Tools matter less than the habits around them — a good tool doesn't create discipline that isn't already there.
- ›Distributed work has real costs — clearer documentation in exchange for some things moving slower — and we think that trade is worth it.