为什么很多程序员不愿意转管理岗？
做管理者，天天面对的，都是一堆的不确定性性，心理压力很大，很容易心累的。
比如说：团队的人你能不能招到，招到了留不留得住，项目能不能按时交付，上级对团队的预期你能不能达成，这些变量不全在你一个人手里的。你做了所有你认为正确的事情，结果可能还是不好。反过来，有时候你什么都没做对，结果反而还行。这种投入和产出之间的非线性关系，是管理岗最让人不安的地方。
下面说说管理岗的不确定性到底体现在哪些地方。
做开发只需要对自己的代码负责，做管理要对整个团队的产出负责。你只有真正坐上那个位置你才知道这句话的分量。你写代码，你加把劲就能多交付一个功能。你带团队，产出是十几个人共同决定的，变量不全在你一个人手里。某个人今天状态不好，某个模块的技术方案选错了，某两个组员之间配合不顺畅，任何一个环节出问题，最终都反映在团队产出上。而这些事情，你作为管理者，你不能替每个人写代码，也不能替每个人做决策。
我之前做过一次大的系统重构，把核心模块从PHP转成Java。方向是对的，团队也需要这个事情。但推动的过程极其艰难。下单接口灰度上线，折腾了9次才全量。每次刚放一点流量进去，不是接口报错就是数据不对，只能切回老接口。测试人员和运维被反复折腾，到后面意见很大，觉得别上了，对生产环境要有敬畏之心。产品经理天天来问全量了没。作为推动这个事情的人，你一方面要承受多方的压力，另一方面结果是高度不确定的，你不知道下一次灰度会不会又翻车。
团队产出的不确定性还只是一层。更具体地说，你手里是握着实打实的权力的，而这个权力本身就充满不确定性。
管理者是有真权力的。给组员打绩效、定建议工资、决定谁是核心骨干谁不是，这些权力不是虚的，它直接影响每一个人的收入和发展。很多人以为做管理就是分分活、催催进度，实际上管理者最核心的权力场景，是每半年或者每年给组员打绩效的时候。
绩效这个东西，直接决定了年终奖拿多少、工资涨不涨、能不能晋升。你给谁A给谁C，每个决定都在改变一个人的轨迹。这种权力带来的其实是压力。因为你很清楚，你在excel那么一填，对面那个人未来半年的收入和职业发展就不一样了。
最痛苦的是公司强制分布的情况，就是那种规定团队里必须有人拿C的。你手底下有个人，工作态度很好，每天来得很早走得最晚，但你认真评估他的产出，今年确实不够。你还是得给他C。打完绩效之后面对面谈，你看着他的眼神，你知道他心里在想什么，他也知道你在想什么。但你没得选，制度就是这么定的。
这种心理负担，做开发的时候是完全不会有的。开发岗的绩效基本就是看你自己的产出，代码质量怎么样，交付了多少需求，线上有没有事故。你对自己的绩效心里有数，不存在要给队友打C的问题。管理岗的绩效评定是在给别人做裁判，这个角色的心理压力完全是另一个级别的。
而且这种压力是「周期性」的，每半年或者每一年来一次。每次评定之前那几天，你得反复权衡和找数据以及分析：这个人给B+还是A-，那个人到底算B还是C，给了A的人后面会不会觉得不公平。这些纠结不是技术问题，技术问题你查文档、看源码、跑跑压测，相对而言比较容易找到答案。这些是关于人的判断，没有标准答案，你怎么选都会有人受伤。
真可谓是：几家欢乐几家愁，哎，每年都是如此循环。
这种持续的心理消耗，慢慢会变成一种很特殊的状态。
开发岗的累是身累。加班到深夜，赶项目上线，身体疲惫是真实的。而管理岗的累是心累。半夜躺在床上，脑子里转的不完全是代码，是某个人最近状态不对是不是要走、某个项目下周能不能按时交付、老板上次开会说的那句话到底是什么意思。这些东西不会因为你下班就停下来，它会一直跟着你。
网络上有一项基于两万多名全职工作者的研究，发现管理层有18%的人报告了抑郁症状，而基层工作者是12%。中层管理者的心理健康风险比基层和高层都高。这个数据不奇怪。基层员工的压力来源相对明确，做好手头的事就行。高层有足够的权力和资源去推动事情。中层管理者恰好卡在中间，上面有预期要满足，下面有团队要操心，手里有的资源又不够多。这种上下受压、又缺乏足够掌控力的状态，是心理问题高发的温床。
心累还有一个很隐蔽的特点：它会侵蚀你的判断力。身体累了你知道要休息，心累到了一定程度，你自己可能意识不到。你会开始变得犹豫，该拍板的事情拍不了，该推的事情推不动。管理者要做的是决策而不是做决定，决策是一次解决一批问题，决定是一次只解决一个问题。做错了决策，全组人的时间都白费了。管理上的决策失误，往往要过几个月才能看到后果，而且后果波及的是整个团队。
没有足够强的心理韧性和意志力，不建议去碰管理岗。这不是能力问题，是承受力的问题。这个是我做了9年管理，特别想要说的。
且管理岗的不确定性还不止这些。一旦你带团队，上级对你的预期会急剧放大，这也是一个很大的压力来源。
你做开发的时候，上面对你的预期很明确：代码写好，需求按时交付，线上稳定。你做管理之后，预期会急剧膨胀。团队战斗力够不够？有没有有效的产出？注意是有效的，不是做了多少事情，是做出了多少对公司有实际价值的成果。成员的成长和梯队建设有没有在做？团队的技术规划有没有？稳定性建设、安全建设、基础组件、架构设计，这些规划层面的事情，上级都会看。
上面列的这些，有几项没达标，你的绩效就不会好。而你的绩效不好，不是你自己一个人的事，是你带着十几二十个人一起不好。这种放大效应让管理岗的失败成本远高于开发岗。开发岗绩效差，影响的是你自己。管理岗绩效差，影响的是整个团队在公司里的处境。
如果你抢过蛋糕，肯定就知道我在说啥，你能否拿到大一些的蛋糕，跟你管理水平和产出强相关的。
我之前写过一篇关于团队管理的内容，里面列过几条自检标准：团队有没有产出，难事你能不能推过去，队伍稳不稳，下面愿不愿意跟你干，结构和梯队有没有。这几条里任何一条亮红灯，你在上级眼里就是不合格的。你不需要每条都满分，但你不能有明显的短板。问题是，这些标准里的每一条都有大量不可控因素。队伍稳不稳，取决于市场环境、薪酬竞争力、个人发展诉求，这些你说了不算。
说了这么多，回到问题本身。
人心是不确定的，你永远不知道他明天会不会提离职，不知道他对你的安排是真心的认同还是嘴上说说。管理岗的不确定性根源就在这里：你的工作对象是人，而人是所有变量里最不可控的。
这不是说管理岗没有价值。一个好的管理者对团队的贡献是巨大的，能带着做成很多人原本做不成的事情。但这个岗位需要的心理素质和承受力，跟技术岗是完全不同的两套东西。技术好不代表适合做管理，这个道理很多人都懂，但很少有人真正从内心接受它。因为社会默认的路径就是做技术做到一定年限就该转管理，不转就是没出路。
这个默认路径该被重新审视了。行业需要给资深开发者提供足够的技术通道，让他们可以在技术线上持续深耕，而不是被年龄焦虑推着去做一个自己不想做也不适合的岗位。
选择继续写代码，是因为清楚自己更适合跟确定性打交道。