有个场景你一定不陌生：一个技术很强的Leader，手下的活几乎都过他的手。白天开会，晚上写代码，周末review。团队成员反而很闲，等着他分配任务，等着他把方案定好。

这个人累得半死，团队成长停滞，业务推进缓慢。但他自己觉得挺充实——"至少事情没掉地上。"

这种场景太常见了。而且有个规律：越是优秀的IC（个人贡献者），转型管理者时越容易掉进这个坑。

优秀为什么会变成陷阱

做IC的时候，你的价值等于你解决问题的能力。代码写得好、架构设计得巧、线上问题处理得快——这些是你被认可的原因。

转成管理者后，评价体系变了。你的价值不再是"你做了什么"，而是"你的团队产出了什么"。之前让你闪光的能力，现在可能正在拖你的后腿。

因为太擅长解决问题，你会本能地冲上去："算了，我来吧。"每一次"我来"，你就少了一次观察团队、思考方向的机会。更糟的是，团队会习惯等你兜底，主动性和成长空间都被你"优秀"地压死了。

说白了，做IC时，优秀是你的加速器；做管理者后，同样的优秀可能变成团队的限速器。

真正的转变不是做更多，而是学会不做

我观察过一些转型比较成功的技术管理者，发现他们有一个共同点：不是技术变差了，而是对"成就感来源"做了迁移。

IC的成就感来自"我搞定了"——代码跑通了，方案落地了，性能优化了。确定性高，反馈快。

管理者的成就感来自"他们搞定了"——团队成员能独当一面，项目在你没介入的情况下顺利交付。不确定性高，反馈周期长，有时候甚至不知道自己的贡献在哪里。

这种转变很不舒服。就像习惯了跑百米的人去跑马拉松，肌肉记忆全是错的。你明明知道怎么做更快更好，却要忍住不动手，看着团队用笨拙的方式慢慢摸索。

但这个过程没法跳过。团队不经历笨拙，就永远到不了熟练。

几个真实的心理坎

"我做得比他好，凭什么不让我做？"

这是第一道坎。管理者需要接受一个事实：短期看，你做确实更好。但长期看，如果你一直做，团队就永远到不了"足够好"。你在用团队的长期天花板，换短期的执行效率。这笔账不划算。

"放权之后我干什么？"

很多人不是不想放，是放了之后会慌。以前日程排满代码和方案，突然空出来大段"不知道该干什么"的时间。这种空虚感很真实，但它恰恰说明你做对了——管理者本就该花时间去想那些"重要但不紧急"的事：团队结构、技术规划、跨团队协同、人才梯队。

"万一团队搞砸了怎么办？"

会搞砸。一定会。但搞砸了才是最好的学习机会。你要做的不是替他们避免失败，而是在失败可控的范围内让他们承受后果，然后一起复盘。这比你亲自上阵有效十倍。

身份重建

从IC到管理者，不是一个岗位变动，是一次身份重建。你要放弃一些曾经定义自己的东西——"我是团队里写代码最好的人"、"没有我搞不定的技术问题"——来获得一些新的东西。

放弃的过程不舒服，但值得。

那些真正完成转型的技术管理者，不是学会了更多技术，而是学会了一件反直觉的事：有时候，不做比做更难，也更重要。