技术负责人很容易变成所有问题的默认入口：方案要确认，代码要评审，线上问题要定位，跨团队信息也集中到一个人。短期看，这能保证一致性；长期看，团队速度被一个人的注意力限制。
如果负责人休假就无法做决定，说明系统依赖了个人，而不是建立了能力。
决策分级
不是每个决定都需要同样参与。影响公共协议、数据模型和长期成本的选择应共同评审；局部可逆实现交给最近问题的人决定；已有原则能覆盖的事情，不再重复开会。
负责人要提供的是上下文和标准：目标是什么，不能破坏什么，如何验证。结论可以由不同成员产生。
我后来用“影响范围 × 可逆性”给决定分级：
| 决定 | 例子 | 决策方式 |
|---|---|---|
| 局部且可逆 | 组件内部实现、测试工具 | 负责人自行决定，PR 说明即可 |
| 跨模块但可逆 | 新缓存、内部协议扩展 | 小型设计评审，约定观测与退出条件 |
| 局部但难逆 | 数据删除、不可恢复迁移 | 双人确认，先演练恢复 |
| 跨系统且难逆 | 核心模型、公开 API、安全边界 | RFC、原型、分阶段发布 |
这张表减少了两种浪费：局部 CSS 实现不再排队等我拍板，核心数据模型也不会在 PR 最后一刻才被发现。技术负责人把精力放到决策成本真正高的地方。
评审关注风险而非控制
代码评审不应要求所有代码都写成负责人的风格。重点是行为正确、边界清楚、风险可控。对于复杂改动，提前评审设计比最后逐行挑选更有效。
设计评审我只要求一页能回答的问题，不鼓励用文档长度制造安全感：
要改变的用户/系统行为是什么？
必须保持哪些不变量？
数据和状态由谁拥有？
失败后如何恢复？
如何观察结果并判断方案有效？
什么信号出现时要撤回或重做？评审结束要留下决定、反对意见和后续验证，不保存一份“大家讨论过”的会议纪要。这样没有参会的人也能沿证据重新判断。
事故发生时，负责人承担协调与结果责任，但不应该独占排查。让成员参与完整过程，复盘改进系统而不是寻找个人错误，团队才会形成下一次独立处理的能力。
上下文要公开流动
很多“必须由负责人决定”的问题，实际是信息只集中在负责人手里。把业务目标、架构约束和历史决策写进团队可访问的位置，成员才有可能独立判断。会议中的关键结论也要留下记录，不能依赖谁恰好在场。
信息公开不等于把所有细节推给每个人。负责人应提炼当前决定真正需要的上下文，并说明哪些边界不可突破。清晰上下文与明确授权同时存在，分布式决策才不会变成各自为政。
领导力不是让自己不可替代，而是让团队在没有即时指令时仍能做出一致、可靠的判断。
图：优秀负责人降低团队等待，而不是让所有决定汇聚到自己。
这套分权要能运行，前提是团队知道什么必须找我。我会公开自己的升级规则：跨团队不可逆决定、生产高风险操作、连续两次无法收敛的故障必须升级；普通实现选择由最接近上下文的人决定，并通过 ADR 或评审留下证据。
我每周检查自己是否成为等待点：多少 PR、发布和方案必须等我；哪些决定可以通过原则、工具或授权下放。技术负责人真正的杠杆，是让系统在自己不在线时仍能做出合格判断。
两条配套实践在这里没有展开：决定怎样留下证据、反对意见怎样不被会议抹掉，属于ADR 怎么写才有人看；把个人经验沉淀为团队默认能力的分层标准，属于资深工程师的产出，不应该只存在于代码仓库。