原文链接:Career Structure. It doesn’t matter. Until it matters.

Career ladder 的 ladder 比较容易吸引关注,因此有人认为不是太好的表述。Career Structure 是 Career ladder 其它表述形式之一,此处译为「职业发展路径」。

企业初创阶段,一般是民主的、精英化的氛围,头衔对于员工未必重要。但是随着组织的发展,人员的增多,会发生一些有趣的事情。作者发现,有一个清晰的职业发展路径,还是重要的。

文末作者还分享了所在企业推行并平稳过渡到新的职业发展路径的实践经验。

以下摘录他们制定职业发展路径的原则,以及划分工程职位级别时参考的关键指标


The principles 原则

举贤(你得配得上你的头衔):没有人是“被任命”为一个头衔。仅仅因为你在这有一阵子了,不意味着你就有资格晋升。在你升职前,我们期待你保持下一个级别的表现一段时间 —— 至少六个月。这件事上,衡量你成功的好的标准是,没有人会为你的升职感到惊讶。唯一的惊讶应该是一个同事说:“我早觉得你已经够得上这个级别!”

个人贡献者和人员领导者的平衡:我们对此深有感触。我们聘请有才能的人设计和开发了不起的东西,我们希望创造一个职业发展路径,鼓励使你变得优秀的技能发展。没有人应该觉得他们必须成为“管理者”才能获得晋升。这种平衡既适用于薪酬,也体现在日常运营。例如在都柏林办公室,我们把定期的“领导者会议”扩展为“领导者和首席(工程师)会议”。

(按:除了以上的考虑,把软件项目的主程序员[们]引入此类会议对业务有切实的回报,遗憾的是这种做法还不够普遍,还有些直系管理者将此视为对他们“权威”的威胁)

我们需要领导者而非管理者:当你拥有在自主的、紧密结合的小团队里工作的有才能的个人,你不需要去管理。我们从团队内部发展领导者。对于我们,领导者热爱他们的活计,但也通过领导他人获得真正的乐趣 —— 指明途径,设定方向,协调一致,并使团队成功。

鼓励员工尝试领导职位,并提供回归个人贡献者的途径:对于许多个人贡献者而言,把自己推向团队领导者位置的想法是可怕的。他们其中一些可能是出于谦卑(为什么我认为我自己比团队中的其他人更有能力领导?),其中一些担心失败(如果我就是不擅长这个怎么办?)。或许最大的恐惧是失去对技能和才干的掌控,而正是这个当初使你成为优秀的工程师。我们希望创造一个环境,个人贡献者可以在其中尝试领导角色,此后如果他们需要,还提供一条返回个人贡献者角色的途径。我必须承认,我第一次看到一个团队领导者被另一个资历更浅的团队成员取代,回归为工程类的个人贡献者角色,我真的认为这永远不会奏效。我错了,原领导(现工程师)和现领导只是专注于他们所擅长的,团队很好。

(按:这个确实不容易,恐怕还是需要更多元化的价值观支撑)

Key indicators 关键指标

知识水平:在一个特定级别预计需要多少领域知识和专长?

工作复杂度

监督:在一个特定级别某个人预计需要多少监督和指导?

经验

影响范围:这是我最喜欢的指标之一。在初期的级别,影响范围真的只是“自己”。当我们达到之后的级别,我们期待个人贡献者和领导者去影响他们的团队、部门、技术、更大的组织,以及行业和社区。

团队规模(针对领导者):关于团队规模有很多好的经验。(按:表略,更高的领导者级别对应更大的团队规模)

责任:你负责哪些系统,它们对于业务有多关键?

One big learning is that these indicators are only guidelines. I dislike the idea of career advancement being a box-ticking exercise: there is a qualitative judgement that we as leaders need to apply, and sometimes a candidate’s excellence in one area may make up for a deficiency in another, or, make up for organisational blockers.

一个重要的心得是这些指标只是参考。我不喜欢把职业发展当做是在格子里打勾的想法。作为领导者,我们需要做定性判断(按:而非定量判断,机械式地打分),有时候选人在一个领域的长处可以弥补另一个领域的不足,或者弥补组织的阻碍。