每个员工都会趋向于晋升到他所不能胜任的职位

你好，我是码哥

有个读者私信我，说 leader 找他谈了话，要他带一个五人小组。他有点懵，跑来问我，码哥，我才工作四年，技术还没搞透，转管理是不是亏了。

这个问题，我当年也被问过，而且是被问得最多的一个。今天干脆把话摊开讲。

先说一个可能扎心的结论。管理不是技术好的人应得的奖励，它是另一条完全不同的职业曲线。把转管理当成升职加薪 plus 版的人，进去之后大概率会怀疑人生。

fig01-value-chain

一、先泼盆冷水：不是你选了管理，是公司选了你

很多人对转管理有个浪漫的想象，觉得那是努力写代码换来的勋章。我见过太多人栽在这个幻觉上。

快狗打车 CTO 沈剑在一次分享里说得很直白。管理还是技术，很多时候你没得选，是公司选择了你。他自己从百度研发工程师，到 58 架构师，再到一线管理者、技术总监、技术 VP，一路走下来，没有一步是铁了心要当领导。

这话听着丧气，其实是个好消息。它意味着你不用背负「我必须主动规划管理生涯」的焦虑。大多数技术管理者，都是被业务需要推上去的。

去年鹅厂前端专家黄希彤因为只做技术不做管理被毕业，网上吵翻了天，「技术人的宇宙终点是管理吗」冲上热搜。我当时就一个判断，把这件事当成不做管理就会被淘汰，是典型的因果倒置。

真相是，管理和技术都是企业里合法的存在方式。技术专家的成长天然往个人方向倾斜，管理者往业务和目标方向倾斜。两者没有高低，只有适配。黄希彤的事，恰恰说明一家公司可以因为战略调整让专家离开，但专家路线本身没错。

所以第一件事想清楚。你是因为想带人、想对结果负责被点燃，还是因为不转怕被边缘化被推着走。动机不同，后面所有的苦都尝出不同的味道。

我带过的人里，凡是抱着「反正公司要我带，我就带呗」心态进去的，前半年都在跟自己较劲。反过来，那些明确想过「我就想看看怎么让一群人把事做成」的，阵痛期短得多。

二、第一个坑：事必躬亲综合症

我带过的一个兄弟跟我讲过他的真事。刚被提成主管那会儿，他把一个模块丢给组里做了两年的开发。deadline 前一天对方交了代码，他打开一看，命名乱、异常没处理、注释敷衍。他第一反应不是教对方改，而是我两个小时改完比扯半天强。

那两个小时他确实改完了。后面就失控了。活分出去又悄悄接回来，他的时间越来越少，组员越来越闲。直到有天领导半夜看到他还在写代码，问了句，你怎么还在写，管理工作呢。他才惊醒，自己根本没在管，只是个带了头衔的高级打工人。

这里有个认知拐点。说着简单，改起来要花一两年。

工程师的价值逻辑是，我写的代码能跑、功能能实现，我就有价值。这个逻辑清晰、可量化，好不好一眼看出来。但管理者的价值逻辑是，你个人的产出几乎不重要，重要的是团队产出的总和。

你一个人再快，也快不过五个人。管理者的核心价值，是让团队持续把事情做成，而不是自己把事情做成。

放权不等于撒手。我后来练的是四件事。目标说清楚，让每个人知道为什么做这件事。边界划清楚，哪些能自己拍板，哪些必须同步。过程有反馈点，别等月底才发现问题。结果有复盘，成了总结方法，败了归因改进。

靠机制和信任转，而不是靠人盯人转。这件事不轻松，因为它本质是在对抗自己的惯性。但一旦转过来，团队状态会明显不一样。

三、第二个坑：把技术权威当管理权威

有个在工程行业摸爬滚打十五年的老兵，刚升项目主管时每天泡在现场。大到方案优化，小到钢筋间距差两公分，都亲自上。有次当场骂了新来的施工员，还自己重新测。本想立威，结果第二天对方递了辞职信，其他人也躲着他走。

他后来才懂，大家觉得他像个监工，不像主管。

你可能觉得，我技术最牛，团队当然听我的。这个想法在写代码时完全成立，在管人时往往反过来。技术能力是你的入场券，不是你的管理执照。

不是说技术不重要。是当你把变量命名不规范、代码风格不统一当成每天要 battle 的战场，成员会把你当成吹毛求疵的监工，而不是能托付成长的 leader。

我刚开始带人也犯过这毛病。盯着 code review 一个空格不对都要拉回来改，组员表面答应，背地里管我叫强迫症晚期。后来一个前辈点醒我，你是在用技术洁癖掩盖管理能力的空缺。

格局打开一点。技术管理者需要包容一定程度的不完美，暂时放下代码洁癖。功能质量出问题必须干预，但美观性、简洁性这种无伤大雅的事，先容得下，事后给改进方案。慈不掌兵，但也不能事事自己上。

说到底，管理者是团队的资源、军师和智慧星，不是保姆。你一看到成员做不好就自己上手，这条红线要严格按住。

fig02-compare

fig02-compare

四、第三个坑：只会埋头干活，不会向上汇报

