“所有拉取请求都需要我审批。”这句话，正在让无数技术领导者变成自己最厌恶的瓶颈。Mirek Stanek 在回顾自己从顶尖工程师到管理者的转变时，对这类看似合理的控制动作做了不留情面的拆解：我们靠写出更干净的代码、更优雅的架构和真正可运行的方案爬上梯子，可一旦站在团队之上，这套赖以晋升的专长，立刻转变为负债。
Stanek 是在一次关于工程领导书籍的调研中，听到最多人提起《翻船》（Turn The Ship Around）。这本书前美国海军舰长 David Marquet 接管太平洋舰队表现最差潜艇“圣塔菲”号的故事，让他反复琢磨一个困惑：为什么我们人数更少的小团队，反而比大群精英跑得快？这些年他推动过品控到品保的转型、从竖井团队到跨职能团队、从固定的大爆炸发布变成持续交付、从码农养成产品工程师，但始终缺少一个能串起所有变革的共同逻辑。
Marquet 的“领导者-领导者”模型，恰好补上了这个缺口。这个模型的颠覆之处，在于它直指一个多数技术领导人不愿承认的事实：当你要求每行代码都必须经你审核、每次部署方案都得先让你过目，你并没有在保障质量，而是在系统性地制造“习得性无助”。团队停止独立思考，因为你替所有人判断；创新原地踏步，因为所有决定都在等你；只要你去休假，整个交付链路就可能摇摇欲坠。你不是质量守门员，你只是一个会写代码的决策单点。
Stanek 把这种模式称为“领导-跟随”的陷阱：领导用一身技术本领不断释放指令，团队只需要跟随。而“领导者-领导者”要做的恰恰相反——把决策权还给应有的人。这并不是放弃质量标准，而是把代码审查从“一个人的签字”变成群体技术对话，让工程师重新拥有对方案的自主判断。当每个人都是自己那份工作的领导者，团队才不会在核心离开时出现功能性解散。
谷歌的“氧气计划”（Project Oxygen）曾对高效管理者的特质排过序。结果很耐人寻味：长期以来被技术管理者奉为护身符的“技术专长”，在八项关键行为里垫底。排在前面的，是成为一位好的教练——能倾听、能提问、能帮人理清思路，而不是替人写代码。这与Marquet在潜艇中推行的“用‘我打算……’代替‘请求许可’”的沟通机制，几乎遥相呼应。
这就是说，当我们从工程师被提拔为领导者，跨过的并不是一道“技术更精”的门槛，而是一道身份转换的急弯：继续用写代码的方式领导，等于亲手把团队锁在自己一个人的能力上限之下。而改走“领导者-领导者”的路，则意味着要学着少给答案，多让团队自己找到答案——哪怕一开始，这会让你感觉自己不再像当初那个无所不能的工程师。
热门跟贴