一个工程团队最慢的地方，有时不是 CI、不是测试，也不是需求变更。

而是每个关键动作都在等同一个人点头：代码能不能合、今天能不能发、架构选 A 还是 B、线上故障先查哪里。这个人通常是团队里最强的技术负责人。问题也就卡在这里：越强，越容易变成人工闸门。

Practical Engineering Management 4 月 21 日刊文，借 David Marquet 在《Turn The Ship Around》中提出的 Leader-Leader 模型，讨论工程团队如何从“领导审批”转向“工程师基于意图自主决策”。这篇文章有意思的地方，不是又推荐了一本管理书，而是把一个老问题说透了：技术负责人继续以专家身份把守所有关键节点，可能正在制造瓶颈，也在训练团队更熟练地请求许可。

技术把关不能取消，但审批点要换位置

Marquet 接手 USS Santa Fe 潜艇后，核心变化不是让船员随便做决定，而是把命令链改成意图链。船员不再只等上级下令，而是说：“I intend to...”——我打算这么做。

放到工程团队里，这个语言变化很具体。

过去是：“Can I simplify this UI?”

更好的表达是：“I intend to simplify the navigation UI because we can reuse existing design-system components and ship in two days.”

多出来的不是客气话，而是理由、边界、风险和验证方式。管理者听到的也不再是一个许可请求，而是一段可检查的判断过程。

场景审批式表达意图式表达管理者该做的事
代码评审“你帮我看看能不能合”“我这样改是为了解耦认证逻辑，风险在缓存失效”问风险、测试和回滚，不替他重写
发布检查“今天能不能发版”“我打算灰度 5%，看错误率、延迟和核心路径转化”看护栏是否完整
ADR“架构你拍板吧”“我建议选方案 B，因为迁移成本低，但一致性较弱”逼清取舍，而不是直接定案
故障处理“我去查一下”“我先查日志，再核配置和网络链路”让排查思路可见，事后能复用

这里不能误读。

Leader-Leader 不是取消代码评审，也不是取消发布检查。它要取消的是“领导作为唯一判断器”。保留下来的，是更硬的决策护栏。

对工程经理和 Tech Lead 来说，日常动作会变。过去回答“可以”或“不可以”，现在要多问四个问题：

  • 你基于什么判断？
  • 失败信号是什么？
  • 怎么回滚？
  • 这和当前团队目标是否一致？

短期看，这会让沟通变慢。长期看，它是在把判断力从一个人身上拆出来，放进团队流程里。

专家型管理最容易把强人变成瓶颈

工程经理和 Tech Lead 大多是靠技术能力赢得信任的。代码写得好，架构看得准，线上问题救得快，这些都是真本事。

也正因为是真本事，他们很容易留在“我来把最后一关”的位置。

这个位置有安全感。团队也省事。遇到不确定的事，找最强的人拍板就行。

代价是隐性的：负责人越忙，团队越等；负责人越准，其他人越不敢判断。久而久之，代码评审像交作业，发布像等批条，ADR 像请领导定夺。

Google Project Oxygen 的结论提供了一个有用参照：有效管理者最重要的行为，是做教练、授权团队、不微观管理；关键技术能力排在后面。这个排序不是说技术不重要，而是说技术能力是必要条件，不是充分条件。

现实约束也要摆在桌面上。

强监管、支付、基础设施、医疗等团队，不可能简单照搬创业团队的“快”。这些场景有发布窗口、审计记录、权限控制和事故责任。出了问题，不是复盘几句就结束。

所以可行路线不是“少审批”，而是把审批前移、固化、自动化。

风险场景不该怎么做更可行的护栏
高风险发布让负责人临时凭经验放行发布清单、灰度、feature flag、可回滚方案
架构分歧让最资深的人口头拍板ADR 记录取舍、约束和后续验证点
线上故障等某个高手上线救火监控告警、SLO、Runbook、无责复盘
代码质量把评审变成领导审稿自动化测试、静态检查、风险导向评审

这对两类人影响最直接。

工程经理要少做临场裁判，多做规则设计者。比如把发布检查从“找我确认”改成“清单满足即可发，异常必须升级”。

Tech Lead 要少做最后答案提供者，多做判断训练者。比如代码评审时，不急着给方案，而是要求提交者说清风险、替代方案和回滚路径。

这不是削弱技术负责人。恰恰相反，技术负责人的价值要从“我最会判断”升级到“我让更多人能判断”。

自治能不能成立，看能力和清晰度两根柱子

Marquet 的 Leader-Leader 模型里，授权不是一句“我相信你”。它靠两根柱子支撑：技术能力和组织清晰度。

技术能力决定“是否安全”。组织清晰度决定“是否正确”。

工程团队也一样。一个工程师会用 Kubernetes、懂发布流水线、知道如何查日志，才有资格在生产环境里自主操作。一个工程师理解产品目标、SLO、业务优先级，才可能在速度、稳定性和成本之间做取舍。

只给权限，不补能力，自治会变成冒险。

只讲能力，不给清晰目标，自治会变成各做各的。

可以用一个简单分层来判断团队走到哪一步：

团队状态典型表现管理者下一步
请求许可大事小事都等负责人点头要求每个请求带上理由、风险和回滚
表达意图工程师能说清自己打算做什么用评审和复盘校准判断质量
护栏自治常规发布和故障处理不依赖单点负责人把经验沉淀到清单、ADR、Runbook 和监控
高风险升级遇到安全、合规、重大客户影响时主动升级明确升级条件，不靠临场猜测

接下来最该观察的，不是团队有没有把“Can I”统一改成“I intend to”。语言只是入口。

更硬的观察点有三个：

  • 负责人休假时，常规发布是否还能稳定推进；
  • 故障复盘能不能产出可复用的判断过程，而不是只记住某个英雄；
  • 代码评审是否从挑语法，转向讨论风险、边界、测试和意图。

如果这些还做不到，团队并没有真正自治。它只是把审批话术换了个说法。

真正的变化，是负责人不再站在所有路口当红绿灯。规则、监控、SLO、feature flag、ADR 和复盘，开始承担一部分判断功能。

这时团队才有机会从“等一个能人”走向“养一群会判断的人”。