上周和一位带过 37 人团队的前同事喝酒，他刚从某大厂离职，理由只有一句："我花了三年把自己修炼成一个合格的经理，然后发现自己最擅长的事变成了写周报。" 这不是段子。我统计过身边 50 位从技术骨干转管理岗的朋友，有 43 人曾在第一年内产生过严重的自我怀疑——不是能力问题，而是他们都在努力变成别人眼里的"好领导"，却忘了先学会当一个"烂人"。
我这里说的"烂人"，不是让你去搞办公室政治或者推卸责任，而是让你在转管理的第一天，就主动放弃"技术上的体面"。我见过太多人转岗后还坚持自己 review 代码、亲自跟线上故障、把下属的方案改得面目全非。你看起来是个好 leader，实际上你成了团队的瓶颈。举个例子：当一个技术专家每天花 3 小时在深度代码审查上，他带的人永远学不会做决定。我的前东家做过一次内部测量，那些"过度亲力亲为"的经理，团队交付速度平均下滑 22%，人员离职率高出 31%。
大部分人讲职业发展，爱用"梯子"模型：从初级到高级，从工程师到经理，一步步往上爬。但真实世界里，近六年的招聘数据却显示——头部公司中 67% 的技术总监身上依然背着核心系统的模块负责人头衔，而"纯管理"的岗位反而在缩减。梯子已经断了，你还在那儿找扶手。我更愿意把职业发展看成拼积木：你手里的技术深度、业务理解、人性洞察、沟通带宽，都是不同形状的积木块。技术转管理的关键不是丢掉技术这块积木，而是学会把它压缩成一块"地基"，而不是每一层楼的梁柱。
具体怎么做？给你一个我改了四版才觉得靠谱的三步操作：第一步，升职前三个月主动向直系领导申请"只做评审和拆解"，不做任何代码产出，把自己逼到只能靠别人交付的绝境。第二步，把绩效考核表里"技术贡献"那一栏的权重主动降到 30% 以下，把时间花在"帮下属解决他们搞不定的外部依赖"上——我认识的某物流平台架构师就是这么干的，他转管理后第一年花了一半时间陪产品经理喝酒，结果团队交付量翻了 1.8 倍，而他自己代码量降为 0。第三步，学会在下属面前暴露自己的蠢，比如你明知某个技术方案有更好解法，也别自己上手写，只问一句"你觉得有没有另一种可能"，然后忍住，让方案以一个不太完美的姿态落地。
说到底，职业发展这条路没有哪条线是笔直的。技术和管理之间不是二选一，而是两团不断混合的颜料。真正独立的观点是：别把"升职"当成目标，把"让自己变得更适合解决更复杂的问题"当成目标。所以当你下次再听到"你该转型了"的时候，先问问自己：我愿意为了更大的局面，变成一个在某些方面"技术很烂"的管理者吗？如果答案是否定的，那说明你还没准备好，那就不转。留在技术岗继续做那个代码完美的人，也是一种极其体面的职业终局。
