前段在文章里谈到程序员的晋升问题，讲到有位程序员技术不错，但因为对待晋升流程不够用心，导致晋升失败。有几条留言谈到这个问题让我发现，似乎有些程序员对于晋升的理解过于简单，认为“做到份了就该升”，就好像代码的运行逻辑一样。如果通不过，就是领导为难，公司作怪。
但是，事情明显比这个要复杂。我以为，面对程序员的晋升，起码应当搞清楚下面这几个问题。
直属领导有没有义务“保证”程序员晋升成功？
答案很明确：没有。
说直白一点，程序员是成年人，晋升这种事情应当自己负责，其他任何人都不应该成为保姆。称职的直属领导，可以给下属足够多的职业生涯指引，协助下属做好晋升相关的准备。但是，直属领导没有权力也没有义务“保证”晋升成功。
直属领导为什么不能决定程序员的晋升？
有种说法是：下属干了多少事，有多少本事，难道你心里还没点数吗？为什么要在晋升上“为难”他？
这种说法，前一部分对，下属干了多少事，有多少本事，直属领导应当是清楚的，否则他就不称职。但是下属程序员的晋升一定不能由直属主管决定，否则如何平衡不同的直属主管的评价标准呢？同一家公司里，甲团队的 P7 和乙团队的 P7，技术水平相差明显，外人会怎么想呢？
我的一个朋友带团队时要求很严格，大家素质很高，很有追求，心也很齐。但是偶然的小事把这一切都摧毁了：有个成员打听到其它团队的职级和待遇，才发现“我们老大对我们太狠了，要求太严格了，我们吃大亏了”——因为他打听的那个团队，领导无方，晋级把关非常松。
所以一般来讲，直属领导决定程序员的晋升是会造成很多问题的。退一万步说，如果都是直属领导说了算，那么 HR 是吃干饭的吗？
怎样“拉平”不同团队的职级
常用的办法就是靠统一的能力模型，这基本是成熟大公司的必备。
我随手搜了一份某大厂的能力模型，仔细看看就发现，即便是研发工程师，也不只考核写代码的能力，还要考虑素质（包括学习、提炼能力，沟通、谈判能力，执行力等），知识技能（还包括风险识别与管控、业务能力、项目计划能力等），客户导向（成本分析、项目管理能力等），领导力（团队影响力、带人的能力、知识传递能力等）。
所以，规范的晋级流程真的不是要用 PPT 去“为难”程序员，去“强求”工程师锻炼嘴皮子，而是要求程序员不能有明显的短板，技能组合基本齐全，能提升组织和协作的效率。
这样会不会有不公平？不会。只要能力模型和晋升机制是公开的，并且不U会临时变化，程序员就可以提前做准备——从某种程度上讲，这也是职业素养的体现。
业绩好但晋升不了，正常吗？
正常，太正常了。业绩虽然是晋升时的重要考虑因素，但绝不是充分条件。
为什么？因为业绩是对工作成果的衡量，而职级是对能力的衡量，二者并不是完全重合的，不能混为一谈。
常见的情况是，因为员工在过去一段时间加班特别多，或者赶上了市场爆发的好时候，工作业绩确实有很大提升。但是，员工的能力（决策判断能力、协调能力等）并没有对应的增长，甚至完全保持在原地踏步。如果这时候晋升职级，员工能掌握更多权力、调动更多资源，反而可能捅出更多的篓子，也会让其他人“不了解业绩”的同事感觉不公平：某某的能力和职级并不匹配呀。
怎么解决这个问题？一般要做到两点，一是要严守能力模型和职级体系，保证公平公正；二是把奖金和工资分开，奖金是对业绩的肯定，而工资是对能力的认可。实际上如今许多成熟大厂仍然在用这套办法，因为行之有效，可惜我倒是见过不少小公司，因为舍不得发奖金，硬生生把创业搞成了打工。这样的悲剧，还是尽量避免的好。
如果你对晋升有其它的看法，或者有独特的经历，欢迎留言告诉我。
