上周看到一个热搜话题：一个人用AI做出了过去需要一个团队才能做的产品。评论区一片焦虑，有人说"技术管理者要失业了"。

我觉得这话说反了。AI越能干，越需要有人决定让它干什么、不干什么。真正该焦虑的，是那些还在用"做得好"来定义自己价值的技术管理者。

做得太好，是一种甜蜜的陷阱

我见过不少技术leader，包括我自己，刚做管理时的第一反应是——代码review我得上，架构设计我得参与，关键技术选型我得拍板。

原因很简单：这是我们最擅长的事，也是最有安全感的事。写出一段精巧的代码、解决一个棘手的bug，那种成就感是开会、写文档、做1on1给不了的。

但问题是，如果你的时间都花在review代码上，谁来做技术规划？谁来协调跨团队的需求冲突？谁来处理团队里那个能力强但态度差的人？

没人做。因为这些事"不急"。或者更准确地说，我们下意识觉得这些事没有"亲手写出一个漂亮的函数"来得有成就感。

身份认同才是真正的瓶颈

我在金融科技团队里见过一个典型场景。新业务要上线，技术方案讨论时，CTO问了一个架构层面的问题。整个会议室沉默了十秒，所有人看向那个最强的工程师。

他答得很好。但我在想：如果这个团队继续发展，他还是那个被提问的人，还是那个回答问题的人？

做IC（个人贡献者）时，你的价值就是你解决问题的能力。但当你开始带团队，你需要让渡这种价值——从"解决问题"变成"定义问题、分配问题、为问题设定优先级"。

这个转变很难，因为它要求你放弃已经建立起来的身份认同。

从"我来"到"谁来做"

读MBA时有一门课讲组织行为学，第一课就说：管理者的核心工作是让别人成功。

听起来简单。但对技术出身的人来说，这句话几乎是反直觉的。我们花了十几年时间让自己变强，现在有人告诉我们，你的价值变成了"让别人变强"。这个心理转变，比学任何管理工具都难。

打个比方：运动员退役当教练，最难的不是战术，而是克制自己不上场。

技术管理者也一样。最难的不是"懂不懂技术"，而是"懂技术但忍住不自己写"。

三种转型路径

我观察过一些做得好的技术管理者，他们不是不碰代码，而是重新定义了"我对团队的贡献方式"。

第一种：技术教练型。保持20%的时间写代码，80%的时间做架构review和人才培养。代码是"手感"，不写就没法做技术判断。

第二种：效能工程型。完全不碰业务代码，专注做技术基建和团队效能工具。他的价值不是自己写代码，而是让整个团队写代码更快更好。

第三种：战略决策型。重大技术决策时深度参与，日常放手退后一步。他的价值是用关键节点的判断力来把控方向。

这三种模式有个共同点：他们不再用"个人产出"来衡量自己的价值。

真正的天花板不在技术

做了很多年技术，我后来想明白一件事：做IC时，天花板是自己——学不动了、写不快了，就到顶了。做管理者时，天花板是团队——团队能成长，你就有空间；团队停滞，你也停滞了。

所以技术管理者最重要的能力，不是"技术有多牛"，而是"能不能让团队里的人变得更牛"。

MBA课堂上讨论过一个概念：领导力是放大器。你的能力是1，乘以10个人，如果每个人都在成长，这个倍数会越来越大。如果团队不成长，你永远只是一个能力为1的人乘以10。

这就是为什么"做得太好"反而可能成为瓶颈——你把自己活成了那个1，而不是那个放大器。

写在最后

回到开头那个问题：AI时代，技术管理者会失业吗？

我觉得不会。AI越能干，越需要有人定义问题、做取舍、承担责任。这些事AI做不了。

但前提是：你真的站在"判断层"，而不是还在"执行层"自我感动。

做得太好不是问题。问题是只会做。