团队变大的第一个症状，往往不是活干不完，而是所有决定都要等一个人拍。那个人未必是控制欲强，他只是最早知道全貌的人；十个人时等他三分钟，三十个人时等他三天。瓶颈的位置不在他的能力，而在决策频率的分布：高频的小事和低频的大事挤在同一条队列里。
下放的不是权力，是决策频率。权力是名义上的，频率才是真实成本。一件事每周发生二十次，每次都要上收，成本是二十次等待；一件事一年发生一次，上收的成本可以忽略。所以判断该不该下放，先看频率，再看后果。
两个维度交叉，处置就清楚了：可逆且影响有限的事，下放；不可逆或跨团队的事，上收。中间地带用机制补齐，而不是靠"看情况"。
1. 两个维度，四格处置
| 可逆性 \ 影响范围 | 单团队内 | 跨团队或对外 |
|---|---|---|
| 可逆（当天能退） | 完全下放，备案即可 | 边界下放：写明触发升级的条件 |
| 不可逆（迁移、删除、承诺） | 上收，但给出判据与时限 | 上收，且必须留下决策记录 |
四格的实际用法是"先定位再决定"，而不是"先问领导"。定位靠两个问题：做错了能不能当天退回去；影响会不会溢出到别的团队。两个问题都能自己回答，这就是下放的第一步——把分类权先下放。
队列理论在这里很好用：决策等待时间由队列长度和服务速率决定，跟单个决定的难度关系不大。高频小事挤在队列前面，会把低频大事一起拖慢，于是团队感受是"所有事都慢"。切开这两条队列，比提高任何一项决策的质量都更有效。
台账是这条链路的底座。没有台账，"高频"只是感觉，"上收比例"无从计算：
// decisions.csv: 提出日,结论日,决策人,事项,可逆性,影响面
2026-03-02,2026-03-03,zhang,发布窗口调整,可逆,单团队
2026-03-04,2026-03-18,li,分库方案变更,不可逆,跨团队
// 一行一次决策；缺"可逆性"列，后面所有统计都做不了
2. 不能下放的四类，和下放的三种形态
不放的四类有共同的底色：代价不由做决定的人承担。
- 不可逆：数据迁移、删除、一次性对外动作。可逆性一旦消失，试错成本就转成了修复成本。
- 跨团队影响：一边的决定变成另一边的约束，被影响方不在决策房间里。
- 对外承诺：时间点、SLA、价格。承诺的成本落在客户关系上，不在代码里。
- 资金与合规：支出、合同、数据出境。这类决定通常还有外部审计链，下放会断开证据。
其余的下放，形式上有三种，责任归属完全不同：
| 形态 | 被授权者能做什么 | 责任归属 | 适用 |
|---|---|---|---|
| 完全授权 | 自行决定，事后记录 | 授权者承担结果 | 高频、可逆、单团队 |
| 边界授权 | 在给定边界内自行决定，越界升级 | 边界内授权者担，越界后决策者担 | 有明确参数空间的决策 |
| 备案授权 | 自行决定，但需在事后 N 天内备案 | 被授权者担，异常由备案暴露 | 需要速度又需要可追溯 |
三种形态里最容易出错的是"边界授权"：边界写得含糊，等于完全授权；边界写得太细，等于没授权。边界的正确写法是给出升级触发条件，而不是给出允许清单。
备案授权的"N 天"要短，短到被授权者记得住。常见做法是一个发布周期，超出就没有追溯意义了——备案的价值在于及时暴露异常，而不在于事后归档。备案期太长，等于把复核成本转移到季度末，那时异常早已扩散。
─── 边界授权模板 ───
事项：单服务数据库索引变更
决策人：______（单人）
可直接决定：单表、预估影响行数 < 阈值、有回滚脚本
必须升级：跨表 / 涉及唯一约束 / 需要锁表超过窗口
记录：变更单 + 决策台账一行
复审：每季度看一次升级比例
3. 下放失败的两个原因
原因一：判据没给。被授权者拿到的是"你可以定"，不是"按什么定"。没有判据的授权会把风险原封不动退回来——他要么来问，要么赌一把，两种都不是授权想要的结果。
原因二：能力没跟上。判据给了，但欠缺判断所需的上下文。这类失败常被误读成"他不行"，实际是信息没到位：他不知道下游有谁、不知道历史上的坑、不知道哪个指标会响。
比这两条更隐蔽的是组织成因：决策被推翻的代价太高。一个人按判据做了决定，结果被上级在群里改掉，还附带一句"下次先问一下"。一次这样的经历，足以让整个团队退回"先问一下"。
"先问一下"文化的成本可以粗算，而且往往超出直觉：
// 每周被问次数 × 平均等待时长（小时）× 涉及人数
$ awk -F, '{q+=$2; h+=$3*$4} END{print "周询问="q, "周等待小时="h}' ask.csv
// ask.csv: 日期,询问次数,平均等待小时,平均涉及人数
这个数字不需要精确。算出来是每周几小时还是几十小时，处置方向完全不同：几小时属于摩擦，几十小时说明决策队列已经成了产能瓶颈。
判据文档是解决第一个失败原因的最小投入。它不需要长，只需要能回答"我能不能自己定"：
─── 判据条目（每条必须可自判，不写"视情况"）───
1. 影响面：只涉及本服务的请求路径与配置
2. 可逆性：有回滚脚本，回滚时间 < 发布窗口
3. 数据：不涉及 schema 变更、不涉及历史数据重写
4. 对外：不改接口契约、不改价格与承诺
5. 资金：不产生新的第三方支出
// 五条全过 → 自行决定；任一条不过 → 升级，并写明哪条
4. 授权不等于放任：可查、有据、有复盘
下放之后必须留下三样东西，否则它不是授权，是失联。
| 留下什么 | 载体 | 谁看 | 频率 |
|---|---|---|---|
| 可查 | 决策台账（谁、何时、依据哪条判据） | 任何人 | 随时 |
| 有据 | 判据文档，含升级条件 | 被授权者 | 变更时更新 |
| 有复盘 | 每季度看被推翻率与上收比例 | 授权者 | 每季度 |
追责的边界也在这里划清：授权范围内的坏结果不该追责，因为那是授权者选择承担的风险；没按判据决策、或该升级没升级，才该追。把这两件事混在一起，团队学到的教训是"不要做决定"，而不是"按判据做决定"。
收回授权是合法动作，但要给条件，不能凭一次事故的情绪：
// 收回授权的四个触发条件（任一成立即收，且书面记录）
1. 连续两个季度越界升级率 > 阈值
2. 出现未按判据决策且造成不可逆后果
3. 判据所依赖的前提消失（如团队重组、系统边界变化）
4. 决策频率下降到不再需要独立决策人
─── 收回时同时给出 ───
收回范围（哪一类事项）
恢复条件（满足什么再下放）
过渡期安排（谁临时接）
度量只需要四个数：决策等待时长（提出到结论的自然日）、上收比例（上收决策数 / 总决策数）、被推翻率（被上级改掉的决策占比）、决策分布（各决策人的决策数占比）。前两个看效率，后两个看健康度。上收比例长期上升而等待时长不降，说明上收的不是该上收的那部分。
被推翻率要用来看原因，而不是看高低。如果被推翻的决策大多是"按判据做了但判据本身有漏洞"，要改的是判据；如果大多是"判据没过却自行决定"，要改的是复核方式；如果推翻发生在同一批事项上反复出现，说明那一类根本不该下放。三种情况对应三种完全不同的动作，混在一起处理只会把授权体系一起废掉。
5. 排错：授权了但没生效的五种情况
| 现象 | 真实原因 | 处置 |
|---|---|---|
| 授权后询问量不降 | 判据缺失，被授权者无法自判 | 补升级条件，而不是补培训 |
| 决定被反复改 | 授权者仍在用旧方式复核 | 明确复核只看判据是否符合 |
| 只有个别人敢决定 | 被推翻的代价过高 | 公开一次"按判据做错不追责"的案例 |
| 边界授权退化为完全授权 | 边界写成允许清单且未设升级条件 | 改为触发条件式边界 |
| 上收比例升高但速度没变 | 上收的是高频小事 | 按频率重排四格归类 |
第一条最常被误判。询问量不降时，团队的第一反应往往是培训，但培训解决的是能力，判据缺失解决的是信息。判据补上，询问量通常在一两周内明显下降。
6. 边界：什么时候正式授权体系是过度设计
| 场景 | 授权体系的必要性 | 理由 |
|---|---|---|
| 团队小于五人 | 低 | 决策者本身在一线，等待成本接近零 |
| 决策频率极低（月级） | 低 | 上收成本可忽略，机制成本反而更高 |
| 决策者在一线且可见 | 低 | 观察成本低于记录成本 |
| 决策频率高且决策者离线 | 高 | 队列必然堆积 |
| 出现跨团队约束 | 高 | 被影响方不在场，必须靠边界与记录 |
三种低必要性的场景有一个共同点：决策者和执行者在同一个信息场里。此时授权体系带来的是文书成本，而不是速度。判断是否需要正式化的最简单办法，是看决策队列是否真的存在——如果没人等，就不需要下放。
反过来，最不该做的是"半套"授权：判据有了、台账没有，或者台账有了、判据没人维护。半套机制比不设机制更糟，因为它把等待从明面的队列换成了暗面的私下确认，成本照付，还看不见。
7. 自测
- 下放的是权力还是决策频率，这个区别对判断有什么影响？
- 四格处置里，"可逆 + 跨团队"这一格该怎么处理？
- 三种授权形态中，哪一种最容易因为边界写法而失真？
- 授权失败的两个原因分别对应补什么，为什么培训常常补错？
- 什么情况下该追责，什么情况下不该？
- 哪三种场景下正式授权体系是过度设计？