Day 18 · 2026.06.07

Async 文化与文档优先:把会议从默认变成例外

主题:Async Culture & Documentation-First·4 个原则
"A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in." — Paul Graham
本周的命题:同步会议是大公司里最贵、也最被滥用的资源。一场 8 人 1 小时的会,是 8 个工时——还不算被切碎的整块时间。文档优先(doc-first)不是少开会的技巧,是一种把"思考"和"广播"分离的组织设计:先把决定写清楚,让人异步读、异步评,会议只用于真正需要高带宽的事——冲突、模糊、共情。本周四个原则:用一页备忘录代替一场会、用 RFC 让决定在写作中成型、用 ADR 给未来留下"为什么"、以及如何系统性地削减会议负荷。这不是远程团队专属——它对任何被会议淹没的 tech lead 都成立。
PRINCIPLE 01

写作优先:用一页备忘录代替一场会 Writing-First — The Memo Over The Meeting

文档优先叙事备忘录默读
重要的决定先写成文档再开会。写作强迫你把模糊的想法逼成清晰的逻辑——PPT 可以靠口才蒙混,一页连贯的叙事不行。会议是用来"读后讨论"的,不是用来听人念稿的。
"The reason writing a good four-page memo is harder than 'writing' a twenty-page PowerPoint is because the narrative structure of a good memo forces better thought and better understanding of what's more important than what." "写好一份四页备忘录比'写'二十页 PPT 更难,因为好备忘录的叙事结构会逼出更好的思考、更清楚地分辨什么比什么更重要。" — Jeff Bezos,《Amazon 2017 致股东信》
情境:你要推动一个架构迁移决策,约了 8 个 stakeholder 开 1 小时评审会。
✗ 常见做法

你做了 20 页 slides,会上逐页讲。前 40 分钟在念背景,最后 10 分钟才到关键 trade-off——但时间没了。一半人没读过背景,全程在跟你的口播节奏,真正的异议根本没机会浮出来。散会时"看起来达成了共识",一周后三个人各做各的。

✓ Amazon "study hall" 式

会前:写一份 4 页叙事备忘录(背景 → 方案 → 被否决的替代方案 → 风险 → 待决问题),提前 24 小时发出。

开场:"我们先静默读 15 分钟,边读边在文档里批注。读完我们直接进入有争议的地方。"

效果:所有人在同一信息基线上。会议 60 分钟全花在 trade-off 和异议,而不是信息广播。批注还成了天然的决策记录。

  • 背景/问题:不懂这块业务的人读完能明白"为什么现在要做"吗?
  • 提案:一句话能说清"我们建议做什么"吗?
  • 被否决的替代方案:有没有写"为什么不选 B 和 C"?(最容易被略,却最有价值)
  • 风险与待决问题:诚实列出未解决的点,而不是只报喜。
  • 没有 PPT 也能独立读懂吗?文档要能脱离讲解者存在。
  • 把 slides 转成"文档"。项目符号堆砌不是叙事。要写完整的句子和段落,逻辑才暴露。
  • 会前发文档但没人读。所以要"会上默读"——不假设人读过,给出读的时间。
  • 用文档掩盖没想清楚。doc-first 的痛点恰恰是:写不清说明你没想清,这正是它的价值。
  • 为小事也写长文。双向门、可逆的决定一条 Slack 就够,别教条。
Female Leader's Note 研究反复显示,会议中女性更容易被打断、被抢功(idea 被复述后归到男性同事名下)。书面文化是一种结构性的纠偏:想法写在文档里、带署名和时间戳,谁先提出一目了然,不靠谁嗓门大。作为 leader,你可以刻意强化这点——在会上引用时点名出处:"这个方案是 Priya 在文档第 2 节提的,我们顺着她的思路。"把功劳锚定在文字上。
Jeff Bezos,《Amazon 2017 致股东信》— 六页叙事备忘录与"禁用 PPT"、会议默读机制的来源。
Camille Fournier,《The Manager's Path》— 强调写作是 senior 工程领导的核心杠杆。
PRINCIPLE 02

RFC 文化:让决定在写作与评论中成型 RFC Culture — Decisions That Form In The Open

RFC设计文档异步评审
RFC(Request for Comments)/ 设计文档是一份公开、可异步评论、有明确生命周期的提案。它把"少数人在会议室拍板"变成"全员可参与、留痕的决策过程"——也是规模化对齐的最低成本方式。
"The most important section… is the one that describes considered alternative designs and trade-offs. Many design decisions are easier to understand when reading about which alternatives were explored and why they were not chosen." "最重要的章节……是描述'考虑过的替代方案与取舍'的那一节。很多设计决策,只有读到'探索了哪些替代、为什么没选'时才真正好懂。" — Malte Ubl,《Design Docs at Google》(2020)
Draft 起草 评论期 异步批注·限时 Decided 明确拍板人 实施 链接到 ADR 归档 可检索 关键:评论期要"限时",否则永远停在草稿
情境:一位高级工程师堵在你门口要口头说服你采用某个新框架。
✗ 当场口头拍板

