The distributed team ADR: how async-first organizations document decisions without a shared whiteboard

The distributed documentation paradox

Distributed teams write more than co-located teams. They have to. The hallway conversation that co-located teams rely on for quick alignment doesn't exist, so everything that would have been said in passing gets written into a Slack thread, a Notion comment, a GitHub Discussion, a Loom recording. The artifact count per decision is higher in an async team than in a synchronous one.

Yet the decision documentation is worse. The artifacts that exist are process artifacts — records of a conversation, not records of a decision. A Slack thread captures who said what and when. A PR comment captures the code reviewer's concern. A Notion doc captures the RFC draft. None of these captures the thing an ADR is designed to preserve: the named alternatives that were considered, the constraint that made one option better than the others at the time of decision, and the reasoning a new team member needs to understand the current state without reconstructing it through interviews.

The fundamental reason is that async threads have no visible ending. When a co-located whiteboard session concludes, everyone in the room knows a decision was made. There is a shared physical moment — the marker goes down, the photo gets taken, someone says "okay, we're going with X." That moment is the signal that documentation could and should happen now. The async Slack thread has no equivalent. The thread winds down. The thumbs-up reactions accumulate. The activity feed moves on. Nobody sends the "we decided" message, because the decision is implicit in the accumulation of agreement. The new-CTO problem is acute in distributed companies for exactly this reason: the reasoning that in a co-located company might at least live in someone's memory of a meeting, in a distributed company may never have been in a single room at all.

Five surfaces, five slices, no complete record

A significant technical decision in a distributed team typically leaves traces across five different surfaces, none of which contains the full decision record on its own.

Slack threads capture the social layer: who agreed, who raised concerns, which concerns were addressed and which were deferred. The decision-relevant information is buried in the thread, unstructured, and buried below hundreds of other messages within a week. Slack's search is adequate for finding a thread if you know approximately when it happened; it's inadequate for a new team member who doesn't know a decision was made at all.

GitHub PR comments capture the technical layer after the decision: the implementation review, the edge cases raised, the test coverage concerns. These are useful for understanding how the decision was executed, not why it was made. The PR that implements GraphQL says nothing about why REST was rejected.

Async documents (Notion, Confluence, Google Docs) capture the proposal layer: the RFC that preceded the decision, with the alternatives and the proposer's recommended approach. The RFC is the richest pre-decision artifact, but it's rarely updated after the comment window closes. The RFC says "I recommend GraphQL for these reasons." It rarely says "the team decided GraphQL on [date], with these trade-offs acknowledged."

Video recordings — of stand-ups, design reviews, 1:1s — capture spoken deliberation but are unindexed and unstructured. A decision that happened in a recorded meeting is functionally as inaccessible as one that happened in a hallway: you have to know the meeting existed, find the recording, and watch it to find the relevant minute.

AI chat sessions capture the individual deliberation layer: the thinking each engineer did before contributing to the group discussion. This is the most complete reasoning record per individual and the most invisible to the team — it lives in a personal chat history that no shared tool indexes or preserves.

The ADR is the document that synthesizes these five slices into one authoritative record. The async RFC pattern and the multi-engineer extraction pass are the processes that do the synthesis without requiring a synchronous ceremony.

The timezone and thread burial problem

Decisions in distributed teams often complete asynchronously across timezone offsets of eight hours or more. The engineer in Berlin proposes an approach at 9am. The engineer in San Francisco wakes up and adds a concern at 11am Pacific, which is 8pm Berlin time. The senior engineer in Singapore, having been asleep for both exchanges, reads the overnight thread at 6am Singapore time, agrees with the Berlin proposal with a modification, and posts the synthesis. The decision is now complete.

The conclusion is buried in a thread where the context requires reading three timezone-offset messages to reconstruct. The PR that follows carries none of this. The commit message says "switch API to GraphQL." The code itself is the decision's artifact. The reasoning is distributed across three messages that will be unreachable without direct Slack search within two weeks.

This is the cross-team decision problem compressed into a single team. The reasoning exists — it's in the thread. It's complete — the three engineers covered the alternatives and the constraint. But it's not in a form that survives the tool or the time. A new engineer who joins in six months and searches for "why GraphQL" will find the commit and the code, not the deliberation.

The timezone problem compounds for decisions that affect multiple teams. A cross-team decision in a distributed organization may involve engineers in three time zones, none of whom were awake for the full thread. The decision summary that someone posts in #engineering captures the outcome. It doesn't capture the reasoning that led to it, the alternatives that were rejected, or the conditions under which the decision should be revisited.

The async RFC pattern

