Topic
Async Teams
Distributed teams drown when chat is the router and calendar is the default. The fix is not more standups: it is named paths for status and blockers, response bands that respect sleep, decision notes that prevent re-litigation, and meetings reserved for choices that cannot move in text.
Async work fails in predictable ways: status that nobody reads, blockers reported as vibes, handoffs that force archaeology, and meetings booked because writing felt harder. Those failures look like communication problems. They are usually system problems.
This topic collects operational patterns: end-of-day updates people actually skim, pick-up-ready handoffs, blockers with owners and UTC dates, and a meet-vs-async filter that protects scarce overlap.
Treat async as the default and meetings as the exception. The cornerstone guide on async communication is the operating contract; the articles below are the daily habits that make that contract hold when someone says "just ping me."
Meet vs async
Default to async; book live time only when a row below is true.
- Async fits
- Status, handoffs, blockers with owners, and decisions that can be written with options and a deadline.
- Meet when
- Two or more plausible paths need a human choice in under thirty minutes and text has already failed once.
- Meet when
- Trust or relationship repair: a misread tone, a repeated miss, or a new stakeholder who has not seen how the team works.
- Skip the meet
- Reading tickets aloud, re-announcing work already in the tracker, or "quick syncs" with no decision on the agenda.
- After either path
- Post what changed, who owns the next step, and by when so the calendar does not become the system of record.
What this topic covers
- Designing async communication that reduces meeting load
- Writing status updates that answer what changed, what is next, and what is blocked
- Leaving work so another person can continue without a call
- Reporting blockers clearly and without politics
- Deciding when a remote team actually needs a meeting