还是那个工程老兵。他刚转管理时觉得，把活干好就行，汇报都是虚的。有次材料供应延迟导致工期滞后，他没及时报，直到领导主动问起才说，被批了一顿缺乏管理意识。

领导要的从来不是惊喜，是掌控感。你带团队干活，还得让领导知道进展到哪、遇到什么问题、准备怎么解。

落到动作上，其实就是三样东西。日报或看板让进度可见，周报同步风险和卡点，主动跟上级对齐目标。别等领导来问，等他来问的时候，往往已经晚了。

我见过一种更隐蔽的版本。有的技术管理者特别反感汇报，觉得那是在邀功。结果团队明明很饱和，领导却觉得不够，因为领导看到的只是「没声音」。后来我学会一句话，汇报不是证明你有多忙，是让上面知道团队在往哪走、需要什么支援。

向上管理不是拍马屁，是职业义务。你不做，信息差就会变成不信任，最后吃亏的是整个团队。

五、怎么判断自己适不适合？一张自测清单

聊完三个坑，回到最开始那个读者的问题。到底要不要转。

我给你四个问题，老老实实答，不用骗自己。

第一，你看到别人因为你而成长、升职、涨工资，是真心高兴，还是有点酸。管理者很大一块工作，是搭舞台让别人唱戏。如果你享受的是自己上台，这活会干得很拧巴。

第二，你能不能忍受通过别人完成目标的延迟满足。你改两小时代码立刻有反馈，但带一个人两个月才可能看到变化。受不了慢反馈的，会忍不住把活抢回来，然后回到第二个坑。

第三，你愿不愿意把沟通当成正经工作。我看过一组真实数据，一个带好几个团队的技术管理者，沟通能占到他时间的 40%，目标管理 20%，剩下才是架构和其他。如果你觉得开会就是浪费生命，先想清楚这点。

第四，遇到自己搞不定的技术问题，你是慌，还是知道去哪找大牛。管理者的技术职责不是样样精通，是有一个深耕领域，剩下的靠组织能力补齐。

fig03-decision

四个都答得舒服，你可以认真考虑。有两三个答不上来，先别急，可能只是还没到时候。大部分答否，那就放过自己，把技术这条路走深也挺好。

我始终觉得，管理不是非走不可的独木桥。技术专家路线走到深，一样有话语权、有影响力。别被「不当管理就没前途」的焦虑绑架。

六、转了之后，技术怎么办

这是被问第二多的问题。转了管理，手生了，怕被年轻人卷掉，焦虑得睡不着。

我的看法很明确。技术管理者不需要样样精通，但必须有一个自己真正扎进去的深耕领域。你是团队的技术天花板兜底人，不是百科全书。遇到搞不定的问题，发挥你管理者的作用，去找那个领域的大牛来破，这本身就是管理能力的体现。

对新技术的敏感度要保留，但精力有限，必须取舍。放弃一部分写代码的时间，放弃一部分技术全面性，换来的是对业务、对目标、对人的判断力。这笔账，长期看不亏。

我认识一个技术 VP，他现在几乎不写业务代码，但每次架构评审他能一眼看出方案在半年后会不会爆。这就是深耕出来的判断力，不是靠天天写 CRUD 练出来的。

所以别焦虑手生。你换了一种方式在长本事。从点的思考，变成线和面的思考，这反而是技术人更稀缺的能力。

七、写在最后

管理不是终点，也不是奖励，它是一种选择。技术还在你手里，一线管理者若是发现真不适合，回头继续写代码完全可行，因为技术没丢。

我始终觉得，与其纠结要不要转管理，不如先想清楚我想成为什么样的人。把这个问题答对了，转不转都是好答案。

如果这篇让你对转管理少了一点迷茫，点个「在看」让更多纠结的兄弟看到。下篇我打算写技术管理者怎么带刚毕业的新人，感兴趣关注一下。身边有人正在被推上管理岗、正犹豫的，这篇可以直接甩给他。

FAQ

转管理后还想写代码，怎么安排？留是可以留的，但要把它当成副业而非主业。基层技术管理者处理一部分核心开发没问题，关键是别让写代码挤占沟通和目标管理的时间。我的经验是，只写那些能定义技术方向、顺手带人的代码，纯搬砖的活交给团队。

技术管理者要不要追最新框架？要保留敏感度，但不用样样追。你最需要的是判断「这个技术对我们的业务有没有用」，而不是亲手把它用熟。把深度留给一个深耕领域，广度交给团队里对应的人。

被推上管理但不想做，能拒绝吗？能，但要讲策略。直接说不想往往被当成没野心，更好的说法是，我想先把某某技术方向做深，半年后看业务需要再定。把拒绝包装成路径选择，既诚实又不伤关系。

管理岗和架构师，怎么选？看你的成就感来源。成就感来自自己把难问题啃下来，选架构师。成就感来自一群人因为你而把事做成，选管理。两者后期都会往技术带头人收敛，不必一次定死。

带不好团队，会被换回去吗？一线管理者做不好，大多不是能力问题，是思维没转过来。真不适合，回到工程师序列完全可行，技术没丢就永远有退路。怕的是明明带得痛苦，还硬撑着不敢回头。