The most effective convention for distributed team decision documentation is the async RFC pattern — not the formal IETF RFC process, but a lightweight version adapted for small engineering teams making frequent architectural and process decisions.

The pattern has five steps:

1. Proposal document. The proposing engineer writes a brief document (one to two pages) before opening a PR or starting implementation. The document describes the proposed approach, the alternatives considered, and the constraint or signal driving the proposal. This is the RFC. It goes to a shared location — a decisions/ folder in the repo, a GitHub Discussion, a Notion database, a Notion page with a comment link shared to Slack. The format can follow the standard Nygard ADR template with Status set to "Proposed."
2. Comment window. The proposal is open for comment for 48–72 hours. For teams spanning ±12 hour timezone differences, 48 hours gives everyone at least one full workday to read and respond. The window is announced in the relevant Slack channel with a link and a deadline: "RFC on API layer — comments by [date and time in UTC]."
3. Synthesis. When the window closes, the proposing engineer reads all comments and posts a synthesis: what feedback was incorporated, what was acknowledged but not incorporated (and why), and the final decision. This is not a new document — it's appended to the RFC document, so the full deliberation history is in one place.
4. Decision record. The proposing engineer updates the RFC document's Status from "Proposed" to "Accepted" (or "Rejected" or "Superseded"), appends the decision summary paragraph, and closes the comment thread. The RFC is now the ADR. The same document serves both functions: it was the pre-decision proposal and is now the post-decision record. The Markdown ADR template is the right format for this — the Considered Options section was the RFC's alternatives, the Decision section is the synthesis, and the Consequences section documents the trade-offs acknowledged.
5. Announcement. A one-line announcement in the team's decision channel: "GraphQL RFC closed — accepted. See decisions/0042-graphql-api-layer.md for the record." This is the registry entry. The full record is in the file; the announcement is the index.

The async RFC pattern works for distributed teams for the same reason the RFC-before-ADR distinction matters in general: the proposing engineer has already done the alternatives analysis and written the constraint in the proposal. Closing the loop into an ADR requires appending one synthesis paragraph, not reconstructing the deliberation from memory. The documentation cost is lowest at the moment the decision closes, which is also when the reasoning is freshest. The async RFC pattern captures the decision at that moment.

The decision channel approach

A simpler convention that many distributed teams adopt before (or alongside) the async RFC pattern: a dedicated #decisions channel where every finalized decision gets a brief announcement, regardless of where the decision-making happened.

The announcement format: "Decided to use X over Y for [context]. Reasoning: [one sentence]. Full context: [link]. If you have concerns, reply here or message @[decision-maker] by [date]." The link points to the RFC document, the GitHub Discussion, the PR thread, or wherever the deliberation actually happened — the #decisions channel is the index, not the archive.

The #decisions channel provides two properties that no other async surface provides:

• A completeness signal. A decision that hasn't appeared in #decisions isn't closed yet. Teams that adopt this convention learn quickly to check #decisions before starting implementation work that might depend on a recent architectural choice. The channel becomes the authoritative signal of decision status — not because it's comprehensive, but because the team treats it as the canonical announcement surface.
• A fast onboarding index. A new team member reading #decisions for the last 90 days gets a fast overview of recent consequential decisions without needing to triage Slack search results across dozens of channels. This is a rougher version of the formal onboarding reading list, but it works without requiring anyone to curate it manually.

The limitation of the #decisions channel is that it is a registry, not a record. The one-paragraph announcement contains the title and the decision — the what — without the context, alternatives, and consequences — the why. The announcement is useful for orientation; it's insufficient for the engineer who six months later needs to understand why X was chosen rather than Y. The full record still needs to live somewhere durable: the decisions/ folder, a Notion database with version history enabled, a pinned GitHub Discussion. The #decisions channel is the front door; the linked document is the room.

For teams that haven't yet formalized the async RFC pattern, the #decisions channel is the right starting point. It creates the announcement habit without requiring a new document format. Once the habit is established — once engineers expect to announce decisions and link to context — the async RFC pattern gives them something worth linking to.

How AI chat plays a different role for distributed teams

For co-located teams, AI chat supplements the synchronous collaboration that happens in person. An engineer uses ChatGPT or Claude to process a problem before a meeting, fact-checks a claim during a discussion, or works through a concern after a whiteboard session. The primary deliberation happens in the room; AI chat handles the individual preparation and follow-up.

For distributed engineers, AI chat often is the deliberation. The engineer working at 10am in a timezone where colleagues aren't yet awake doesn't have a whiteboard or a rubber-duck colleague to think out loud with. They use Claude or ChatGPT to reason through the decision before posting the RFC. The AI chat session contains the full pre-proposal deliberation: the alternatives explored, the constraints identified, the trade-offs mapped. By the time the RFC is posted, the individual reasoning is complete — and it lives in the AI chat export.

