从 Leader-Follower 到 Leader-Leader 方法的转变

# 从领导者-追随者模式转向领导者-领导者模式 来源：https://www.practicalengineering.management/p/shift-from-a-leader-follower-to-a 尽管如今我们领导着团队，但我们很可能正是凭借技术卓越才在工程阶梯上爬上来的。我们的代码更整洁，架构更优雅、更具扩展性，构建的解决方案也确实有效。 现在，当我们领导一个工程师团队时，可能会感觉自己的效率下降了。团队等待我们的决策，创新几乎停滞不前，尽管我们工作得更久、更努力，却正在成为自己曾发誓绝不成为的瓶颈。 这是一种相当常见的情况，让我们怀疑自己是否适合管理岗位。但关于技术领导力，每个人都忽略了一点：当初让我们获得晋升的那种专业技能，如今却成了我们最大的负担。 当我向不同领导者询问他们的书籍推荐时，最常见的回答是：海军上校 David Marquet 的《Turn The Ship Around》（https://amzn.to/3Ee7WuO）。我甚至把这本书列入了我推荐的工程领导者十大书籍（https://www.practicalengineering.management/p/book-recommendations-for-engineering）（作为社区选择）。 我终于读完了 Marquet 关于接管 USS Santa Fe 号潜艇——舰队中表现最差的潜艇——的故事。这本书让我意识到：尽管我的团队中没有一个是“表现最差的”，但我经常问自己，为什么有时候规模更小的工程师团队能比我们快得多。 多年来，我经历了多次转型： - 从质量控制到质量保证 - 从孤岛团队到跨职能团队 - 从固定的大爆炸式发布到持续交付 - 从编码者到产品工程师 我一直想知道——是什么共同点让这些举措获得了成功？ 如今，读完《Turn The Ship Around》后，我相当确信 Marquet 的“领导者-领导者”模型可以成为在工程组织中运作良好的框架之一。 [](https://substackcdn.com/image/fetch/$s_!PmYK!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fdc3e1387-2c07-4011-a78c-c4cfa09c2d69_1920x1080.png) - *“所有拉取请求都需要由我批准。”* - *“让我先审查那部分代码，你再继续。”* - *“在推送到生产环境之前，先把部署计划给我看看。”* 听起来很熟悉吧？ 在软件工程中，很多这类活动被视为良好实践。同行评审是有效的“左移测试”转型（https://www.practicalengineering.management/p/leading-qa-shift-left-transformation）的基础。 但作为领导者，你已不再是“同行”。你可能会说服自己是在确保质量。但实际上你所做的，只是在训练团队养成习得性无助。 令人不安的真相是：你基于专业知识的微观管理正在造成： 1. 一个决策瓶颈（就是你自己） 2. 一批停止批判性思考、不再投入的工程师 3. 一个脆弱的组织，你一休假就瘫痪 数据也支持这一点。Google 的 Project Oxygen 发现，“技术专长”在高效管理者的特质中排名垫底。排名靠前的是什么？是成为优秀的教练，以及授权团队而不进行微观管理。 顺便提一下，完整的列表如下： **高效管理者的 8 项关键行为** 1. 是一名优秀的教练 2. 授权团队，不进行微观管理 3. 营造包容的团队环境，关心成员的成就与福祉 4. 高效且以结果为导向 5. 善于沟通——倾听并分享信息 6. 支持职业发展，讨论绩效 7. 为团队制定清晰的愿景/战略 8. 拥有帮助团队提供建议的关键技术技能 信息很明确：技术专长很重要，但它是必要条件而非充分条件。你培养和赋能他人的能力才是真正的差异化因素。 但如果控制不是答案，那什么才是呢？ 当 Marquet 接管 Santa Fe 号时，他做了一个激进的决定。他不再下达命令，而是训练船员说出：“我打算……”。这个小小的语言转变引发了一场变革，带来了惊人的成果。 当我身处一种 **“寻求许可文化”** 时，我们经常遇到这样的情况： - *工程师：“我从 UI 设计师那里拿到了原型，但由于它们太定制化了，实现起来需要几周时间。我们能简化一点吗？”* - *我：“你想具体改变什么？”* - *工程师：“导航的尺寸和默认行为。”* - *我：“让我先看看，再和 UI 设计师确认一下……”* 在实施了 **“意图驱动领导力”** 之后，对话更像这样： - *工程师：“我打算简化导航的 UI/UX，这样我们可以在 2 天内实现，而不是 2 周。我想复用我们设计系统中已有的组件。”* - *领导者：“你觉得我现在在想什么？”（这是 D. Marquet 的默认问题）* - *工程师：“你可能在想这是否符合产品团队对 UI/UX 外观的愿景。”* - *领导者：“完全正确。说服我这步是对的。”* - *工程师：“我已经和产品设计师确认过，给他们看了现有的组件，这些组件看起来几乎和他们的新方案一样。我想用这些而不是定制的。”* - *领导者：“这是正确的做法吗？”* - *工程师：“是的，因为我们可以提前几周推送给客户，UX 也会和我们应用的其他部分保持一致。我们以后随时可以迭代。”* 另一个例子： - *工程师：“我打算重构认证服务，通过消除冗余的数据库调用，将令牌验证时间从 120ms 降到 50ms 以下。”* - ... 再来一个： - *工程师：“我打算修复上周的前三大崩溃，确保我们 99.9% 的 SLO 不受威胁。”* - ... 注意到区别了吗？意图驱动的方法迫使工程师深入思考为什么、怎么做以及如何验证。它培养的是能力，而非顺从。正如 Marquet 所说：“如果你希望你的员工思考，就不要给指令——给出意图。” 要在你的团队中实施这一点： 1. 在技术讨论中禁用“我可以……吗？”这种说法 2. 训练团队使用“我打算……因为……”来代替 3. 抵制批准/拒绝的冲动；转而提出澄清性问题 4. 创建清晰的护栏（架构原则、非功能性需求（https://www.practicalengineering.management/p/non-functional-requirements）），而不是检查点 结果可能会非常显著。 关于前面提到的 UI/UX 变更请求，故事结局如何？ 原来，UI 设计师并不知道微小的改动就需要彻底重写导航组件。一旦他们知道我们可以在同周内推送变更，这对他们来说已经是巨大的胜利。对我们而言，这意味着没有自定义逻辑、没有额外测试，只是复用了现有组件。 双赢。 “但我的团队还没准备好接受这种自主权，”你可能在想。 事情是这样的：能力并非先于自主权存在，而是从自主权中涌现出来的。 当 Marquet 最初实施他的领导者-领导者模型时，他的船员也犯了错误。但他没有退回到命令与控制模式，而是加倍努力构建必要的知识。 这种方法建立在 Marquet 所说的“两个支柱”之上，支持着下放控制权： 1. **技术能力**（安全吗？） 2. **组织清晰度**（这样做对吗？） 对于工程团队来说，这可能意味着： 在 Marquet 的潜艇上，水兵在操作设备之前会触摸设备并口头陈述他们的意图。 对于你的团队，你可以创建类似的协议： - 代码审查政策，要求解释变更背后的意图 - 部署前清单，工程师在推送生产前需逐项检查 - 架构决策记录（ADR）（https://www.practicalengineering.management/p/lightweight-adr），记录推理过程而不仅仅是决策 我领导过的一个团队在周五将东西推送到生产环境。那是一个移动应用，假设周五总是工作周的美好收尾。 后来，我完全脱离了这些发布流程。团队自行决定是否上线或跳过该周，部署流程是什么，风险有哪些等等。 Marquet 的 **技术能力** 元素在我们情境中体现为： - 应用通常推送到测试频道（或仅推送给一小部分用户） - 关键和/或大型功能无论如何都藏在功能开关后面，因此客户发布与生产推送是分离的 - 我们可以在不到 1 小时内推送热修复（全自动测试和部署流程） - 丰富的遥测和监控系统主动告知我们任何故障 - 我们有一套明确的目标和 KPI（例如清晰的 SLO），定义了团队必须维护的标准 综合起来，它为团队创建了一个清晰的操作协议，使他们能够自主工作。 在传统的工程组织中，高级工程师默默解决问题。典型例子是，当你报告一起事件时 —— “好的，我检查一下”，然后就是死一般的沉默。 最坏的情况下，答案永远不会回来；系统会自己开始正常工作。更乐观的情况下，过一阵你会听到：“好的，搞定了。我修复了应用中的 NPE。” 在这种情况下，经验较少的工程师只看到了解决方案，却错过了导致该解决方案的思维过程——这相当于只展示了答案，却没有展示过程。 当一位高级工程师说：“我不确定为什么失败了。让我先看看日志，然后检查配置是否更新正确，再验证网络连接，” 他们正在展示自己的故障排查思维模型。这种思维过程的外化正是 Marquet 在 Santa Fe 号上鼓励的做法，对于软件团队来说也是一种强大的实践。 *附注——边想边说也是在系统设计面试中经常考察的能力，在系统设计面试中，面试官问题的最终答案不如你推导出答案的思考过程重要。借此机会，我推荐阅读 Alex Xu（https://open.substack.com/users/22329494-alex-xu?utm_source=mentions）的精彩著作：《System Design Interview》（https://amzn.to/42n8Wof）* 这种做法比任何文档都能更快地创建共享心理模型。目标不是完美的解决方案，而是可见的思考——因为可见的思考能创造学习机会，而无声的专业知识永远做不到。 *附注2——报告问题（以及后续步骤：确认、修复、验证）本身就是一个可以从控制理论中汲取经验的话题。如果你想了解良好实践和常见错误，请查看我的文章《放大——让信号响亮清晰》（https://www.practicalengineering.management/p/amplification-make-signals-loud-and）* [](https://substackcdn.com/image/fetch/$s_!L8Nm!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F50f78fc4-ed89-4f52-a95f-84e7a3cbb16a_1920x1080.png) 大多数工程领导者是通过比别人懂得更多才晋升上来的。现在你需要转变思路：你的工作不是知道答案，而是创造一个持续学习的环境。 这意味着： 1. 将“我不知道，让我们找出来”这句话正常化 2. 进行无指责的事后复盘，专注于系统改进 3. 专门拨出预算和时间用于探索与实验 这种转变需要你放下作为专家的身份。正如 Marquet 所指出的：“放弃控制，说‘如果你需要我，我就在这里，但这是你的任务’，需要力量和自信。” 以下是一些我在工作中最喜欢的技巧： - 当工程师问你问题时，抑制立即回答的冲动。问“你怎么看？”， “你试过什么方法？”， “你还打算做什么？”。让他们主导，并在此基础上构建你的回答。 - 说“无指责”很容易，但让团队真正感受到这一点却很难。对我经常有帮助的是在安全空间内定期讨论问题。所以，在公司的全员会议上展示你的崩溃率之前，先每周与你的团队检查，讨论所有下降和峰值，在团队中建立信心。“是的，上周我们的稳定性有所下降。根本原因是我们服务的性能问题。相关工作已经清晰描述并计划好了，但作为团队，我们强烈建议设置更高优先级，以避免将来出现类似问题。” - 在较大的组织中，最有效的知识分享实践之一是工程公会，我最近在这系列文章（https://www.practicalengineering.management/p/why-your-engineering-guild-is-quietly-failing）中进行了描述。 正如 Marquet 在 Santa Fe 号上发现的，改善结果最快的方法不是过度关注结果本身——而是建立一个能够持续学习和改进的团队。 当你从答案提供者转变为学习推动者时，你就把自己从瓶颈中移除，并释放了团队的潜能。 在传统的工程团队中，一个人发号施令，其他人听从指令。 正如 Marquet 在“什么是领导力？”中所说：“在另一艘潜艇上，一个人负责，一个人发号施令，一个人思考，而另外 134 个人则做他们被告诉要做的事。我不在乎你有多聪明。在我的潜艇上，我有 135 个会思考、积极、充满热情、有创造力、主动、有主动性的人。” 当你停止给出答案，开始提出正确的问题时，你并没有削弱自己的影响力——而是在整个团队中将其成倍放大。 下次当工程师请求许可时，用这句话回应：“你打算做什么，为什么？” 然后，看着他们开始从技术人员走向领导者的旅程。 你最大的成就不会是你写的代码或你设计的架构。而将是你创造的、那些在你离开后仍能继续构建和创新的领导者们。 但这不会造成混乱，让每个人都朝不同方向去吗？不会，因为“你创造了这样的环境，让那些人能够做出决定，就好像 CEO 就站在他们身后一样。如果决策不一样，那实际上会是更好的决策，因为他们拥有信息。” 如果 David Marquet 的领导者-领导者方法引起了你的共鸣，我邀请你看看下一篇文章，其中我将分享一个实用的练习，可以帮助你在你的团队或组织中实施它。 同时，我也推荐阅读《Turn The Ship Around》（https://amzn.to/3Ee7WuO），因为这本书是领导力实践的宝库。 以下来自 Practical Engineering Management 的更多文章可以帮助你实施领导者-领导者模式： 1. 自上而下领导力 vs 中心向外领导力（https://www.practicalengineering.management/p/top-down-leadership-vs-center-out） 2. 发展型领导力 vs 事务型领导力（https://www.practicalengineering.management/p/developmental-leadership-vs-transactional） 3. 安全领导力与神经感知（https://www.practicalengineering.management/p/safety-leadership-and-neuroception） 4. 期望管理入门（https://www.practicalengineering.management/p/intro-to-expectations-management） 5. 通过线性化实现简化（https://www.practicalengineering.management/p/simplification-through-linearization）