即使今天我们领导着团队，我们很可能是通过技术优秀的表现攀升工程阶梯。我们的代码更干净，架构更优雅和可扩展，我们所构建的解决方案都能正常工作。现在，当我们领导一支工程团队时，我们可能会感到效率下降。团队等着我们的决策，创新几乎没有向前推进，尽管我们工作得更长更努力，但我们正成为我们发誓永远不会成为的瓶颈。这是一个相当普遍的情况，让我们怀疑自己是否是担任管理职位的合适人选。但这里有一个大家对技术领导力常常忽视的事实：促使我们晋升的专业知识，现在成了我们最大的负担。当我询问不同的领导者他们推荐的书籍时，最常见的答案是：海军舰长大卫·马尔凯特的《逆转舰船》。我甚至将这本书列入了我为工程领导者推荐的十大书籍之一（作为社区的推荐）。我终于赶上了马尔凯特关于指挥“圣菲号”潜艇的故事，这艘潜艇是舰队中表现最差的。这本书让我意识到：虽然我的任何团队都不是“表现最差的”，但我经常在想，有时小规模的工程组为什么能比我们更快地推进。多年来，我经历了多次转型：从质量控制到质量保证，从孤立的团队到跨职能团队，从固定的大爆发发布到持续交付，从程序员到产品工程师。我一直在疑惑——有哪些共同点使这些倡议成功？这些天，在阅读《逆转舰船》后，我相当确定马尔凯特的“领导-领导者”模型可以成为工程组织中有效的框架之一。“所有拉取请求都需要我批准。” “在你继续之前让我先审核那段代码。” “在你推向生产之前，先让我看一下那个部署计划。”听起来熟悉吗？许多这些活动在软件工程中被视为良好的实践。同行审查是有效的左移测试转型的基础。但作为领导者，你不再是“同行”。你可能会说服自己在确保质量。但你其实是在训练团队形成习得的无助感。这里有一个不舒服的真相：你依赖专业知识的微观管理正在造成：一个决策瓶颈（你），失去参与感的工程师，他们停止批判性思考，一个脆弱的组织，一旦你休假就会崩溃。数据证实了这一点。谷歌的氧气项目发现“技术专长”在有效管理者的特质中排名最后。那么排名第一的是什么？成为一个好的教练，赋能团队而不是微观管理。顺便说一下，这里有完整的名单：有效管理者的8个关键行为是：一个好的教练，赋能团队，且不进行微观管理，创造一个包容的团队环境，关心成功和福祉，工作高效且以结果为导向，是一个好的沟通者——倾听和分享信息，支持职业发展并讨论绩效，有着清晰的团队愿景/战略，拥有关键的技术技能来帮助指导团队。信息很明确：技术专长很重要，但它是必要的而非充分的。你发展和赋能他人的能力才是真正的差异化因素。但如果控制不是答案，那是什么？当马尔凯特指挥圣菲号时，他做出了一个激进的决定。与其发号施令，他训练他的船员说：“我打算……”。这个小语言上的转变触发了一场令人惊讶的转变。当我在一个寻求许可的文化中工作时，常常会出现这样的情况：工程师：“我收到了来自UI设计师的效果图，由于它们的定制性，实施起来需要几周。我们能否简化一下？”我：“你想改什么呢？”工程师：“导航的大小和默认行为。”我：“让我先看看，然后再和UI设计师确认……”在实施意图驱动的领导之后，谈话更接近于：工程师：“我打算简化导航UI/UX，这样我们可以在2天内实现，而不是2周。我想重用我们设计系统中已有的组件。”领导：“你觉得我现在在想什么？”（这是大卫·马尔凯特的默认问题）工程师：“你可能在想这是否与产品团队的UI/UX愿景相一致。”领导：“正是。说服我这是正确的举动。”工程师：“我已经和产品设计师确认过了，展示了现有组件，与他们的新提案几乎相同。我想用它们，而不是定制的。”领导：“这这样做是否正确？”工程师：“是的，因为我们将比原定提前几周将其推给客户，用户体验将与我们应用程序的其余部分保持一致。我们可以在之后继续迭代。”另一个案例：工程师：“我打算重构认证服务，减少……”