This creates a structural difference in the value of AI chat exports for distributed teams:

In a co-located team, the most thorough decision reasoning may live in the whiteboard session that the founding engineer ran. The AI chat for the same decision may be a brief fact-check or a post-session recap. In a distributed team, the most thorough reasoning almost always lives in the proposing engineer's pre-RFC AI chat session — because that's when and where the deliberation happened, with no synchronous alternative available.

Practical implications for the quarterly extraction pass:

• Run the extractor on multiple team members' exports, not just the technical lead's. In a co-located team, the reasoning is often concentrated in the person who facilitated the whiteboard session. In a distributed team, the reasoning is distributed across the person who proposed the RFC, the person who raised the key objection, and the person who synthesized the decision. All three may have separate AI chat sessions containing extraction candidates.
• Cross-reference extraction outputs across team members. The proposing engineer's pre-RFC session and the objecting engineer's counter-argument session may together produce a more complete decision record than either alone. The proposing engineer's session has the initial framing and alternatives; the objecting engineer's session has the reasoning behind the concern that shaped the final decision. Both are needed for the full Considered Options section of the ADR.
• Expect higher extraction yields than co-located teams. The WhyChose extractor's question-shape and trade-off marker patterns are tuned for deliberation that happens in natural language. Distributed engineers who use AI chat as their primary thinking tool produce deliberation sessions that are more structurally explicit than the shorthand of a whiteboard session. The extraction yield per export session is typically higher for remote engineers than for co-located engineers who use AI chat only as a supplement.

The ChatGPT export and Claude export processes are the same for distributed teams as for co-located ones. The difference is that distributing the export request to three or four engineers rather than running one lead engineer's export produces significantly more complete coverage of the quarter's decision deliberations.

The distributed team extraction workflow

The standard 30-minute quarterly review doesn't translate directly to distributed teams — the synchronous triage session isn't available. Here's the async-adapted version:

