# Chapter 30: Asynchronous First, Public by Default

## Lesson objectives

- **O1** Can state the input-output order of asynchronous record, default visibility and sensitive exception (artifact: async collaboration decision log)
  - Evidence: The async collaboration decision log connects asynchronous record, default visibility and sensitive exception in input-output order
- **O2** Can construct a async collaboration decision log with an owner and completion rule at every step (artifact: async collaboration decision log)
  - Evidence: Every step in the async collaboration decision log states its owner, input, output and completion rule
- **O3** Can handle a sensitive exception through asynchronous records and default visibility (artifact: async collaboration decision log)
  - Evidence: The artifact contains one asynchronous decision, visibility scope, sensitive exception and review date

## Learning paths

- **Novice**: Chapter transfer task: Can handle a sensitive exception through asynchronous records and default visibility. Use the diagram's flow relationship to complete the first evidence item in the async collaboration decision log, then check each owner and decision rule.
- **Experienced**: Apply this task to a current project before reading the explanation: Can handle a sensitive exception through asynchronous records and default visibility. Submit the async collaboration decision log, then check the relationship type, missing evidence and authority boundary.

## Teaching diagram

- **Required artifact**: async collaboration decision log
- **Diagram kind**: async-public-flow
- **Relationship semantics**: The three steps connect through one-way inputs and outputs; each must create a reviewable input for the next and end with an exit decision.
- **Core concepts**: asynchronous record · default visibility · sensitive exception

![Chapter 30 teaching diagram for the async collaboration decision log](/learning/diagrams/en/chapter-30.svg)

Follow the async collaboration decision log through inputs and outputs and inspect evidence at every exit, not only the final result.

The diagram connects asynchronous record, default visibility and sensitive exception from left to right. Each arrow means one output becomes the next input. Every step needs an owner and completion rule; missing exit evidence causes rework or a stop.

> **Adapted public course.** Concepts, procedures and examples are adapted from the internal textbook. Case sizes, timings, improvement figures and target thresholds are illustrative, not site delivery results or universal standards. Verify tools, platforms and skills in your environment. Prompts do not grant permissions and retry counts do not authorize recovery. Preserve work and verify targets, sharing and external-state effects first.

## Lesson explanation

### 30.1 Farewell to "Are You There?": From Synchronous Communication to Asynchronous Collaboration

"Hey, are you free right now? Let's grab a meeting room and sync up quickly." -- This is the "master key" for solving problems in the office. It looks efficient, but hidden behind it is a huge implicit cost: it interrupts other people's state of focus (flow), forces everyone into the same time rhythm, and the conclusions of a meeting are usually spoken aloud, making them extremely easy to forget or distort.

When we bring this habit online, it turns into "pulling people into a video meeting anytime, anywhere." As a result, everyone's calendar is chopped to pieces by assorted "15-minute quick sync meetings" -- most of the day is spent either in meetings or on the way to preparing for one. To wait for half an hour of a single key person's time, the whole project team may have to come to a standstill for half a day.

This overdependence on "synchronization" is the single greatest killer of remote collaboration efficiency. It assumes that everyone's time is a cheap resource that can be interrupted and requisitioned at will.

The logic of the office is: the fastest way to solve a problem is to get everyone in one room. The truth of remote work is: synchronization is expensive, and asynchrony is the norm. Protecting large, uninterrupted blocks of focus time for every member is the lifeline of the team's overall output.

The "asynchronous first" principle: by default, communication should happen asynchronously -- using documents, task cards, messages, and code comments to convey information, letting each person respond at their own pace instead of interrupting in real time. Synchronous communication (meetings, voice calls, real-time IM) is reserved only for scenarios that genuinely require real-time interaction: brainstorming, urgent incidents, and conflict resolution.

Three practical guidelines for asynchronous communication:

1. Write it down first, then call the meeting: for a discussion that needs multiple participants, first write it up as a structured document (background, options, viewpoints) so everyone can read and comment asynchronously. If discussion is still needed after reading the document, then organize a meeting -- at that point the meeting is already focused on the genuine points of disagreement, rather than syncing up background from scratch.
2. Turn "are you there?" into complete information: don't send empty messages like "are you there?" Give the full question, background, and context directly, so the other person can understand and respond in one go. Your message should be "self-contained."
3. Respect focus time: by default, assume your colleagues are doing deep work. Use asynchronous channels for non-urgent matters; only genuinely urgent matters (online outages, production incidents) warrant an immediate interruption.

### 30.2 Information-Saturating Communication: Don't Assume Others Know; Assume They Don't

There is a curious phenomenon in the office called "information osmosis" or "osmotic learning of knowledge" -- you overhear two colleagues at the next desk discussing something and learn the progress of a new feature; while getting water in the break room, you hear next quarter's plans from the product manager; at lunch, you learn about a hidden bug in some module from the QA folks.

We once thought this was an efficient way to synchronize information. But remote collaboration ripped away this warm, comforting veil and exposed its essence: it is an extremely unfair, extremely unreliable random event that easily creates information gaps. In remote mode, there is no corridor and no break room. The communication that relied on "chance" disappears entirely. As a result, information begins to flow rapidly toward a few core nodes, and the team quickly splits into the "information-rich" and the "information-poor."

The rule for fighting information gaps is "information-saturating communication": don't assume others know; assume they don't.

This means:

