Facebook 工程师的发展之路

Quora 上有人提出一个问题：

Facebook 的工程师在职位上如何提升？你们需要玩儿政治吗？是不是跟最善于展现自己的团队坐在一起？是不是先要帮你们的经理升职？还是就是坐下来不断写代码就好？

Nam Nguyen 是 Facebook 的工程师，他对上述后四个问题的回答是：

不；不一定；不；是的但不是惟一的方式。

他进一步说明了自己的感受：

跟我在其他公司工作时差不多，原则和指南都是类似的，我们有文档说明对于不同级别的人的期望，而且我们用这些期望作为指南，帮助我们在评审和校准人员时，就有关升职问题协助决策。不过，Facebook 的工程师部门看起来要做得好得多。

在 Facebook，工程师要想得到提升，要有“持续的技术卓越表现，并以贡献和影响的方式展现”。绩效评估从常用的流程开始：自我评估、同事反馈、经理评估总结。此时，经理会评估每个工程师的贡献和影响，对于优秀的工程师，会推荐他们得到提升。然后，我们会进入校准阶段，在决定是否要提升前，我们会跨越多个级别和团队对推荐人进行评估和讨论。

虽然这听起来跟其他公司差不多，但是 Nam 指出：

Facebook 的工程师经理在下面这些领域接受了指导，而且有持续的关注和实践：

1. 非常重视同事反馈。在我工作过的其他地方，经理的反馈要比同事反馈更重要，因此会有偏向，办公室政治也就很有可能发生。这里不会。
2. 校准以非常透明和协作的方式进行。虽然总是有例外，不过，人们倾向于没有那么强的防御性，在这些讨论中心态更开放，因此更公平、更平衡。这就解决了对于“要在最善于展现自己的团队和项目中工作”的担心。如果“善于展现”意味着“工作的影响和意义”，那么当然，自然会有人看得到。校准的讨论也有助于减少经理的偏心，因为我们把重点放在目标、角色和每个人的影响上，而不仅仅是一个经理在要提升某个工程师时用到的各种形容词。
3. 尽管我们有指导方针，但我们也知道每个人都是不一样的，因此我们不会强迫每个工程师走同样的路径。一般说来，在展现出自己的技能和贡献足以满足高一级水平的要求后，大部分工程师都会得到提升（我们称为“牵引式提升 [trailing promotion]”）。在校准阶段中，我们会把级别 N 的工程师 A 跟级别 N+1 的好工程师们放在一起，看看工程师 A 是否“属于”这里。如果是肯定答案，提升是自然而然的。即使答案是否定的，我们也会再讨论下，因为我们知道每个人都有其特点。很多工程师得到了提升，是因为他们产出了很多优秀和有影响的代码。我们也会基于以下因素提升工程师：出色的想法、指导和帮助其他人、优秀而具革命性的工程设计、在效率上的提升。虽然我说过“持续的贡献水平”，我们也曾发现和提升了一些工程师，因为他们一次或几次的卓越表现，而其卓绝的成果为公司带来持续的正面影响。

在我看来，上述这些东西都很重要，因为升职以及对应的奖励尽管是好事，但也可能变成坏事，因为对他接下来的表现有了更高期望。理想情况下，我们希望：每个工程师都能放在其人能持续表现、并不断为人认可、得到激励的位子上。过早或不成熟的提升，会伤害工程师，因为待遇不仅仅取决于级别，还取决于绩效评估。从这个角度上看，办公室政治在长期也就没什么立足之处了。

另外一名曾工作于 Facebook 管理层的人也留下了自己的看法：

至少在当时，经理和总监在讨论谁应该得到提升时，讨论的中心是：哪个工程师帮助其他人最多。

高水平的工程技能仍然是个前提条件（你可能帮助了不少人，但如果你不在顶级工程师行列，那你也没戏），个性不能太过侵略性（你可以有一点儿粗鲁、没耐心，但要是得罪了太多人，那你也没戏），要是你这两点都具备了，那就要看谁最有“服务他人”的心态，因为我们希望在经理中推广这种心态，也希望在技术成长阶梯上前进的工程师们发现这一点。在技术阶梯上最好的工程师，同时要是最能“残忍地”帮助其他人的工程师。

敏捷咨询专家，敏思特咨询首席合伙人王晓明在微博上对此文的评论是：

表面上是讲 Facebook 工程师的晋升之路，实际上是讲如何避免办公室政治。总结：1，所有信息透明，可视（当然不包括薪酬）；2，更重视合作同事之间的 review 而不是 manager；3，给团队一个更有挑战的工作，如果他们胜任了就晋升。

InfoQ 中文站的读者们，你们所在的公司和团队是如何为工程师提供上升空间的？Facebook 的方式对你们有借鉴吗？欢迎在评论中留下你们的反馈。