1. Pre-extraction request (one week before the review). The team lead asks each engineer to export their AI chat history for the quarter and run the extractor. This can be a single async message in the team channel: "Quarterly decision review coming up — please export your ChatGPT/Claude history for Q2 and run the WhyChose extractor. Share the output file to [shared folder] by [date]." The 48-hour lead time accommodates timezone distribution and export processing time.
2. Pool and triage (async, 48–72 hour window). Extraction outputs go to a shared folder. A designated triage lead (rotating) reads all outputs and proposes triage assignments in a shared document: each extraction candidate tagged as Promote / Link / Park / Dismiss with a one-line rationale. The document is open for comment corrections for 48 hours before any ADRs are written.
3. ADR drafting (async, per-Promote item). Each Promote item is claimed by the engineer who has the most context — usually the proposing engineer from the original decision. They write an ADR draft using the standard template, cross-reference the extraction output from other engineers' sessions for the Considered Options and Consequences sections, and post the draft for a 24-hour comment window.
4. Merge and announce. ADRs that receive no blocking objections are merged to the decisions/ folder. Each merged ADR gets a #decisions announcement. The quarterly review is done when all Promote items have merged ADRs or have been reclassified (Park or Dismiss).
5. Archive. Extraction output files are archived (not deleted — they're the source material). A quarterly reminder is set for the next cycle.

The async extraction workflow takes about a week of calendar time and two to three hours of actual effort distributed across the team. It fits the distributed team's working rhythm because no single synchronous session is required. The decision records that result are often more complete than those produced by a co-located team's synchronous triage session, because the multi-engineer pooled output captures individual deliberation that the whiteboard session would have homogenized.

Three distributed-team-specific challenges

The "who decided" ambiguity

In a synchronous team, the person who closed the whiteboard session decided — or at least there's a clear facilitator who can be asked. In an async thread, decisions often accumulate through implicit consensus: nobody made the call, the thread just stopped with everyone thumbs-upping. The ADR's Deciders field is especially important in this context. If no one writes down who made the decision, the answer becomes "the Slack thread" — which is not a useful answer six months later when the decision needs to be revisited or its reasoning explained to a new hire.

The async RFC pattern solves the "who decided" problem structurally: the proposing engineer who writes the synthesis paragraph and updates the status is the decision-maker of record, even if the decision was shaped by multiple reviewers. The Deciders field lists everyone whose input materially shaped the outcome. This is the same mechanism that cross-team ADRs use when multiple functions own a decision — the Deciders field handles multi-owner cases without requiring a single authoritative vote.

The tool-migration cliff

Distributed teams change tools more frequently than co-located teams — Slack to Discord, Notion to Confluence, GitHub Issues to Linear, Zoom to Around to Gather. Each migration creates a documentation cliff: decisions made in the old tool's threads or documents may be read-only, archived, or inaccessible to engineers who join after the migration.

AI chat exports are unaffected by tool migrations. A ChatGPT or Claude export session from 2024 is still accessible and runnable through the extractor in 2026, regardless of how many times the team has changed project management tools. This makes AI chat export history uniquely valuable for distributed teams reconstructing a historical decision log — the deliberation that happened in a Notion page that was migrated and partially lost may still be intact in the engineer's AI chat export from the same week.

The not-building-this record type is especially vulnerable to tool migrations: decisions to defer or reject a product direction rarely produce any persistent artifact in project management tools (there's no Jira ticket for "decided not to build X"), but the deliberation exists in AI chat exports from the period when the decision was made.

The synthesis problem

A synchronous decision produces one artifact (the whiteboard outcome) that can be documented. An async decision produces multiple partial artifacts — the RFC document, the Slack thread, the PR review comments, the individual AI chat sessions — that need to be synthesized into one authoritative record. The synthesis step is more effort than documenting a single-source decision, and it's the step that most distributed teams skip.

Skipping the synthesis is worse than not documenting at all. The partial artifacts create the illusion of documentation: the RFC exists, the Slack thread exists, the PR exists. A new team member who searches for the GraphQL decision may find all three and still not understand why REST was rejected, because none of the three documents contains the full decision frame. Three partial artifacts are more confusing than zero, because they require the reader to reconstruct the synthesis that nobody wrote.

The async RFC pattern's key contribution is making the synthesis step mandatory and minimal: the proposing engineer who already wrote the alternatives (in the RFC) and read the feedback (in the comment window) has everything needed to write the synthesis paragraph. The cognitive cost of adding "we chose GraphQL because the client-side query flexibility outweighed the schema complexity for our current team size; REST remains the right choice for teams above 15 engineers or with strict bandwidth constraints" is low when the RFC is still open. It's high when someone is asked to reconstruct it from a buried thread six months later.

Where to start

For a distributed team starting its first decision log, the sequence that works:

1. Run the extractor on last quarter's AI chat exports from three engineers. The team lead and two engineers who were most active in architectural or product decisions last quarter. Pool the outputs and triage them to identify the five to ten decisions that would most confuse a new engineer today — cross-team constraints, architectural invariants, process decisions, and any "not building this" choices that are actively relevant to the current roadmap.
2. Write ADRs for those five to ten decisions. Not the most recent decisions — the ones that would cause the most confusion if undocumented. Historical ADRs written after the fact are still valid; they document the reasoning as it was understood at the time of decision, even if the decision itself was made months ago.
3. Add a #decisions channel and announce the next two or three decisions there. Once the channel exists, the announcement habit forms quickly. Engineers who see decision announcements understand the format and begin making their own announcements when closing RFCs or reaching consensus on a design choice.
4. Adopt the async RFC pattern for the next significant decision. One practice session with the full RFC → comment window → synthesis → ADR flow is enough to make the pattern feel natural. The second RFC takes a third of the time. The third becomes routine.
5. Set a quarterly extraction reminder. The same reminder that schedules the next export request to the team. The quarterly cadence is the correct frequency for distributed teams: monthly is too frequent to accumulate enough decisions for a productive triage session; annual is long enough that the extraction candidates are from decisions whose context the team no longer has active memory of.

The distributed team decision log, once it exists, is more valuable than a co-located team's equivalent because the team is more dependent on written records for continuity. Onboarding a new engineer onto a co-located team is slow but possible through in-person absorption. Onboarding a new engineer onto a distributed team without a decision log requires scheduling synchronous calls across multiple time zones to reconstruct reasoning that should have been written down. The onboarding use case applies with double force to distributed teams: the decision log isn't a nice-to-have, it's the primary mechanism by which distributed institutional knowledge transfers to new team members who will never be in the same room as the people who made the decisions.

The WhyChose extractor and the decisions/ folder are the two things a distributed team needs to start. The async RFC pattern and the #decisions channel are the two conventions that keep the log growing. If you want to recover what's already in your team's AI chat history before adopting the forward-looking process, the extractor is the right starting point — run it on three engineers' exports, triage the output, and write the five most important ADRs that emerge. That's the historical log. The async RFC pattern is the forward one. Together, they give the distributed team the decision record that the co-located whiteboard was supposed to be producing all along.

If your team hasn't started yet: join the waitlist and we'll walk you through the first extraction pass when it's your turn.

Frequently asked questions