你被他的热情说服,会上点头"听起来不错,做吧"。两周后另外两个团队跳出来说有冲突——因为他们从不知道这件事,决策没有任何痕迹可追。

✓ 引导进 RFC 流程

"这值得认真做。写成一页 RFC:问题、你的方案、你考虑过又否决的两个替代、对其他团队的影响。开评论 3 个工作日,@上 Platform 和 Data 两个组。"

"如果三天后没有 blocking 异议,我们就 approve。这样比你说服我一个人更稳——你是在说服所有受影响的人,而且留了痕。"

  • 标题 + 一句话摘要:扫一眼就知道在提什么。
  • 明确的 评论截止日拍板人(DRI),不是"大家看看"。
  • "考虑过的替代方案"独立成节——这是 RFC 价值最高的部分。
  • 显式 @ 所有受影响的团队,而不是默认他们会发现。
  • 决定后状态改为 Decided,并链接到对应的 ADR / 实施 ticket。
  • RFC 没有截止日。评论期无限延长 = 决策瘫痪。doc-first 不等于慢,要限时。
  • 没有 DRI。"大家觉得呢"导致没人负责,最后还是回到会议室。
  • 把 RFC 当审批盖章。如果异议永远被忽略,第二次就没人认真评论了。
  • 所有事都要 RFC。RFC 留给"架构上重要"或"跨团队"的决定,琐事别套流程。
Malte Ubl,《Design Docs at Google》(2020)— 设计文档结构,尤其"替代方案"一节的论述。
Will Larson,《An Elegant Puzzle》— 用 RFC 与架构评审在 hypergrowth 中维持一致性。
PRINCIPLE 03

决策记录 ADR:给未来的人留下"为什么" Decision Records — Capturing The Why

ADR决策日志机构记忆
代码记录"做了什么",ADR(Architecture Decision Record)记录"为什么这么决定、当时的上下文、放弃了什么"。半年后没人记得为何当初不选另一条路——ADR 就是组织的防遗忘机制。
"We will keep a collection of records for 'architecturally significant' decisions… Each record describes a set of forces and a single decision in response to those forces. We will keep ADRs in the project repository." "我们为'架构上重要'的决定保留一组记录……每条记录描述一组当时的约束力,以及针对它们做出的一个决定。ADR 就放在项目代码库里。" — Michael Nygard,《Documenting Architecture Decisions》(2011)
情境:半年前你们决定不用 Kafka 而自建一个轻量队列。今天新来的 staff 工程师在群里质疑"这明显该用 Kafka,谁拍的脑袋?"
✗ 没有记录

没人记得完整理由。你凭记忆辩护,听起来像事后找补;团队开始怀疑当初的决定,甚至有人想推翻重做——把已沉没的成本又翻一遍。

✓ 有 ADR 可指

"看 ADR-014。当时的约束:团队 3 人、消息量 < 1k/s、运维 Kafka 的人力为零。在那个上下文下自建是对的。"

"现在量级变了,欢迎写一条新 ADR 取代它——但要基于今天的约束论证,而不是说当初蠢。" ADR 把争论从"谁错了"拉回"约束变了吗"。

  • Context(上下文):当时的约束、规模、人力、时间压力——最关键的一节。
  • Decision(决定):我们决定做什么,一句话讲清。
  • Consequences(后果):这个决定带来的好处、代价、我们接受的风险。
  • Status(状态):Proposed / Accepted / Superseded by ADR-XXX。
  • 编号 + 放进 repo(不可逆的决定才值得写,可逆的别写)。
  • 只记结论不记上下文。"我们用 Postgres" 毫无价值;"3 人团队、需事务、团队最熟 Postgres" 才有价值。
  • 写完就改。ADR 是不可变的——决定变了写新的并标 superseded,而不是改旧的,否则历史就丢了。
  • 追求完美格式。5 行的 ADR 也远胜于没有。门槛越低越有人写。
  • 给鸡毛蒜皮立 ADR。只记"架构上重要"的——会影响结构、依赖、难逆转的决定。
Michael Nygard,《Documenting Architecture Decisions》(2011)— ADR 概念的原始出处。
Will Larson,《An Elegant Puzzle》— 将决策记录纳入工程组织的运行机制。
PRINCIPLE 04

削减会议负荷:把同步当昂贵资源 Cutting Meeting Load — Sync As A Scarce Resource

Async 默认Maker Schedule减会
默认 async,会议是 escalation 而非 default。同步只用于真正需要高带宽的事:冲突、模糊、情感、头脑风暴。能写清楚的事就别开会——开会前先问"这能不能是一份文档"。
"When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in." "当你处于创造者时间表上时,会议是灾难。一场会就能毁掉整个下午——把它切成两半,每半都小到做不成任何难事。" — Paul Graham,《Maker's Schedule, Manager's Schedule》(2009)
有人想约会议 先别接受 需要高带宽吗? 冲突/模糊/共情/脑暴 否 → 写下来 文档 / RFC / Loom 异步评论解决 是 → 开会 有议程·有预读 最少人·定结论
情境:你团队的日历被会议填满,工程师抱怨没有整块时间写代码。
✓ 系统性减会动作

