This essay expands on the “context” thread from Management Retrospective.
Two teams can work as if separated by great distance even in the same time zone. It is not because the network is slow, but because as a decision moves from proposal, to explanation, to handoff, to execution, its context keeps getting compressed — until only a sentence like “could you help change this” remains.
In cross-time-zone collaboration, the biggest loss is usually not the time difference itself, but the context that gets dropped during handoffs. The “this change is meant to solve A” that you understand today may, by the time it reaches a colleague next week, have shrunk to just “this needs to change here.” The responsibility remains, but why the change is being made and what it must not break are all gone.
Close the Loop on Responsibility First
What distributed collaboration fears most is “everyone owns a little bit.” If a feature is designed in one place, implemented and tested in another, and released by yet another as the fallback, any change will bounce back and forth across boundaries — and each pass thins the context further.
A more stable approach is to divide closed loops by deliverable: who can own something all the way from clarifying the problem to verifying it; which dependencies must cross teams; and who the cross-team point of contact is. A closed loop does not mean never collaborating; it means giving collaboration a clear entry point instead of slicing the whole responsibility too finely. The more finely responsibility is sliced, the greater the context loss.
Preserve Context in Documentation
Meetings are a synchronous tool, not the only memory. Important decisions should leave behind a short document: the problem, the options, the rationale, the owner, the open items, and the review time. That way, people who join the discussion late don’t have to guess from chat history, and they can still offer their opinions asynchronously.
A common practice: two cities jointly maintain a release pipeline. Rather than holding a one-hour status meeting every day, write down the scope of impact and the rollback plan before each change, update the same incident log when something goes wrong, and at a fixed weekly time discuss only the matters that truly need a synchronous decision. Documentation does not replace communication; its job is to make sure what has “already been thought through” no longer relies on people’s memory.
Keep a Small Amount of High-Quality Sync Time
Async does not mean canceling communication. The team still needs a stable block of overlap time for resolving disagreements that can’t be aligned quickly in writing, building relationships, and making key decisions. The difference is: materials are read beforehand, the meeting has an agenda, and conclusions land back in the documentation.
The standard I use to judge whether a distributed team is mature is not how quickly messages are answered, but: even if someone is temporarily offline, do important tasks still keep their direction and ownership? If the answer is “no,” the problem is probably not the time difference but that context is stored in individuals’ heads rather than in the team’s shared space.
Async-first is not about canceling communication; it is about reserving real-time attention for the issues that truly need synchronization. Do the three things above, and context loss will shrink considerably.