What does it mean that asynchronous team cognition?

Much of a team's best thinking happens outside meetings — in written documents, code reviews, design proposals, and structured asynchronous exchanges. Designing for asynchronous cognition extends the team's thinking capacity beyond the limits of synchronous time.

Example: A distributed engineering team spanning San Francisco, London, and Singapore had a recurring problem: their synchronous meetings were scheduled at the only hour that worked for all three time zones — 8 AM Pacific, 4 PM London, 11 PM Singapore. The Singapore engineers were exhausted, the London engineers were distracted by end-of-day tasks, and the California engineers were not yet fully engaged. The team's most important thinking was happening in its worst cognitive conditions. The engineering director, Kenji, restructured the team's collaboration around an async-first protocol. Major decisions began with a written RFC (Request for Comments) document shared across all time zones. Each engineer had 48 hours to add written comments, questions, and alternative proposals directly on the document. The Singapore team reviewed and commented during their morning, London during their midday, and California during their afternoon — each contributing during their peak cognitive hours rather than their worst. After the comment period, a synchronous meeting was held only if the written discussion revealed unresolved disagreements that required real-time debate. The team estimated that seventy percent of decisions that previously required meetings were resolved entirely through the async RFC process — and the remaining thirty percent were resolved in shorter, more focused meetings because the written pre-work had already narrowed the discussion to the genuine points of disagreement.

Try this: Identify one recurring synchronous meeting that could be partially or fully replaced by asynchronous collaboration. Design an async alternative using this template: (1) Document format — what information will be shared and in what structure? (2) Contribution protocol — who contributes, by when, and in what format? (3) Resolution criteria — how do you determine if async discussion has resolved the question or if a synchronous meeting is needed? (4) Decision mechanism — how is the final decision captured and communicated? Run the async alternative for three cycles alongside (or instead of) the synchronous meeting. After three cycles, compare: Did the async process produce comparable or better outcomes? Did it free up synchronous time for work that genuinely requires it?