去年年底，在回顾那几年的 Tech Lead 生涯，以及对新 Tech Lead 的培训时写了那篇 《Tech Lead 的养成》。在新的团队稳定了下来之后，我开始寻找下一个合适的成长路径，或者说是模型。因此，从某种意义上来说，这是一篇写给自己的文章。

最近，我在探索中发现公司内的各种 Growth Paths（成长路径）已经成熟了，比如我试着重新对比一下其中各类的模型，Technical Anchor。那么，我的下一个阶段是不是应该与 PRINCIPAL ENGINEER 相挂钩？

职级并非与能力挂钩

PS：我只在 ThoughtWorks 待过，所以我对其它公司的职级体系也不是非常了解。所以，其中的部分内容来源于：我在和客户一起工作时所总结的，还有网上所看到的资料。

职级是 在某一组织内部 ，将工作内容、难易程度、责任大小、所需资格皆很相似的职位划分同一职级。

对于大部分公司来说，职级体系必然与薪资体系相挂钩的。你的职级越高，你要做的事情 level 更高，那么你的 应得 收入就越多。即从理论上来说，你创造的价值越大，那么你所获得的收入就越多。比如说，程序员 A 写了某个业务系统的关键代码，这个业务系统非常成功，那么你创造的价值就远比另外一个程序员 B。（PS：但是实际上并非如此，有可能不会伴随你产生的价值）。

与此同时，A 之所以拿的工资比 B 高，并非因为 A 的编码能力比 B 强很大，又或者是因为 A 的其它能力比 B 强。而是因为 A 刚好出现在一个合适的地点上，所以 A 有了更多的职级和更高的收入。

当然了，那些在 BAT 996 的程序员，能力都是比我强的。

职级与能力：外在与内在职业生涯

PS：在写文章的过程中，我看到了一个更专业的词汇：外在职业生涯与内在职业生涯

• 外职业生涯（对外在职场而言），是指从事职业时的工作单位、工作时间、工作地点、工作内容、工作职务与职称、工作环境、工资待遇等因素的组合及其变化过程。
• 内职业生涯（对个人自身而言），是指从事一种职业时的知识、观念、经验、能力、心理素质、内心感受等因素的组合及其变化过程。

多数人在他/她们的职业生涯间，都要面对着各种各样的角色变换。或是从开发人员变为产品经理，或是从测试人员变为项目经理，又或者是从程序员变成滴滴司机。在过去的几年里，我也面临着一些细微的变化，如从开发人员变为技术负责人，从交付项目来到咨询项目……。唯一不变的是，写代码还是我日常的主要活动，但是我需要提升其它能力。

简单来说，内在就是你想做事情，外在的就是你做的事情。这两点的平衡是一件非常有意思的事 —— 尽管我一直平衡不好。

角色成长路径

每个成熟的公司都有对应的职级路径，至于划分的好坏就是另外一回事了。晋升就是与职级路径相匹配的活动，它会伴随在我们的外在职业生活中。而这部分的内容不是这篇文章的主题。

回到标题上来，看看 Technical Anchor 角色的定义：

具有丰富的技术和行业知识的领导者，沟通者和工程师。 能够提供技术合作的信心和方向。 他们拥有解决方案和技术堆栈的设计和架构，从头到尾对其进行指导。他们专注于确保团队内部战略的成功实施

这是一个角色，并非与真实的职级挂钩。这个角色定义的能力有诸如于：

• Technical visioning and roadmapping
• Evolutionary Architecture
• Integration
• ……

但是呢，Technical Anchor 的定义上和我去年定义的 Tech Lead 最大的区别在于：这个角色要花 70% 的时间在代码库上，而 Tech Lead 要花费的只有 30%。Tech Lead、Tech Anchor 以及 System Architect 相当于是这个第二级角色。

PS：一级角色就是具备完成工作能力的成员。简单来说，对比如下：

• 新手 vs 普通程序员
• 骑士 vs Tech Lead 等
• 圣骑士 vs Principal Engineer 等

这个过程，非常有意思，我们要围绕的是能力成长。换句话来说，我们需要练习打更强的怪，才能获得职业成长。如我司定义的 Principal Engineer

A Principal Engineer is a highly experienced technologist who drives the success of a complex engagement through the depth and breadth of their engineering skills.……

它要做的事情是 推动复杂交付的引擎室 ，对应有一些关键能力：

• Legacy Mitigation
• Application Architecture
• Cloud Native Architecture
• Back End Development
• Distributed System Architecture
• ……

如果每一级都定义好了，那么我们只需要有针对性地提升能力，并进行实践即可。

其它

整个过程中，唯一麻烦的点在于，如果在一个组织内部，只有职级，而没有成长路径。那么，就需要从社区上来获得对应的能力模型，才能想着配套上对应的练习。

原文 http://www.phodal.com/blog/growth-path/

本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！

链接: https://fly63.com/article/detial/10039