从“领导-追随”到“领导-领导”：工程团队的管理范式转移

背景

在技术行业中，许多工程师是通过技术卓越（Technical Excellence）晋升为管理者的。他们的代码更干净，架构更优雅且具备可扩展性，构建的解决方案也确实行之有效。然而，当这些技术专家转变为团队领导者时，往往会陷入一种困境：团队效率下降，成员等待指令，创新停滞不前。尽管团队工作更努力、时间更长，但领导者本人却成为了他们曾经发誓绝不成为的“瓶颈”。

这种情境让许多技术管理者怀疑自己是否适合管理岗位。然而，一个被普遍忽视的事实是：正是那些帮助他们获得晋升的技术专长，现在可能成为了他们最大的负担。

为了寻找解决方案，作者参考了美国海军上校 David Marquet 的著作《Turn The Ship Around》（中文译名：《翻转领导》或《舵手》）。Marquet 曾指挥 USS Santa Fe 号潜艇，该潜艇曾是舰队中表现最差的潜艇。通过阅读 Marquet 的故事，作者意识到，虽然工程团队并非“表现最差”，但小型团队有时能比大型团队移动得更快的现象，与 Marquet 提出的“领导-领导”（Leader-Leader）模型有着深刻的共鸣。

核心内容

1. 控制的危险幻觉

许多技术领导者习惯于微观管理（Micromanagement），例如：“所有拉取请求（PR）都需要我批准”、“在我继续之前让我审查一下代码”、“在推送到生产环境前，先让我看看部署计划”。

虽然同行评审是有效测试左移的基础，但当领导者不再作为“同行”而是作为“管理者”时，这种基于专业知识的微观管理实际上是在训练团队产生“习得性无助”（Learned Helplessness）。其后果包括：

• 决策瓶颈：所有决策都集中在领导者一人身上。
• 工程师参与度降低：团队成员停止批判性思考。
• 组织脆弱性：一旦领导者休假或离开，组织就会陷入瘫痪。

Google 的 Project Oxygen 研究数据支持了这一观点。在有效管理者的八大关键行为中，“技术专长”被排在最后。排名靠前的是：成为优秀的教练、赋能团队且不微观管理、创造包容性的团队环境等。这表明，技术专长是必要的，但并非充分的条件；真正区分优秀管理者的是培养和他人的能力。

2. 意图驱动：从“寻求许可”到“明确目的”

Marquet 在接管 Santa Fe 号时做出了一个激进的决定：不再下达命令，而是训练船员使用“我打算……”（I intend to...）的句式。这种语言上的微小转变引发了惊人的变革。

对比案例：

• 传统“寻求许可”文化：

  • 工程师：“UI 设计师给了我原型，由于定制程度高，实现需要几周。我们可以简化一点吗？”
  • 领导者：“你想具体改什么？”
  • 工程师：“导航的大小和默认行为。”
  • 领导者：“让我先看看，再和 UI 设计师确认……”
  • 结果：流程缓慢，依赖领导者的审批。

• 实施“意图驱动”后的对话：

  • 工程师：“我打算简化导航 UI/UX，以便在 2 天内而不是 2 周内完成实现。我想复用设计系统中已有的组件。”
  • 领导者：“你觉得我现在在想什么？”（这是 Marquet 的默认问题）
  • 工程师：“您可能在考虑这是否符合产品团队对 UI/UX 的愿景。”
  • 领导者：“没错。说服我这是一个正确的举动。”
  • 工程师：“我已经和产品设计师确认过，展示了现有的组件，它们看起来与新提案几乎一样。我想使用现有组件而不是定制组件。”
  • 领导者：“这是正确的做法吗？”
  • 工程师：“是的，因为我们可以提前几周推向客户，UX 将与应用程序的其他部分保持一致。我们以后可以迭代。”

通过这种方式，工程师被迫深入思考“为什么”、“怎么做”以及“如何验证”。这创造了能力（Competence）而非仅仅是顺从（Compliance）。正如 Marquet 所说：“如果你想让你的员工思考，不要给指令——给意图。”

3. 能力悖论：自主性催生能力

许多管理者担心：“我的团队还没有准备好拥有这种自主权。”但事实是：能力并非自主性的前提，而是自主性的产物。

Marquet 在实施“领导-领导”模型初期，船员也犯过错误。但他没有回归命令与控制模式，而是加倍努力构建必要的知识体系。这种模式建立在两个支柱之上：

1. 技术能力（是否安全？）
2. 组织清晰度（这是否是正确的做法？）

对于工程团队，这意味着建立类似的协议：

• 代码审查政策：要求解释变更背后的意图。
• 部署前检查清单：工程师在推送到生产环境前必须完成。
• 架构决策记录（ADRs）：记录推理过程，而不仅仅是决定。

实际案例： 作者曾领导一个移动应用团队，习惯在周五发布。起初，作者完全脱离了这些发布流程。团队自行决定何时上线、发布流程及风险。Marquet 模型中的“技术能力”要素在我们的语境中体现为：应用通常推送到 Beta 频道或仅面向少量用户；关键功能通过特性标志（Feature Flags）隐藏。这种自主性让团队学会了承担责任，最终实现了双赢：UI 设计师得知变更可以在一周内完成，这对他们也是巨大的胜利，而工程团队则避免了自定义逻辑和额外测试。

关键要点

• 技术专长是双刃剑：晋升为管理者后，原有的技术微观管理会成为团队的瓶颈，导致决策集中化和团队去技能化。
• Google 的管理启示：有效管理者的核心特质是教练能力和赋能，而非技术技能。技术技能是基础，但不是区分卓越管理者的关键。
• 语言重塑行为：禁止使用“我可以……”（Can I...）的句式，转而训练团队使用“我打算……因为……”（I intend to... because...）。这迫使团队成员阐述意图、理由和验证方法。
• 领导者角色转变：领导者应从“批准/拒绝”者转变为“提问/澄清”者。通过问“你觉得我在想什么？”来引导团队对齐目标和愿景。
• 建立护栏而非检查点：制定清晰的架构原则和非功能性需求作为护栏（Guardrails），而不是设置过多的审批检查点（Checkpoints）。
• 自主性培养能力：不要等待团队“准备好”再放权。通过赋予自主权并建立技术能力和组织清晰度的双重支柱，团队的能力会在实践中涌现。
• 意图驱动优于指令驱动：给予意图而非指令，能激发工程师的批判性思维，从而创造出既高效又具备韧性的组织。

意义与影响

这篇文章深刻揭示了技术团队从“命令与控制”向“赋能与自主”转型的必要性。对于工程领导者而言，其意义在于：

1. 打破管理者瓶颈：通过放弃微观管理，领导者可以从日常决策中解脱出来，专注于战略愿景和团队发展，从而提升整体组织的吞吐量。
2. 提升团队韧性与创新：当工程师被赋予自主权并被期望思考“为什么”时，他们不再是被动的执行者，而是主动的问题解决者。这种文化能显著加快创新速度，并使团队在面对不确定性时更具适应性。
3. 重新定义领导力：领导力的核心不再是“我知道答案”，而是“我能帮助团队找到答案”。这要求领导者具备更强的教练技巧、沟通能力和建立信任的能力。
4. 实践可行性：通过具体的语言技巧（如“我打算...”）和流程设计（如 ADRs、特性标志），这种管理哲学的转变并非空中楼阁，而是可以在日常工程实践中落地执行的。

最终，从“领导-追随”到“领导-领导”的转变，不仅是管理风格的调整，更是组织文化的根本性重塑，旨在打造一个高绩效、高参与度且可持续进化的工程团队。