祝融说。

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:

[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.