十个人的时候，很多事没有机制也照样运转：谁在做什么，抬头问一句就知道；一个决定，午饭时三个人碰一下就定了；新来的两周就摸清了全部约定。人长到三十，这套做法会同时失效，而且失效得很安静——没有人辞职，没有事故爆发，只是同样的活开始变慢、开始反复、开始有人反复做同一个判断。
真正失效的不是人，是机制。机制不是写在 wiki 里的流程，而是"当负责人不在场时，事情仍然按某个确定方式发生"的那部分结构。十人规模的结构大多长在人身上：记忆、关系、默认信任。人数一旦超过共同上下文的容量，这些人身上的结构就从资产变成单点。
一个粗糙但有效的判据：一件事的正确做法如果只存在于某个人脑子里，它在十人时是效率，在三十人时是风险。
1. 十人以内真正在起作用的三件事
不是"管得好"，而是三件隐式机制在兜底。它们在三十人时全部反转，而且反转的方向一致：从"覆盖全员"变成"覆盖一部分"。
| 隐式机制 | 十人时为何有效 | 三十人时的失效形态 | 可观测信号 |
|---|---|---|---|
| 口头同步 | 同一房间，一句话覆盖全员 | 靠转述衰减，二次传播丢条件 | 同一问题被不同人问到第三遍 |
| 共同上下文 | 每人多少知道系统全貌 | 只有少数人知道全貌，判断开始分叉 | 同一规则在两处有两种实现 |
| 默认信任 | 谁靠谱一目了然，不必验证 | 无法逐一观察，信任退化为印象 | 产出质量靠"感觉"评价 |
三件事的失效顺序不一样，这个时间差最容易造成误判。口头同步最先断，因为它依赖空间——不在同一间屋子就传不到；共同上下文随后被稀释，因为新人对系统的了解永远滞后于系统本身；默认信任衰减最慢，因为它靠长期相处积累的印象。于是会出现一种典型场景：信息其实已经断了，信任还在，团队继续用"他很靠谱"解释交付延误，而不是去查机制。
把这三件事逐项落到人头上，失效点会立刻显形：
─── 隐式机制盘点（每项填"在谁身上"）───
决策默认人 ：______ 可替代人：______
系统全貌 ：______ 书面版本：有/无
发布前的隐性检查 ：______ 是否成清单：是/否
新人上手路径 ：______ 是否可自助：是/否
异常升级对象 ：______ 第二顺位：______
// 出现三个以上空位，说明机制仍长在人身上
2. 四类机制：换什么、按什么临界点换
换机制不是换工具，是把"依赖在场"改成"依赖结构"。四类机制各有自己的临界点，到了就换；早了是过度设计，晚了就是把风险留给某个人。
| 机制类别 | 十人的形态 | 三十人的形态 | 临界点判据 |
|---|---|---|---|
| 决策 | 共识：说通了就定 | 授权：写明谁定、定到哪 | 同一决定一周内被问到第三次 |
| 信息 | 广播：群里发一遍 | 可检索记录：写下来、查得到 | 有人因"没看到"而做错 |
| 协调 | 直接找人：谁有空谁上 | 明确接口：谁给谁交什么 | 一件事要三方以上口头对齐 |
| 评估 | 观察：我看着你干 | 可观测产出：可核对的交付物 | 评价需要回忆而非查记录 |
决策这一格最容易被拖过。共识在十人时便宜，因为参与者共享同一份上下文；三十人时参与者变多，而每多一个人的信息增量急剧下降——会议从"对齐"滑向"背书"。授权不是不信任，是把决策频率从"每次走一遍"降到"只在例外时走一遍"。
信息和协调这两格的临界点常被误判成"有没有文档""有没有流程图"。真正的标志是可验证的：信息机制换代的标志，是新人只靠搜索就能完成第一次改动；协调机制换代的标志，是两个组不约会议也能完成一次交接。验证方式很省：找一件真实的小事，让一个不熟悉的人只靠记录走完，卡在哪一步就是哪一步没换。
评估这一格最晚换，也最容易被跳过。十人时"我看着你干"是真的有效，因为观察成本接近于零；三十人时观察变成抽查，抽查又依赖印象。它换代的标志很朴素：评价一个人时，你是去查记录，还是在回忆。
授权要落在纸面上，落进仓库而不是群公告：
─── 决策权声明 ───
决定事项：单服务发布窗口的最终确认
决策人 ：______（单人姓名，不写"团队"）
授权范围：单服务、非跨团队、可回滚
升级条件：涉及对外承诺 / 数据迁移 / 资金支出
记录位置：docs/decisions/______.md
写"团队"是最常见的错误：责任落到一个不存在的实体上，等于没有决策人。
3. 最常见的崩法：招人快过机制
增长的顺序错了。人先到，机制后建，中间那段时间由老人做缓冲——他既写代码，又当接口，又做评审。看起来团队还在运转，实际上所有协调都压在同几个人身上。等他撑不住，问题一次性暴露，事后看起来像"某人离职导致崩溃"，本质是机制建设被增长甩开了。
中间层是这段缓冲期的常见解法，但它有自己的代价：
// 引入中间层的判据（满足两条再设）
1. 直接汇报人数连续两个月 > 7
2. 负责人每周协调类时间占比 > 30%（按日历核，不靠回忆）
3. 出现"只有他能决定"的事项超过 3 类
─── 中间层的代价 ───
信息过滤：向上汇报省略细节，向下传达省略背景
决策上移：本来能定的事重新回到上一层
责任分散：出问题归因于"沟通不畅"，无人认领
// 反向判据：若协调成本主要来自不确定性而非人数，加中间层无效
最后一条判据最容易被忽略。团队人数不多但方向反复变，协调成本也会很高，此时的解法是缩小不确定性（明确目标与边界），而不是加一层人。
换代要排期，一次只换一类，否则失效原因无法归因：
─── 换代排期（按季度排，同期只动一类）───
Q1 信息：决策台账 + 新人上手路径
Q2 协调：接口清单（谁给谁交什么、什么时候交）
Q3 决策：授权声明（含升级条件与记录位置）
Q4 评估：可核对交付物的定义
// 同期换两类以上，出问题时分不清是哪一类引起的
4. 四个数，和一句确认信号
"我们还像以前一样"这句话出现时，通常不是现状描述，而是对旧机制的怀念。它常伴随具体抱怨：还要问一下、还得拉个群、又开了个会。这句话是机制失效的确认信号，不是安慰。
把抱怨换成四个可采集的数：
| 度量 | 采集方式 | 典型量级（按规模核对） | 恶化方向 |
|---|---|---|---|
| 决策等待时长 | 决策台账：提出日 → 结论日 | 十人时以天计，三十人时以周计 | p90 拉长 |
| 跨组协调次数 | 每周跨组对齐的人次 | 随接口数增长，非线性 | 单人占比过高 |
| 新人上手时长 | 入职到独立交付首个小需求 | 十人时以周计，三十人时以月计 | 中位数上升 |
| 信息重复询问率 | 同一问题被问次数 / 问题总数 | 超过两成即异常 | 上升 |
决策等待时长可以直接从台账算，不必上系统：
// decisions.csv: 提出日,结论日,决策人（日期已转 epoch day）
$ awk -F, 'NF>=3{print $2-$1}' decisions.csv | sort -n \
| awk '{v[NR]=$1} END{print "n="NR, "p50="v[int(NR*0.5)+1], "p90="v[int(NR*0.9)+1]}'
信息重复询问率更简单：把重复问题记在同一个文件里，按周统计出现次数，连续两周上升，说明记录位置不对，而不是人记性差。
四个数不必都上仪表盘。决策等待时长与重复询问率可以手工维护，成本是每周十几分钟；跨组协调次数从日历里数即可；新人上手时长只需要记住第一次独立交付的日期。先手工跑一个季度再考虑自动化——很多团队在度量工具上投入的力气，超过这四个数本身的价值。
5. 排错：机制换了但没起效的五种情况
| 现象 | 机制层原因 | 处置 |
|---|---|---|
| 写了流程但没人看 | 记录位置不在工作路径上 | 挪到 PR 模板、发布脚本、告警链接旁 |
| 授权了但事仍上收 | 判据没给，被授权者不敢定 | 补"什么情况必须升级"的清单 |
| 加了中间层更慢 | 中间层只转发不决策 | 明确它可独立决定的事项范围 |
| 新人上手仍慢 | 文档描述"是什么"未描述"怎么改" | 补一个可跑通的最小改动路径 |
| 度量数字好看但体感差 | 指标选在易采集处而非痛处 | 换成等待时长与重复询问率 |
第一条是通病：文档放在 wiki 深处，等于没写。机制的有效性取决于它是否出现在"人必然经过的那一步"。
6. 边界：什么时候不必急着换代
| 场景 | 机制换代的紧迫性 | 理由 |
|---|---|---|
| 人数增长但模块完全独立 | 下降 | 协调面没扩大，接口成本不变 |
| 已有强文档文化 | 下降 | 信息机制已从人身上搬到记录上 |
| 临时项目组（有明确解散日） | 下降 | 机制投入周期长于团队寿命 |
| 人数翻倍且共享同一代码库 | 上升 | 决策与协调同时受压 |
| 核心成员同时离开 | 上升 | 隐式机制的唯一载体消失 |
三种下降情形都不是"不用管"，而是"可以先换信息机制，把决策与评估往后放"。换代的顺序有讲究：先信息（最便宜、收益最广），再协调（接口化），再决策（授权），最后评估（可观测产出）。评估放最后，因为它的前提是前三条已经产出可核对的东西。
7. 自测
- 十人时有效的三件隐式机制，各自在三十人时的失效形态是什么？
- 决策从共识转向授权，最可靠的临界点判据是哪一条？
- 为什么授权声明里写"团队"等于没有决策人？
- 中间层引入的反向判据是什么，它对应哪类问题？
- 机制换代的推荐顺序是什么，评估为什么排最后？
- 哪三种情况下，机制换代的紧迫性反而下降？