1. 设无会日:"周三全天 No-Meeting Day,团队所有人。我先把自己的清掉做示范。"

2. 砍经常性会议:"所有 recurring 会先取消两周,谁真的需要谁再加回来。" 多数不会被加回。

3. 状态走异步:"每日 standup 改成异步——早上在 channel 发三行:昨天/今天/阻塞。只有阻塞才触发同步。"

4. 立规矩:"约会议必须带议程和预读,没有就有权拒绝参加。"

  • 这场会有没有可以替代它的文档?(先写,写不清再开)
  • 每场会都有议程 + 预读 + 明确的"会议要产出什么"吗?
  • 受邀人是真需要,还是"以防万一拉进来"?砍到最少。
  • 有没有保护团队的整块时间(无会日 / 核心专注时段)?
  • recurring 会议有没有定期清零、按需重建?
  • 把 async 当"永不同步"。冲突、敏感反馈、共情时刻,硬走文字反而冷漠且低效。async 是默认,不是教条。
  • 减了会却把负担转成"随时 ping"。把同步会换成全天 Slack 轰炸,专注时间一样被毁。async 要尊重"不必即时回"。
  • 无会日只是嘴上说。你自己第一个破例,规矩当天作废。
  • 砍掉 1:1。1:1 是关系与信任,不可异步化(见 Day 1)。要砍的是状态会。
Female Leader's Note "office housework"——记会议纪要、定会议室、追进度——长期不成比例地落在女性身上,且很少转化为晋升资本。转向书面/异步文化时要顺手修掉这个分配:让文档 DRI、记录者按角色轮值(写进流程,不靠"谁主动"),而不是默认让团队里那位女性"顺便记一下"。把隐形劳动显形、可轮换,本身就是公平设计。
Paul Graham,《Maker's Schedule, Manager's Schedule》(2009)— 整块时间为何对创造者至关重要。
Jason Fried & DHH,《It Doesn't Have to Be Crazy at Work》— "会议是最后手段"与异步默认文化。
GitLab Handbook— "handbook-first":默认把一切写下来的极致实践。

本周习作 · Your Day 18 Action

本周做一件具体的事,不是反思也不是阅读:

选你日历上一场本周的经常性会议(最像"状态广播"的那场)。这周把它替换成一份异步文档:会前发出,给 24 小时异步评论,到点只对"还有争议的批注"开一个 15 分钟短会(或干脆不开)。

会后记两行:(1) 实际花的同步时间从多少分钟降到了多少;(2) 决策质量更好还是更差

反思题:你团队里有哪些会,其实是在用同步时间补偿"没人愿意把事写清楚"?

深入思考

doc-first 在"读写文化弱、英语非母语为主"的团队会失灵吗?
会显著变难。叙事备忘录对写作能力有要求,强行推行可能让表达弱但技术强的人吃亏,也可能放大母语者的优势。对策不是放弃,而是降门槛:提供模板、接受 bullet + 短视频(Loom)混合、用 AI 辅助润色、明确"评的是内容不是文采"。文化要渐进培养,而非一刀切。
异步过头会不会牺牲掉"弱关系"和偶然的信息流动?
会。走廊偶遇、会前闲聊催生的是创意碰撞和信任——纯异步会把组织变成高效但疏离的机器。所以 async 是默认而非全部:刻意保留少量高带宽场合(团队 social、脑暴会、不设议程的漫谈),用同步去做异步做不好的事:建立关系、处理情绪、激发创意。
在一个"开会=刷存在感、文档没人读"的政治化大公司,单个 tech lead 推 doc-first 现实吗?
自上而下推全公司不现实,但在自己团队边界内可行。策略:先在你能控制的范围做出样板(你的会都带预读、你的决定都有 ADR),用结果说话;向上时把文档当向上管理工具(老板更爱读一页 memo 而非被拉进会)。文化是局部示范扩散的,不是一纸政令。
RFC/ADR 的维护成本会不会最终变成"文档债",没人更新形同虚设?
真实风险。关键区分:ADR 是不可变的历史快照,本就不该更新(决定变了写新的),所以它几乎没有维护成本——这是它优于"活文档"的地方。会变成债的是那些试图"始终保持最新"的活文档。原则:能用不可变记录(决策、会议纪要)就别用活文档;活文档要指定 owner 和复审节奏,否则宁可不建。
削减会议会不会反噬 manager 自己的影响力("开会"也是被看见的方式)?
这是诚实的灰色地带。在很多组织里,出现在会议室=政治资本,纯异步工作的人可能"隐形"。成本是真实的:你可能高效但不被高层注意到。务实的平衡——把省下的时间投入少数高杠杆的同步场合(关键评审、跨部门、向上汇报),在那里高质量地"被看见";同时让你团队的产出(文档、决策记录)本身成为你影响力的证据。不必为刷存在而开会,但也别天真地以为纯产出会自动被看见。