编者按：初创企业在早期一般都是人人身兼数职，倡导扁平化的管理，并不怎么看重头衔。但是随着组织的扩大，初期的这种管理模式会引起诸多问题。身兼软件工程师、经理与创始人角色的Chuck Groom从个人经验出发，分析了设定工作阶梯的好处，并提出了他的建议。无论是创业公司管理人员还是软件工程师都可以参考一下。
软件公司应该审慎地考虑工程岗位职级的设置，制定好一个工作阶梯，向员工解释清楚对其的希望，不同角色之间的区别，以及职业发展的领域。
在本文中，我将讨论为什么制定工作阶梯可以帮助到每个人；好的工作阶梯应该是什么样的；我对软件工程师职级是如何思考的；最后我还会提供一些建议。尽管本文的受众是管理层，但工程师看了之后也应该能从公司的角度去思考而获得一些洞察。
注意，本文仅讨论独立贡献者（IC）的工程发展路径。其他并行的发展路径（管理、产品）包括转岗均不在本文讨论之列。这些话题都值得讨论，但不在本文范畴之内。
是的，工作“阶梯”的想法有点奇怪
工作“阶梯”这种说法暗示了所处行业的高度结构化、非常稳定的，有着抵达某个有意义的终点的长期路径，就像成为合作伙伴那样。但是现代的职业流动性更强发展方向更加多样。员工往往每几年就要变动一下工作。
不要把职业阶梯看成是长远的人生规划。这样你会把太多关注放在阶梯顶部（“我究竟应该怎么过我的一生？”），但这是你下一步的关注重点。阶梯就是个工具，让你设定好对未来几年的期望。
假设你没有工作阶梯
新公司或者团队往往对头衔或者角色没有很好的定义。实际上，这他们也许反而会引以为豪；你应该听说过“我们是一家扁平化的组织”，“头衔并不重要。”尽管大家的薪水可能很不一样，但大家普遍感觉这是英才管理的模式。
好吧，如果没有工作阶梯地球也照转的话，为什么要自找麻烦改变这些呢？我们可以看一些例子。
-
Frank希望晋升到“资深”头衔，但是我们感觉他还没准备好；但是他反问为什么不行→ 我们得想办法解释不同职级之间的差别，并且指导Frank应该发展那些技能。
-
我们在面试一位候选人。大家都比较中意她，但在招聘汇报时我们对提供2级还是3级的角色意见产生了分歧→没有清晰定义的招聘门槛，重要决策就变得太过主观了。
-
我们的初创企业没有正规的头衔。我们刚刚融了A轮，并且还一并引入了新的领导层。经过紧张的闭门磋商之后，他们给每个人都分配了职级，但是很多工程师非常恼火自己只是“初级。”→哦废话，头衔不重要直到它们变得重要。现在一堆人恼火失望了。
-
几年前我们以85000美元的年薪招聘了Karen。今年夏天我们又雇了Noreen——在跟Facebook抢过一轮之后，他的薪水被提高到了120000美元//年。Karen和Noreen做一样的事情。一次喝酒之后，Karen发现Noreen的工资居然比他高这么多。→这是个灾难。每个人12万美元我们可支付不起。但Karen完全有理由宣判这是犯规。
当设定好职级时每个人都是胜利者
工作阶梯对员工和公司都有帮助。
-
管理：好的经理应该对员工表现是否满足当前职责要求，以及需要发展哪些职业技能给予定期反馈。工作阶梯提供了一个不带偏见的框架来框定这些讨论。
-
招聘：好的工作阶梯应该能够很容易地帮助设定对应聘人员的技能集要求。团队可以针对每一级建立一套标准的问题集和招聘门槛，并且对员工之间进行同类比较。
-
HR薪酬范围：只要招聘员工就得确定薪水问题。这就需要确定内部层级以及将这些层级与业界市场费率匹配的手段。
公司原则
工作阶梯传达的是那些技能和特质重要。这些必须与公司的使命与价值观一致——你希望大家把解决问题的文化聚焦到最终客户、解决冲突以及做出艰难决定上。出现在公司原则和使命的语句应该纳入到工作阶梯里面，也应该用到员工反馈里面。Amazon的领导力原则就是很好的例子。
好的工作阶梯应该包括哪些要素？
制订得当的工作阶梯应该做到：
-
解释不同职级的差别并证明其合理性。每一个职级应该是尽可能不同的角色，而不仅仅是不同的技能程度；你需要的是阶梯函数而不是渐变函数。
-
告诉员工那些因素影响到晋升（以及自我改进）。工作阶梯是职业发展计划的记录，同时也应该能够解释用于员工评估的条件是什么。
-
应该容易理解和阅读。少即是多。这应该是结构清晰语句精炼的参考指南。
反模式包括：
-
角色跟我们所做的事情并不匹配。职级和价值观的描述跟我们日常经历和需求并不一致。
-
技能和表现列表很长。员工可能会把这些当做晋升的检查表。这样很容易一叶障目不见泰山，导致大家迷失在细节中而忘了不同层级之间的本质区别。
-
写得像算法一样。一些技术公司似乎认为自己可以建立一个客观的、机械化的流程。对不起，但人的管理永远都是混乱且多少会有些主观性的；你最好把工作阶梯写得人性化一点，要有雄心勃勃的目标，听起来模糊但却是真实可靠的。
我针对软件工程师制订的工作阶梯
我倾向于按照所有权和责任范围而不是既定的技能程度制订工作阶梯。我之所以偏好这种模式是因为它跟任务分解和分配方式匹配得很好，而且不同层级之间也有着明显的不同。
当然，技能仍然非常重要。所有软件工程师都必须能够写代码并且在团队环节下解决客户问题。我发现的一些基本特质包括：
-
编程能力：编码、设计、测试、系统维护，
-
沟通：有效邮件和Slack通知，前瞻性的状态更新，结构化的基于事实的论断，协作。
-
批判性思维：平衡短期需求与长期目标的矛盾；思考可能会出错的地方；找到需求。
-
主动性：有活力、主人翁精神、做事有头有尾坚持到底。
不过话又说回来，这些能力之间其实也没有明显的“阶梯函数”级的差异，你随便拿出一项技能就能够说“啊哈！这意味着你是2级而不是3级水平！”我的工作阶梯假设的是这些特质重要，但避免特别的指引。
唯一的例外是4级（及以上水平）工程师；这个层级及以上需要非常深厚和特殊特殊的技术和架构性经验。
1级
-
外部头衔：[初级]软件工程师
-
角色：开发定义好的功能，调查和修复bug，写测试。沟通进展情况，识别阻塞问题。找到工作生活平衡。
-
反模式：糟糕的代码质量。缺乏上进心；需要有人告诉自己接下来该做什么。经常转到无用的事情。更愿意发牢骚而不是撸起袖子加油干。通常很无奈。无视团队进展。
-
经验：0到3年
初级工程师可以给公司带来很多的原始活力和潜能。他们做你交给他们的工作——往往是很多的工作。不过他们需要帮助，要有预先的项目计划，要把任务分解成特定的工作细项。团队领导需要经常检查一下，确保他们没有偏离方向。
我更愿意给他们的头衔时“软件工程师”（把“初级”去掉），因为没人希望被叫做“初级”。在内部你可以叫他们1级工程师，这并没有冒犯之意。
我发现1级工程师的面试是最难安排的，因为候选人的技能水平都差不多。主动性和批判性思维是最重要的，但这些特征很难在1、2小时内就判断出来。2年内没法晋升到2级的1级工程师就让他们走吧。
2级
-
外部头衔：[资深]软件工程师
-
角色：负责某个功能领域。把大型请求分解为子任务，提交更高层的状态更新。编写测试计划。承担运营责任。制定可衡量目标，并且达成目标。审核代码变更。帮助导师招聘新人。
-
反模式：消失到对企业不重要的项目当中。无法识别或者沟通大的障碍。区别你我的工作态度。不断低估时间表。不认真对待卓越运营。解决方案过于复杂。
-
经验：约1到8年
2级工程师可以负责某个重大的软件很大一部分。你可以信任这些人，他们可以把松散定义的请求做对——分解负责任务，做出合理决策，而且在定期检查间相当独立地自主工作。沟通和批判性思维是必须的技能。
这些人应该叫做“软件工程师”还是“资深软件工程师”呢？我持中立态度，但倾向于2、3级工程师的名片和LinkedIn上面都用“资深软件工程师”的头衔，而内部就按层级称呼他们。
尽管有的2级工程师可以当好几年，但最终他们应该能证明自己可以承担更多的责任并晋升到3级，否则的话就离开组织。
3级
-
外部头衔：资深软件工程师
-
角色：对整个产品或者大型项目的开发和推出负责。责任流程（Scrum、TDD等）。编写技术规范，在开始重大项目前识别风险。制定标准。想方设法减少复杂性。根据需要，承担额外的“技术领导”责任来推动主动完成。
-
反模式：傲慢的蠢人。不授权。总是说“是”把自己搞的筋疲力尽。没哟最细考虑就着急做。不注意细节。无法提高对项目风险或者人事问题的意识。不遵循新技术或者行业趋势。
-
经验：约5+年
3级工程师对整个产品（比如整个应用或者整套服务）负责。除了交付可靠、可维护的软件以外，他们还了解公司动态和好的流程是什么样的。
资深工程师往往还要额外戴一顶“技术领导”的帽子。这意味着他们要承担（吃力不讨好的）项目管理和流程监督的工作。他们要保证列车准点运行。注意，技术领导并没有直接上级也没有老板，他们完全是靠责任感来做事。
4级（及以上）
-
外部头衔：架构师（或首席工程师，或发明个很酷的头衔）
-
角色：负责跨团队共享的的基础设施。跟CTO及其他架构师一起选择新的技术，促进文化/流程。在关键业务领域具备深厚的技术专业知识。进行认真的调研来评估和测试选项。理解可靠性、伸缩性、营业成本、组织容易采用、招聘等的影响（以及权衡）。
-
反模式：过于强调伸缩性或高可用性而不是业务需求。花费太多的时间追求最新的“亮点”技术。不协作或者提出问题。居高临下。有“宠物”议程。厌恶资深领导。
-
经验：约8年以上
4级工程师是能够评估系统级平台决定设定长期的公司级技术战略的架构师。他们往往有两种角色，既是某功能团队的独立贡献者，也是跟CTO合作的架构审核人员。你的架构师应该是谦逊的，外向的；他们是你工作上的拉拉队。
其他工作阶梯
当然，这里设定工作阶梯只是其中的一种，你可以跟其他出色的博客比较一下。这里就有一些：
-
Fog Creek （Joel on Software）
以下这些领域你会看到不同的观点：
-
独立贡献者的职级应该有多少种？（3？6？）元老级的那些家伙应该如何对待？
-
工作阶梯应该规定得多详细？（这牵涉到复杂的分数制度、电子表格矩阵、文章段落，或者只是几条一般指导）
-
“技术领导”的角色和责任是什么？
-
谁负责项目管理？
相关建议
什么时候需要建立工程工作阶梯？
要我说等到你有5到10位软件工程师并且开始考虑找人当全职经理时，就应该开始考虑明确工作角色和职业路径了。
谁来编写工作阶梯？
让一个委员会从头开始编写一份好的工作阶梯是很难的。我建议先找一位工程经理写好草稿，然后交给工程管理团队进行讨论和研讨。另一个办法是让所有的过程经理各写一份草稿，然后碰头比较一下，再由委员会合并。
头衔很重要
即便有人真诚地告诉你“头衔不重要，”其真正含义也只是说“目前这个时候头衔不重要。”随着公司的发展，职级设定是不可避免的；头衔可以用来作为职级的代表，要求要有相应的薪水和职业选项。当你换工作时，招聘和工资薪酬也要以你的上一份工作作为参考。
永远都要确保写清楚你的头衔和角色。
工资跟职级绑定，用股权激励表现
要当成你要把它贴办公室门口一样管理工资
— M. W. Mantle,《知人善用，Managing the Unmanageable》
雇主应该基于行业可比数据针对每一个职级都建立一个薪水范围。基于基本工资水平，或者用大幅加薪来奖励一流表现者的确会限制他们招聘到明星求职者的能力，但这是保证预算在控制范围并避免不公平的唯一可靠办法。
予以一次性股权授予并设定未来的最短生效期是比较好的做法，比方说授予2年期权每年行权就是奖励特别出色员工的一种手段。这向关键员工表明即便你不能给予大幅加薪，但你仍然非常重视他们的贡献并且希望他们留下来继续一起奋斗。
提拔看能力而不是资历
提拔一般不是奖励其过去的表现。相反，管理层提拔的是那些展现出解决下一级的更大更棘手问题潜能的人。
— Ray Weiss，《技术生涯导航员（ The Technical Career Navigator）》
提拔那些已经胜任下一级别职能的人。如果一位2级工程师想要获得晋升，他们应该展现出可以做3级工作的能力。作为经理你的工作是提供项目给他们，让他们获得初步经验（并且在他们不大胜任的情况下保证项目的软着陆）。
不要让大家以为晋升只是时间的函数，或者对能力不够的人打开晋升大门。
不必要求计算机科学学位
就1-3级工程师而言，我并没有发现正规教育是成功的可靠预测指标。我就见过好几个表现出色的人是自学成才的，或者是参加了6个月的职业编码学习后过来的。我不再要求应聘者具备CS本科学位，而且面试的时候也不再问一些偏重算法的问题了。
4级（首席）工程师角色是例外；这个角色在算法、系统、架构等等方面需要有可靠的学术基础。
第三方适用工作阶梯吗？
不；他们是受雇方。你对他们的评估不在于他们的能力水平，而在于他们是否完成了特定项目。
实习生适用吗？
再次强调，实习生不在工作阶梯范畴，因为你没有当全职来雇佣他们。对于实习生我的原则是这样的：
-
你开展实习生计划的原因是想从中物色好的苗子次年招聘为1级工程师。（当然也有其他一些好处，但这是主要原因）
-
因此，仅招聘那些准备毕业并且次年要就业的那些实习生。避免大二学生和毕业生，因为这些人未必会留下来。
-
招聘实习生的条件是：这个人明年能否达到我们初级工程师的招聘门槛？避免招那些态度冷淡的人；好的学生表现的确非常突出。我通常会挑选那些已经写过不少代码而且讨论起来总是很兴奋的人，比方说在Github上有业余项目的那些。
最后思考
员工希望了解自己在组织里面的位置。有一个职业的里程碑，把期望和目标都写得清清楚楚会让每个人的工作都变得更加容易。
编写工作阶梯的时候，关键要：
-
职级跟公司的组织方式匹配（角色、汇报结构）。
-
招聘和晋升的条件跟公司价值观一致。
-
保证公平。
制定了工作阶梯后你也可以在今后调整角色和评估标准；但是一定不能违反公平性原则。每个人都必须坚持一致的标准，否则你的士气和生产力就要崩溃。一份好的工作阶梯能够创造出公平的职场竞争环境，为比赛设定好规则。