1. Complete the context by default: when you describe a problem or make a request to a colleague, don't assume they know the backstory. Pass along the necessary background, decisions, and history all at once, saturating the recipient with it.
2. Write context into every artifact: write the "why" and "background" clearly in task cards; write "what changed, why it was changed this way, and how to verify it" clearly in PR descriptions; write "the full story behind this decision" clearly in documents.
3. Redundancy is good: it is better to write one extra sentence of seemingly superfluous background than to let the recipient misunderstand due to missing context. The cost of redundant information is far lower than the rework caused by omitted information.

An example of high-quality information-saturating communication:

<!-- code-example:chapter-30-E1 mode:reference -->
> **Example type: reference.** Reference fragment; it is not guaranteed to run alone. Adapt it to the lesson context, project versions and real interfaces, then validate with observed output.
```text
[Task] Add a "user labels" feature for the customer-service team.
[Background/Why] Customer service currently cannot distinguish high-value users,
users at risk of churn, and newcomers. Broad-brush communication strategies are
lowering user satisfaction. We want more precise user segmentation.
[Goal] After launch, reduce monthly churn among high-value users by 5%.
[User scenario] After speaking with a new user who has just completed their first
order, customer-service representative Xiaoming can add a "First order completed"
label on the user's detail page. Next week, operations can use that label to
target coupon offers.
[Functional requirements] ...
[Acceptance criteria] ...
```

Help requests should likewise include the environment, symptom, attempts already made, and a clear question; Chapter 32 contains the full npm dependency-conflict counterexample and revision.

### 30.3 The Value of Public Channels: Let Information Flow, Let Consensus Emerge

Default to Public is the second principle that remote teams must uphold. It means that, by default, information should flow into public, team-visible channels rather than private chats and emails.

Why is public so important?

1. Let information flow: private chats are the makers of information silos. If a key decision is made in a private chat, everyone else loses the right to be informed and to participate. Public channels let information flow naturally through the team.
2. Let consensus emerge on its own: when discussions happen in public channels, different viewpoints collide in the conversation, and the consensus that finally forms is one "seen and endorsed by the whole team," not one "privately agreed upon by a few people."
3. Become team assets through accumulation: the discussion records of public channels naturally become part of the team's knowledge base; newcomers can trace the history and understand the full story behind decisions.
4. Eliminate duplicated effort: the problem you just solved may be the very pit someone else is falling into right now. Public sharing turns every problem solved into a team asset.

Practical guidelines for public channels:

- If it can be public, don't use private chat: project discussions, technical proposals, and progress syncs go into the team's public channels by default;
- Private chat is only for: personal matters, one-on-one sensitive feedback, and initial contact for urgent coordination (but the eventual conclusion still needs to be recorded in a public channel);
- Conclusions must flow back: even if a problem is resolved in private chat, sync the conclusion to a public channel or document so no information is lost.

"Asynchronous first + default to public + information-saturating communication" together form the "operating system" of remote collaboration. They are not three isolated suggestions but a self-consistent system: asynchronous first protects everyone's focus time; default to public ensures the flow of information and the formation of consensus; information-saturating communication makes every asynchronous exchange efficient and self-contained enough.

### 30.4 Boundary: The On-Site Exception

The principles in this chapter govern collaboration inside your own team: both parties are assumed to share a team culture, and you can help set the collaboration rules. The FDE's defining setting, however, is work on site with the customer (Chapters 1 and 27). There you are a guest: trust is still forming, tacit information is dense, and you cannot dictate the customer's collaboration culture. On-site work therefore relies mainly on synchronous, intensive interaction: sitting beside users to see obstacles, learning crucial information in hallway conversations, and building trust face to face. Making "write a document and leave me a message" the default there forfeits the value of being on site. The reverse does not follow either: daily customer meetings are no reason to bring that synchronous rhythm back to your own team. Asynchronous collaboration is the internal default; the on-site phase is mainly synchronous. Neither setting determines the other's rules. Chapter 28 covers when presence is essential, when asynchronous work is possible, and how to work with stakeholders on site.

---

## Independent exercise

Use fictional or authorized deidentified material. Answer independently before revealing the reference. Save `chapter-30.md` with versions, decisions, evidence and gaps.

Write an update with context, decisions, evidence, blockers, owner and next update time. Identify material that cannot be public by default.

<!-- chapter-artifact-requirement -->
### Required chapter artifact: async collaboration decision log

The submission for this independent exercise must contain the evidence below. The existing prompts supply content but do not replace these acceptance items.

- O1: The async collaboration decision log connects asynchronous record, default visibility and sensitive exception in input-output order
- O2: Every step in the async collaboration decision log states its owner, input, output and completion rule
- O3: The artifact contains one asynchronous decision, visibility scope, sensitive exception and review date

<details>
<summary>Reveal reference feedback (answer first)</summary>

## Reference feedback

Include versions, failing fixture IDs and check locations so another engineer can reproduce. Raw customer data, accounts and personal information belong only in approved spaces. Default visibility is within authorization; incidents or major ambiguity may require synchronous communication and a decision record.

### Self-review and next steps

Check whether your decision is explicit, evidence reproducible and unknowns honestly recorded. The reference illustrates one defensible approach, not a unique answer. Seek peer review for alternatives with equivalent evidence. Mark unsupported parts unfinished and revisit the corresponding step.

</details>

## Sources and boundaries

Registered sources support only the external claims used here. The async collaboration decision log, example numbers and exercise scenario are internal instructional design and require project-specific validation.

- [The Twelve-Factor App: Logs](https://12factor.net/logs) — Adam Wiggins, 2026-09-17. Application logs can be treated as time-ordered event streams captured and routed by the execution environment.