Core Primitive
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.
The cognitive advantage of not being in the room
Richard Daft and Robert Lengel's media richness theory, published in 1986, argued that face-to-face communication is the "richest" medium because it carries the most information — verbal content, tone, facial expression, body language, immediate feedback. For decades, this theory was used to justify the superiority of synchronous meetings over all alternatives: if you want the best communication, get people in a room together (Daft & Lengel, 1986).
The theory is correct about information richness. It is wrong about what matters for collective thinking. Richness is valuable for building relationships, resolving emotional conflicts, and navigating ambiguity — but it can actively hinder the cognitive processes that produce good team decisions. The immediate feedback of synchronous discussion enables anchoring (the first speaker sets the frame), social pressure (disagreeing face-to-face is harder than disagreeing in writing), and processing speed mismatches (fast talkers dominate slow thinkers, regardless of the quality of their ideas). The "richness" of real-time interaction carries social signals that interfere with cognitive signals.
Asynchronous communication strips away these social interference patterns. When you write your analysis in a document rather than speaking it in a meeting, you have time to compose your thoughts carefully, review your reasoning, and express disagreement without the interpersonal intensity of face-to-face confrontation. The reader processes your contribution at their own pace, without the social pressure of responding immediately. The result is often deeper thinking, more honest input, and better integration of diverse perspectives — precisely because the communication is less "rich" in the social dimension (Dennis et al., 2008).
Writing as team thinking
The practice of writing as thinking — using the act of composition to clarify and develop ideas — is well-established at the individual level (Phases 1-2 of this curriculum). At the team level, writing serves the same function: the discipline of articulating a position in writing forces the writer to examine their reasoning, identify their assumptions, and anticipate counterarguments in ways that verbal contribution does not.
Amazon's practice of the "six-page memo" — a structured narrative document that replaces PowerPoint presentations for decision meetings — is perhaps the most famous corporate implementation of writing-as-team-thinking. Jeff Bezos has explained the rationale: "The reason writing a memo is harder than preparing a PowerPoint presentation is that the narrative structure of a good memo forces better thought and better understanding of what's more important than what." The memo discipline ensures that the author has thought clearly before the team invests its collective attention, and that the team's reading and commenting process engages with a complete argument rather than a series of bullet points that can mean different things to different readers.
GitLab, the largest all-remote company in the world with over 2,000 employees across 60+ countries, has built its entire organizational cognition around asynchronous writing. Their public handbook — over 2,000 pages — serves as the company's externalized brain: every process, decision framework, and cultural norm is documented. Decisions are made through merge requests to the handbook, with written discussion that anyone in the company can participate in. The result is a decision-making process that is more inclusive (anyone with relevant knowledge can contribute, regardless of time zone or seniority), more transparent (the reasoning is permanently documented), and more deliberate (writing forces careful thought) than any meeting-based process could achieve at their scale.
Designing async collaboration protocols
Asynchronous collaboration does not work by default. Sending an email and waiting for responses is not async collaboration — it is unstructured communication that produces inconsistent participation, unclear timelines, and fragmented discussion. Effective async cognition requires designed protocols.
The RFC (Request for Comments) process. Borrowed from internet standards development, the RFC is a structured document that proposes a change, explains the reasoning, presents alternatives considered, and invites written feedback. The RFC has a defined comment period (typically 48-72 hours for routine decisions, one week for significant ones), a clear list of required reviewers, and a decision mechanism (the author incorporates feedback and either proceeds or escalates unresolved disagreements to a synchronous meeting). The RFC process ensures that async discussion is bounded, structured, and conclusive rather than open-ended.
Structured comment protocols. When sharing a document for async review, specify what type of feedback you want. "Please comment on technical feasibility, not on writing style." "For each section, indicate whether you: agree, disagree, or need more information." "Flag any assumption you believe is incorrect." Structured prompts produce structured responses — responses that are easier to synthesize and act on than free-form comments that range from typo corrections to fundamental disagreements.
Async stand-ups. Daily or periodic status updates shared in writing rather than in a meeting. Each team member posts answers to three standard questions: What did I complete? What am I working on? What is blocking me? The written format is faster (two minutes to write vs. fifteen minutes in a meeting), more equitable (every voice is represented equally), and creates a searchable record that can be referenced later. The key design choice is the platform — a dedicated channel or thread that team members check at their convenience, not a stream of messages that competes with other communication for attention.
Decision logs. When async discussion produces a decision, the decision is captured in a persistent, findable location — not buried in a Slack thread that will scroll out of view within days. The decision log includes: the question, the options considered, the decision, the reasoning, the date, and the participants. This log becomes part of the team's memory system (Team memory systems) and enables future retrospective analysis (Team retrospectives as collective reflection) of the team's decision patterns.
The sync-async spectrum
Gary Olson and Judith Olson's landmark 2000 paper "Distance Matters" argued that remote collaboration is not simply a degraded version of co-located collaboration — it is a different mode with different strengths and weaknesses. Their research on distributed teams found that the most effective distributed teams do not try to replicate co-located work patterns remotely. Instead, they redesign their collaboration to leverage the strengths of each mode (Olson & Olson, 2000).
The optimal design is not all-sync or all-async but a deliberate combination that matches mode to cognitive need:
Synchronous for: Relationship building, emotional processing, rapid iteration on a single problem, conflict resolution, and generative brainstorming where energy and spontaneity matter.
Asynchronous for: Deep analysis, complex reasoning, independent evaluation (pre-work for decisions), status communication, documentation, and any discussion where the quality of contribution matters more than the speed of response.
Hybrid for: Decisions that benefit from both individual reflection and group debate — the pre-work is async, the discussion is sync, and the documentation is async again. This hybrid pattern is the default for high-stakes decisions: written RFC → synchronous deliberation → written decision record.
The attention economy of async work
Herbert Simon's 1971 observation that "a wealth of information creates a poverty of attention" applies with particular force to asynchronous team collaboration. When the team communicates primarily through written channels, the volume of information grows rapidly — documents, comments, threads, updates, decision records. Each piece of information competes for the finite attention of every team member. Without design, the async workspace becomes an attention tax that consumes more cognitive energy than it saves (Simon, 1971).
The antidote is information architecture — deliberate design of where different types of information live, how they are organized, and how they signal their urgency and importance. Effective async teams distinguish between:
High-signal channels that require attention (decision RFCs, blocking questions, incident notifications). These should be few, clearly labeled, and reliably monitored.
Reference channels that are consulted when needed (documentation, decision logs, process descriptions). These should be well-organized and searchable but do not require active monitoring.
Low-signal channels that are optional (general discussion, social chat, links and articles). These provide social cohesion and serendipitous information sharing but should never contain information that someone needs to do their job.
When these categories are collapsed into a single stream — as they are in most Slack workspaces — every team member must scan everything to find anything, and the cognitive cost of staying informed rises until it becomes the dominant work activity rather than a support for the real work.
The Third Brain
Your AI system can serve as an asynchronous collaboration architect. When designing an RFC or async decision process, describe the decision to the AI and ask it to draft: the document template, the structured comment prompts, the decision criteria, and the timeline. The AI can produce a more complete and better-structured starting point than most humans would create from scratch, because it can draw on the full range of async collaboration patterns from multiple organizational contexts.
The AI can also serve as an async discussion synthesizer. After a comment period closes on an RFC, share all comments with the AI and ask: "Summarize the areas of agreement, the areas of disagreement, and the questions that remain unresolved. What themes emerge?" The synthesis saves the RFC author hours of manual processing and ensures that no comment is overlooked in the integration.
For distributed teams, the AI can function as a "time-zone bridge" — summarizing the discussion that happened during one team's working hours so that the next team's working hours begin with full context. "Here is what the London team discussed and decided today. Here are the open questions for the Singapore team to address." This bridge function reduces the information loss that naturally occurs when async discussions cross time zones.
From process to persistence
Asynchronous collaboration produces artifacts — documents, comments, decisions, analyses — that represent the team's externalized thinking. But artifacts are only valuable if they persist, remain findable, and stay current. A brilliant RFC that is buried in a Slack thread from three months ago contributes nothing to the team's ongoing cognition.
The next lesson, Team memory systems, examines team memory systems — the infrastructure for capturing, organizing, and maintaining the outputs of the team's cognitive processes so that past thinking informs future work.
Sources:
- Daft, R. L., & Lengel, R. H. (1986). "Organizational Information Requirements, Media Richness and Structural Design." Management Science, 32(5), 554-571.
- Dennis, A. R., Fuller, R. M., & Valacich, J. S. (2008). "Media, Tasks, and Communication Processes: A Theory of Media Synchronicity." MIS Quarterly, 32(3), 575-600.
- Olson, G. M., & Olson, J. S. (2000). "Distance Matters." Human-Computer Interaction, 15(2-3), 139-178.
- Simon, H. A. (1971). "Designing Organizations for an Information-Rich World." In M. Greenberger (Ed.), Computers, Communications, and the Public Interest. Johns Hopkins University Press.
Frequently Asked Questions