工程判断力书库

Q什么是“造王国”（empire building），为什么它在大公司里一直存在？

伊森把“造王国”定义为只关注原始的人头数，而不关注一个团队做了什么或产生了什么影响。他说，它之所以存在，是因为它受到奖励，而它受到奖励，是因为数人头是最容易做的事。影响力是主观的：一位领导可能觉得某个项目很难，另一位可能觉得很容易。没有人能反驳“一位经理有 42 个人，另一位有 17 个人”这个事实。

伊森补充说，有些公司把人头数的门槛写进了晋升标准。得到这样一个目标的高绩效者会想办法达成，包括声称自己需要人手，或接管其他团队，并且会对自己把这一切合理化。

Q重组往往带有第二个未说出口的动机吗，比如让某个人得到晋升？

伊森说，总是有别的事情在背后进行。领导们知道，重组太多会让他们失去人才，所以会尽可能拖着。等他们终于行动时，会问怎样才能把想要的全部拿到：怎样少给一个他们希望离开的人一些，给一位高绩效者铺路，并留住关键人物。他说，一旦业务理由敲定，问题就变成：在船离开码头之前，还能往上面再装些什么。他指出，经常有人来找他，说老板告诉他们，他们被安排到一位同级名下，是为了让那位同级有足够的职责范围去争取晋升。

伊森说，因为一次重组通常规模大到会有人来审查，所以领导必须构建一套叙事：这次重组奖励了值得奖励的人，达成了业务目标，而任何痛苦都落在不是顶尖绩效者的人身上。他回忆自己做过的重组，大多是为了留住人才，问的是他必须留住谁、又能接受失去谁。他想不起来自己曾把某人放进一个岗位、却预期他们会辞职，但他记得自己用重组给一位有离职风险的人更有吸引力的东西。

Q重组和晋升中，是不是“会哭的孩子有奶吃”？

伊森说，这句老话有道理，而人们不喜欢这个残酷的事实。如果两个人表现大致相当，其中一人明确表示在考虑离开，经理可能会推断那位忠诚的人会再等六个月。于是经理用这六个月去挽留另一个人。伊森说，这并不是为了伤害那个安静的员工，但那个人可能仅仅因为“人好”而落后。

他经常对辅导的客户说，他们人太好了，而在这种语境下，这不是一句夸奖。伊森并不是说人们需要变成混蛋。强势的人在一定限度内会得到更多，超过之后就会招人反感，得到的反而更少。他补充说，在重组中，领导可能会先照顾强势的人，因为这样能让整个团队保持完整，同时假设安静的人会没事。

Q有没有哪位要求很高的高绩效者，让伊森恼火到拒绝他们？

伊森给出了两个回答。第一，如果一个要求很高的人已经成了净负资产，一口回绝通常会让他们辞职，哪怕是去一份更差的工作，因为他们被驱使着一定要得到想要的东西。这里有一个权衡：哪种回答能产生领导所需的结果。

第二，伊森更愿意做交易。他会告诉一位高绩效者，如果他们在他需要的事情上交出出色的成果，他会帮他们得到他们想要的。他说自己总是兑现承诺，只有一次职业生涯早期的例外，大约二十年过去了，他仍然为此后悔。

Q经理们会不会保留一个“下一个轮到谁晋升”的队列？

伊森说，确实有一个队列，大公司往往对此有政策。在亚马逊，人力资源部按半年跟踪一份前瞻性的晋升名单，名字预计在六个月、十二个月、十八个月，有时是二十四个月之后。大家对轮到谁了有一种感觉，不过他说在他任职期间并没有严格的名额。

他说，他在谷歌辅导过的某个人，描述过一种严格的名额，比如在某个半年里，一个组织里有两个人从 L8 升到 L9。伊森指出，这是二手的转述。在他看来，名额主要出现在罕见而昂贵的高级别上，那里一个职位，比如资深工程师、首席工程师或杰出工程师，一年可能要花费约一百万美元。职业早期的级别通常没有名额。

Q当组织里有人试图从同事手里夺取职责范围时，领导应该怎么处理？

伊森说，随着增长放缓，这种情况变得越来越常见。当一家公司快速增长时，就像亚马逊在他任职的大部分时间那样，招新人比争夺现有的人容易。在人头数不变的公司里，他描述了更多的“同类相食”。他的回答是，领导不能让团队成员扮演一个夺取别人船只的海盗，因为这会让领导显得毫无头绪、不再掌控全局。领导必须为这个人找到出路、说服他们等待，或者，如果他们变得有毒，就让他们成为离开的那个。

伊森指出，赤裸裸的自私会被“被抓到”的风险所约束。他给想要更多的人的建议是，提前告诉自己的经理，你有兴趣，并且如果出现空缺，你准备好站出来，而且你打算留下来。重组会带来震动，而经理们担心把某个人放进岗位后，他又离开。伊森说，一个表示自己会留下的人，会成为最可靠的人选，不一定是最优秀的人选。

Q那些通过发现一个没人要求他们解决的问题，来创造职责范围的工程师呢？

伊森说，这也可以，并且他两条路都推荐：问你的经理你怎样才能帮上忙，同时也想想你自己能做点什么。他举的例子是定制印花 T 恤，他说亚马逊现在这项业务一年的销售额超过十亿美元。伊森帮助启动了这项业务，并从他的 Appstore 组织里出钱组建了第一支团队。他的老板问，T 恤印刷与 Appstore 有什么关系。

伊森告诉老板，他在那里看到了一个大生意，需要从 800 人里抽出 10 个人。伊森说，如果他不能把大约百分之一的资源花在自己相信的事情上，那就是微观管理。老板不同意，但还是答应了。伊森说，他的 800 人里大约有 790 人在做他的经理想要的事，10 人做他自己的押注；而一位运行副业项目的领导，必须迅速砍掉失败的项目，并保持较高的命中率。他的总结是，通往顶端有多条路径，他都试过：做乐于助人的人，也做发明家。

Q重组是如何被用来把某些领导劝退的？

伊森说，实际操作中，领导会把这个人放到他们不想做的事情上，并声称这是唯一的空位。他讲到亚马逊早期的一个小组，领导们分别负责 Prime Video、Prime Music、Kindle 和一条内容摄入管线。有一位领导被分到了数据库维护、质量保证和几项零碎的事，他开玩笑说自己的小组叫“其他”（Other）。那位副总裁反对称之为“垃圾桶”，但伊森相信这位副总裁预期那位领导会离开。据说，这位冷静而有团队精神的领导，二十年后仍在亚马逊。

伊森的观点是，给一个强势、野心过大的人安排“其他”这个座位，几周之内就能制造出一个空缺。他自己倾向于直接解雇人，但他称这种“坏座位”的招数是经典的，并非亚马逊独有。据伊森理解，在日本文化里（他说自己不是专家），靠窗的座位意味着被放逐出行动的中心，与美国人看待转角办公室的方式正相反。

Q工程师对一位能力不足的经理该怎么办：可以去找这位经理的老板吗？

伊森说，这类升级上报总是找到他，而员工低估了隔级老板的想法。一位老板听到关于下属某个弱点的反映，面临两个选项。一是认定抱怨的人过于敏感、很难伺候，那么问题就在抱怨的人身上，老板可以把它甩回给那位经理。另一个是同意，而这会带来三个问题：决定怎么处理这位经理、招聘并培训一位接替者，以及在此期间代做这位经理的工作。他说，即使是下意识的，老板也有很多理由不轻易相信。

所以他的建议是，永远不要单独兵变。如果员工真的想要行动，他们应该带上两三位同事，或者依次去找。他描述了一位对团队里的女性很糟糕的领导。单独一位下属大概会被忽视，但当伊森询问了几位女性、她们都证实了此事，他意识到自己一直对一个问题视而不见，于是采取了行动。

Q人们怎样才能为这类对话找到谨慎的措辞，比如伊森描述过的那些礼貌的虚构？

伊森说，他不确定怎么教这个，但一个常见的错误，是进入房间之前没有想好措辞。这类对话大多不是临时起意的：它们在日程上，像绩效评估一样，或者是已知会发生的。他建议提前准备好一句关键的话，这样就能真诚地说出来。在他的例子里，没有一句是谎言，但他说话时很温和。他说，表达方式与内容同样重要：同样的话，语气生硬会引发敌意的反应，语气温暖则不会。

对那些说自己讨厌政治的工程师，伊森回答说，这不过是人与人之间的互动，伴随着别人的情绪、防御和压力，他们应该学会擅长它。

Q当一位经理或同事是影响力高手时，这是积极的信号还是警告？

伊森说，两者都是。他认为影响力和政治用的是同一套技能，区别在于动机。他教授高管气场（executive presence），并指出达斯·维达（Darth Vader）就有很多。当他遇到一位老练的操盘手时，他会问对方站在哪一边。有三种情况：动机良好的人，容易合作；完全只为自己的人，他把他们比作西斯（Sith）；以及动机还可以谈得拢的中间群体。对第三类人，他可以做交易：他们不是利他的，但他们想要某样他能帮上忙的东西，两人可以一起交付某样东西或赚取某些收益，而不必成为朋友。

Q其他组织有没有试图从伊森的组织手里夺取职责范围？领导该如何防御？

伊森说，这种事他一直在见。据他的描述，试图夺取职责范围的人很少把自己看作掠夺者。他们很了解自己的使命，所以清楚地看到你的职责范围怎样对他们有帮助，却不了解你的使命，于是可以想象你的组织不重要。他引用了一位聪明的工程领导的话：两个工程团队之间的尊重，与它们之间的距离成反比。他举了亚马逊 S3 的例子，它存储着数百万亿个对象，有时却被轻视为一个大硬盘；越靠近，你看到的复杂性就越多。他说，很少有人打算作恶；他们想要某样东西，然后构建一条逻辑，来说明为什么这是好事。

他列出了防御的策略。“臭鼬招数”是让自己变得没有吸引力：列出你维护的那些不光鲜的事情，而对方团队并不知道，并让客户解释它们有多重要。另一招是带刺，让攻击者去找更软的目标，不过他警告说，做出损害自己信誉的行为，会让你更容易成为目标。第三招是在有力地说明自己工作价值的同时，揭露对方的动机，这在业绩出色的基础上更容易做到。第四招是拖延：重组要花掉大约六个月的生产力，所以一个正在达成目标的团队可以争辩说，现在不是时候。伊森说，共同的线索是叙事，因为人们先得出情绪化的结论，然后再合理化，所以更会讲故事的人获胜。

Q对于另一个组织里一位人缘很好、却给自己的组织带来大麻烦的人，领导能做什么？

伊森说，他的一位经理曾经安排了一个他称为“肉盾”的人，其工作是在一个项目完成之前，让那位难缠的人远离团队的其他人。这位经理坦白说这是个糟糕的角色，并承诺日后补偿。伊森说，如果你想改变局面，最重要的一步，是理解这个人在他自己的组织里为什么受重视。他们的领导大概在想：这个人手肘尖，但能办成很多事，而别人都太软。

然后他描述了两种谈法。一种是说：我们想要这份价值，但不想要这份痛苦，并请对方给一个更好的办法。另一种是说，这个人在虐待团队，要么改变对接方式，要么合作就停止。伊森私下的版本是用拖延和流程来报复。他对外的版本则是礼貌的：这位同事是被重视的，但团队很吃力，伊森提出一个新的联系人，否则两个团队就要保持距离，这会产生摩擦，耗费两位领导的时间。他指出自己有人准备离开，并问另一位领导换作他会怎么做。伊森说，这是同一个信息，没有威胁，而那个级别的领导，不用听见就能感觉到未说出口的大棒。他把它比作对冰球场上一个粗野的对手说：我也有手肘。

Q工程师为什么需要一位能为组织挺身而出的经理？如果经理不愿意，工程师能做什么？

伊森说，经理不需要刻薄才能坚定，但需要有技巧。很多人只有把自己逼到生气之后，才能传达艰难的信息。他试着坚持自己的信念，而不把愤怒当燃料，同时承认朋友会告诉他什么时候他表现得像个混蛋。他重复了一个形象的说法：经理要么是一把伞，要么是一个漏斗，而漏斗会把压力传给团队。一位唯唯诺诺的经理，要在向自己的老板顶回去（感觉很危险）和向工程师施压（后者级别更低）之间做选择。

伊森说，工程师必须改变安全感的平衡：要么帮助经理觉得向自己的老板顶回去是安全的，要么让“要求第四个周末加班”变得不安全。瑞安觉得第一个选项听起来几乎不可能。伊森回答说，第二个选项恰恰就是经理长出脊梁骨的方式。他给了一个关于周末加班的示例话术：指出这个规律，给出数据，说家庭很重要，工程师不能再继续周末加班，并问下次该怎样规划顶回去，这样经理就不会陷入承诺了一件不会发生的工作的境地。

Q什么是“私下沟通”（backchanneling），它什么时候有用？

伊森区分了好的私下沟通与操纵性的私下沟通。操纵性的私下沟通，是做一些你不会公开说的事，比如破坏一项提案，或者给另一位领导抹黑。他说那通常没必要，他想说永远没必要。积极的私下沟通，是给人们一个机会，不必公开地提问和分享顾虑。比如，一位担心预算的财务人员，可以私下问，而不是在会上问。

伊森说，它起作用，不仅因为交换了信息，还因为对方觉得被理解、被征求意见、被倾听，而这种情感上的认同会建立信任。他解释说，当一位高管在两份相似的提案之间做选择时，他们会问：我能依靠谁，这个决定会让我看起来怎样，冲突将如何解决？一位征求过他们意见的领导，即使另一份提案的回报稍高，也可能获胜。伊森将此与幕后交易（比如回扣）对比，他把后者描述为一方提议去做错事，因为双方都受益。他说，有些人会接受，因为他们对自己说，这是他们应得的，而如果你能了解他们的故事，就有更大的机会把它引向别处。

Q影响力能不能来自“下属层层累计的人数”之外的地方？

伊森说，他见过软实力来自想法。亚马逊做了一个名为 Cloud Drive 的存储产品，他把它比作 Dropbox 或 Box，这个提案来自一位刚毕业的工程师。这位工程师赢得了一张工程大会的邀请，给杰夫·贝佐斯（Jeff Bezos）发邮件，请他去看海报，并介绍了这个想法。贝佐斯喜欢，就给这位工程师的三级以上的经理发了邮件，那是一位副总裁，也是伊森自己的老板。那位副总裁不喜欢这个想法，但贝佐斯说过要研究一下，所以伊森为这个项目提供了资金，它也就建成了。伊森还提到一位资历稍高的同事，他在做了大量跑腿工作、建立人脉之后，帮助推出了亚马逊 Fire TV 的提案。

伊森说，共同的线索是一个故事：一个以易懂的短句讲述的愿景，没有人反对，比如拥有一个云存储系统，或者一个低成本的客厅设备。它通常始于真实的事实，带着热情讲述并反复讲述，并讲给有权力采取行动的人听。

Q除了绩效记录里写的，人们被解雇还有哪些最少被谈论的原因？

伊森说，关于什么时候、怎样可以解雇一个人，有法律规定，所以对外的说法几乎总是关于绩效。他说，未说出口的原因往往是风格不合：注重细节与着眼大局，或者技术优先与业务成果优先。一个小小的差异，可能变成一场争论，进而变成标签，比如“技术上一窍不通”或“只想着钱”。他说，一旦一个人被贴上标签，他们做的一切都会透过这个镜头去解读，人们就是在这里被解雇的，尽管总是被称为绩效问题。

他还描述了一个案例：一位新聘的、级别很高的高管，被几位女性包括一位人力资源代表举报性骚扰，随即被解雇。伊森解释了为什么这样的人可以在别处再次被聘用：公司没有法律证据，所以点名这个人有被起诉的风险，而前雇主通常只确认任职日期。伊森说，他后来看到这位高管把亚马逊的这份工作从简历上去掉了，而他不认为这是个例。

Q为什么解雇一位糟糕的经理，比解雇一位糟糕的工程师更难？伊森是怎么做的？

伊森说，他同意这更难，原因有三。第一，经理往往更有经验，所以他们的弱点很隐蔽。他解雇的第一个人是不再来上班了，这很容易。第二，经理的工作很难衡量：招聘、评审、交付的功能或 bug 数量都有局限，于是对话变成了“各说各话”的问题。第三，经理了解这套系统，能很快把自己放在难以被撤换的位置上。伊森仍然解雇了大量的经理。

他理想的办法，是他并不总能用的，即在社交层面提出事情可能行不通，并问这位经理是否希望获得帮助，去找一个更合适的地方。聪明的经理会听出老板不满意，并在为他们指一扇门，也许还给出时间去找工作，或者一笔遣散费。他避免使用“解雇”或“绩效”这样的词，因为据他理解，它们可能引发一个称为“推定解雇”（constructive termination）的法律问题。一位圆滑的经理会回答说，很遗憾老板不满意，并愿意接受改变，伊森把这解读为一场反向谈判的开始。另一条路是正式的绩效管理，有书面记录的期望和未达标之处。他说，几乎所有的经理在这个流程结束之前就辞职了，因为这个流程给了他们大约 90 天去找工作。

Q许多人会卡在资深工程师或一线经理这个级别，怎样才能突破？

伊森说，这是他的老本行。人们被卡住，是因为他们一味把当前的技能做得更用力，而不是学习下一级别所需的技能。让人早期获得晋升的，是努力而有效的交付。后来他们需要放权、沟通，并放下硬技能，因为微观管理会赶走好的工程师。他推荐了马歇尔·戈德史密斯（Marshall Goldsmith）的《成功人士的 5 个坏习惯》（What Got You Here Won't Get You There）。

他实用的建议是，去和高一两级的人聊聊，问他们当年不得不放下什么、学到了什么，以及他们看到是什么在拖这个人的后腿。他更喜欢征求建议，而不是征求反馈，因为反馈是请别人批评，而建议则以更积极的方式邀请对方给出同样的信息。他看到很多人拼命地努力，却没有成效。

Q当你与需要的那些领导之间没有天然的合作关系时，你怎样为资深晋升材料争取到支持者？

伊森最喜欢的方法，要求经理站在你这一边。作为经理，他会给同级或隔级领导发邮件，说瑞安将在六个月后参加晋升，他们的团队与你们相邻，他会请他们提供反馈。这给了他们六个月的时间来观察，而且因为着眼于他们的时间，并不让人觉得是为自己谋利，六个月后，这位领导就不能说他几乎没怎么见过这个人。伊森说，他变得擅长让人晋升，这帮助他吸引和留住人才；有一个人错过了一轮，让他又多了六个月，晋升最终通过了。

如果经理不支持，次优的选择是由这个人自己去找那些领导，问怎样才能处于一个自然的位置，在六个月里给出反馈。伊森建议超额邀请，因为会有离职、重组和拒绝：如果你需要四位支持者，就请六七位。这个请求可以被表述为“提前、按规矩地做好”，而不是通常那种临时抱佛脚的请求。

Q一个鄙视政治的人，能做些什么来避开它？

伊森给出两个回答。第一，选一位同样鄙视政治的领导，最好有相似的技术背景，并且想奖励真正的工作。第二，在可得的最难的领域里工作，那里专业能力最重要，工程师也最突出。他回忆起当时担任 AWS 负责人的安迪·贾西（Andy Jassy）说过，有几位首席工程师在做最难的问题，被免除了审查架构和指导他人这样的常规职责，因为公司需要他们去解决那些问题。伊森指出，这样的工程师拥有完美的老板。

他补充说，一项独特而有价值的技能会带来例外。当其他人抱怨一位高级别员工的工作达不到亚马逊的水平时，贾西说他同意，但这个人处在公司需要的岗位上，并且他自己也清楚，所以公司会忍受。伊森的结论是，避开政治需要一项不可替代的技能和真正的筹码，这正是卡尔·纽波特《优秀到不能被忽视》的要点。

Q对于如何应对企业政治，伊森会给年轻时的自己什么建议？

伊森希望能告诉早年的自己：正确和技术精湛是不够的，还有太多别的事情在发生。他说，他当时对此视而不见，或者把它当作“管理方面的杂事”而放在次要位置，但这些杂事控制着整个世界，即使对个人贡献者来说也是如此。他用一句话说，人们应当认真对待这一点：关系才是真正控制你进步的东西。

Q在从内部工作过之后，John 对 Meta 和 MSL 还是看好吗？

John 说，他对 Meta 这家公司非常看好，现在是以股东而不是员工的身份。对于作为一个几乎没有股权的员工，他就没那么看好了，他说这描述了大多数人，因为大多数员工的薪酬主要是现金。

他说，在 Meta 工作不如以前愉快，尽管从利润的角度看，公司运营得非常好。他继续投资这家公司，并预期会继续下去。他把在那里当员工，描述为比以前更有压力的一段时间。

Q在 Meta，职业成长的承诺作为留任工具，有没有发生变化？

John 说，Meta 的许多部门不再把薪酬、使命和享受工作作为留下的理由来谈。人们反而说，做任何事的唯一理由，是一个关于晋升的清晰故事。当他从数据基础设施转到 AI 基础设施时，他发现几乎没有人的首要目标不是晋升。

变现（Monetization）部门是最典型的例子。它从 AI 基础设施里招人，并附带详细的晋升计划。John 说，这对晋升有效，但搞垮了许多团队，包括好几个他后来管理、并不得不去修复的团队。那些团队里的人同意，这些工作不好，也不太可能成功，却为了达到他们的晋升门槛而把它交付了。

他说，这使得做出好的软件决策几乎不可能，并且最有助于职业发展的技能，变得与晋升脱钩。当市场转向不利于员工时，经理告诉人们，要更害怕裁员，而不是期待晋升。他不认为这是一种好的文化修复，不过他把它看作一种消除早先损害的尝试。

Q你早期在 Facebook 做实验工具的那段时间怎么样，那时还没有晋升的压力？

John 说，他在 Meta 的头两年是他最快乐的时光之一，但也是最可怕的时光之一。他曾申请了六个月的假期，去做 Julia 这门语言，他是核心贡献者之一。在他离开期间，招他进来的经理离职了，他加入的团队则拆分成核心数据科学和数据科学基础设施两部分。

他想加入核心数据科学，却与拥有实验工具的数据科学基础设施团队紧密合作。他说，那项工作是他作为个人贡献者做过的最有价值的事，而在 Meta 认识他的人，也因此记得他。核心数据科学当时动荡不安，有重组、新经理和人员更替。

几个月后，John 所隶属的一个偏研究的小组发表的一篇论文，成了 Meta 的一场重大公关问题。John 记得它大概叫《社交网络中的情绪传染》。他试图防止这个问题，但没有权限。作者后来在一次问答中向公司道歉。John 发现自己要出席与法务负责人的会议，他的团队面临被解散的可能。他称这是一段塑造他的经历，尽管余波逐渐消退。

此后几年里，他成了 Deltoid 的主要开发者之一，是它的第三代。当大多数资深工程师在大约六个月内离开时，他成了唯一还记得这个系统如何运作的人。在大约 IC5 的级别上，他成了事实上的技术负责人，并多年来推动 A/B 测试工具的愿景。他说，这是他在 Meta 做过的最有成就感的工作之一。

Q你有没有什么遗憾，是别人可以借鉴的？

John 说，他有一个现成的回答，因为他经常被问到。最初的好几年里，他的隔级经理 Javi 开设了答疑时间。John 的经理 Danny 一直建议应该有人去。John 没有去，因为他觉得自己对 Javi 没什么有价值的话可说。

后来，当 John 为一个更大的组织开设答疑时间时，他希望有人来，并意识到 Javi 当时也有同样的感受。John 说，他错过了一个宝贵的机会，也让 Javi 的处境更难了。他称这是一个出于恐惧而做的、伤害了双方的决定。

他给初级工程师的建议是：当一位领导说他们想听听大家的声音时，就去。总监及以上的人离工作很远，John 说，他有时是由经理来管理经理。他说，带去一个具体的想法，而不是问怎样才能晋升。领导们欢迎这样做，而许多人害怕这样做，这让每个人的处境都更糟。

Q如果你能回到职业生涯的起点，给自己一些建议，你会说什么？

John 说，他持有很强的观点，但可能比应该的更爱难为情。他的建议是相信更大的工作是可能的，而有了高度的自律，它就是可能的。他说，从高中到大学，他太经常怀疑自己能做什么。他称这是他犯过的最大的一类错误：不够有雄心，或者不相信一个问题是可以解决的。

他还说，人们过分地让自己相信别人很伟大，又让自己对自己能达成的事不够有信心。这种组合让他们承担的风险比本可以承担的少。他说，直到他与许多取得成功的人共事之后，才看到这些人往往并没有好太多。他们只是去尝试了，而别人没有。对于 20 岁时的自己，这就是他会给出的主要教训。

Q量化研究员（quant）和软件工程师是怎样协作的？

Nimit 说，这取决于公司。在 Jane Street，被称为 quant 的人数很少，而交易员有技术背景，并自己实现很多工作。在 Citadel，Nimit 称其更偏重量化，量化研究员的人数可能与技术人员大致相当。量化研究员、软件工程师和交易员之间，角色有很多重叠。

在一些公司，量化研究员设计策略，交给工程师去实现。在另一些公司，同一个人可能两样都做，因为最能理解其原因和边界情况的人，恰恰是最能把它实现好的人。Nimit 写了很多代码，主要是 C++，还有一些 Python。

Q是什么让前 1% 的 AI 研究员和量化研究员与众不同？

Nimit 说，有几条路径。原始的技术能力、直觉和执行速度都很重要。玩转政治游戏也一样，它能帮助人们上升。量化领域更难钻空子，因为表现更容易衡量。一位为公司赚了很多钱的优秀 alpha 量化研究员，会得到明确的认可。

在 AI 领域，衡量标准更难解读。一篇开创性的论文，或真正的突破，比如一个好得多的模型，起的是同样的作用。Nimit 补充说，在两个领域里，天时地利都很重要。

比较各组织的冒险精神与群体迷思

Nimit 说，大实验室拥有雄厚的资源、算力和众多的研究员。硬币的另一面是，它们可能排斥跳出常规的想法，容易陷入群体迷思，也不太愿意冒险，因为失败的实验代价高昂。创业公司可以更灵活，有策略地探索，挑战正统观念。这正是吸引 Nimit 去 Cartesia 的原因。

Q你怎么看强制排名、流失率目标和绩效改进计划？

埃文斯从自己的管理经历出发，描述了亚马逊的一套流失率目标体系：一份名单，上面是离开后不被视为遗憾的人，并有压力要通过改进、辞职或解雇，达到每年一定的比例。他引用的百分比因时期而异，是历史上的回忆，并不是经过核实的当前政策。

他说，当亚马逊试验性地取消这项目标后，经理们就不再与表现不佳的人进行艰难的对话了，于是这项目标又回来了。当一个人人缘很好时，经理可能避免采取行动，尤其是在大型组织里，眼前的代价对他们并不明显。这项目标迫使人们关注一个真实的问题。

另一面是扭曲。配额可能把一个本来仍有成功希望的人放进名单里。一旦经理在心里决定了某个人应该离开，确认偏误就可能让改进计划在心理上变得不现实。埃文斯认为，许多计划因此更像是一条通往离职的路，而不是一次开放心态的改进尝试。

他讲到自己辅导过大约六位处于亚马逊绩效改进计划中的人，结果都不成功，而没有接受他辅导的人，结果也类似。他现在敦促处在那种境地的人，要准备好找另一份工作，而不是指望局面逆转。这是基于他的案例的强烈警告，并不是一个经过衡量的普遍失败率。

即使是一位一开始怀着善意的经理，也可能面临来自人力资源和领导层的压力，要求算上一个离职的人，或者在第一个人有改进后，再点出另一个人。埃文斯更宏观的诊断是：公司往往没有培训经理去进行及早的、有用的绩效对话，然后又依赖一个扭曲的后期流程。

Q是什么阻止经理向人力资源部不公平地呈现一位员工？

埃文斯区分了“让一位员工离开”与“反复地把人逼走”。高离职率的模式，最终可能暴露一位经理，但单独一个案例可能依然难以质疑。经理通常地位更高，可以在员工意识到一场争议正在形成之前，就向人力资源部定下问题的基调。

他用代码评审来说明叙述的模糊性。同样大量的评审，可以被描述为改进了每个人的代码并培养了团队，也可以被描述为吹毛求疵地挑别人的毛病，却几乎没有贡献原创的实现。数量本身并不能决定哪种解释才是准确的。

他说，自己没有亲自利用这种权力去不公平地针对某个人，并指出留住能干的合作伙伴符合经理的目标。他担心的是，这种体制容易受到一位怀有报复心的经理的伤害，或者对“什么算有用的工作”存在真正不同的看法。人力资源部听到一句熟悉的“否认表现不佳”的说法，可能不容易分辨出一项正当的投诉。

他实用的结论是：尽可能修复关系，或者换一位经理，而不是假定人力资源部一定会拯救员工。这是他对权力不对等的描述，并不是对报复的认可，也不是说每个组织都缺乏制衡。

Q当合作者争夺能见度时，你怎样获得应得的功劳？

埃文斯认为，认可在一定程度上取决于由谁来讲这个故事。及时传达一项真实的成就，点出合作者，并清楚地说明你自己的贡献。如果别人先宣布了，就补充一条有用的评论，说明你解决的具体问题，而不是指望沉默会被理解为谦逊的卓越。

他还观察到，后来的职业叙事，往往比眼前的功劳分配更少有争议。他自己用一句简略的话说，自己是后来变成 Prime Video 的那个产品上的早期工程师，这说明一项成就的公开描述，可以比所有相关人员的详细记忆存在得更久。他把这视为认可的一个实际特征，而不是证明同事的贡献就不再重要。

Q鼓励能见度，是否在奖励噪音而不是影响力？

他同意，一个人人都在说话却没有增加价值的组织是不健康的。他提出的应对是提高自己贡献的质量，而不是退出沟通。告诉领导层它需要知道的事，比如一次上线是否已经为增长做好准备，或者如果成功了，是否需要额外的投入。

埃文斯把他论点中最有力的部分，指向那些因为不喜欢自我推销而保持安静的人。他说，拒绝参与并不会创造出更公平的评估体系；它可能让有用的工作无人看见。这是一个关于“有用的能见度”的务实论证，而主持人对过度政治化行为的担忧，仍然是一个真实的局限。

Q你应该尽可能地高调、直言不讳吗？

不。埃文斯把“提出最有力的、站得住脚的主张”，与“变成一个虚假夸口的人”区分开来。他倾向于使用听众能记住的简单的成就表述，同时承认这种简化可能会惹恼偏好更精确说法的人。

他的例子，是称自己是 Prime Video 的第一位工程师，尽管他的工作开始于亚马逊的视频产品，当时还没有 Prime 这个名字。一位同事对这个命名提出了异议，而不是质疑埃文斯有没有做底层的工作。埃文斯对这条界线感到安心；这场讨论暴露的是一个有争议的判断：多大程度的简化是可以接受的，而不是一条“每一句美化的话都无害”的规则。

Q一位天生安静的工程师怎样让工作被看见？

写作可以替代在会议上发言：邮件、内部帖子、Slack 消息、白皮书和技术演讲，都能把工作展示给受众。另一个人也可以帮着宣传。核心要求是，工作不应该孤立地留在原地。

一个被广泛使用的共享组件，可以创造自己的声誉。埃文斯回忆起亚马逊的面试跟踪系统被称为“Matt Round 工具”，简称 MRT；他是通过这个被广泛使用的工具知道它的作者的，尽管从未见过他。即使是这条所谓“沉默”的路径，也需要分发，以及与创造者之间可辨认的关联。

Q如果你发现了一个有价值的新机会，怎样才能确保自己有机会带头去做？

要一起提出三个论点：这个想法有价值，你能执行它，你能为它腾出时间。经理需要信任你的能力，并需要一个可信的计划，来交接、记录或自动化你现有的职责。提出这个想法，会给你一个有用的领先优势，因为你对它想得最多，但它并不会抹去一份薄弱的履历，或另一项关键的任务。

要明确表达你对构建它的热情。否则，领导层可能只听到了一个想法，然后把它分配给别人。埃文斯还建议，当一个机会被拿走时，要让失望被看见，而不是表现得好像每一种分配都同样可以接受。

他坦率地描述了管理者的一种诱惑：安抚要求苛刻的员工，同时推迟帮助随和的员工。他说，经理可能打算回头去找那位安静的人，却始终没有做到。他建议“要让人不太容易让你失望”，针对的就是这种模式，同时承认这是一种不公平的、务实的取舍，而不是领导力的理想。

Q你更喜欢一整支有野心的明星团队，还是一支稳定的角色球员团队？

埃文斯更喜欢混合。一个高增长的业务，有时能为许多极有野心的人提供足够多有吸引力的项目；在人头数不变、机会受限的情况下，这些人可能会彼此以及与经理之间展开破坏性的竞争。

只有随和的角色球员，会产生一支平静的团队，却缺乏推动变革的足够压力。他看重一些质疑限制、推动想法的人，而太多人同时朝不同方向推动，则可能造成混乱。最佳的组成，取决于业务能提供的有用职责范围的供应量。

Q当同事想参与你那个有吸引力的项目时，你怎么处理？

他的第一步，是挑战稀缺性思维。其他工程师的热情，可以让项目更大、更快或更有价值，由发起人来协调各方的贡献。在把每一位感兴趣的同事都当作威胁之前，先试着创造一个共赢。

如果有必要保护主人翁责任，在原型上领先一步，或者等到责任明确了再说，会有帮助。提供其他值得做的想法，可以让同事们得到有用的机会，而不挤掉你的。他还描述了把现有的工作交接出去以腾出产能，但明确警告：显得是把不吸引人的工作甩给点了名的同事，可能会制造敌人。

埃文斯强调要理解动机、满足感、恐惧和情绪。他的扑克类比，把在公认的规则内巧妙地竞争，与作弊（比如偷看另一位玩家的牌）区分开来。他相信，一个人可以理解这场社交游戏并且获胜，而不必采用不诚实的操纵。一些例子，包括向同事发起挑战、要求他们通过周末加班来证明投入，被描述为社交上的策略，而不是呈现为每位队友都应该接受的义务。

Q对于别人想甩给你的、你不想要的工作，你怎样保护自己？

埃文斯建议在交接到来之前，先确立有价值的举措。如果人们已经知道你在推动什么重要的工作，就有了可信的理由，不必给你加上别人的维护工作。一旦你只是在防御某项具体的任务，他认为你在这场谈判里就已经落后了。

如果有人说这项工作很容易，就问他们为什么不自动化或解决它。要说清楚自己的产能，以及替换你其他工作的代价。他用了一个凶猛动物的类比，来说明：人们有时会把任务交给最不可能反对的那个人。这个观察解释了他为什么建议设立边界，尽管它并不会让把工作转嫁给更安静的同事成为一个公平的结果。

他还提出了建设性的议价。承认不吸引人的工作需要有人做，完成其中有限的一部分，然后事后要求一个更好的机会。提前自愿承担一轮维护冲刺，可以表明你站在经理这一边，同时创造出一次具体的交换，而不是默默地累积一份没有尽头的积压。

Q当只有一个名额时，你怎样赢得晋升？

首先问这场竞争是否真的有可能赢。如果已有几位合格、且更资深的人在等同一个岗位，那么去一个正在增长的组织，可能比无限期地试图插队更好。埃文斯不会保证每一种受限的处境都能得到解决。

在有路径的地方，说出你的兴趣，并问在什么情形下，你会成为经理的首选。这会引出具体的标准，而不是让人去猜心思。然后他强调要成为领导在困难的问题或危机中能够依靠的人。问问是什么让领导夜不能寐，或者他们最大的问题里哪一个最糟，并帮助解决它。

他对代价说得很明确：危机可能发生在方便的工作时间之外，而成为格外可靠的人，可能需要牺牲。他回答的是怎样去竞争这个岗位，而不是怎样在没有额外付出的情况下保证拿到它。这条建议关乎让一项真正的贡献对领导有价值，而不是仅仅表达渴望。

Q如果你的经理不愿明确地谈晋升，怎么办？

埃文斯首先考虑，换一位经理是否更契合你的抱负。如果换人不现实，就研究这位经理实际上奖励什么。看看好几次晋升，与那些人聊聊此前的工作和对话，并学会这位经理谈论成长的语言，而不是假定每个人都像埃文斯那样直接地谈判。

如果没有人得到进步，或者经理的选择没有可行的规律，那么可能根本没有可以遵循的有效流程。接受一个缓慢且不确定的体系，或者去别处，也许才是真正的选择。

他建议用 AI 来审视经理的沟通方式，并提出一种适合其风格的做法。他对通过 AI 推断性格的信心，是他的看法，并不是这场访谈所呈现的经过验证的评估。他把调整沟通方式与操纵区分开来，同时预测，有说服力的操纵以及 AI 的反制手段，将变得越来越重要。

Q你怎样处理一个始终含糊的晋升“胡萝卜”？

首先区分正当的不确定性与回避。经理可能需要一个委员会、隔级批准或另一位决策者，而无法保证他们的回应。要问什么才能让经理成为热心的倡导者，而不是要求对最终结果作出承诺。埃文斯自己的副总裁赞助人，承诺为这次尝试押上自己的声誉，却无法保证杰夫·贝佐斯（Jeff Bezos）的批准。

经理也可能不确定这项工作是否足够有力，或者不愿给出一份忽略新要求的清单。要承认这些限制，同时解释没有可见的目标或时间点会有什么实际影响。问问成功是什么样子，怎样衡量进展，谁成功过，以及你应该怎样朝着一个未知的目的地努力。

对于一位只会吊着人的经理，要拿你的经历，与别人的结果比较。如果人们确实得到了机会，就去探究是什么让他们与众不同。如果没有人得到任何东西，埃文斯建议离开那位经理，或者改变这段关系中的筹码。他建议使用谈判式提问，目的是引出清晰度；它不会在没有真正机会的地方，凭空创造一次有保证的晋升。

Q如果你的经理没有晋升，正在阻碍你的晋升，怎么办？

如果经理想成长，可以考虑一个共同的计划：帮助他们达成一个能为两个人的职业生涯都腾出空间的目标。埃文斯说，他曾让优秀的下属参与这样的安排，他们的晋升和他自己的晋升，互相强化。要问他们的目标，而不要假定停滞就意味着漠不关心。

如果经理不想晋升，就问问他们是否能帮你在别处找到机会。一些不那么激进的领导，有强烈的动力去支持别人，可能愿意这样做。如果他们需要留住你，就解释你的职业发展很重要，你更愿意在这个团队里成长，而如果无法创造出一条路径，你就需要考虑其他选择。

埃文斯建议解释一个真实的、有紧迫性的阶段，比如对家庭或照顾家人的安排。主持人对未来计划尚不确定时的灰色地带提出了质疑。埃文斯为表达感受和可能性辩护，但说不要撒谎。站得住脚的实质，是说明一个真实的优先事项和偏好，然后让经理回应；文字稿并没有确立“可以编造个人义务”的权利。

他还把正常的雄心与不现实的要求区分开来。一位坚持要在两年内成为副总裁的应届毕业生，需要被泼一盆现实的冷水。一位完全拒绝雄心的经理，可能只是不适合这类人群，而一位拼命驱赶的经理，则可能因为要求太多而造成另一种问题。

Q你自己的下属有没有对你使用过这些政治策略？

埃文斯回忆起几位非常圆滑的谈判者，但大多数人都是直接的，也许是因为他公开地讨论成长。他说，他也遇到过不诚实的说法，并把说这些话的人清除了出去。他把这些情形与正当的雄心区分开来。

有些优秀的下属想要的角色，他无法足够快地提供。当另一家公司有明显更好的机会时，他支持他们离开，包括有人去三星担任一个大角色。即使是一位有野心而又支持下属的经理，也可能用光可用的职责范围。

他对不说出口的、消极攻击式的不满感到沮丧，因为它既阻止了解决问题，也阻止了坦诚地讨论其局限。同时，他认识到，有些员工处在人生的某个阶段，只想做好自己的工作，然后被人安安静静地留在一边。这种选择可以与一支由“攀登者”组成的团队共存，不过他警告说，这样的员工可能得到不那么理想的工作。

Q当正常流程需要证据时，经理怎样才能因为撒谎而让某人离开？

埃文斯说，可以证明的不诚实，可能支持直接解雇，但没有决定性证据的怀疑，则是另一回事。他更宽泛、更令人不安的说法是：一位处境良好的经理，有许多非正式的办法，可以把一位员工逼走：不吸引人的任务、不鼓励晋升、批评性的评审、过度的审视，或者一连串让继续工作变得不愉快的要求。

他说明了看似站得住脚的工作分配，如何掩盖惩罚性的意图，以及一位有权势的经理，如何能在员工投诉之前，就向人力资源部定下事情的基调。这些例子解释的是一种滥用的机制；它们并不能证明这样的行为是公平的、合法的，或者是一种合理的管理实践。埃文斯承认，无辜的人可能受到伤害，并把体面的经理希望留住好人的愿望，视为通常的约束。

他所说的区别，是在清除一个他认为不诚实或有破坏性的人，与针对一位好员工之间。这种区别在很大程度上取决于经理的判断，而这恰恰是主持人所追问的那个薄弱点。

Q员工能通过人力资源部成功地挑战一位不公正的经理吗？

埃文斯认为，说法和时机很重要：经理可能已经把这位员工描述成了一个绩效问题。员工应当带上事实性的行为及其对有成效的工作的影响，而不是以要求解雇经理开头。独立的佐证、已建立的绩效记录，以及具体的、有书面记录的不当行为，可以让一场艰难的较量更有力。

他说，他曾在多位员工的陈述不断累积、并与他自己的观察吻合之后，撤掉过经理。他也认为，领导往往会保护自己个人喜欢的经理，即使员工在不断离开。在一个辅导案例里，一位领导花了 18 个月，试图改善一位手下的人不断辞职的经理。埃文斯向那位领导提出挑战：如果同样的故事发生在一个他们不喜欢的人身上，他们会怎么建议。

现实的局限是制度上的惰性。他相信，离开往往比说服一个层级体系，去撤换一位与上级关系良好的经理更容易。他关于胜算和先发优势的数字化说法，是修辞性的，并不是衡量过的概率，也不是对任何特定的人力资源流程的保证。

Q绩效和人缘，怎样影响职场中的权力？

埃文斯把糟糕的绩效加上普遍的不受欢迎，描述为最容易采取行动的情形。一位平庸但人缘很好的同事更难撤换：没有哪一场单独的灾难提供明显的理由，而别人会为这个人的乐于助人和温暖辩护。在他看来，人际关系因此改变了相似绩效记录的实际后果。

他通过建议保持普通的友善，并在某项任务或决定重要时，做出有选择的、适度的反击，来调和“讨人喜欢”与“守住边界”。幽默可以传达某种反复出现的模式是不可接受的，又不会造成对抗。他那个好玩的“代币”例子，把有限量的不愉快工作，描述为他愿意接受的东西，然后问经理是否想现在就用掉这份额度中的一部分。

“代币”的说法，是一种示例性的谈判策略，并不是正式的雇佣上限。它的目的，是让代价和期望被看见，同时保持合作。

Q就工作保障而言，被人喜欢比绩效更重要吗？

他说，答案取决于情境。决策可以包含产出之外的考虑。一位领导可能会为一个讨人喜欢的人辩护，称他们的存在，有助于一次困难事件之后的士气与合作。埃文斯讲述了一场用家庭情况作依据的裁员讨论，他把这标为不当；本书把这视为他的回忆，而不是经过核实的法律指导。

一位技术上不可或缺但令人不悦的工程师，也可能被留下，然而团队可能正在积极地转移那些知识，让它不再依赖这个人。他称这种依赖，是一种脆弱的保护形式。理想是既有能力又正派，而不一定要格外有魅力。

他补充说，经理可能对自己的技术能力缺乏安全感。公开羞辱一位经理，可能同时威胁他的自尊和权威。于是人们会把报复性的选择合理化为服务于更大的利益。这是他对一种社交上的失败模式的描述，并不是为报复辩护，也不是要求避免一切技术上的分歧。

Q在竞争晋升时，你怎样防御同事对你的暗中拆台？

如果这种行为已经明显，就在某项具体的指控给你下定义之前，先与领导层讨论这种模式。埃文斯建议，请求按实际的贡献来评判，并给予机会去证明，同时拒绝加入相互攻击的运动。他认为，这会让经理日后更容易识别出诋毁。

如果指控已经落到了你头上，就平静地问经理听到了什么，以及什么证据能让他们看到全貌。他建议提反思式的问题，包括镜像几个词，来引出信息，而不是立刻进入防御。然后让工作可以被核实，并就未来更好的能见度达成一致。

他还描述了支持那些贡献被不公平地忽略的同事，这也许能帮助他们注意到暗中拆台的模式。当这意味着准确地肯定工作时，这是有建设性的；他关于陷阱和埋下怀疑的措辞，也说明了防御性的政治，是多么容易变成另一场政治运动。他回到一个重要的退出选项：充斥这种行为的团队，并不是仅有的团队。

Q如果每个人都老练地使用政治策略，最佳策略会变吗？

埃文斯首先拒绝“职场关系必然是对立的”这个前提。诚实地分享功劳、培养他人、更好的业务表现，以及上涨的股权价值，可以产生共同的收益。访谈中那些更黑暗的案例，是失败的情形，而不是他理想的组织。

在每个人都老练地与所有人角力的假设下，他预期优势会相互抵消。他实用的建议，是找一个能让你特有的技能组合创造出更清晰优势的环境。对于他自己的辅导业务，他结合了公开演讲、职业知识和社交媒体的经验；他不需要成为每一项里最好的个人实践者，也能拥有一个与众不同的交集。

他把在一支名气较小的球队里当明星，与在一支冠军球队里当替补相比较。地位、薪酬、学习和偏好的竞争，可能指向不同的、有效的选择。

Q你当亚马逊副总裁时，建过自己的王国吗？

回过头看，埃文斯说是的，尽管他常常告诉自己，更多的人能让他执行更多有用的想法。他回忆起一次亚马逊 Appstore 的人员申请，被杰夫·贝佐斯拒绝了，因为提议的各个“桶”太大，用途也含糊。在两次薄弱的回答之后，贝佐斯要求一份新计划，只含两三人的小组和确切的职责，然后逐行审阅。埃文斯认为贝佐斯是对的：团队想象的是种种可能，而没有做分配的功课。

后来他把扩张与具体的业务、客户和结果挂钩。他描述了就分阶段释放招聘额度进行谈判，并证明自己能为每一批招到好人。重要的区别，在于让资源产生价值，而不是单纯要求一支庞大的团队。

Merch by Amazon 说明了一次转向。他的团队曾尝试为游戏开发者印制周边商品，作为吸引应用进入亚马逊商店的一种方式。最初的这个理论失败了：周边商品并没有重要到足以改变开发者对平台的选择。然而，T 恤印刷在标语、活动和其他设计上找到了需求，并成为一项独立的业务。埃文斯说后来的收入规模非常大，但那是他在访谈中的说法，并不是经过独立核实的当前财务信息。

他还在领导层收回之前，把人从失败的项目转到有前途的项目上。他承认，同事们可能认为他的手段滑头，而他靠指出结果来把它们合理化。这场访谈既保留了他相信自己所创造的价值，也保留了他参与其中的资源竞争。

Q人们应该怎样为 AI 对技术职业的不确定影响做准备？

埃文斯给出的是预测，而不是水晶球。他预期会有赢家、输家、被消除的工作、改变的工作和新的角色。他赞成灵活的学习和人的技能，同时对 AI 工具有实际的熟悉。他担心，只专精于操作某个工具，可能暂时保住一个角色，而工作本身却被自动化掉了。

他也考虑了相反的可能性：更容易的生产可以扩大需求，就像工具在其他一些行业里所做的那样。试验软件的人，最终可能需要工程师来让它变得可靠。他不知道哪种效应会占上风。

他的核心建议是留意价值在向哪里转移。更多的代码或更多的功能，不一定是客户需要的。选择要构建什么、省略什么、发布什么，以及如何解释它，可能变得更有价值。他宁愿占据一个需要判断力和品位的位置，也不愿完全依赖手工操作这些工具。他关于 AI 在哪里最强或最弱的说法，描述的是他在访谈时的预期。

Q压平管理层级是一种永久的变化，还是一个周期？

埃文斯认为，去掉层级的压力是周期性的，尤其是在公司想保持人头数不变的时候。他怀疑新工具能消除人们组织、集中和沟通工作的需要。AI 也许能让一位经理监督更多的人，但更大的产出，也会产生更多的决策和协调需求。

他告诫不要从拥有许多极资深直接下属的杰出领导者，去推广到普通的一线管理。一支由高度独立的资深领导者组成的团队，与一位试图从十位工程师扩大到一百位的经理，是不同的问题。他提到一段很长的行政管理史，是在修辞上支撑他的直觉；文字稿中有关古代历史的细节，在这里并没有被确认为经过核实的史实。

Q你怎样降低被裁员的风险，又怎样在不带负面观感的情况下解释一次裁员？

关于解释，简短而如实地陈述组织层面的事实，然后转向你接下来能贡献什么。如果整个组织被关闭了，就这样说；如果没有发生整个组织层面的事件，就不要暗示有。埃文斯认为，大公司的裁员已经变得足够普遍，这样的解释所带来的污名，比以前少了。

关于预防，他首先承认，有些裁员是无法避免的。他见过领导在一个组织关闭时，试图把关键人物安排到别处。出色的评级、可辨认的成就、需要的独特专长，以及在直属经理之上的领导面前的能见度，都有助于让一个人被考虑进这些调动中。

模式仍然是有价值的工作与关系的结合。他不承诺，当一项业务被取消时，无论是技术上不可替代，还是与高管熟悉，就能保证受到保护。

Q什么是高管气场（executive presence），怎样培养它？

埃文斯在一定程度上通过别人的行为来定义它：他们是否在一个房间里尊重你，是否在你直接的工作之外也寻求你的判断？他还引用了一个结合了威严（gravitas）、沟通和外表的框架，权重大约是 60/30/10。这个数字框架是他引述的参考，并不是本书中经过独立验证的公式。

他把专业能力与权威的信号区分开来。自信、果断、受控的节奏、停顿、肢体语言、沉着和具体，都能让某个人显得可信。他还指出了涉及外貌和身份的不公平的社会偏见；他把这些描述为人们会做出反应的偏见，而不是值得追求的标准。

他自己的失败模式，是听起来比他的知识所能支撑的更笃定。他的妻子有时因为他听起来如此自信，而没有提出一个正确的异议。他在对话中故意编造了一个精确的“62%”统计数字，来说明自信和具体，如何能让胡说八道听起来令人信服。那个数字是对编造的演示，不能当作证据再次使用。

他说，没有哪一项表面特质是必需的。一份出色的记录，不必靠戏剧性的演讲，就能赢得尊重。这些例子对比了一位安静的、已经站稳的专家，与有意识地控制舞台气场的领导者；它们是他对公众人物的解读。

Q你怎样自然地在工作中建立关系？

找一件你喜欢的、相当了解的、可以分享的事。把它变成一门课、一场演讲、一个工具、一段录音、一项有用的服务，或者一些建议。给出被珍视的东西，会创造共同的兴趣，以及日后交谈的理由，而不要求你成为在房间里接近陌生人的专家。

埃文斯教经理们如何又快又好地招聘，然后扩展了他的教学和在线建议。亚马逊的另一位员工，批量订购了滑雪票，并在内部以折扣价转售。那个人从自己喜欢的事情中得到了好处，同时与其他滑雪者建立了数百个联系。

这项专长不必非凡，甚至不必是技术性的。共同的兴趣让交谈更容易，持续的有用互动可以加深为一段关系。工程师也可以用一项比普通同事理解得更深的技术做同样的事。

Q你怎样与一位有权势的决策者建立自然的关系？

埃文斯从你已经提供的价值谈起。一个有用的工具、课程或服务，可能直接引起一位副总裁的兴趣，也可能因为他的许多员工从中受益而变得重要。一条克制的说明，解释它的使用情况，可以打开一场对话，而不必假装分享一个你并没有的个人兴趣。

人脉也能提供引荐，通过已经认识那个人的人。他讲述了自己为把医疗物资运往波兰、援助乌克兰难民而寻求帮助：一位联系人把他介绍给联合航空（United）董事会的主席，行李就免去了本应收取的费用地运了过去。结果远远超出了他最初的需要。

他的解释是，一个位置合适的、举手之劳的人情，可以让中间人为一件有价值的事情出力，并因帮了忙而感觉良好。因此，人脉对于第一段关系形成时无法预料的需要是有用的。他并不把每一位帮助者的动机，都归结为自利；他承认想要帮忙的正当愿望。

Q当有人带着明显的拓展人脉的动机来找你时，你是怎么回应的？

他常常明确说自己时间有限。对于想要定期指导的人，他有时会提供一次会面，并请对方带来一个有趣的想法，或者他不知道的信息。如果这次会面创造了价值，并保持了他的兴趣，他们可以再见一次。

埃文斯把这呈现为比一概拒绝更有用的开场。有些人很好地利用了这次机会；另一些人没有再回来。他直接的、交易式的风格适合他，但并不假定每一位资深领导都偏爱这种方式。

Q当别人没有直接说明自己的激励时，你怎样发现他们想要什么？

他给出四种方法：问、听、三角验证和观察。倾听会议上提到的问题和目标；询问与这位领导共事的人听到了什么；并考察领导把时间、金钱、招聘和注意力放在哪里。行动可以澄清被泛泛的说法所掩盖的优先事项。

然后朝着这个人看重的东西靠近，并通过恰当的途径，让这份贡献被看见。这可能是一份报告、一位共同的联系人、一次走廊里的交谈，或者一个直接的问题。风格必须适合这段关系。

埃文斯认为，当机会对每个人开放时，明确的“价值换成长”协议是公平的，但他也认识到，有些人偏爱隐含的安排，并能容忍不那么直接的语言。建立信任，最终可以让私下的对话更清晰，即使这个人在公开场合仍然很含蓄。在那之前，更多的模糊可能是不可避免的。

Q当某人突然从公司消失时，幕后可能发生了什么？

埃文斯说，突然的离职，可能与操守或风险有关，而不是普通的绩效流程：骚扰、种族歧视、盗窃、泄露机密信息，或类似的严重事件。他回忆起有员工因为向记者泄露内部材料，并在公司系统里留下了痕迹而被清除。

他给出了两个不寻常的例子，来区分意图与后果。一位游戏美术师把一批真枪收藏带到办公室，作为武器的视觉参考；领导认为这是考虑不周而不是威胁，让他回家，并指示他绝不能再犯。在另一个案例中，一位清洁工对一位女员工令人不安的骚扰，导致他被撤换，据埃文斯讲述，还下达了禁止接触的命令。

这些故事说明了，为什么同事可能只看到突然的缺席，而经理知道一起保密的操守事件。它们并不能让旁观者推断出任何一次未解释的离职的原因，也不能证明每一次突然的离开，都涉及不当行为。

Q你有没有为了出人头地，而不得不伤害别人？

他不愿意不加限定地说“没有”，因为人们会把自己的行为合理化。他记得自己竞争过，并试图占上风，但不记得曾有意把某个人往死里整。

他感觉最糟的一件事，发生在他在亚马逊的第一周。他被给予一个选择：一款面向客户的视频产品，或者支持视频、音乐和图书的摄入基础设施。他选了那款产品，却不知道另一位即将入职的经理显然被许诺过它。那个人下一周到了，结果被分到了基础设施，埃文斯相信这对他是个糟糕的结果。

埃文斯说，即使被告知这个冲突，他也仍然会去争取那个适合自己经验和兴趣的工作。他把想要一个机会，与意图伤害区分开来，同时承认另一个人仍然承担了长久的代价。没有恶意，并不会抹去这个结果。

Q对那些觉得整个政治游戏在道德上令人反感的人，你有什么要说的？

埃文斯同样希望有一个让才能、意图和贡献得到公平认可的世界。他的辩护是，人们必须在应对当今有限的资源和偏见的同时，努力去改善它们。他相信，透明、信守协议，以及帮助人们应对现有的歧视，都有益处，而并不意味着认可歧视本身。

为了让这种道德冲突变得具体，他讲述了自己曾帮助出资一笔贿赂，据他描述，这使一位乌克兰朋友的丈夫在服役两年后得以离开军队。他认识到，别人可能因此承担了代价，并说自己不知道这个后果是否发生了。这个故事是他个人的说法和道德上的辩解；它的合法性、细节和影响，并没有被这份文字稿核实。

他对这个决定感到安心，因为它帮助了一个他认识的人，同时承认，从其他道德立场看，它可能受到谴责。这个例子让他的方式比单纯“乐于助人”更复杂：他接受偏袒，以及不确定的外部代价。主持人在伦理上的不安，仍是讨论的一部分，而没有被编辑的认可所化解。

Q你推荐哪些关于人、谈判和权力的书？

他的第一个推荐是阿宾格学院（Arbinger Institute）的《领导力与自我欺骗》。他从中汲取了这样的区分：把人看作带着关切的人，与把他们当作障碍或界面、按下按钮以获得结果。前者可以让合作更温暖，也更少操纵。

他推荐克里斯·沃斯（Chris Voss）的《掌控谈判》（Never Split the Difference），用来谈判和理解动机。他还不太情愿地推荐了《权力的 48 条法则》，把它作为更阴暗的策略的目录。他说，了解它们也许有助于读者识别操纵，同时承认，同样的材料也可能被用来变得善于操纵。

Q如果你今天想尽可能快地升到副总裁，你会怎么做？

埃文斯不会假定，自己在亚马逊的路径，在一家增长缓慢得多的公司里是可以复制的。他说，亚马逊在他任职期间急剧扩张，创造了他认为在所讨论的环境中较少存在的机会。他提出的假设性做法，是用大约 18 到 24 个月密集学习，培养外部看重的专长，比如 AWS 知识，然后寻找一家高增长的公司，让这份专长去解决一个重要的采用问题。

他会交付价值，让成长目标变得明确，学习管理、决策、心理学和组织，并承担一些大的风险。他认为，高能见度的胜利可以加速晋升，同时承认，失败和多次换公司，可能是这条路径的一部分。他提到离开失败留下的“冒烟的废墟”，暴露了单纯为职业速度而优化的真实代价；这并不是反复冒险就一定会成功的保证。

他认为，工程师层面的早期成长，在一家成熟的公司内部也许仍然可能，但更高级别的晋升，越来越需要一个可用的业务依据。一项在大公司里让你成为成千上万人之一的技能，在别处可能让你变得独一无二。他的员工人数和薪水对比，是示意性的近似值，他的建议反映的是这场访谈的市场观点，而不是经过核实的当今预测。

Q你在加入亚马逊之前的职业生涯是什么样的？

埃文斯在家用电脑出现时，就想从事计算机行业。苹果对一封关于就业的信件的回复，帮助他选定了大学；他就读于卡内基梅隆大学，后来在普渡大学完成了硕士学位。他早期的工作，是一连串小公司，大体上由网络、搜索、网络管理、广告和音频流媒体松散地联系在一起，中间还短暂地岔入过娱乐灯光领域。

亚马逊最终招他进来，部分是因为流媒体音频方面的经验与其计划中的视频工作相契合。在他的第一家之后，大多数创业公司，在互联网泡沫前后都很艰难或失败了。他描述自己两次被裁员，而他对抗性的行为也是原因之一。成为亚马逊副总裁，并不是他最初的人生计划；这条路径是逐渐演变而来的。

Q你最初为什么选择创业公司，而不是成熟的公司？

最初的选择，主要是由朋友和一个看似有吸引力的机会推动的，而不是对公司规模做过缜密比较的结果。朋友们加入了一家由教授创办的本地公司，并向他介绍了股票期权。一位较早加入的室友做得特别好；埃文斯加入得晚，但也赚到了足够的钱付买房的首付。直到事后，他才学会更有意识地做职业决策。这个故事说明，为什么一个成功的早期选择，不一定始于一个精妙的策略。

Q你有没有预见到裁员？咄咄逼人的作风在其中起了什么作用？

没有，尽管有过警告。他的第一位经理已经注意到他好斗的解决问题方式，而埃文斯曾经自豪地把当个“失控的大炮”，描述为瞄准那些错的人。技术能力和精力充沛的执行力，仍然把他带上了创业公司的领导岗位，但同事间的冲突，变得越来越代价高昂。

在一家公司里，一位产品负责人警告说，按现有的时间和资源，计划中的范围无法交付。埃文斯现在认为这个警告是对的；当时他却把它当作对使命的背叛。在裁员期间，他主动提出去另一家创业公司，CEO 接受了。他怀疑，清除冲突让这件事变得更容易。

在下一家公司，他与一位销售负责人争吵，因为对方承诺了并不存在的功能。埃文斯至今仍认为这里有诚信问题，但承认当时公司正在为生存而战。在随后的那次“裁员”中，他是唯一的人，所以他把它视为为了消除矛盾而被解雇。在第二次经历之后，他终于去审视了自己在这种模式里反复出现的角色，并改变了处理分歧的方式：更多提问和倾听，更少升级。

Q早期的攻击性是否有用？还是说，如果有人际技巧，会更好？

埃文斯认为，精力加上良好的人际技巧会更好。他仍然赞成要有主见并为之倡导；纯粹的服从，不是他的领导力模型。区别在于如何争论。他早期的版本是提高嗓门，并把别人的想法斥为愚蠢。一个更有技巧的版本，可以持续地提出挑战，而不咄咄逼人或充满敌意。往往是对的，让他得以蒙混过关地用那个糟糕的版本，但这并不能使它成为最好的版本。

Q领导者怎样避免在背后被政治手段挤走？

他说，过度的对抗，可能导致人们不再与你辩论，而是开始与别人讨论你。第一道防线，是为诚实的分歧留出足够的空间，让人们不觉得私下的运动是唯一的途径。

第二是更广泛的、值得信任的关系。埃文斯缺少那些会在另一位同事提出顾虑时告诉他的盟友；相反，那些人同意他是个问题。技术上的正确，无法取代关系，以及人们在一起工作时的感受。他承认，组织有时会选择一个在技术上较差的方案，因为它感觉更容易支持。

Q最终是什么让你认真对待人际技能？

第二次离职，以及随后在互联网泡沫破裂和 9·11 之后难以找到另一份工作，迫使他反思。一位面试官质疑了他“我曾经如此有价值，却留不住”的说法。埃文斯得出结论，缺少的能力不是编码或推动项目，而是与人良好地共事。他研究了动机、提问和工作心理学，然后对如何领导和激励产生了兴趣，而不只是陈述答案。痛苦的反馈，变成了一种持续的学习兴趣。

Q为什么搬到全国另一端去亚马逊，值得冒这个风险？

在一家与巴诺书店（Barnes & Noble）合作的搜索公司工作时，埃文斯调查过这家零售商为什么在网上输给了亚马逊。通过一家竞争对手来看亚马逊，让他对它的能力有了具体的认识，当亚马逊的招聘人员找上他时，他可以谈这些。

他也厌倦了创业公司在融资和产品与市场匹配方面的挣扎。亚马逊是上市公司，当时尚未盈利，但与几十人或几百人的公司相比，它的规模看起来很稳定。这个决定结合了对这项业务的钦佩，以及想要一种不同风险状况的愿望；它并不是对亚马逊后来成为的那家百万人规模公司的赌注。

Q晋升为总监，然后是副总裁，实际上需要什么？

对于总监，埃文斯描述的是：只凭高层次的目标，就能领导一项业务或一项重大工作的能力。在他的情形里，一件超乎寻常的事很重要：他追求与 TiVo 的视频合作，尽管领导层建议不要这样做，并明确给了那位资深领导，下令叫他不要继续的机会。它成功了，而他的晋升叙述强调，没有他，这项合作就不会发生。

他还向正准备离开的副总裁明确表达了自己的职业优先事项。埃文斯礼貌地解释，如果亚马逊不像他自己那样重视他的成长，他就需要考虑这一点。当时的时机造成了留任的压力，因为两位领导同时离开，会损害这个项目。他认为，已展现的判断力和明确的倡导，两者都是核心。

他承认一个令人不安的管理上的取舍：当两个人资质相近时，那位在推动晋升并威胁要离开的人，有时会比耐心的团队成员得到优先。他描述的是实际的留任压力，而没有把它当作理想的公平来辩护。

那个成功的项目是一次真正的冒险。一个普通的结果，可能让他留在原地，而在无视建议之后的一场灾难，则可能伤害他。回头看，他会承担更多经过计算的风险，但他的结果并不会抹去可能的下行风险。

晋升副总裁，涉及一个更长的过程：与一位稳定的经理建立利益相关者的支持和信任。他致力于一种合作关系：他解决重要的问题，而经理则为认可而倡导。大约两年半之后，这位副总裁同意为这次尝试押上自己的声誉，但不保证最终的决定。此后不久的一次重组，凸显了有利的时机与努力同样重要。

Q当你在亚马逊早期向一位优秀的工程师许诺晋升时，出了什么问题？

一位年轻的工程师，同意帮助交付产品的第一个版本，条件是得到支持，从入门级工程师晋升到下一个级别。埃文斯出于善意同意了，但假定晋升的运作方式与创业公司里一样。他被上线的问题占据了心思，并不知道亚马逊有固定的评审周期。窗口就这样过去了。

他明确承认这个错误。这位工程师不必为经理的无知负责，但工程师却承担了职业上的代价。埃文斯建议员工无论如何都要了解这个流程：确认经理是否了解，找出截止日期，并问清具体的文件和日期。一位新经理可能真心想帮忙，却缺少必要的程序性知识。

这位工程师离开了，并在别处有了成功的职业生涯。埃文斯为失去的时间感到遗憾，但强调，一年的挫折，不必定义一份长达几十年的职业。恰当的教训，是经理的责任和员工对流程的了解两者兼备，而不是为一个被打破的承诺责怪员工。

Q为什么要离开一个 800 人的组织，去担任 Twitch 整合的角色？

亚马逊在收购之后，会让一位副总裁担任整合联络人，同时让被收购公司的 CEO 继续负责。亚马逊收购 Twitch 之后，埃文斯争取了这个职位，因为它能检验没有职权的影响力。他是向 CEO 提建议，而不是向他下命令，也没有自己的团队。

他已经学会了凭正式职权运营一个大型的全球组织。现在，他不得不与一位更年轻、新近暴富的创始人共事，后者服务的受众和商业文化，与他自己的不同。他放弃了庞大的团队，去学习这个挑战，并既享受这段合作，也享受学习在 Twitch 上直播。

Q你在一位快速扩张的公司的年轻创始人身上，看到了哪些差距？

埃文斯回忆说，Twitch 把持续的亏损视为常态，因为风险投资一直都有，并且起初认为亚马逊的资金，让盈利没那么紧迫。他的领导层想要盈利，所以一个核心的挑战，是先确立这个目标到底重不重要。

他还看到了对早期员工的忠诚所带来的难题，这些人的技能没能随着组织一起扩展。在一位朋友之上引入一位更有经验的领导，或改变他们的角色，需要进行艰难的对话，有时还会导致愤怒的离职。他指出，创始人也许会用不同的方式描述这些差距；这是埃文斯对学习过程的看法。

Q在你的经历中，杰夫·贝佐斯（Jeff Bezos）和安迪·贾西（Andy Jassy）作为领导者有什么不同？

埃文斯说他与两人各开过几十次会，并强调创始人的身份是一个主要的区别。他回忆起一次预算讨论，当有人提醒现金有限时，贝佐斯却问还有多少，因为他可能想把它花掉。埃文斯把这解读为创始人对自己创立的公司，主张拥有下非凡赌注的权威。

他把贾西描述为一位更传统的高管，必须与其他领导者合作，并在董事会和创始人的期望之内运作。两人都要求很高。

他个人的契合度也有所不同。他觉得，贝佐斯的追问之后是热情和一种共同承诺的感觉，而贾西的追问，更像是审视，随后是个人问责。埃文斯明确表示，其他高管可能有相反的体验。这是对他工作关系的比较，并不是对两个人的普遍排名。

Q当一项业务举措失败时，副总裁的评估会怎样？

埃文斯区分了达成近期目标与实现业务愿景。Prime Gaming 可以交付功能并达成一些财务目标，却没有让亚马逊成为其创始人所设想的游戏领域的主要力量。他说，即使一些业务没有实现那个更大的抱负，他仍然得到了很高的副总裁评级。

他回忆起自己预计能达成所有 Appstore 的目标，同时又认为它们最终并不重要。他更宽泛的批评是，大型组织可能让产品一直存在，因为没有人愿意承认失败或关闭它们，同时又没有人知道怎样让它们取得重大成功。他关于后来的关停以及未来游戏领域可能的结果的评论，是访谈时的说法和推测。

Q强制排名和绩效计划，做对了什么，做错了什么？

埃文斯描述了亚马逊历史上的一项流失率目标，推动经理们去处理表现不佳的问题。当它被试验性地取消时，他说经理们回避艰难的对话，尤其是对人缘好的人，所以这项目标又回来了。他给出的各年比例不同，是对这套系统的回忆，并不是当前经过核实的政策。

问题在于，配额可能把一个支持性的流程，变成一个让人离开的流程。等到一位经理写下绩效改进计划时，他们可能已经决定这位员工应该离开了。确认偏误，以及来自人力资源或领导层要求记录一次离职的压力，可能与真正的恢复背道而驰。把一位员工从名单上拿掉，可能带来要再找出另一位的压力。

他说，那些来向他求助亚马逊绩效改进计划的人，后来都被解雇了，那几位没有使用他辅导的人也是如此。他现在敦促人们为另一个角色做好准备。他的强烈警告来自个人案例，而不是一项受控的成功率研究。

他的诊断是，公司往往没有培训经理及早解决问题，或者进行有用的艰难对话。一份正式的计划来得很晚，又处在被扭曲的激励之下，即使经理最初相信自己是想帮忙的。

Q是什么阻止经理不公平地描述一位下属？

埃文斯区分了清除许多员工的模式（这可以通过人员流动变得明显），与一起有针对性的案例（这可能难以质疑）。经理有地位，可以在员工投诉之前，就确立绩效的叙述。

同样的评审数量，可以支持相反的叙述：一位优秀的工程师在改进每个人的工作，或者一个人在吹毛求疵而几乎没有产出原创代码。单靠数量，都无法回答价值问题。经理可能怀有恶意，也可能是真心用不同的方式评估这份工作。

他说，自己没有亲自这样针对过某位员工，并认识到好的经理从有能力的搭档中受益。危险在于一位有报复心、掌控着叙述的领导。他实用的建议是尽可能改善关系，或者找另一位经理，而不是假定人力资源部会自动拯救员工。这是对一种脆弱性的描述，并不是对不公平对待的认可。

Q你会给职业生涯起点的自己什么建议？

继续偏好成长。他把自己的职业阶梯比作自动扶梯，因为快速增长的业务，在他自己努力之外，创造了向上的流动。他所报告的亚马逊的规模变化，提供了仅凭个人动力无法创造的机会。

更早地认识到，工作是与人一起完成的。专业能力和正确，应当与友谊、信任和被人所知相结合。内向的人可以利用写作和在线工具，而不必强迫自己采用单一的外向风格。亚马逊主动找上了他，他认为良好的声誉，是促成这类机会的一部分。

Q是什么最能解释你在 Uber 迅速升到资深 Staff 级别？

Attwell 把功劳归于几个因素的结合：一个不断增长的工程组织、可以向其学习的优秀人才，以及他所体验到的、以能力为本的文化。增长带来了许多问题，不过他承认，一家公司不需要增长，也有有用的工作。他还认为，关心团队对持续的成功至关重要。

他有意的选择，是异乎寻常地投入地工作。他相信学习会复利累积，而经理在看到能力的证据之后，才会分配有价值的工作，所以他为自己创造时间去培养这种证据。职业早期，他预期自己会比后来拥有更多可自由支配的时间。他所主张的努力与成长之间的关系，是他的判断，并不是一个被证明的普适公式。

Q这条轨迹里有多少是运气？

他把频繁的行动与不常做的决定区分开来。反复把许多小事做好，给偶然留下的空间较少，而每隔几年才选一次公司则不然。他有意选择了 Uber，但认识到这个选择可能出错。

他认为，他的努力和心态，在那种崇尚能力的特定环境里，大概会对他有利。加入一个不看重同样贡献的组织，可能延迟成长。他明确拒绝从个人努力到职业结果之间完全确定性的映射。

Q是哪些信号让 Uber 具有吸引力？你会怎样评估另一家公司？

他会考察工程师的质量，以及把他们招进来的招聘流程。他偏好困难的、与岗位相关的任务，需要对相互冲突的需求进行推理、快速吸收新材料和做取舍，而不只是回忆练习过的解法。

他的例子，是阅读一份复杂的事后复盘，并就它揭示了团队或架构的什么问题展开讨论。他相信，为许多不同的岗位设计好的面试，需要大量的领导投入和持续的实验。关于测试和智力的论断，反映的是他的招聘理念，并不是节目里经过独立科学验证的结论。

Q你会怎样测试你所寻找的推理能力？

Attwell 偏好需要同时记住多个想法和约束，又与工作保持相关的任务。一个有相互冲突需求的应用型编程问题，或者细节相互质疑的事后复盘，比练习过的回忆能揭示更多。

他还在考虑正式的智力筛选，特别是为了减少在不成功的产品经理面试上花费的时间。他把这类测试描述为一种筛选的辅助手段，而不是对已经很优秀的候选人的完整排名。他关于它们的可训练性、预测价值和 AI 的局限的说法，是归于他的主张，并没有被这份文字稿确立为研究结论。

Q为什么面试产品经理比面试工程师更难？

他认为这个角色的定义不那么一致，在不同学科之间更多样，并且缺乏同样成熟的教育和面试传统。他的组织问了几位 CEO，优秀的产品经理工作是什么样子，写下了自己的定义，并围绕它设计了流程，因为几乎没有什么是它想原样借用的。他再次把智力筛选视为一个可能的早期过滤器，同时把后面的面试，留给区分优秀与出色的应用表现。

Q除了聪明，你怎样选择时间的最佳用途？

Attwell 同意，其他技能也需要有意识地培养，尤其是优先级排序。他考虑一项举措在固定时间段内的价值，他的参与在多大程度上改变它成功的机会，以及它需要的时间。他是在试图最大化每小时的增量期望价值。

当一位初级工程师听说公司的头号优先事项时，它可能已经有了充足的人手。一项没那么显眼但仍有价值的举措，可能有更大的缺口，可以由这位工程师来填补。所以，做最重要的项目，与做出最大的个人贡献，是不同的问题。

Q工程师怎样学会估算业务价值？

问一个指标或季度目标为什么重要。一个模型召回率的目标，可能是为了降低流失，而流失又与收入有关。利用一对一，去了解领导们为什么选择或取消项目。如果公司有一份举措清单，带有估算的价值，或每个项目为什么重要的理由，就研究那一列：它暴露了别人的推理，并有助于建立直觉。他预期这是需要学习的，因为大多数新工程师几乎没有业务背景。

Q你为什么最终成为了经理？

尽管好几位经理建议，他还是推迟了这一步。在他后来的公司，一群强大的工程师已经把他当作技术领导，所以他享受着指挥工作，却不必承担正式管理的全部义务。当他的老板说，这个小组需要他，或者一位新招来的经理时，他接受了，因为他想保护一个他在乎的团队和技术愿景。

他起初做得很糟糕，躲在编码里，而不处理管理的基本功。一位新队友在三个月后曾问，Attwell 是不是真的是他的经理。他把这当作自己疏忽的证据，提升了这些技能，之后看到向他汇报的组织迅速增长。这个故事并没有让技术领导力，自动成为人员管理的替代品。

Q为什么会有越来越多的组织划到你名下？

他从一个信念开始：即使是强大的团队，也可能有很大的改进空间。他不是保留每一项继承来的做法，而是邀请人们质疑假设，包括他自己的。对一个长期存在的流程的怀疑，是发现浪费的有用起点。

一个集成团队维护着大约 1,200 个连接，用来收集餐饮行业的信息。每一个当初看起来都是一项好的投资，但维护工作不断累积，却没有对价值重新作比较。一位同事质疑，它们怎么可能全都同样重要。团队花了几天时间估算它们的价值分布，停止支持其中价值低的一部分，减少了告警，并改进了对重要的其余部分的支持。

他把整体产品描述为变得更好了，尽管它现在支持的集成更少。回收的时间还让新工作成为可能。这个例子说明，当有用的结果比被支持项目的数量更宽泛时，做减法可以创造产能。

Q当职责范围在领导者之间转移时，你怎样处理关于人的对话？

Attwell 说，这些对话需要同理心和诚实。一位有能力的人，也可能没有交付某个特定岗位现在所需要的东西，或者需要一个更小的职责范围。要解释所需要的工作，指出差距，并认可这个人仍然做得好的地方，或之前的贡献。他的描述更倾向于清晰的期望，而不是隐瞒一次组织调整的原因。

Q激励机制怎样才能让经理们不再死抓着职责范围不放？

他认为晋升与组织规模之间的自动联系是一种糟糕的设计，因为它鼓励造王国。他的公司最初借用了一套类似 Uber 的职级体系，然后试图改进它。特拉维斯·卡兰尼克（Travis Kalanick）质疑这次修订，认为它仍然过于聚焦在职责范围上，也不够有洞察力。

Attwell 和一位同事随后投入了几个月，去理解其他体系的弱点。他的核心担忧是，职责范围只捕捉了一种复杂性，同时对职位和政治手腕的奖励，多于对有用能力的奖励。

Q重新设计的职级体系，发生了什么变化？

他们从大约一千个人们通过真实工作使自己与众不同的例子开始，把它们归纳成大约 250 个属性，并使用一种他称为主成分分析的方法，得出十二个技能维度。他把薪酬描述为随着沿这些维度展现出来的技能和影响力而上升，而主要不是随职位。

重点从“把影响团队作为地位的标志”，转向“拥有可靠的想法”，包括成功地质疑基础性的假设。沟通仍然是一项独立的能力，并有好工作的例子。他希望人们提升那些通常对公司有帮助的能力，即使他们同时也在努力争取晋升。

Q撤掉一位人人都喜欢的表现不佳者，是不是格外困难？

Attwell 不同意把这当作一个无法克服的问题。一线经理可能会感到依恋，也看到社交纽带，但勤奋的同事们，也可能怨恨要替这个人兜底。他预期，艰难的当下反应，之后可能让位于一个更快乐的团队。这是他对这种取舍的看法；这期节目并没有展示某一次具体的解雇，也没有证明这个结果总会随之而来。

Q你怎样提供“求真”的证据？

寻找挑战既定做法的有用发现：一个人人看在眼里却没人认出的重要问题，或者因为团队的约束不同，而对行业惯例做出有理有据的偏离。单凭一个新奇的观点是不够的；偏离的背后需要有价值和推理。

他承认主观性仍然存在，经理们必须在例子上进行校准。现有的科技公司职级体系并非完全坏掉，他预期会有边际上的改变，而不是完全不同的结果。他想要的区别，是稍多地关注那些产生好结果的领先行为，而不是只奖励一个已经达到的职位或结果。

Q当一个项目被降低优先级时，出色的工作仍然能得到奖励吗？

能，在他的体系里。如果一个人做了出色的工作，而领导层因为与那份工作无关的原因取消了项目，这个人的贡献仍然可以被评估。他把较晚取消的责任，部分归于领导者。在最高的级别上，他预期在“一个项目是否应该存在”上有更强的业务判断，所以这项限定会改变这个论证被评估的方式。

Q为什么一些大公司，不对最高绩效者给予强有力的奖励？

Attwell 认为，它们有时仍然能留住人，尤其是当已有股权的增值，让薪酬感觉不错的时候。他反对把过去的投资收益，作为减少未来奖励的理由，并说他的公司试图避免这一点。他赞成围绕公平来设计流程，以获得长期的组织收益。这是他对激励的判断，并不是对每家大公司薪酬政策的经过核实的描述。

Q在谷歌起步，让你学到了什么？

这让他对大型科技公司的管理水平持怀疑态度。他回忆起一位他认为几乎不干活的队友，而一位经理和一位总监却强调，这个人讨人喜欢、人缘好。Attwell 提出了抱怨，这个人最终调去了别处，不过他无法证明是自己的抱怨导致了这次调动。

他认为，领导层至少应该进行一次严肃的绩效对话。这则轶事是他对某一情形的视角，并不是读者可以独立核实的评估。

Q大公司为什么可能避免这种艰难的对话？

Attwell 认为，个别团队的表现，与大公司近期的业绩之间，联系可能很弱，这让经理们可以把方便放在艰难的改进之前。提高标准要花力气；对人少要求一点，往往几乎不会遇到阻力。他预期标准会向下滑，除非领导者有意去抵制这种趋势，或者一场危机迫使改变。

他还说，好几位谷歌经理曾告诉他，过去有一项策略：即使聪明人没有产出，也要留住他们，部分原因是不让他们去竞争对手那里。他明确说，自己没有看到过书面文件，也无法证明它存在过。这种不确定性是核心；这则轶事不应该变成一项已确立的公司政策。

Q与特拉维斯·卡兰尼克（Travis Kalanick）直接共事是什么感觉？

除了人们熟悉的那种强度，Attwell 还看到了他有耐心的教学的一面。在一次资深工程师的集体外出活动中，卡兰尼克在工作环节之间，教人们玩西洋双陆棋，并指导大家滑水。Attwell 说，他很喜欢那种耐心，包括对不那么擅长运动的队友。这个个人故事增加了不同的维度，但并不声称它代表每个人对这位创始人的体验。

Q一个人应该主要因为创始人而选择一家早期公司吗？

他认为这可能说得通，因为一位拥有大量控制权的创始人，会塑造公司的构成、文化和标准。一位强大的人，可以成倍放大公司的效能，而错误的领导者则可能起反作用。建议是仔细评估这种影响，而不要单凭创始人的名气就当作保证。

Q什么建议对你的职业生涯影响最大？

一位高中的计算机老师，反复告诉他要自己想办法弄明白。Attwell 从来不知道，那究竟是有意的教学，还是老师自己不知道答案，但这帮助他接受了自主学习。他相信，大多数职业学习都需要这种习惯：不断地走出你已经习惯的领域。

Q你在亚马逊成长为软件开发经理的过程中，有什么值得一提的故事吗？

Stefan 说，他的主人翁责任意味着他常常是事实上的技术负责人，实际上也在扮演团队经理的角色，因为他的老板没有时间提供经理通常提供的那些体面。头衔落后于他觉得自己在做的事，所以他争取了它。

他相信自己拿到它为时过早。他说，人们觉得自己准备好了，却没有意识到自己还有多远的路要走。大多数新经理在早期都会犯很多错误，而围绕他们的支持结构，在很大程度上决定了他们的结果。他的第一年很不舒服，他以自己没有完全看清的方式在失败。大约 18 个月后，他才开始摸到门道。

Q你对改进讲故事有什么建议吗？

Stefan 称讲故事是一项基础技能，并说其中一部分是练习。人们一直在讲故事，却没有留意：回忆细节是一个故事，你给自己起床找的动力也是一个故事。他的第一个窍门，是留意这些时刻，并问自己今天在给自己讲什么故事，因为一个版本帮你起床，另一个则不然。一旦你能批评自己的故事，你就可以练习把它们讲得更好。

他说，作为经理，这对他来说很自然。每隔几个月，他会回顾团队完成了什么，并清晰地把它描绘出来，让人们感到自豪，比如他们从一个两个人的团队、一个糟糕的值班起步，把它修好了，并用腾出来的精力去交付。

Stefan 的主张是，一支觉得自己在赢、并由经理来定义“赢”意味着什么的团队，会在下游得到许多别的东西：人们避免零和思维和争吵，并对自己的工作感到兴奋。没有那个故事，这些问题就会溃烂。

Q你的经理在做什么？你是怎样在拥有头衔之前，就做起经理的角色的？

Stefan 的经理是一位资深经理，本应管理其他经理，却不想招别的软件开发经理，或者想尽可能拖延。Stefan 的印象是，这是一种保持对产品掌控的方式，而他喜欢这样：与设计一起工作，并为市场打磨它。Stefan 认为，这是不是经理时间的最佳用法，是值得商榷的。经理传统上负责的任务，比如检查进展、了解职业发展和指导，都被抛在了一边。

Q在你亚马逊任期的最后，是什么让你离开并加入 Meta？

Stefan 首先强调，亚马逊是一个特别而值得待的地方，无疑是成功的，并且有强大的工程学科。他离开的理由，是在那里待了相当长的时间之后逐渐累积起来的。

第一，要在亚马逊成功，需要同化到一种独特的领导风格里，公司称之为“与众不同的做事方式”（peculiar ways）。他逐渐觉得，这会让你成为一个好的亚马逊人，却不一定是一位好的工程领导者，并担心自己没有成长。第二，亚马逊把薪酬保持得更平均，这有一定的代价。他回忆起一次晋升或极高的评级，薪酬却没有变化，被解释为股价的增值，他觉得这令人沮丧，因为这适用于整个团队。

第三，当一位 Facebook 的招聘人员联系他时，他并不喜欢那个产品，却钦佩那里的工程文化。那个团队在做诚信（integrity）方向，负责儿童安全和防范恐怖主义。在亚马逊，他的供应链和机器学习工作改变的是利润，对人有一些影响，但没有同样的质性影响。前两个原因让他去看机会，这一个则把他推向了跳槽。

Q你从一线经理晋升到高级经理的背后有什么故事？

Stefan 在加入 Meta 大约三年半后得到晋升，那段时间里换了大约七位经理。这种动荡拖了他的后腿，他说，他晋升故事的一部分，就是如何在组织变动中保持势头。

入职时，他想很快变得有用，所以加入了值班并写代码，这与他的工程师和兄弟团队建立了信任。这无法持续，所以他转向了招聘，他说在那里，他从总监那里得到了一张空白支票。他说，人们如何看待一位经理，是逆风或顺风，而被贴上标签可能是毁灭性的，因为人们很难更新自己对某人将成为什么样的人的看法。

一旦他的团队的成效得到展现，他就得到了另一位经理。他说，领导一位领导者，既是又不是与领导工程师一样：这个转变比成为经理要小得多，但把它当作完全一样，很快就会失败，而对许多人来说，结局是兵变。在经理的层层叠叠之间，有一种未言明的竞争，因为如果组织没有增长，叶子节点的经理，可以通过取代他们所汇报的人来晋升。他的晋升，发生在他的组织达到大约 30 到 40 人的时候。到那时，他与其他 M2 一起坐在校准会上，很难否认他在做这份工作。

Q经理比个人贡献者更难被裁吗？

Stefan 说，调动经理本质上是痛苦的，因为爆炸半径更大。撤换是否困难，取决于这个人是不是承重的：一位拥有紧密团队和深厚领域知识的人，如果他的跨职能搭档没有尽到责任，就很难被调走。如果团队看不到什么价值，而搭档们在抱怨，撤换甚至可能令人振奋。

关于裁员，他不认为经理不太容易被裁。大多数公司都有经理与个人贡献者的目标比例，所以裁掉许多个人贡献者之后，需要的经理就更少了。公司还会做管理幅度的缩减，他相信亚马逊最近就做了，而经理们首当其冲。他不认为这对一位同级别的个人贡献者来说，更容易或更难。

Q在一家很小的公司和一家很大的公司里，哪种领导力最有效？

Stefan 说，小公司需要能鼓舞人心的执行者。工作是全员上阵，人们想为一位令人印象深刻、能做他们的工作并随时顶上的人工作。随着公司扩大，这变得更难，而这些人往往缺乏所需的组织能力。他说，在大公司里，专注是一种珍贵的商品。那些在没有对齐、也没有在组织结构图上下传递信息的情况下，就冲向一个机会的进取者，会碍事，并分走核心举措的精力。

他对比了亚马逊和 Meta 的扩张方式。亚马逊在团队之间建立了具体的、类似 API 的边界，每个团队拥有两三个指标，这样领导者可以把可靠的部件，组装成一个高耸的堆栈。代价是在组织的接缝处损失了价值，并对变化反应迟缓。Facebook 的组织是可塑的：工程师在项目之间流动，任务分配很弱，代码是共同拥有的。它的领导者需要软性的对齐技能，了解人们的长处，以及如何推动和激励他们。

Stefan 补充了一个提醒：一家公司不能只配备精通组织的人，因为那会变成负和，鲨鱼们互相争斗。他举 OpenAI 为例，并指出自己没有在那里工作过，依据的是它的招聘流程，以及与内部人员的交谈。它的面试更看重技术成就，而不是组织技能。他说，那里有很多政治，但在早期阶段，它需要技术上的成就者来吸引人才。随着组织扩大，会出现熵增，就需要能驾驭它的人。

Q如果把一位典型的 M1 放进 M2 的角色，最大的技能差距会是什么？

Stefan 说，主要的差距，是可信地为向你汇报的人增加价值。管理经理的人，与团队互动的方式更少，而一位纯粹的 M1，很难认识到这些限制，以及在哪里使用那些重要的方式。

他的例子，是一位新的 M1 设立了隔级会议，并向一位间接下属 Jan 提出引导性的问题，问她的经理 Jim 有没有把工作做好。一周后，Jim 找这位 M1 对质，而 Jan 说，这位 M1 有 Jim 所缺乏的洞见。这位 M1 绕过了 Jim，打击了 Jan 的积极性，并制造了新的问题。他说，资深领导者的小动作有放大效应，你要么通过观察，要么通过拥有一个关于事物如何传播的良好模型来学会它们。

这样的错误，是新 M1 失败的简单方式，他说领导层预料到了它们，就像对第一次当经理的人一样。战略和组织设计的错误，是后来的事，但头几周里细小的行为错误，就可能让你栽跟头。

Q个人贡献者和管理的成长路径如何比较？两者都是以能力为本吗？

Stefan 说，在高层，一切都变得不透明、模糊。在校准会上，他发现很难接受非常资深的个人贡献者，在没有可见证据的情况下大放厥词，因为不清楚他们只是身处有价值的举措周围，还是真正推动了它们。经理也一样：归因很难。在较长的一段时间里，比如在一个岗位上持续成功四年，是无可否认的，但如果以半年为单位，就可疑了。

对于六级、也许七级的个人贡献者，外部观察者更容易判断，而一位 M1 的团队和交付物，也让人能有一个不错的判断。再往上，处于领导链之外的人，看不到那么清楚，Stefan 在许多管理工作里，看到了一些无人问责的现象，好比在股市里评判一家公司的领导团队。他说，到了某个层面，很难拿到数据。主持人把这总结为早期的晋升最容易核实，而后期的晋升更容易受观感和叙事的影响，Stefan 说这是个很好的总结。

QMeta 和亚马逊之间，有哪些突出的文化差异？

Stefan 说，亚马逊是有纪律的，这是一项主要的优势，他预期那里的设计评审更有结构。他认为，Meta 的工程师平均来说稍强一些，但纪律性较差，所以评审更模糊。亚马逊更可预测，部分是因为业务节奏更慢，部分是因为你可以指望其他团队满足服务等级协议（SLA）。在 Meta，你可能得自己去做这个改动，因为负责人现在去做照片了。许多从亚马逊转到 Meta 的人，觉得这种没有结构的环境让人手足无措。

在 Meta，他看到的主要积极之处是开放与协作：他团队里的工程师，与全公司的各个组织合作，比如巴黎的一位研究员，往往不需要他来牵线。他也喜欢 Meta 对赋能于人的关注。亚马逊以流程为导向：当某件事失败时，它会增加一个机制来防止重演，而在 Meta，更可能有人说自己吸取了教训。他说，这有缺点，而 Facebook 的许多隐私问题，反映出它无法做好亚马逊擅长的流程工作。在机器学习方面，他对亚马逊的数据访问之难感到惊讶，各个团队都在建自己的数据湖，而 Meta 则有一个共享的数据仓库。

Stefan 更喜欢 Meta 的方式，尤其是在领导力方面，但也怀念亚马逊的一些东西。他认为，对一些人来说，亚马逊是更合适的选择，因为他们会比 Meta 混乱的执行方式更喜欢它。

QMeta 和亚马逊的绩效体系如何比较？

Stefan 说，它们相当接近。有一个公开的流程，在其中确定评级并告知下属，还有一个更私密的流程，通常仅限于较高的级别，用来决定把投入放在哪里：在亚马逊是“顶级”（top-tier）的认定，在 Meta 是额外的或可酌情发放的股权。目的是找出公司想留住的关键人物。无论哪家公司，人们都必须相信这个流程奖励绩效。

他曾经跟踪过 Meta 评审周期（PSC）所花的时间，并估算每位工程师的成本大约是 15,000 美元。人们很容易反应说这是浪费，但他说这是只见树木、不见森林：评审流程的公信力就是全部的关键，如果人们不相信它会为他们带来结果，他们就不会努力表现。

他看到的一个差别，是 Meta 愿意为最上面的五分之一不遗余力。亚马逊在这方面做得较少，部分出于节俭，部分出于公平。在他的组织里，一些工程师通过额外的股权，拿到的薪酬大约是同级的两倍，因为他们被视为非常重要、前途无量。在亚马逊，这种情况不常见，公司往往会想办法把它收回。

Q你经历过低绩效者的配额吗？它们是怎样运作的？

Stefan 说，每家有规模的公司都有。在 Meta 的 PSC 流程里，一个仅仅算好的半年，会被写成惊天动地，而评估通胀的方式，在平均意义上不可能是真的。所以公司以一个分布为目标，并为了保持高绩效，必须让一些人离开。经理们不喜欢这样，Stefan 也包括在内，但如果一个团队不对低绩效者采取行动，团队就会受苦，因为它看起来不再公平。

他说，被放入较低分档的比例各不相同，通常是 7% 到 15%，有时高达 20%，在亚马逊叫“需要改进”（needs improvement），按字幕所述，在 Meta 叫“部分达标”或“大部分达标”（meets some／meets most）。那个分档里的一些人，预计无法过关，而那时绩效改进计划就开始了。经理们为不让人进入这个分档而争斗，大多是为了保住面子。

他说，最糟的情形，是先告诉团队他们有多努力，然后被你的总监告知必须有人进入低分档，于是不得不告诉那个人，他们的工作是不可接受的。更好的情形是，经理及早传达较低四分位的结果，这样就没有人会感到意外。

Q考虑到你在岗位上待了大约四年，你对跳槽怎么看？

Stefan 说，对处于较低级别的、有野心的人来说，换工作通常有好处，因为成长往往发生在你在一个新环境里感到不舒服、并必须泛化自己技能的时候。他自己并没有这样做，因为他的动力是深入：大约两年之后，他到达能产生影响的程度，这是他觉得最有回报的。

在较高的级别，他说，频繁调动是个坏信号，因为很难深入到足以建立关系和理解领域。作为招聘经理，他会对每 18 个月或两年就换一次工作的资深者持怀疑态度，因为他会花一年时间让对方上手，然后看着他们离开。对中级招聘来说，这是不错的任期，但对 Staff 级别，他会犹豫。早期，换工作是合理的；随着资历增加，找到能扎根的地方是有回报的。

Q回顾你的整个职业生涯，你什么时候成长得最多？为什么？

Stefan 说，主要是在转折点，当他身处一个新的领域，一边学习一边应用的时候，这对他的技能进行了压力测试，并显示出哪些是持久的，哪些是假的。转到 Facebook，在公司承受着大量压力的背景下，以意想不到的方式拉伸了他的领导力。转向以机器学习为重点的角色，让他觉得有很多东西需要证明，这带来了他所欣赏的外部压力。

另一些成长发生在较小的跨度上。他作为个人贡献者和经理的大部分效能，来自写得好，这主要是他在亚马逊学到的。他说，亚马逊的一部分写作文化是浪费时间，人们在细枝末节上吹毛求疵，但公司鼓励好的写作，这在某种程度上意味着好的思考。

Q如果你能在刚毕业时给自己一些建议，你会说什么？

Stefan 说，他本可以在寻找指导上做得更好。他大部分是自己做的，而向像他这样的人问三个问题，也许就能省下几个月的辛苦。

他还提到书面的计划：盘点自己所在的位置，决定自己想去哪里，并列出一份清单。他的 Dropbox 里至今还有一份进入机器学习领域的旧计划。这样的计划带来了惊人的回报，而他至今仍然强调得不够。大多数人缺乏主动性，不会决定自己想去哪里然后去做，但世界对这样的计划是非常可塑的。

他回忆说，在成为高级经理后不久，他向自己的老板和总监说了一长串自己要完成的事，其中许多他不知道该怎么做。总监后来告诉他，那一刻他就知道 Stefan 会在这个角色上成功。他说，缺乏主动性让许多人止步不前，也很难灌输，但逼自己写下一份关于你真正想要什么的计划，对你的成长能力有巨大的梯度。

Q这个失败的项目对绩效评估有什么影响？工程师是否应该害怕取消一个项目？

嘉宾把负面的绩效反馈，描述为迫使他面对问题的信号。一位新经理以全新的眼光看待这项工作，并告诉他它行不通。他没有无限期地保护这个框架，而是为终止它担起了责任。

这意味着帮助各个团队，把他们现有的产品和功能迁移到原生代码、React Native 或另一种选定的方案，并把这个框架整个删除。他没有留下一个永久的残余，让别人需要去维护或清理。他还分享了经验教训。据他讲述，这种负责任的收尾赢得了好感，并在紧接着的一段时间里提升了他的声誉。这并不意味着每个失败的项目都能改善评估；重点是在这个案例里，有担当的收尾是什么样子。

Q回头看，哪些信号是你本该更早采取行动的？

他说，在项目的最后一年里，他就知道进展不顺。作为一名多产的程序员，他的本能是多写代码、转换更多功能，直到采用率起飞。这种反应回避了更艰难的结论：项目本身可能就是错的。他希望自己当时更早地对这种不安采取行动，并找到另一种有用的贡献方式。

Q亚马逊期望“劝退”多少人？

嘉宾拒绝给出确切的数字。百分之五或六，是作为假设性的示例出现的，并不是披露出来的配额。据他讲述，近年来这种指引更像是一项强制要求，而缺少补员，让反复的削减更令人不安。

他承认自己视角的局限，作为一个认为自己是高绩效者的人：他参与过决策，却无法完全代表那种害怕被解雇的体验。他强调，绩效对话关乎真实的人，以及在情感上有重大影响的结果。

在正常补员的情况下，他可以把一些离职看作因文化不合而退出。没有补员时，反复的削减会触及那些以前会被认为足够强的人。他对失去工作的同事感到惊讶，尤其对把百分比套用到很小的管理者群体上感到不安。

Q绩效讨论中会发生什么？资深的个人贡献者如何参与？

资深工程师开始被拉进来，据他所述，L7 或更高级别的参与者，会定期参与。他描述了漫长的会议，可能把人简化为指标和反馈。他没有披露详细的流程，但说它不是一个简单的线性算法。时间往往集中在分布的两端，而不是给每个人分配同样的讨论，部分原因是人群太大了。

Q对于处在绩效边界附近的工程师，你有什么建议？

他不喜欢把一个艰难的适配，当作这个人天生就是低绩效者的证据。通过一场要求很高的面试，已经说明有相当的能力；公司的期望、文化，与这个人的假设，也许只是不同。

他的建议是，找出期望没有被满足的具体维度，然后朝着扎实的表现努力，再去瞄准出色的评级或晋升。直接问经理期望是什么，以及你是否达到了。如果缺少了什么，就及早商定一份具体的改进计划。

他把这看作主动的成长，而不是等待一个正式的绩效改进流程。重点是在还有时间回应的时候，发现可以采取行动的信息。他估计很少有工程师会明确询问期望，这是一种印象，而不是一次经过衡量的调查。

Q是什么让 Singleton 这么快就从个人贡献者转为经理？

Singleton 当时是一名玩得很开心的工程师，身边有一些产品经理，帮助团队看到自己的影响。Singleton 走进经理的办公室，说想当产品经理。经理建议改做工程管理，理由是它能带来类似的、来自影响力的成就感，同时保留技术工作。当时谷歌有一个叫 TLM（技术负责人兼经理，也叫“Uber tech lead”）的角色，Singleton 觉得这个选择很容易。Singleton 承认，团队需要经理，所以也是在解决经理的问题，但说自己确实从帮助人们一起做成更多事情中获得真正的能量。

Singleton 一直深入细节，写代码、做设计，随着时间推移，同时管理好几支团队，管理占去了正常工作日的大部分时间。谷歌鼓励员工利用 20% 时间，有那么几年，Singleton 白天管理团队，等大家都回家后，再做个人的工程项目，当时 Singleton 的配偶工作也非常忙。其中一个项目，就是 iPhone 上第一版的谷歌翻译。Singleton 给所有热爱代码、但又想要管理影响力的人的建议是：如果你能找到一个两者兼顾的地方，那会非常有成就感，而如果什么能给你带来能量，就去做它。

Q作为谷歌的副总裁，Singleton 还在做功能开发吗？

Singleton 说，不是作为关键的贡献者。但 Singleton 深信（并把这个想法带到了 Stripe）：无论多资深，高效的领导者都会找到办法，在 Singleton 所说的“一英尺”层面上，亲身体验团队的工作。作为负责 Android Wear 的工程副总裁，Singleton 把它描述为谷歌智能手表可穿戴平台的基础，并且几乎像总经理一样，管理着产品、工程、合作关系、用户体验和营销，Singleton 发现，亲身体验工程师所用的工具链很有价值。大约每两三个月，Singleton 会在代码库里做一个小项目，这让提出聪明的问题、看清为扫清别人的阻碍需要什么，变得更容易。

Q在成为经理与继续做个人贡献者之间，最好的决定方式是什么？

Singleton 同意这样的建议：管理和个人贡献是不同的工作，不应该同时做，并已经把这个建议给了许多人。如果你在考虑管理，Singleton 建议找一个可以全职做它的环境，把自己个人的工作放在一边，并密切关注是什么让团队高效又快乐。这样做的人往往会成长得很好，而两样都做则更难，除非精心设计结构。一家愿意让你试做管理的公司是幸运的，如果有这个选项，Singleton 建议接受。

当人们告诉 Singleton 想转管理时，Singleton 往往先试着劝阻。Singleton 说，十年前（现在已经少了），有一种奇怪的激励结构，把管理越来越大的团队，视为奖赏。谷歌和 Meta 这样的公司，此后培育出了让个人贡献者可以晋升到很高级别的职级体系。要做一位感到充实的经理，需要从让别人发挥出更多中获得大量能量，而这并不适合每个人。Singleton 建议思考，这是否让你兴奋，如果是，就去试试。

Q当你从一线经理转为经理们的经理时，你最大的技能差距是什么？

Singleton 认为，自己作为非常早期的经理，学到了错误的教训。管着一支团队时，你可以做一切让这支团队快乐的事，但这与从它那里获得最佳影响并不相同，而且团队日后也未必会把那段时间看作职业生涯中最好的时光。Singleton 在管理一支团队时，曾赢得谷歌的“优秀经理奖”，这个奖是由团队们自己投票的，Singleton 说自己当时并不配得上。

作为经理们的经理，Singleton 认识到，完全快乐的团队很少发挥出全部潜力。要产生最大的影响，必须直接管理低绩效者，而且除非人们觉得周围的同事都尽到了责任，否则你无法让整个团队快乐。Singleton 看到一些经理，明白目标、清除干扰，并稍微推动团队一把，而另一些人，则在做 Singleton 过去做的事。Singleton 的做法，是帮助后一类人从团队里获得更多，并更频繁地走上阳台，看整个群体是怎么自我配置的。

工具也在变。一线经理需要良好的一对一、一对一的文档和目标，以及一些手艺上的辅导。经理们的经理，则可以思考组织的系统，比如产品评审和招聘流程，而 Singleton 说，自己很幸运，能在每个阶段改变这些。作为一位软件和分布式系统的爱好者，Singleton 觉得把组织当作某种操作系统来对待，令人兴奋，去问每日、每周、每月、每季度和每年所做的一切，是怎样组合在一起的。Singleton 称这是一整套一线经理不会去想的新工具箱。

Q从非常资深的经理转为副总裁，发生了什么变化？

Singleton 说，这因人而异，但对 Singleton 来说，决定性的变化，是对工程之外的职能担起责任。头衔是工程副总裁，但那时谷歌几乎不在意职位序列，而是关心把完成一件事所需的全部技能组合起来。这改变了 Singleton 的视角。在当年 Singleton 视为工程优先的那家公司的早期，Singleton 曾以为其他职能是为了给工程师服务的。Singleton 现在说，这不是真的。如果没有其他职能来帮助确保你解决的是对的问题、得到正确的用户反馈并做成正确的商业合作，你就会少很多乐趣，也少很多影响。

这也是个人层面的调整。当你管理一个自己做过的职能时，你对怎么做这项工作有直观的感觉。Singleton 有设计师向自己汇报，并称自己是个相当糟糕的设计师，在 Figma 里会做得很差。Singleton 仍然得学会好好领导他们，并发现自己很在乎设计，可以就此进行高带宽的对话。难点在于建立信心：无法跳进组织里的任何一个座位并做好那份工作，并不妨碍自己去领导。Singleton 称这是那一跃中最大的转变。

Q工程领导者应该怎样提高沟通能力？

Singleton 把沟通分为说和写。对于面向大型听众的演讲，头号方法是练习。早期，Singleton 在向一大群内部听众做演示时相当紧张，一位支持自己的经理的回应，是给了更多练习的机会。这促成了 Singleton 在做广告业务时，向一整个礼堂的谷歌客户演讲。Singleton 回忆起在伦敦、国王十字车站附近的一场，可能有一千人，有现场演示，还有一段关于本地广告的励志演讲。这很吓人，但 Singleton 做到了，并说重复才是让它顺利的原因。

关于写作，Singleton 说自己仍在学习，并大量使用 Claude。Singleton 认为，把最重要的要点浓缩成一份简短清晰的文档是有价值的。向大型听众演讲，也许只有大约 30% 的人真正在听，而且人们会忘记。一份好的文档会被传阅、阅读和重温，所以它是一种大规模沟通的高杠杆方式。但 Singleton 认为两者都需要：人们会听与自己有私人关系的人说话，这种关系来自现场的交谈，而一旦它存在，书面材料就很容易扩展。

Q对于资深领导者来说，除了辅导直接下属之外，有哪些高杠杆的方式来扩大规模？

Singleton 指出了组织的仪式和流程。作为职业早期的工程师，Singleton 曾觉得“流程”是个脏字，部分是因为 Symbian 的流程库，那是一种质量认证的做法，人们被要求查阅并遵循有文档记录的流程。实际上没有人这样做，如果有人问起，人们事后才填表。当 Singleton 成为组织的领导者，被告知要考虑流程时，第一反应是沮丧。从第一性原理出发，Singleton 认识到，重点在于事情借以完成的那些仪式和工作方式，而把它们做对，影响非常大。

作为一个例子，Singleton 在同事的帮助下，在 Stripe 设立了一组叫作“运营评审”（ops review）的会议。其中一个由 Singleton 主持的每周会议，审视最重要的事项，而一套嵌套的会议，则贯穿公司里所有的工程团队。Singleton 说，这帮助整个公司关注并改进了可靠性和效率等事项，而这些事如果只是与直接下属谈话，让信息层层往下渗透，是很难推动的。

Q借鉴伦敦的经验，你怎样让一个远程的工程站点承载正确的文化？

主持人指出，Facebook 伦敦站点的负责人，曾称赞 Singleton 给出了关于创建那个站点的最佳建议。Singleton 解释说，自己当时领导谷歌的伦敦工程站点，而另一位领导 Facebook 的站点，所以两人在人才上展开激烈的争夺，常常发现双方给同一位候选人都发出了邀请。另一个站点的负责人最终联系了 Singleton，这让 Singleton 很钦佩。Singleton 珍视一种硅谷式的态度：即使是激烈的竞争者，仍然会在手艺上互相帮助，并相信两人帮助提高了伦敦的工程水准。

对于一个远离总部的站点，比如伦敦到山景城，每天也许只有一小时的重叠，Singleton 推动团队能够自己扫清阻碍并自主运作，这样他们在重叠的时间里要做的事就尽可能少。每个伦敦的团队，都需要一个清晰而完整的使命、大量的自主权，以及独立执行所需的全部装备。Singleton 说，最糟的安排，是每个地方各有半个团队，因为扫清工作障碍所需的每天上百次对话，塞不进那个时间窗口。一个时区相同的站点，比如 Stripe 的西雅图办公室相对于旧金山，则可以设置得很不一样。

Singleton 还描述了早先的一位伦敦站点负责人，很少待在伦敦，并解释说，对这个站点最好的事，是待在山景城，建立私人关系，并把背景信息带回来。Singleton 后来也这样做，经常飞往加州，让别人不必去，并确保团队的能力被看见，比如曾做过 WebKit 的那些伦敦专家。

最后，Singleton 说，每个有效的远程站点，都有一点自己的文化。一种身份认同感，让人们愿意花精力去消除摩擦，因为他们是同一个“部落”的一员。但这种文化不能与整个公司的截然不同，否则人们就会开始把海洋另一边的人看作傻瓜。窍门是拥有足够的身份认同，让人们互相帮助，并植根于公司的文化。回应主持人的提示，Singleton 确认，这意味着 T 恤、笔记本电脑上的标志，以及聚会，讨论这个站点擅长做什么工作，之后 Singleton 又把这些带到了加州。

Q哪家大科技公司的工程文化设计得最好？

Singleton 说，自己处于劣势，因为在大公司里只在谷歌工作过，对其他公司只是凭名声了解。据 Singleton 所述，谷歌的文化是非凡的：每个人都是来做大事的，被鼓励去产生影响，并被给予很大的自主权。但 Singleton 不认为它是经过非常刻意的设计的。它不是混乱，也有组织结构，但主要是自然生长出来的。

相比之下，当 Stripe 在扩张的同时设计自己的组织结构和工作方式时，Singleton 参考了那些做得刻意的公司，尤其是亚马逊。Singleton 与那里的许多资深领导者交谈过。Stripe 曾经开、现在仍在开的运营评审，就是仿照亚马逊的。Singleton 回忆起 Charlie Bell 花了一顿午饭的时间，讲解它是怎么运作的，而 Stripe 采纳了适合自己规模和文化的部分。Singleton 称亚马逊是其系统化的组织与运营设计最让自己受启发的公司，尽管从未在那里工作过。

Singleton 说，很想在每一家这样的公司里为一个项目工作，去亲身体验。比如苹果，打造 Singleton 喜爱的产品，内部不太透明，对自己的组织结构很刻意，设有一所“苹果大学”，新人在那里学习用苹果的方式工作。这让 Singleton 想起职业生涯之初与手机制造商打交道，看到许多达到同样目的的方式。Singleton 想从“自助餐”里挑选，但只在一家大公司工作过，并与另一家的领导者深入交流过。

QStripe 的运营原则似乎呼应了亚马逊的。运营原则与价值观有何不同？

Singleton 解释说，运营原则不同于价值观。早期的 Stripe 团队问，他们工作方式中，哪些让他们最有效。他们的原则是具体的，从高效同事的行为中提炼出来，并随时间重新审视。

最激励 Singleton 的原则，是对自己的手艺一丝不苟：为可靠性、打磨精致的细节和谨慎的对外沟通感到自豪。他说，这种用心对人们如何看待这项工作有巨大的影响，即使它很难量化。更宽泛的教训是，让一支团队成功背后的工作原则变得有意识、有目的。

Q在公司的哪个阶段应该开始考虑文化？领导者怎样让它落地？

Singleton 正在创办一家非常早期的公司，并认为文化从第一天起就很重要。在注册公司的那天，Singleton 和联合创始人们一起去喝了一杯，写下了他们的价值观，并在招聘和公司的运作方式中使用它们。因为早期的公司经常会被意外“当头一棒”，价值观有助于说明哪里该妥协，哪里不该。Singleton 说，现在就安排每周的文化活动还太早，在这个阶段，文化应当是自然生成的。但在较后期的公司里，你需要有意识地去做，因为公司是一大群人，如果没有什么东西以共同的目标和对齐把他们聚在一起，熵增就会接管一切。Singleton 说，如果你不在文化上投入，几乎可以肯定你不会有文化。Singleton 指出，像 Stripe 和亚马逊这样有意识的组织，往往非常有效，而 Singleton 早期工作过的一些没有这样做的公司，没能持续下去。

Q有哪些有意识的工程文化改变，成就了 Stripe 的多个九的可靠性？

Singleton 说，Stripe 在任期内达到了五个九以上的可靠性，并说自己听说上个季度达到了六个九。这些是 Singleton 的数字，这里未经核实。对于一家支付公司，每一秒的宕机都让商家损失真金白银，所以可靠性极其重要。Singleton 说，这始于有意识的行动。2020 年的疫情，让大批线下业务涌向线上，Stripe 的系统扩张得比预期快得多，所以公司知道必须提高标准。工程组织当时并没有为此做好准备。此前，它正确地专注于产品与市场的匹配，紧急情况随到随修，但到了规模化阶段，可靠性很重要。Singleton 称这个变化主要是文化上的。

Singleton 的做法，是给每支团队提供工具，用科学的方式权衡功能开发与可靠性工作之间的取舍。这意味着运营评审，加上一套嵌套的系统、会议和数据工具，以及反复查看数据并决定做什么的机会。简言之，就是建立“它很重要”的信念，搭建一套可重复的系统，让每个人都有正确的输入，并足够频繁地查看，以便采取行动。因为一切都被系统地衡量，并被广泛地呈现，Singleton 说，在效率和性能上也取得了进展。

QStripe 做了什么，来招聘这么强的工程师，而又不依赖 LeetCode 式的面试？

Singleton 从吸引力说起。许多优秀的工程师想来 Stripe 工作并主动联系，通常是因为他们对这款产品有过良好的体验。Stripe 的核心是一个开发者平台，它拥有行业里最好的文档之一，这一声誉当之无愧。Stripe 把文档当作构建产品的一部分，由产品团队来写，而不是单独的团队，API 设计得很漂亮，并为呈现的方式感到自豪。所以，Singleton 说，推出一款出色的产品，人们就会想去做它。

关于评估，Singleton 说，在 Singleton 加入时，行业里仍有很多白板面试，Singleton 在 Stripe 之前的所有面试都是这种。Stripe 相信（Singleton 现在仍然相信），在白板上写代码，并不是模拟看一位工程师做真实工作的好办法。所以 Stripe 设计了一套流程，候选人用自己惯用的工具，在笔记本电脑上，与面试官结对编程，以提供尽可能真实的工作体验。这些练习是刻意设计的，用来选拔那些想对自己的手艺一丝不苟、并具备核心的工程、设计和探究技能、能发现需要做什么的人。Singleton 认为，这让人才的门槛多年来得以保持。

QSingleton 从 Stripe 的领导团队那里学到最多的是什么？

Singleton 说，从领导团队的朋友和同事那里得到的最大教训，是从第一性原理思考的价值，这是 Singleton 加入时不擅长的。在谷歌，行业里的许多工作方式是它发明的，Singleton 的习惯是问上次是怎么做的，然后重用。在 Stripe，面对一个问题时，反复出现的一句话是：问问究竟发生了什么，并理解其中的动力。一项相关的技巧，是询问几家外部公司的人，他们是怎样处理类似问题的，并进行三角验证。Singleton 说，这听起来可能很慢，但应用于最关键的问题，它带来了多重视角的好处，Singleton 至今仍这样做。

QSingleton 现在的日常工作，与第一次当一线经理时相比有多大不同？

Singleton 说，相当不同，主要是由于此后的经验和教训。Singleton 正在运用讨论过的许多东西：定期走上阳台，看看一切是怎样运转的，并把更多精力投入到每周的准备上，确保团队知道最重要的事情是什么。职业生涯早期，更多是凭直觉走向最明显的下一件事。Singleton 也发现有很多相似之处，所以既有点像回家，又像一个美好的新挑战。Singleton 不想去做任何别的事情，相信这是一次深刻的技术飞跃，并说这份工作很难，但很有回报，现在正在创造大量的“第二类乐趣”。

Q像做事故复盘那样回顾，Singleton 的职业生涯里有哪些做得好的地方？

Singleton 从早期选择里的运气谈起。落脚 Symbian 是一段塑造自己的经历，用 Singleton 的话说相当随机，所以 Singleton 不确定别人能从中借鉴什么。Singleton 说，更大的因素，是始终确保自己在学习，这解释了为什么在谷歌待了很久，也解释了在 Stripe 的愉快时光。Singleton 还在公司内部换团队，专门为了在舒适区之外学习。

举个例子，Singleton 在谷歌做安卓之前先做移动方向。有一个周末，Singleton 记得很清楚，移动端的搜索查询量超过了桌面端，对公司是一记警钟。那个做移动业务的小型旁支团队决定解散，把这项工作推广到公司的其余部分。Singleton 默认的路径，本来是加入安卓团队，后来确实去了。但当时 Singleton 决定，最值得学的是广告，因为 Singleton 完全不知道谷歌是怎么赚钱的。当时已经相当资深，加入的是一个人员大多在其中成长起来的组织，必须以惊人的速度学习。Singleton 现在理解了拍卖系统以及发布商和广告主的商业模式，如果没有这一跃，就不会懂。

Q有没有一本书真正影响了你的职业生涯？

Singleton 点出了英特尔前 CEO 安迪·格鲁夫（Andy Grove）的《高产出管理》（High Output Management）。Singleton 说，在谷歌遇到、并以为是谷歌发明的几乎每一种工作方式，结果都来自格鲁夫，包括 OKR 和如何开高效的一对一。这是一本很短的书，Singleton 在从伦敦飞往山景城的航班上读完了它，有点让人爱不释手。Singleton 承认，其中有些内容也许已不再适用，但说读它是一个关键时刻，让自己以不同的方式思考如何运作工作中的一切。

Q有没有一种习惯，在你整个职业生涯里产生了持久的影响？

Singleton 描述了一种规划的习惯。很长一段时间里，Singleton 只是做送到面前的事：邮件、日历邀请和已经排好的一对一，所以日历和收件箱支配着自己，即使有目标也是如此。Singleton 意识到这是本末倒置，并在多年前的谷歌时期，开始为每一周写一份待办清单。按 Singleton 的经验，一周是合适的粒度。周日晚上，Singleton 会问：要做哪些事，这一周才算很棒，并把它写下来。这份文档叫“火箭文档”（rocket doc），一旦谷歌文档支持表情符号，就加上一个火箭表情，以传达想要的能量。在这一周里，Singleton 不是去收件箱或日历，而是去火箭文档，来决定下一步做什么。

后来，Singleton 把这份文档分享给了行政助理，Singleton 称之为“作弊码”。共同的目标，是让 Singleton 把时间花在那些事情上，所以到周二中午，助理可能会问进展如何，并催 Singleton 去做原定的工作，并围绕它安排日历。

Q如果给刚毕业、即将进入这个行业的年轻的自己一些建议，你会说什么？

Singleton 会重复前面的教训。当你知道某件事，却以为是因为你不是负责人，就要开口。Singleton 相信，当你这样做时，好事就会发生，而且即使多做一些，在 Singleton 担任过的各个角色里，也会带来更多的好事。

QNetflix 与 David 工作过的其他公司有什么不同？

David 说，之前的每一位雇主，从 IBM 到好几家较小的公司，都容忍“自大的名角”（prima donna）：非常聪明、却很难共事、会对同事和客户大吼大叫、不能承认错误的人。他描述了一位 1990 年代被视为不可或缺的工程师，隔间里堆满了杂物，避开别人，在夜里修好问题，而经理们并不理解他的工作。当他辞职后，公司活了下来，团队的其他人也逐渐理解了他曾把守的那个领域。

David 说，在 Netflix，没有人是那样的。文化幻灯片里说，公司不雇用“聪明的混蛋”，并且会让任何难相处或难以接近的人离开，无论多聪明。David 称这在 21 世纪初是革命性的，并指出他现在所知道的大型科技公司，也都是这样运作的。

他与当时的首席人事官帕蒂·麦科德（Patty McCord）的面试，让他感到意外，她批准那家小公司的每一次招聘。David 说，她告诉他，Netflix 并不看重 24/7 的工作，他应该用一个八小时工作日里能做的事，给公司留下深刻印象。David 后来看到一位经理说，他无法继续全天候工作。麦科德谢过这位经理，然后告诉他不要再这样做，并把团队安排好，让他不必这样。David 称这在 2008 或 2009 年是不可想象的，并说他从麦科德身上学到的关于领导和协作的东西，比他认为的甚至从里德·哈斯廷斯（Reed Hastings）那里学到的还多。

David 给出了自己的例子。在早期不稳定的持续部署的尝试中，一位优秀的工程师说，David 一定喜欢周末休息，因为如果团队停止工作，系统就会垮掉。David 在一对一里告诉他去休假，并说自己不在乎东西坏了。这位工程师休了一周，其他人也休息了，David 说，团队随后用自己的方法很快稳定了系统。

David 以哈斯廷斯结束。据 David 说，哈斯廷斯把邮寄 DVD 视为通往流媒体的垫脚石，这就是公司不叫 DVDsbymail.com 的原因。哈斯廷斯不是视频专家，但组建了一支由强大的领导者和工程师组成的团队来解决这个问题。

Q随着公司的成长，Netflix 的文化发生了怎样的变化？

David 首先说，文化备忘录是志向性的。当人们问 Netflix 是否真的这样运作时，他回答说，它描述的是公司渴望成为的样子。

然后他描述了没能规模化的东西。Netflix 把功劳归于团队，而不是个人。当公司在 PlayStation 3 上推出服务时，David 说，索尼的 DVD 部门要求 Netflix 停下来，因为他们并没有为此设计这台游戏机，而 Netflix 继续做了。事后没有人点出那些奠基的工程师；功劳归于 Netflix。这在公司很小的时候行得通。当它承担了许多产品之后，个人的贡献就被淹没了，而如果工程师得不到认可，他说，领导者就会把功劳都收走。

Netflix 也没有工程职级。每个人要么是工程师，要么是资深软件工程师，名片上可以印除经理、总监、副总裁或首席之外的任何头衔。这适合一支全是资深者的团队。随着招来更多的初级工程师，David 认为，团队里既有强的、好的，也有弱的工程师，而如果没有客观的方法来区分他们并奖励胜利，最优秀的人就会离开。到 2010 年代后期，他一直主张设立职级。他假定此后已经加上了，但他已经离开六年了。

David 补充说，麦科德面试了几乎每一位早期的新员工，而哈斯廷斯每次会见几位新人，随着公司的成长，这无法继续。当他离开时，他觉得这份备忘录适合一家非常小的、有进攻性的、以工程为中心的公司。

QDavid 怎样在招聘中识别真正优秀的软件工程师？

David 说，他的招聘一直成功，直到 Meta。像 Meta、谷歌、亚马逊和微软这样的大公司，需要结构和一致的标准，所以它们使用正式的面试体系。在较小的公司，当他自己做出雇用或不雇用的决定时，由他、三位团队成员和人力资源一起面试每位候选人。

他讲了一位 1990 年代末的候选人，她曾构建过无人驾驶列车的软件。David 是最后一位面试官，他的 45 分钟时段延长到了 90 分钟，两块白板上画满了状态转换。他说，她对由相互作用的各部分构成的复杂系统的把握，是他见过最好的之一。其他人问了她编码问题，她表现不错，但面试小组反应冷淡，他的老板也表示反对。David 争辩说，团队正苦于整合各个互不相同的系统，需要她。他们雇用了她，他说她表现出色。他声称，自己在小公司的招聘记录近乎完美。

David 知道他接下来的观点有争议：他不喜欢 LeetCode。他说，它显示的是，一个人为一个练习过很多次的问题，能多快地写出代码。他承认，以 Meta 和谷歌的招聘量，他们几乎没有别的选择。

他的替代方案，是工程基础：理解复杂的系统，强大的技术直觉，以及在数据不足时做出可靠的决策。他见过来自其他领域的工程师，在软件方面做得非常好。他也见过那些把 LeetCode 做得很出色、并演练过谷歌 type-ahead 这类系统设计题的人被录用，然后产出糟糕的工程，这是他在评审材料里看到的。他相信这种基础在很大程度上是天生的，就像音乐天赋，并说他可以帮助某人改进他们的软件，但无法教会他们做出好的决策。

他的第二个故事，是关于圣何塞州立大学研究生课程里的一位项目搭档，他在 50 多岁、加入 Meta 之前上了这些课。她当时快读完土木工程的硕士学位，在污水处理领域工作，想转入软件行业。David 对她的分析头脑和对统计学的掌握印象深刻，想让 Netflix 雇用她。她的带回家完成的视频软件任务，花了三周，还有新手的错误，所以为了帮助促成交易，David 建议她给团队教点东西。她在白板前花了两个小时讲污水处理，到一半时，David 意识到自己看到的是一个非常复杂的状态机。一位经理问，污水跟软件有什么关系，却还是雇用了她，后来在一次 Meta 的活动上告诉 David，她做得非常好。David 说，当你看到一个杰出的工程头脑时，LeetCode 的速度或者构建一个可扩展的 type-ahead 都无关紧要，因为那些可以很快学会。

David 承认，这种方式在 Meta 或谷歌无法规模化，在那里，法律和政策上的问题会让它行不通，所以它们设定一个标准和级别。他在级别方面的建议是接受较低的录用：在别处是 6 级、在 Meta 被给到 5 级的人，应该接受它，并按更高的级别去执行，因为奖金、乘数和后续的股票随之而来。一位定级过高的新人如果吃力，没有干净的补救办法。他的规则是，有疑问时，宁低勿高，然后赢得快速晋升。

QDavid 共事过的最强的工程师是谁？这个人强在哪里？

David 点出了 Giannis，尽管他通常避免提名字。字幕把姓氏弄混了，所以这里省略。他们 2000 年在 InterVideo 相识。Giannis 当时已离开这个行业，去希腊教信号处理，2010 年夏天，David 趁着休息期间把他请来，帮助出一些关于并行编码的想法。David 说，这项工作催生了基于内容的编码（现在整个行业都在用），以及一项早期的专利。

Giannis 后来加入了 Netflix，David 说，他把这个想法进一步推进，字幕把它写成“convex all encoding”，大概是 convex hull（凸包）。David 说，它在给定带宽下提供最高的质量，现在是 Netflix 和 Meta 的模式。Giannis 还构建了一个用于评估编解码器的成本效益模型。David 认为他的长处，在于把学术的严谨性带入实践：决策依据的是在 1 万、一百万或十亿个视频上的测试，而不是两段压缩视频在理论上所显示的。

QDavid 是怎样被招到 Meta 的？

David 说，Netflix 早期的文化幻灯片，建议经常去面试，以了解自己的市场价值。据他回忆，当 Facebook 在 2017 年末联系他时，他已经大约十年没有面试过了。用他自己的话说，他去的时候有点自视甚高，引用 Netflix 如何构建了最大规模的编码平台。一位面试官告诉他，Facebook 无法用 CPU 解决它的视频规模问题。David 被惊到了，后来向对方道了谢，并意识到自己对视频的理解过于狭窄。他得到了录用通知，却拒绝了，因为他还没有准备好。

不久之后，Giannis 告诉 David，他收到了 Facebook 的录用通知，以及他将要做的定制芯片（ASIC）工作。David 看到了他身上有一种已经有一段时间没见到的热情。他认为，Netflix 的文化不是围绕个人贡献建立的，可能没有奖励 Giannis，而且那里的问题对他来说也许显得不够大。David 说，他没有试图劝 Giannis 别走：作为他的老板，他不想失去他，但作为他的朋友，他无法反对。David 面试主要是为了锻炼自己的面试技能，但最终他看出，Facebook 的视频工作是一个非常难的问题。他的团队很扎实，接班人也已就绪，所以 2019 年他离开了 Netflix，Facebook 很快给了他一份工作。

在 Netflix，他的编码团队从一个人增长到大约 55 人，信任也随之增长。在 Meta，他接手了一支 55 到 60 人的视频处理团队，他们并不认识他。在一次早期的会议上，他谈了哪些方面需要改进。一位团队成员在一对一时告诉他，他才来了两周，就已经在告诉团队该做什么了。David 的结论是，他需要停止说话并建立信任，这是他从未需要培养的技能。

他的教训是，领导力关乎关系。如果一支团队是坏的，领导者的工作就是修好它。如果它已经执行得很好，工作首先是不要把它搞坏，其次是帮助它向前走，而他当时直接跳到了第二步。David 说，关于 Meta 最悲哀的事是，那是他的最后一份工作。他相信自己现在会是一位好得多的组织和工程领导者，但不再想承担那份责任，并说他在那里学到的关于工程领导力的东西最多。

QDavid 在 Meta 最喜欢的工作或项目是什么？

David 首先说的是，把 Netflix 级别的质量带到 Meta 的规模上，他说这成功了。然后他转到新冠疫情。他在 2019 年 7 月下旬加入，到 2020 年 3 月，所有人都在家办公。Meta 从夏天起就为除夕夜做规划，因为视频流量会在 24 小时内飙升。David 说，到 2020 年 4 月，每一天在上传、播放和直播视频方面，都像除夕夜。那些从未在这样持续的负载下运行过的系统，正在慢慢“失血”，问题之一是竞态条件。他说，印度总理当时正通过 Facebook Live 向全国讲话，他被这份分量吓坏了。团队在家工作，找到了问题，并解决了竞态条件。大约一个月后，系统和指标稳住了，David 说他为此感到自豪。

他还描述了自己对公司价值的看法是如何改变的。他起初是通过一种以美国为中心的视角，把 Facebook 看作一款社交应用。他逐渐看到 35 亿客户意味着什么。按 David 粗略的比较，Netflix 大约 3 亿的订阅者，是按收入计算全世界最富有的 5%，而 Meta 触达的是最富有的 50%。他称“富有”是个带倾向性的词，因为最底层的人每天靠大约 68 美元生活。他说，Instagram、WhatsApp 和 Facebook，是整个印度小商店的生命线，西雅图一位来自索马里的优步司机告诉他，WhatsApp 让他分散各地的家人保持了联系。

David 说，美国对社交媒体的讨论，集中在假新闻等危害上，而忽略了这些产品在别处如何改善生活。他相信，这家公司通过给人们一门生意、一个分享视频并从中赚钱的平台，以及一种与家人保持亲近的方式，改变了人们的生活，而能以小小的方式参与其中，感觉很好。

QDavid 的职业生涯中，工作与生活的平衡发生了怎样的变化？

David 说，在 1990 年代末，他为一位有远见的高管拼命工作，是因为团队在努力追赶，而不是因为有人要求。在创业公司 InterVideo，期望是 24/7。他大约上午 10:30 到，晚上 10 点左右离开，有时凌晨两三点，常常一周七天，追逐交易，以在 IPO 之后抬高股价。

2004 年 1 月，他在一个周日病倒，并持续恶化。周五，他的妻子带他去了急诊室，他说，一位医生说那是结肠癌，伴有一处可能很快致命的梗阻。他住院大约三周，做了两次手术和化疗。那是三期，伴有淋巴结转移，他把自己的五年生存预后定为大约 25%。他的孩子们当时分别是两岁、四岁和七岁，他说最小的几乎不认识他。

在医院里，他决定自己的工作方式是错的。他告诉老板，他仍然想要这份工作，但无法以那种方式工作，并说如果一家公司威胁说，你不晚到就要开除你，那你能做的最好的事就是离开。他相信 InterVideo 是用工时来掩盖糟糕的领导。他称工作与生活的平衡，是被强加到他身上的，而他下定决心，永远不做一个期望人们为一份工作拼命的领导者。在 Netflix 听到公司不看重 24/7 的工作，对他来说是一个震撼。

他的建议是不要等到得癌症或心脏病发作。尽早把平衡融入进去，去休假，让公司独自撑一周。David 说，如果它离开你七天都撑不住，那是它的问题。

David 说，像 Meta 和 Netflix 这样的高绩效公司，常常被误解。他回忆起 Meta 的一张摇摇木马的海报，大意是不要把运动误当作进步。他建议与你的老板就最重要的工作达成一致，并告诉老板哪些任务你不会做；如果其中某一项很重要，就必须有别人来做，或者必须改变优先级。在大科技公司里，赶工期会来，但它应该是例外，提前计划，比如五六月冲刺，然后休假。他说，即使在 Netflix 或 Meta，如果经理提供清晰的背景，平衡也是可以实现的。

Q哪份工作让 David 学到最多？为什么？

David 说，他最近的四份工作，每一份都有贡献。第一份把他变成了一位高绩效的软件工程师，靠解决的问题而不是工作的小时数来表现。第二份给了他视频方面的基础。他说，Netflix 是从零到一，在那里，他学到了领导力、招聘与解雇、设定背景和跨职能工作，并把这些带到了 Meta。

他到 Meta 时缺少的，是一套关于规划、评审和绩效的客观流程。他称 PSC 绩效周期，既是他最害怕的，也是他最喜欢的一年中的时间。据他描述，每个人写一份自我评估，经理整理一份材料，附上与目标挂钩的反馈，然后经理们在校准会上为自己的工程师辩护。David 说，每位经理都认为自己的团队是最好的，所以目的是用数据来说服：谁应该得到什么级别，谁在一个项目上做了什么。他看重把每位工程师的影响记录在案。他说，离职的员工会保留他们曾拿到的每一份绩效材料。

David 曾听说过关于绩效周期的恐怖故事，但进去之后发现它很重要。他说，他最大的快乐，是给一位下属最高评级，他也看重帮助低于期望的人恢复过来。他补充说，他过去以为自己通过关于分片和微服务的书籍懂得了规模，但在他看来，那些作者并不懂 Meta 那个级别的规模。他到一份新工作里能带去的最有价值的东西，是一套客观规划、评审和绩效的系统。

Q有没有一本影响了 David 职业生涯的顶级好书？

David 选了一本 1990 年代末的书，他称之为《12 Secrets to Microsoft Success》；这个书名来自自动生成的字幕，未经核实。他说，它描述了微软的激进思维。一个想法是“押注公司”，他说自己在 Netflix、亚马逊和 Meta 都见到过，当一个大机会值得拿公司冒险、却不孤注一掷时。另一个是“好的失败”：在一家健康的公司里，项目和人都会失败，重要的是你怎样失败，学到了什么，以及这次押注是否合理并被及早管理。

据他回忆，这本书里提到，微软是第一家公开说要雇用前 5% 软件工程师的公司，并创造了“吃自己的狗粮”（dogfooding）这个词。他说，当 NT 服务器在 1990 年代中期严重出问题时，比尔·盖茨让全公司都迁移到它上面，这把 bug 摆在了每个人面前，并得到了修复。在快速增长之后，盖茨还实行了全公司的招聘冻结，因为人们在做无关紧要的事，比如 Microsoft Bob。高管们被迫砍掉项目，David 说，最后的 20% 被裁掉了，他认为这本该发生。

David 说，微软为现代的工程领导力设立了早期的模型，别人也借鉴了它。在 2022 年的崩盘之前，他就觉得招聘速度说不通。在疫情期间，每个人都加快了招聘，没有人放慢。他相信，如果大科技公司的领导者读过这本书，他们在 2021 年末就会看出，招聘已经失控了。

QDavid 有没有什么遗憾，是别人可以借鉴的？

David 说，他毕业后的头六年，是在非常大的、正在衰落的公司里虚度的。他点出了从通用汽车分拆出来的休斯（Hughes），以及卖给西门子的一个 IBM 部门，两者都失败了。他有不错的薪水和轻松的工作，只想着眼前，没有考虑成长。他不是指对十年后的副总裁头衔有野心，只是指考虑成长。

他说，特别是对软件工程师来说，学到的一切，大约五年后就会过时。当他加入 Meta 时，新兵训练营和整个开发环境都被换掉了；作为总监，他一直是精通的，但当他后来转到个人贡献者的角色时，发现一切都变了。David 说，他保持成功的办法，是不断推向前沿，并不断学习新的工程技能。

QDavid 会给职业生涯起点的自己什么建议？

第一，做困难的问题。David 说，如果工作不难，你就没有在成长。他说，一旦一个角色停滞不前，在 Meta 这样内部流动容易的公司里，工程师就应该去找另一个困难的问题。困难的问题，才是推动工程师前进的东西。

第二，公司的大小无关紧要，但每个人都应该在某个时候，最好是年轻时，在小公司或创业公司工作。他告诫不要过分被技术迷住，并说要为既有远见又能执行的领导者工作，因为没有执行的远见哪里也去不了。他举扎克伯格和哈斯廷斯为有远见的人，并说哈斯廷斯在 1999 年就是，当时 Netflix 只有四个人。领导者应该让你梦想扬帆出海，而不只是为一艘船砍木头。

第三，从第一份工作起，就有意识地规划工作与生活的平衡。他说，工作和生活是有张力的，但最好的工程，来自既热爱工作、又享受休假的人。

第四，从第一天起就开始财务规划，因为随着技术人员成功，他们赚得更多，而没有规划，就不知道钱去了哪里。David 建议有意识地规划支出，以及短期和长期的储蓄，二十多岁时定期存入小额资金，并且不要长期的信贷或债务。他说，到 40 岁出头，除非你很幸运（比如早期在 Facebook 或 Netflix 工作过），这通常还不够退休，但它可以带来财务独立，这样你就可以接受一份薪水较低的工作。在他看来，对于起步较晚的人，单靠 401(k) 和社会保障是不够的。他认识许多 50 多岁的工程师，赚得不少却没有规划，并说一位受雇 30 到 35 年的好工程师，没有理由不能舒适地退休。他在别处说过，自己不是理财规划师，所以这只是一个人的看法。

Q有没有下属向你升级上报过与他们经理之间的问题？隔级领导为什么可能不愿采取行动？

伊森·埃文斯说，这样的升级上报很常见。他描述了一种令人不舒服的激励：接受一位下属的陈述，会给隔级领导带来三个问题：决定怎么处理这位经理，必要时替换并培训一个人，以及在此期间顶住工作。反过来，把这位下属斥为过于敏感，则让问题更容易被重新推回给经理。埃文斯把这呈现为一种可能的潜意识偏见，而不是为无视一个有效的顾虑辩护。

他讲述了自己是在几份下属的陈述累积起来，并与受影响的同事交谈之后，才发现一位领导对女性的恶劣对待。早先单独一份陈述，也许不会打动他，这是他坦率地承认的一个失败。多份独立得到佐证的陈述，改变了他的认识。因此，他建议在同事愿意提供时，进行交叉印证；讲述者的“兵变”比喻，针对的是职场的升级上报，不应掩盖这个例子的严重性。

Q你能出于业务原因寻求调动，而不是组织一次升级上报吗？

埃文斯区分了两种做法。如果有一个真正可信的理由，说明另一个角色会让工程师对组织同样有价值或更有价值，就以这个理由为先，而不要提出对经理的投诉。如果真正的需要，是互不相容的工作关系，就以不指责的方式说明，并往前想好几步：领导者实际上有哪些选择。

他讲述了自己在亚马逊的调动。他的领导想把他留在现在的角色里，但埃文斯除了在这位领导的组织内部有一个他更想要的角色之外，还有另一个在该组织之外的可用角色。他解释说，留在原位已不再是一个可用的选择，这把决定从“把他留在这里，或在内部调动他”，改变成了“把他留在组织里，或者失去他”。经过几周的抵制，内部调动很快就实现了。这个故事依赖的是拥有真正的备选方案，而不是编造一份外部的录用通知。

Q你是怎样传达这些备选方案，又不显得带有威胁的？

他用领导者能认出的方式来表述这个情形。两人都是副总裁，而备选的邀请来自一位高级副总裁。埃文斯解释说，他需要给出答复，而一旦他做出承诺，就必须兑现，就像这位领导自己也会这样做一样。这让领导者能够理解这个约束，而不必听到生硬的要求。

埃文斯建议，在可预见的对话之前，先准备好关键的措辞，而不是在压力下即兴发挥。事实和承诺应当保持真实；谨慎的表述，改变的是对方接收它们的方式。表达也很重要。同样一句关于需要考虑自己职业发展的话，根据语气和肢体语言，可能听起来充满敌意，也可能显得平静、可以理解。

他承认，一些工程师不喜欢职场政治。他的论点是，领导者仍然有情绪、压力和防御，所以理解人与人的互动，有助于一个人更有效地传达一个诚实的需要。他并不声称自己已经完全想明白了怎样教这项技能。

Q当一位一线经理走上经理们的经理这个角色时，会出现哪些技能差距？

嘉宾强调要学会如何为向你汇报的经理们增加价值。更资深的角色，改变了哪些干预有帮助、哪些会削弱组织。他用一次隔级会议来说明：一位新晋升的领导者，就某位员工的经理提出引导性的问题。这位员工可能开始转而依赖这位资深领导者，而那位经理则觉得自己被绕过、被削弱了。

重要的失败，不仅仅是开了这次会议。而是忽略了问题和判断是如何在管理链条中传播的。小小的举动，在多重关系中被放大。嘉宾说，这些微妙之处，往往是通过观察和实践学到的，而不只是通过阅读关于管理的内容。

他预期在转型期间会有一些错误，就像新经理在从个人贡献者转型时会犯错一样。因此，晋升决定应当考虑这个人周围的支持：他们自己的领导者能否帮助他们认识并修复问题。战略和组织设计也很重要，但早期的互动失误，可能在那些更长期的职责成为主要问题之前，就造成损害。

Q个人贡献者和管理的成长路径如何比较？它们都是以能力为本的吗？

他说，无论在哪条路径上，高层的评估都变得更加不透明。在校准讨论中，一个人可能与一项有价值的举措联系在一起，却并非它成功的关键。同样的归因问题也适用于经理。较短的评审周期，使得很难把一个有说服力的叙述，与一项清楚展现出来的贡献区分开。

更长时间的观察可以让图景更清晰：一位在几年里反复取得好结果的领导者，比只在某一个半年周期里的人更容易评估。他认为，一些资深个人贡献者和一线管理的工作，对外部观察者更可见，而更高层级的工作，往往需要接触内部的细节和领导链条。

他没有给出“一个阶梯公平、另一个不公平”这样简单的结论。他担心的是，当相关的影响难以追溯时，证据和问责不足。对于能见度有限的员工来说，由此而来的沮丧是真实的，而想要公平的愿望，并不会自动创造出判断它所需要的数据。

Q你为什么选择加入 Airbnb？

Laurent 曾在苹果和 Meta 工作，并认定开发者生产力是自己关心的领域：让工程师在写软件时更高效。搬到旧金山，让他原本的通勤变成每个方向大约九十分钟，这促使他开始寻找。Airbnb 把他喜欢的人、可以步行到达的办公室，以及一个早期的、足以提供大量可塑造工作的开发者基础设施组织结合在一起。

他加入时，是两位测试基础设施工程师之一，正值这项更广泛的工作变成多支团队之际。这个选择结合了日常的生活质量和一个技术机会；并不是纯粹由头衔驱动的跳槽。

Q为什么从测试基础设施的个人贡献者工作，转向管理？

一位经理负责好几支团队和十五人以上，留给开发和支持的时间有限。Laurent 已经作为技术负责人，开始做其中的一部分工作。随着他的团队增长到六到八位工程师，其中许多人处于职业早期，他认为一位专职的经理，可以更好地支持他们，并改进这个大项目的交付。

他向自己的经理提出了这个需求，并主动提出在得到帮助的前提下试一试这个角色。他从两位下属开始，后来管理了整支团队。他的理由，是一个他能帮助解决的组织问题，而不是把管理当作对技术资历的自动奖励。

Q管理改变了你在工作中对无聊的体验吗？

他把无聊当作一个信号，用来审视哪里出了问题，而不是简单地忍受。成为经理，起初提供了强烈的学习：招聘的级别、评审、晋升，然后是建立关系，并规划下属的成长。后来，他用自己对优化的本能，去改善团队的工作条件。

他做了一个日历工具，来减少他自己和下属日程的碎片化。他还详细地调查了团队里的每一个流程，包括会议、规划、代码评审和工作方式，以改善团队的健康。调查显示，每个人都认为那个冗长的站会对别人有用，而实际上没有人真正从中获益多少。改变它和其他流程，提高了参与度，并让团队用更少的时间做更多的工作。

一次为期三周的婚礼旅行之后，他回来发现，团队已经用他们建立的流程，规划好了下个季度和各项任务。这种成功的独立，也让他感到无聊。下一步可能是管理经理们，但他觉得自己还没有准备好，而且怀念编码、交付，以及在生产环境里看到效果。他回到了个人贡献者的工作。这个故事把一支运转良好的团队，视为成功，即使它的经理之后想要不同的挑战。

Q学习管理，在之后让你成为更好的个人贡献者了吗？

是的。理解评审、职业叙事、晋升路径和晋升，帮助他驾驭自己的工作，而辅导和艰难对话的技能，提升了他对他人的领导。回到个人贡献者的工作之后，他继续培养这些能力。好处是一套新技能，而不只是对一个委员会享有的特权知识。

Q提出组织价值，是转入管理的好办法吗？

他把这个教训扩展到与经理的对齐。人们常常犹豫要不要说出自己想要晋升、专长或另一种成长，然后在评审时拿出一年的活动，并希望得到想要的结果。他更喜欢一场持续的对话，让员工和经理都有机会塑造这项工作。

作为经理，他使用了一个“惊讶因子”练习：在交付评审之前，每个人写下预期的评级和晋升结果，然后与他自己书面的评估对比。一致是理想的结果。他接近完全一致，却没有达到。目的是减少不确定性，并说明这一年里的沟通是否有效。

Q个人贡献者应该在什么时候尝试管理？取舍是什么？

Laurent 觉得这段经历是无价的，并鼓励那些正在考虑的人去试一试。这是一份不同的工作，所以亲身经历，既能揭示有用的技能，也能看出这个角色是否合适。即使结果不好，也能让人了解自己的偏好和局限。

他建议从带一位实习生开始，同时警告说，一位实习生是一个高度偏颇的样本。实习生往往需要更多的指导，并激发强烈的个人感情，与一群有经验的个人贡献者不同。他回忆起情绪上很艰难的实习生校准会，因为导师们强烈希望自己的实习生成功，并把转正的录用通知，混同为良好管理的证明。一位经理即使在正确的决定是不发转正通知时，也可能做得很好。他帮助主持了校准会，让这种区分更清晰，也让流程不那么吓人。

Q你自己的晋升和评审，没有惊喜吗？

他首先说，自己常常感到意外，然后澄清说，意外的是评级，而不是晋升。他把这视为证据，说明自己没有足够理解这套体系及其价值观。在一次转型中，他预期自己的技术领导力会支持一次晋升到 Staff，但在周期临近结束时，转到了管理岗位。

评级回来是“符合期望”，因为他在新角色里花的时间太少。他觉得这令人沮丧，并把精力转向争取下一个管理级别。他现在认为，自己本该事先明确地问，角色变动的时机，会怎样影响评审和晋升。

Q一位经理或个人贡献者，怎样成功地挑战一条既定的规则？

他从审视一个流程可能引入的偏见，以及什么让员工评估公平开始。收集证据，理解规则背后的原因，并提出论证。历史也许揭示了一个你没看到的有用约束，或者一个已经不再适用的旧先例。

他通常更喜欢最初的一对一谈话，而不是在校准会上公开对抗。在一群人面前，人们可能把分歧解读为对声誉的威胁，并变得防御。理解这些人的动态，提高了改变流程的机会，而不只是赢得一场争论。

QAirbnb 的工程文化有什么突出之处？

他发现，在一家以设计师为主导的公司里，更难解释底层基础设施为什么重要，但那种不同的专业视角，也产生了有用的想法。在一段出现可靠性问题的时期，公司借助有应急响应背景的人，来改进危机管理。

他钦佩由此形成的严谨性和做法，并把其中一些带到了之后的工作里。他举的积极例子，是愿意问：哪个其他领域已经很好地处理了类似的问题，而不是假定所有的事故管理专业知识，必然都起源于软件工程内部。

Q为什么从 Airbnb 回到 Meta？

四年之后，最初股票授予的归属期限（cliff）影响了收入潜力，这是考虑跳槽的一个原因。他还认为自己想成为一名基础设施通才，在跨越测试、计算、数据库和其他领域工作之后。他后来认定这个自我描述是错的，但当时它把他带到了 Instagram。

一次扰乱性的七月四日值班经历，促使他去追求可靠性的改进。他知道，Facebook 已经有工具，解决 Instagram 仍然深受其害的那些模式。他向自己的隔级经理提议，采用那套基础设施并围绕它合作，并加入了由此产生的跨组织项目。

Q你是怎样选择导师的？是什么让辅导有用？

他寻找的是那些体贴、直接、能够挑战他、并能以他愿意回应的方式改变他想法的人。这些特质不一定只属于工程师；他在自己现在的教练身上也看到了它们。

Facebook 一侧的合作者具备这些品质，并帮助他审视自己对问题的界定哪里错了。衡量辅导是否有用的一个标准，是这个人之后是否真的改变了思考和行动的方式，而不是重复同样的行为。尽管主持人问到他明确提出指导请求的说法，回答主要解释的是选择和价值；它没有提供提出这个请求的详细话术。

Q你对 Stripe 的第一印象是什么？

他遇到了很强的工程师，就像在其他工作中一样，并特别看重在做决定之前，先收集和分析数据的重视。他认为它的指标和实验文化，比他所知道的 Meta 的文化还要强。这个判断是他个人的比较。它适合他自己享受衡量进展和成功的乐趣。

Q你的技术负责人角色，是怎样在一个大得多的开发者基础设施组织里成长起来的？

他加入是为了领导大约三十五位工程师的构建、测试和工具，在他熟悉的领域。他的第一项任务，是在已经了解本地系统的人面前赢得信誉。他刻意避免把自己的前雇主，当作某个设计应该被照搬或被否决的自动证明。

相反，他在各个团队里“嵌入”了大约一个月，做具体的工作，了解他们的节奏，并提出能帮助人们自己重新考虑决定的问题。对于紧急的事故响应，他是个例外，那里可能需要直接的指令。一年时间里，他在这个小组的大部分部门工作过，并多次与这些人见面。

领导一个更大的组织，也意味着接受每位专家对自己领域的了解，都比他多。他可以用宽广的开发者生产力视角来指导，而不假装自己是各处的本地专家。后来，他承担了与不同的人或团队合作的两到八周的任务，来启动工作，并让它可持续。文档和自动化，应当让这项工作无需他一直在场、也不打断他的假期就能继续。做秘密的唯一守护者，是成功的反面。

Q你是怎样让自己覆盖这么多工程师的？

设定现实的期望：没有哪位领导七十个人的领导者，能知道每一个当前项目的细节。保持能提供信息的联系人，并愿意说你还不知道，并会在约定的日期前回来给出答案。他相信，自信的错误信息，比坦率的不确定，对信任的损害大得多；他强调这是对职业的警告，表达的是这种担忧，而不是适用于每一个错误的字面规则。

他用答疑时间，来取代与每个人每周的会面，提供足够的时间，让人们在一周内能约到。由于小组大约一半在欧洲，他把日程调整为大约清晨五点半开始，以便与欧洲和美国的同事都有重叠。规模化仍然需要直接的沟通和可得的帮助，只是通过一种不同的结构。

Q教练们常常在哪方面做错？

他们认同某一种单一的风格：放手不管、高度指令式，或暗示式，并把它用在每个人身上。Laurent 则根据这个人的熟练度、信心、动机和眼前的处境，来选择提供什么帮助。在他早期的 Facebook 入职工作里，四位被指导者中，三位正常进展，一位停滞了；学习一个情境领导力的模型，帮助他调整，并释放了那个人的表现。

他描述了从对初学者的指导，到鼓励和共同决策，到支持，最后随着技能发展到授权。这种评估是针对某项技能和某种情境的。一位技术上有能力的人，在不熟悉的事情上，仍然可能需要明确的帮助。一位疲惫的家长，凌晨四点打电话问 iPhone 的问题，需要的是清晰的步骤，而不是泛泛的称赞，或一场关于系统的讲座。只选择支持这一个阶段，会让许多其他需求得不到满足。

Q为什么从资深到 Staff 的转变，会比下一次转变感觉更难？

他认为在 Staff 级别有一种心态的转变：独立找出问题，选择并提出它，端到端地解决，解释结果，并记录下来。资深工程师可以是强大的设计者和实现者，同时仍在做别人发现的问题。

在他的模型里，更高的级别，是在更大的范围里延续这个完整的循环，而不是再次引入同样的根本性的自主性转变。这是他对这种区别的描述，并不是断言后面的晋升很容易，或者是机械地决定的。

Q一个卡在资深级别的人，怎样开始找到 Staff 级别的问题？

Laurent 把沮丧引向真实的工作流程。在开发者生产力领域，每一条别扭的命令、每一个窗口、延迟或重复的手工任务，都可能暴露一个机会。Stripe 的摩擦日志，把这种观察制度化了：走一遍流程，用图片记录这些步骤，并问每个操作或加载界面为什么存在。

他在一次代码改动期间，就能识别出几十项可能的改进，然后把相关的问题归类，排序，并处理有价值的那些。目标不只是收集烦恼。要寻找那些消除后能改善整体体验的“一类问题”。他还会想象一位疲惫的用户：这个人会在哪里困惑、卡住，或者流失？

他把同样的习惯用到了软件之外。反复的出差，可以是一个机会，每次都改进流程，直到第二十次出差比第一次顺畅得多。Staff 的习惯，是不断从使用中学习，发现摩擦，并有意地改进它。

Q哪本书对你的职业生涯影响最大？

他点出了金·斯科特（Kim Scott）的《绝对坦率》（Radical Candor），它帮助他在建立信任、激励和辅导下属的同时，处理艰难的对话。他欣赏它对经理与员工关系的解释，以及他认为许多有经验的经理仍然忽略的想法。这是他基于自己转型经历的个人推荐，并不是对这本书的外部评论。

Q你会对职业生涯开始时的自己说什么？

这个领域变化得比看上去还要快。Laurent 把他早期遇到的面试做法，比如估算谜题，与他在这场访谈所处的 2025 年的背景下观察到的、技术性强得多且受监控的面试，作了对比。这些例子说明的是变化，而不是确立一项普遍的招聘政策。

他建议保持好奇，并定期阅读技术新闻和讨论。他关注 Hacker News 上每周排名靠前的条目，并在整个职业生涯里一直保持这个习惯。他预期软件工程的技能和经验会继续发生巨大的变化，并鼓励年轻时的自己保持留意，而不要假定这份工作的原有模式会一直持续。

Q你怎样在一个重要项目与团队健康之间取得平衡？

首先确定这种情况是否真的值得一次特殊的冲刺。Fung 记得 Marketplace 的封闭式冲刺，或者说“作战室”（war room），让人们集中在一个紧迫的目标上。这种专注可能是有价值的，但它对士气有真实的代价。领导层应当与团队有意识地讨论这个取舍，而不是让代价一直隐而不宣。

有一个作战室，把一个增长目标作为退出条件。团队起初想象，也许几个修复就能达成，但这项工作持续的时间，远远超出预期。回头看，她会更现实地评估可能的持续时间，讨论对团队健康的影响，并预先说明这段旅程和预期的长度。仅凭一个可衡量的目标，并不能让持续的高强度变得可以承受。

Q当你成为经理们的经理时，会发生什么变化？

这种关系，变成了一种合作伙伴关系，双方都既有管理技能，也有技术技能。当她第一次支持经理们时，包括一位她认为是杰出编译器工程师的 TypeScript 经理，她问每个人擅长什么，以及他们可以怎样划分责任。支持另一位经理，会创造更多让长处互补的机会。

授权也需要在信任与核实之间取得平衡。如果授权让你与项目的接触太少，提供支持的领导者就可能失去联系。她请经理们提供快速的反馈，并对成功和问题都保持透明。有用的对话，是那个能暴露哪里需要帮助的对话；一份说一切都好的、让人安心的汇报，可能掩盖了这段合作本应解决的那个问题。

Q导师怎样让这段关系变得有用？

首先问被指导者，他们想从这段关系中得到什么，以及三个月或六个月之后，成功是什么样子。一个明确的目标，让双方都有办法有效地利用自己的时间。

还要把指导（mentoring）和辅导（coaching）区分开来。在她的描述里，指导是把倾听与来自经验的建议结合起来。辅导则更像一面镜子，帮助对方在自己内心发现答案。弄清这个人想要哪种模式，可以改变对话应当如何进行。

Q个人贡献者应该怎样利用一对一的时间？

把例行的状态汇报，放到一个异步的渠道里。Fung 使用消息，或一份共享的、持续更新的一对一文档，双方都可以在上面添加更新。

把现场的对话，留给那些适合互动的话题：这个人想学的东西，对他们工作的更深入讨论，或者值得一起探讨的产品问题。重点是把稀缺的会议时间留给对话，同时把运营层面的更新，单独提供出来。

Q你为什么离开微软去了 Facebook？

她有朋友在 Facebook 过得很开心，但她一再地想要先完成手头在微软的工作。她在那里的最后一个项目涉及 JavaScript 和 TypeScript，她在乎帮助团队交付 TypeScript 1.0。一位以前 Visual Studio 的同事，后来成了她在 Facebook 的第一位经理，在 2014 年末联系了她，说要围绕在小组里买卖东西，构建一款产品。她在 2015 年加入。

商业这个使命很重要，有三个原因。二手物品，可以给预算较紧的人带来有意义的实惠。重复使用，可以让现有的物品拥有第二次、第三次或第四次生命。一个销售平台，可以帮助一家本地小生意起步，而不必先开一家实体店。Marketplace 对她来说，还代表了一种新的联系：结识新的人，而不只是与已经认识的人重新联系。

在微软工作了十一年半之后，她还想在一个她已经习惯的生态系统之外，检验和拓宽自己的工程能力。这次转变，把她在乎的使命，与一个超越熟悉的工具和做法去学习的机会，结合在了一起。

Q微软和 Facebook 之间的差异，有什么突出之处？

两边都有有才华、在乎自己工作的同事。她的例子里最明显的差别是速度：早期的 Marketplace 每周发布更新，而她记得的 Visual Studio 的工作，大约是四周一个冲刺。即使是那些四周的冲刺，与更早的开发周期相比，也曾经显得很短。

Facebook 当时也显得小得多。她欣赏那种期望：一个问题是每个人的责任，不论角色。她的例子，是愿意主动投入并帮忙，而不是把一个问题当作完全属于别人的。

Q为什么使用你自己的产品如此有价值？

她的第一份工作，涉及用 Visual Studio 来构建 Visual Studio，所以每天使用产品，是工作内置的一部分。这让她对用户有同理心，并对产品的状态有感觉。她把这个习惯带到了 Marketplace，留着一些要卖的物品，这样她就能亲自体验这个流程。见到用户，也让这项工作的影响变得具体，并令人受到激励。

在 VR 和相关的设备团队，她使用 Quest 设备和早期的 Ray-Ban 产品。对于很少有机会写代码的经理来说，使用产品，可以是一种体验团队在构建什么、并直接做出贡献的方式。她描述了在家复现一个棘手的地板高度 bug，并收集日志，当作一小段“创作者时间”。

Peterman 补充说，领导者的汇报，可以引起人们对一个本来已知、却失去了紧迫性的 bug 的关注。Fung 强调另一个效果：团队成员会注意到，领导者使用并在乎他们的产品，这可以建立融洽的关系。

Q你怎样让频繁使用产品变得可持续？

把产品融入你喜欢的事情里。她用 VR 来锻炼、看电影，以及边看边织毛线。令人愉快的日常使用，创造了反复的接触，又不会让这件事感觉像一件苦差事。

在这场访谈的时候，她用 Claude Code 来构建 Claude Code，这让那个反馈循环成为她日常工作的一部分，并让她再次交付生产环境的软件。她还提到，在离开 Meta 之后，她仍然继续提交对 Meta 产品的反馈。

领导者可以增加结构化的产品体验环节。在她最后的 VR 团队，她和她的产品与设计搭档，在周五一起试用几乎就绪的功能，并给出快速的反馈。这用一个定期的机会，补充了日常的使用，去检查即将发布的东西。

Q工程领导者怎样与产品管理良好合作？

从领导小组共同的目标，以及每个人带来的长处开始。因为工作总会多于人手，所以要明确约定谁负责哪些部分，并据此划分工作。

使用产品，也改善了她与产品经理的合作。他们的一对一，可以变成扎实的产品对话，立足于他们真正体验过的东西。这场讨论把合作关系与产品知识联系了起来：当工程领导者贴近客户使用的东西时，他们就有更多可贡献的。

Q善意对一个工程组织有什么贡献？

她把这条原则与疫情联系起来，当时设备团队试图在无法正常使用办公室、实验室和同地办公的专家的情况下，交付 Quest 2 并开发 Ray-Ban 产品。人们在做艰难的工作，同时还要应对家里的压力。

一个个人的例子，让这条原则变得生动。她的祖母住在加拿大的一家护理机构，她无法去探望。工作人员只能安排有限的视频通话，而一个难得的空档，与她答应参加的一次一对一冲突了。她所支持的那个人，爽快地接受了临时取消。对他来说，这也许只是一个小小的通融，对她却有很大的影响。

教训是，同事的私人处境，往往是看不见的。善意是一种务实的方式，用来与你并不了解其全部情况的人共事，而团队正在一起努力完成困难的事情。

Q你为什么选择 Anthropic？

她在 Meta 做 VR 和 Horizon OS 时很开心，并没有在广泛地寻找新工作。她描述的选择，本质上是加入 Anthropic，或者留在一个她已经喜欢的角色里。

使用一个内部的 AI 工具来构建有用的工作工具，让她看到，AI 已经在改变她自己的工作流程。随后与 Anthropic 员工的交谈，让她被他们对使命的重视、对安全的强调，以及共同责任的感觉所吸引。她把这种吸引力，比作曾经吸引她去 Marketplace 的那个使命。这些是她做出这一调动的理由，以及她对这个组织在当时的印象。

QFacebook 的文化，随着增长发生变化了吗？

是的。她把文化视为一种通过行动来表达的、活的东西，而不是墙上的一句话。增长改变了公司，尽管她仍然在 VR 这样的团队里，看到了对使命的坚定承诺。

当新员工问，哪个团队会给他们带来最大的影响时，她也会问他们对什么充满热情。这个问题，恢复了一个在只关注职业影响的比较中可能消失的维度。

Q在 Anthropic 的头两个月，有什么让你印象深刻？

她在入职培训中看到了使命和对社会的责任被表达出来，这让它感觉比一句面试时的口号更实在。

Claude Code 团队的速度也令人印象深刻，即使与她记忆中很快的 Marketplace 时期相比。广泛的内部使用，提供了一个快速的循环：构建一个想法，在内部上线，从员工那里得到反馈，公开发布，并不断学习。随着团队的壮大，她关心的是保持这种敏捷性和速度。

Q什么反馈最大地改变了你的职业生涯？

那是关于她如何接受反馈的反馈。作为工程师，她的本能是立刻去调试这个情形：问问题，回放发生了什么，并确定如何改进。有人指出，给出建设性的反馈本来就让人不舒服，而她的问题，可能让对方觉得自己必须为之辩护。

她把第一次对话改成了倾听和学习。问题可以等到改天，在她反思之后再问。区别在于时机，以及提出问题的那个人的体验：一份真诚想要理解的愿望，如果来得太快，仍然可能让人觉得是在要求他们为反馈辩护。

Q你会对职业生涯开始时的自己说什么？

在体验发生的时候，享受它。工作和生活都过得很快，那些日后让人觉得是“美好旧时光”的时刻，也正是你现在正在经历的时刻。

Q你为什么在 Meta 要求降级？

Igor 以资深 Staff 的级别加入，并觉得自己必须足够快地获取深入的技术背景、人际关系和信任，才能与有经验的同事并肩工作。他描述了一个比头衔所暗示的要长得多的上手期：外部招聘的人，一开始对环境的了解，可能比一位已经在那里待了几周的实习生还少。期望的职责范围越大，需要重建的能力和背景的层次就越多。

大约一年零两个月之后，他自己的评估是，已经达到了更接近 Staff 级别的效能。绩效压力让这个差距显得有风险。他对公司绩效环境的描述，是他当时的经历，并不是对当前政策的说明。

他还发现自己更喜欢 E5–E6 区间的工作：编码、调试、设计和指导。资深 Staff 的角色涉及更多的领导、会议和设计文档，直接编码更少。他问自己能否降一个级别，同时理解现有的股票和薪酬使这件事很尴尬。他被告知，在保持同一职类的同时降低级别，不被他可用的流程所支持。

Q为什么资深的角色在谷歌和 Cruise 行得通？

在谷歌，他以初级工程师的身份加入，并通过一次次晋升成长起来，包括起初失败的尝试。资深 Staff 的晋升，是在他已经待了多年的团队里的一个重要项目之后到来的。专长、熟悉度和可信度是一起累积起来的。

Cruise 也需要艰难的第一年上手期。随着时间推移，他找到了一个结合了编码、指导和更广泛的技术指导的角色。在他描述的那起事故和随后公司的动荡让他离开之前，他在那里很快乐。

Q你对你的入职会有哪些改变？

他花了太多时间，试图通过阅读文档来建立基础知识，然后才做足够多的实际工作。回头看，他会边学边做：接一个任务，亲自上手，在取得进展的同时获取相关的背景。

他没有经常换公司，所以这种入职方式对他是新的。他还觉得，管理团队在让资深的外部招聘者上手方面经验有限，因为许多资深员工是在公司内部成长起来的，已经了解它基本的运作机制。

Q对资深的个人贡献者来说，换公司是不是变得更难了？

他见过谷歌的同事在一次调动没成之后离开，又回来。这样的故事更难听到，因为人们往往更乐于分享成功而不是失败。他也怀疑，反复调动可以培养在新环境里上手的技能；他自己有限的经验，不应被当作每一次资深调动都会失败的证据。

Q有没有人给过你关于级别差距的反馈？

有，尽管他没有分享私下的细节。他举了一个项目的例子：他预期两周能完成的工作，变得复杂得多。即使他成功地完成了，他也不认为它的范围足以支撑 E7。低估复杂性，和选择范围不够宽广的工作，是两个不同的问题，在同一个项目里结合在了一起。

Q回到谷歌，是否也能恢复你以前团队的背景？

不能。人和基础设施都是新的。好处是熟悉公司的运作模式和文化，而不是保留以前角色里所有具体的知识和关系。

Q以 L6 而不是你以前的 L7 回去，顺利吗？

这需要招聘人员做一些工作，因为通常的回聘流程，支持相同的或更高的级别。一个要求较低级别的请求，可能引起这个人为什么想要它、以及是否会接受较低薪酬的疑问。

他明确地向招聘人员保证，自己理解，并会接受大幅度的薪酬降低。他们在他的情况里让这种安排成为可能。他并不声称知道，招聘经理是怎样解读这个请求的。

Q回聘的流程是怎样的？

招聘人员发来了职位空缺，他与几位招聘经理交谈，并追求那个看起来最合适的团队。然后他与工程师和经理的经理交谈。

尽管他已离开大约三年半，他并不需要重复正常的面试流程。曾讨论过，以 L6 回来是否需要编码面试，因为更资深的角色，可能涉及较少的编码，但他得到了一个例外。

他不知道，这是一项普遍的回聘政策，还是为他安排的特殊情况。所描述的流程，是一个人的经历。

Q你为什么愿意公开谈论这些？

他通常对正面和负面的经历都很坦率，但也强调，是让他的坦率成为可能的安全感。他不依赖雇主来获得工作签证，可以通过配偶获得医疗保险，孩子已经长大，也没有房贷，并且负担得起一段不工作的时间。

这些条件，减少了公开发言后失去工作的后果。他不会自动建议处于不同约束的人，披露自己的职场挑战。他愿意分享，伴随着对自身特权的明确承认。

Q在追求晋升与追求较低级别之间，发生了什么变化？

在职业生涯早期，很难想象高出好几级的角色，实际上是什么感觉。亲历这个进程，澄清了他的偏好：他最快乐的工作，涉及一支相对较小的团队，大量的编码和调试、设计和指导。一旦较高头衔的日常工作变得具体，它对他的价值就降低了。

Q那些优秀的资深同事做了什么，是你觉得自己所缺乏的？

他警告不要把其他所有人的长处，合并成一个想象中的竞争者。一位同事可能擅长演讲，另一位擅长沟通，还有一位擅长领导。把自己与整个群体比较，可能造成一个不可能达到的标准。

他认为，只要有足够的时间，自己本可以在 E7 上完全高效。他只是不享受这个过程，也不必继续。朋友和家人质疑，为什么在被迫离开之前就离开，或者拒绝在别处寻求同样的级别。他的回答，把“有能力做某件事”与“想用一生去做它”区分开来。

Q有没有一个你特别记得的指导的故事？

他在大约 L4 时带过一位实习生，后来这位实习生全职加入，并最终成了那个团队的经理。那时 Igor 已转到另一个项目，所以他并没有向以前的实习生汇报。他的教训很直接：不要低估一位实习生的潜力。

Q你会给早年的自己什么建议？

问问这项工作对公司是否重要，谁需要它。他记得做过一些项目，其目的对他并不清楚，而领导层后来关停了它们。选择有用的工作，是比仅仅因为它被分配了就留在一个项目上更具体的指引。

Q为什么有些名字和想法，比类似的工作更广为人知？

当被问到为什么 Paxos 比 Viewstamped Replication 更为人熟知时，Liskov 回忆起 Lamport 的解释：他做了那些演讲，而她在实现这项工作。她承认，他的演讲和论文是能见度的一个来源。当主持人想知道，更朗朗上口的名字是否也有帮助时，她同意这是个吸引人的名字，但没有把命名当作一个经过证明的因果解释。

Q为什么有些人质疑你图灵奖工作的重要性？

Liskov 首先质疑主持人的假设，即只有她面对过负面的评论。她的丈夫碰巧在网上读到了那些评论；她认为，其他获奖者如果去看，也可能遇到类似的待遇。

她更有意思的解读是：有些工作已经变得如此基础，以至于人们无法再想象之前的世界。即使她的研究生们，也没有完全领会，抽象数据类型和模块化编程的思维方式，是必须被发明出来的。一个具体的协议，很容易被认定为一项发明；而一种渗透进日常实践的思维方式，则可能成为不被注意的背景。

因此，尽管那些轻视的评论有其本意，她仍把它们视为对创造了这些基础的更广泛研究社区的一种赞美。影响力变得难以看见，恰恰是因为这些想法被视为理所当然。

Q你怎样找到最重要的问题？

Brooker 建议广泛地看，而不是只优化自己代码的数量。客户会揭示他们觉得困难的工作、正在做的投资，以及他们希望不要分散对自己业务注意力的运维杂务。技术趋势提供了另一种输入：更快的网络、存储、计算、多核系统和 GPU，可以让以前不切实际的设计成为可能。更广阔世界里的变化，也会创造出空间。

Q什么样的事后复盘才算好？

首先要弄清到底发生了什么，而不是把事件套进一种既有的偏见。如果做不到，这个困难本身，就指出了缺失的可观测性、日志、指标或模拟能力。然后在几个层面上考察原因：代码缺陷，测试为什么没发现，为什么测试方法或假设不足，以及哪些团队或组织的决定，塑造了这些条件。

Q为什么一个事后复盘习惯薄弱的团队，应该在这方面投入？

这个选择，是把工程时间花在哪里：改进产品，还是一再地扑灭同一场火。一种薄弱的文化，可能缺乏对结果和客户体验足够清晰的关注。标准不必处处相同；对持久性要求极高的系统，值得有特别高的标准，而另一款产品，可能有意接受更多的缺陷，以优化其他目标。重要的区别，在于是有意的取舍。

另一种失败模式，是把运维上的英雄主义常态化。一支通宵达旦、容忍不断告警、修复每一次紧急情况的团队，从内部看可能令人钦佩，却把自己最强的主人翁责任和专业能力，花在了一个昂贵的、反复的“出错-修复”循环上。纠正的做法，是把这股精力，转向理解并消除原因。防止再次发生，能为更深入的产品改进腾出时间。

Q对一位被这些更高的期望吓到的新工程师，你会说什么？

他不指望应届毕业生立刻什么都懂。雇主和职业早期的工程师，都从人们的成功中受益，所以组织必须建立一条有支持的学习路径。与客户的第一次对话，可能让人害怕；指导、反馈、护栏，以及逐步变大的经历，让它们变得可以学会。

他把这与其他职业作了比较，在那些职业里，许多实践性的学习发生在工作中。变化的是学习的重点，而不是毕业生需要它这个事实。领导者必须重新思考职业阶梯，而不是简单地雇用初学者，然后要求专家级的表现。他承认存在不确定性，同时对机会的规模保持乐观。

Q作为工程师，为什么要写这么多？

写作让专业能力跨越人与时间而传播。一款产品、个别的指导和演讲，都能传播知识，但一篇很久以前写下的解释，十年后仍然能帮到一位读者。他把写作看作一种倍增器，而不仅仅是一种提升能见度的活动。

它也让写作者的思考更敏锐。把一个想法写成文字，会迫使它有一种口头或幻灯片所未必具备的深度和清晰度。Brooker 有时写作，并不打算发表。他欣赏 Leslie Lamport 关于形式化数学的更有力的论点，同时把散文视为一个容易入手的起点。分享想法、保存它们，以及更好地理解它们，是各自独立但相容的动机。

Q对那些把文档看作瞎忙活的工程师，你有什么要说的？

问问这份写作是为了什么，它是否在问题的正确层面上运作。Brooker 并不觉得每一种设计符号都有用；他批评 UML 把重点放在一个对自己的工作没有帮助的语义层面。一份文档之所以有价值，可能是因为它为未来的读者，保存了一项决定，或者帮助人们理清一个困难的、难以撤回的设计或 API 选择。例行的、可以撤回的选择，并不都值得采用同样的流程。

对重要的设计，记录理由也把深思熟虑的决定，与没有数据的临时猜测区分开来。未来的工程师，可以带着新的证据，重新考虑那些随意的选择，同时更用心地去理解那些深思熟虑的决定背后的推理。事前思考了多少，与结果同样重要。出于这个目的而写作，是一项值得培养的技能，即使这项活动本身并不令人自然地享受。

Q你怎样在做事与谈论它之间取得平衡？

他把两个极端都看作失败模式。一位能力很强、却从不沟通的人，如果分享，可能有更大的影响，而且待在 IDE 里，可能错过重要的问题。一个只说不做的人，如果回到实践中，可以让自己的建议更切合实际。

Brooker 个人把大约百分之七十五到八十的精力用于实践，其余用于教学或沟通。优秀的同事们，从大约九比一到五五开不等；他把这些作为观察提出，而不是一个最优的分配公式。专职的沟通者可以有不同的工作，只要他们保持好奇，并对自己知道什么、不知道什么保持诚实。在快速变化期间，他会稍微更偏向实践，同时不切断与外部世界的联系。

Q是被高估更好，还是被低估更好？

从长远看，他会选择被低估。被高估可能感觉很好，但很难持续。体育和手艺，很快就暴露出外表与能力之间的差距；而工程则可能让定性的观感存在更久。他钦佩的那些职业生涯，建立在对自己实际知识和技能的诚实之上，而不是靠维持一个被夸大的形象。这补充了他的建议：传达有用的专长，而不是隐藏它。

Q你钦佩哪些 AWS 工程师？为什么？

他重点提到退休的同事 Al Vermeulen，其工作包括对 S3 和数据库设计的重大贡献。Brooker 记得 2010 年前后，与他争论 Paxos 的细节，同时也看到他讨论高管层面的云战略，并解释业务该构建什么。他钦佩这种在这些层面之间穿梭、而不失深度的能力。

更一般地说，他尊敬那些被有用的工作和客户影响所驱动、而不是被名气所驱动的同事。广度、细节和目标结合在一起，构成了他想追随的榜样。

Q你刚加入 AWS 时，会给自己什么建议？

当学习和影响开始减弱时，在调动上要更大胆一点。他热爱自己在 EC2 和 EBS 早期的团队，离开时比他现在认为理想的更犹豫。他做了大约四次重大的组织变动，并怀疑再多几次可能更好，但并不是建议不断地换。

他会反复问自己，在学什么，向谁学，以及另一个环境是否会帮助自己学得更快。在他自己的职业生涯里，追随好奇心既有用又令人愉快。

Q你怎样在有挑衅性的标题与诚实之间取得平衡？

他反对误导性的标题党。目的是有效地传达最有趣的真相部分。撒谎可能吸引注意，但会摧毁与用户建立有益关系的基础。

Q截断了坐标轴的图表呢？

他拒绝带有欺骗性的图表呈现，然后强调真正的基准测试的难点：缓存、项目选择和不相关的原生构建，都可能改变观察到的结果。没有哪张图能涵盖所有情形。这并不免除给用户一个关于性能的诚实印象的义务；他承认，自己的团队有时也可能把握不好这个平衡。

Q愿意走开，是否给了你谈判的筹码？

他同意，自己处于一个强势的位置，同时拒绝把自己描绘成一位谈判专家。他强调的是一致的、支持他的投资人，以及除了让他更激进地增长的建议之外几乎没有压力。那段积极的经历是幸运的；他认识到，其他创始人可能有不同的关系。

Q作为第一次创业的工程师，有什么让你意外的事？

他不信任普适的创业建议，因为成功的创始人可以给出相互矛盾的指示，而幸存者偏差隐藏了其他选择。选择适合团队和你想要的生活的原则。远程办公让他得以雇到一支在一个地点无法组建的团队，尽管线下见面有真实的好处。融资优化的是值得信赖的合作伙伴、合理的条款，以及尽快回去工作。他没有仅仅因为被推荐，就强行建立联合创始人的关系，尽管后来他感到缺少一位分担重担的同伴。

Q毕业后，你会给自己什么建议？

相信出于可靠的个人理由做出的决定，同时意识到，事后看来，一条幸运的路径可能显得是必然的。他曾担心，选择 Khan Academy 让他失去了大公司的经验和薪酬；他现在看重自己真正想要的那段经历。他不会假装知道另一条路会怎样。

Q在 Anthropic，现在有多少“粘合性”的写作，比如发布文章、更新和设计文档，是由大语言模型写的？

Thariq 的经验法则是：如果你乐意把提示词给别人看，你就可以把输出发给他们。提示词往往只是在汇集背景。在每次一对一之前，Thariq 让 Claude 读取 Slack 消息、GitHub 消息和 PR，并汇编一份 Thariq 做了什么的报告。经理缺乏那些背景，而 Thariq 乐意让他们知道提示词。

对于数据解读，Thariq 建议表明你读过结果，比如做一些小的修改，或对数字进行合理性检查。对于一个提案或新概念，人们想知道你相信它。即使 Claude 的想法很出色，Thariq 也会说，这是 Claude 生成的，而 Thariq 认为它很棒。人们不喜欢的，是觉得被误导。

有些写作取决于每一个字。Anthropic 内部那些主张某个方向的文章，通常由人来写，Thariq 说，让 Claude 来写你的文章，是被人瞧不起的，因为每一个字都应该是有意的。

Q软件工程师应该在 Twitter 或 X 上发帖来建立能见度吗？

Thariq 说，尽可能多地对外分享你的工作，尽管有些雇主不允许；副业项目是一个选择。在加入 Anthropic 之前，Thariq 与不同的公司合作，构建东西，并就它们写作和讲述。Thariq 说，这增加了自己的“运气表面积”，而且门槛比人们以为的低得多。

Thariq 说，自己把这个建议给了很多人，几乎没有人照做，而照做的人，都在一份自己很兴奋的工作里，或者在经营自己的公司。配方是：无视你的简历，选一个有趣的项目，努力工作、全力投入，然后把它发布出来并写下来。会有不这样做的理由，但如果第一次尝试失败了，就再来一次。

Twitter 可能不是合适的地方；Reddit 或 Hacker News 可能更合适。目标是找到喜欢你所做之事的人。人们想要高质量的内容，那需要大量工作，而 Thariq 说，没有捷径，比如让 Claude 来运营你的 Twitter 账号。要真实地参与。Thariq 把它比作每天去健身房：简单、需要自律，也很容易放弃，Thariq 说自己没见过坚持尝试的人失败。

Q工程师应该围绕晋升来规划职业，还是围绕培养有用的行为和影响力？

嘉宾强烈地偏向影响力而非头衔。在评估晋升时，他想看到的是重要的成果，而不是试图谈判出一张清单，一旦完成就机械地触发晋升。一个人可以在技术上满足某项明说的活动，却以几乎不增加价值的方式去执行它；这样，晋升背后的根本原因就没有得到满足。

他也承认自己的一种个人反应：一再试图让领导者就奖励给出明确的承诺，会让他觉得交易化、令人厌烦。这是他作为领导者的视角，并不保证所有经理的反应都一样。他实质性的论点是，真正的影响力，仍然应该是被认可的东西。

Q比较安静的工程师，应该怎样在影响力与让工作被看见之间取得平衡？

主持人对纯粹的“影响力优先”的说法提出挑战：优秀的工程师可能不善于传达自己的成果，当晋升决定取决于人们是否注意到时，他们可能吃亏。他把有用的能见度与愤世嫉俗的自我推销区分开来。

嘉宾同意能见度很重要。工程师需要与了解重要挑战的人接触，与合作者协调，并让自己的能力得到认可，这样别人才会把更大的工作托付给他们。他的区别在于沟通的目的和框架：让工作易于理解并协调它，与试图吹嘘自己，可能导致不同的行为。

更新也应当认可合作者，并感谢团队。这让贡献变得清晰可辨，又不暗示只有发送者才重要，帮助别人感到被重视，并支撑起领导所需要的信任。主持人观察到，两种动机可能产生表面上相似的更新；嘉宾强调的是，这条信息在多大程度上以个人为中心，而不是以工作和其他人为中心。

Q一位高调的高绩效者，是否往往比一位同样优秀的安静同事更早被晋升？

主持人认为，持续的游说，即使在两个人都有真实影响力的情况下，也能赢得额外的关注。嘉宾说，结果取决于组织文化，而他自己的文化试图不去奖励这种行为。他承认，也有一些边缘情况，游说仅仅因为让人一直被记在心里，而赢得了考虑。

他并不建议放弃雄心。他希望雄心被表达为对更大影响力的渴望：问问自己是否在做最重要的问题，能学到什么，以及可以在哪里做出更多贡献。否则，一位勤奋的工程师，可能把非凡的努力花在一个低优先级的任务上，仍然错过自己想要的结果。

让这些抱负为人所知，并要求机会，是有价值的对话。他反对的，是把关系简化成合同式的勾选框，然后要求晋升。因此，这场辩论仍保留着一种真实的张力：主持人担心认可不平等，而嘉宾更喜欢以影响力为中心的能见度和经理的判断，而不是晋升的讨价还价。两者都没有确立认可总会完美地匹配贡献。

通过与用户的关系建立动力

在社交层面，Facebook 是一款人人都听说过、也都有看法的产品。Novati 可以得到大量关于人们喜欢和不喜欢什么的反馈，并发现构建一个人们在乎的东西很有激励作用。Novati 补充说，公司也经历了起起落落，即使在 Novati 任职期间。

Q现在文化变了，Novati 怎么看“快速行动，打破常规”（move fast and break things）？

Novati 描述自己当时就是那个“快速行动、打破常规的人”，并且仍然喜欢这个说法。在 Novati 的理解里，“打破东西”那一半，部分是外界的观感，Facebook 并不想告诉公众，人们在鲁莽地打破一切。最初的精神是打破常规：第一性原理的思考，从头尝试，不为了追随潮流而追随潮流。它并不是为了制造破坏。

Novati 仍然认为它在今天会是一句不错的格言。不过，在一家更大、更成熟的公司，即使最小的 bug，也可能花费数百万或数千万美元，所以 Novati 能理解公司为什么放弃了它。

Q考虑到 Novati 刚开始时大约有 200 名工程师，文化是否随着年月发生了变化？

Novati 描述了一种极度由工程师驱动的文化。设计师和产品经理必须赢得工程师的支持，因为工程师不愿做的工作就做不出来。几乎所有的内部工具，都是在内部编写、并由员工使用的，这确立了 Novati 所热爱的、工程优先的基调。

Novati 把 2012 年的 IPO 视为转折点。之后股价下跌，因为人们问 Facebook 要怎样赚钱，这个问题在最初的三年里几乎没有出现过。随着公司的成长，Novati 形成了更成熟的看法：广告优化、成本节约和高效的基础设施变得更重要。早期，资深工程师们当面辩论设计，在很大程度上独立于管理层。到后来，两支团队的副总裁更多地进行协商，结果再层层往下渗透。

Q那份让 Novati 出名的内部新闻简报是什么？为什么要开始写？

它叫作“每周的 Novati”（the weekly Novati），是在 Notes 产品（Facebook 的博客功能）上每周发的一篇帖子。Novati 2009 年加入时，Notes 没有负责人，所以 Novati 在黑客松上改进了它，把富文本加到原本只有纯文本的功能里。这次改动是一个 11,000 行的 diff，大到 Novati 不得不组织一场当面的会议来评审它。Novati 还经常使用这款产品，这是 Facebook 内部“吃自己狗粮”的习惯之一。

几篇略有争议的、关于产品构建的帖子引起了关注，所以 Novati 更有规律地发帖，常常是随口而写。Facebook 坚持留在门洛帕克的园区，而旧金山的创业公司，比如 Stripe 和 Uber，正在把员工吸引走。Novati 反复写这件事，包括一篇提议在南旧金山设立办公室的帖子，那个办公室后来真的开了。

Q哪些工程师给 Novati 留下了最深的印象？为什么？

是产品基础设施团队，他们构建了 PHP 的各种抽象，后来演变成今天的 React 框架。Novati 看着这个框架一砖一瓦地搭起来，把那些工程师看作另一种类型，一种不属于 Novati 的专长。与 Novati 最相像的人，是 Evan Priestley，Novati 说他是 Novati 之前提交最多的人。Priestley 几乎凭一己之力写出了内部的代码评审套件，后来它被分叉并开源了（字幕里它的名字写得不清楚）。

QReact 框架的工程师与 Novati 的原型不同，是什么给 Novati 留下了深刻印象？

Novati 把他们归入专家型原型：非常擅长某一个技术栈的人。另一个例子，是一位工程师，他是世界上也许十个深入理解电子邮件协议的人之一，包括垃圾邮件和路由的实际方面。Novati 喜欢用运动队来类比：在一支棒球队里，每位球员都能合理地胜任大多数位置，但你还是需要明确的角色，以及对每位球员位置的相互尊重。Novati 尊重那些工程师，并认为一支拥有不同类型球员的团队，是出色的。

QNovati 说过，大约 30% 的时间给了团队，70% 给了自主选择的项目。这是怎么运作的？

Novati 把它描述为：作为一支大约十人的团队里的资深工程师，同时把一半以上的时间，花在覆盖整个代码库的举措上：清理、重构、一个新框架、一次性的帮忙和紧急情况。那 30% 是心智专注力的份额，而不是八小时工作日里的一块。Novati 整天都在团队里，评审代码，与初级工程师交流想法，指导他们走向晋升，并编写团队排好队的功能。Novati 还参加产品会议，评估产品经理提议内容的可行性。团队工作产生的代码量，相当于一位资深工程师的水平。

QNovati 是怎样过渡到 IC7、为整个组织解决最难的问题的？

Novati 说，产出在第一天就已经是编码机器的水平。提高的是品位和判断力。举个例子，同一个数据源上，有两个任务工具的分叉，一个快而精简，一个功能臃肿而缓慢。在一周或更短的时间里，Novati 把它们合并成了一个，兼具第一个的速度和第二个的功能。Novati 没有告诉任何人，只是向全公司发帖说工具已经合并了，并说现在做不到这样了。

每个人都向 Novati 道贺，但教训是，用改变了的网址，让数百位用户措手不及，并不是最好的做法。Novati 当时没有理解对各个团队的后果。在许多次大的改动中，有些太快，有些有 bug，Novati 保持了同样的速度，同时提升了判断力：一次该改多少，别人会有什么感受，哪些地方是敏感的。Novati 说，这种判断力和品位的积累，才是跨过 IC7 门槛的东西。关于如何培养它的建议，取决于情境：先和经理谈，再和隔级经理谈，然后找一位在类似组织里的非常资深的工程师谈。

Q对软件工程师来说，品位和判断力是什么意思？

Novati 把品位比作铸铁锅上的包浆，是一层层历史堆积起来的。有些人早早就有更强的直觉，也许来自成长环境，或者来自代码之外的经历，比如舞蹈或体育。一般来说，需要经验。Novati 的第二个意象是速滑运动员：你不能读一本书、穿上冰刀，就成为最快的。这需要多年去感受不同温度下的冰面，以及滑过一次和滑过两次的冰刀的差别。

Novati 看到太多处于职业早期的人，试图跳级，就像在建立起那种手感之前就参加奥运会。Novati 说，这没关系，他们也没有什么问题。建议是投入练习和重复，得到反馈，迭代，并有毅力坚持下去；没有反馈，练习并不能提高技能。

QNovati 在动每个人的代码。其他团队有没有给反馈？是怎么处理的？

有。在一个案例里，Novati 在一个团队工具的线上版本里，重构了一个旧框架，而那个团队当时正在构建一个更新的工具，并小心地维护着向后兼容。他们有许多 diff 正在进行中，这次重构造成了合并冲突。他们想让它被回退。Novati 当时没有关注这一点，教训是，要小心那些团队正处于复杂、长期工作的迁移途中的地方。

Q随着工程师更加资深，他们会被拉进更多的会议。Novati 是怎样保护专注时间的？

Novati 把会议降到最少。当日历邀请没有背景就来了，Novati 会问是做什么用的，并回绝了很多。Novati 会跳过站会，除非相关，比如在冲刺、要在一个月内交付的时候，而且不参加纯社交闲聊的会。Novati 对时间很严格，并有意地选择团队，看重那些明白自己的工作是帮助下属表现出色的经理。Novati 的经理们保护 Novati 免于不必要的会议，这样影响才能最大。

Novati 承认有时太傲慢。Novati 回忆起一两次，在觉得会议不再有用之后，直接走出了会议室，现在后悔了，对主持会议的人感到抱歉。

QNovati 是怎样培养出选择重要问题的技能，让代码更有影响力的？

Novati 首先说，自己并不擅长这个，在排优先级上仍然很差。Novati 倾向于选择那些已经能看到答案的事情，所以唯一的问题，只是代码能打多快。这也是为什么大语言模型对 Novati 帮助这么大：想法在 Novati 的脑子里，工具能把它更快地弄出来。

Novati 称这可能是拖累职业生涯的事情之一。当经理要求做任务 A，而 Novati 看不到答案时，Novati 就去做了 B 到 H。这能得到一个及格的分数，并受到赞赏，但如果 A 真的很重要，那么如果 Novati 做了它，公司整体的影响很可能更高。Novati 把它表述为一个弱点，受限于 Novati 能想明白怎么做的东西。

QIC7 以上的工程师有什么共同点？

Novati 说，无论原型是什么，编码机器、专家，还是救火者，都有一个共同的标准。每个人都表现出极强的勤勉和尽责，而且头脑敏锐。Novati 举了全 A 的在校成绩，以及觉得自己相当聪明的感觉，但也承认，这个群体里很多人可能更聪明。在一个房间里，一个新提出的协议，不会得到一小时的演讲；人们会立刻提出尖锐的追问。对细节的关注非常高。

对 Novati 来说，这些是性格特质，比如把强迫症式的倾向，富有成效地用在产品的每一个细节上。另一些人，则通过 25 年的经验达到了这些。Novati 说，在与初级同事的交谈中，背景往往缺失，追问不那么敏锐、也耗时更长，项目的范围通常也更小。

Q在最高的表现水平上，有多少是天赋，有多少是努力和成长？

Novati 说，天赋存在，由生理、成长环境和机遇塑造，其中一部分尚未被发现。一个觉得自己没有天赋的人，也许只是还没找到它，或者在不是自己本职工作的事情上有天赋。Novati 说，这就是目前正在做的、帮助人们找到自己能做的最有影响力的工作这项工作背后的使命，因为不是每个人都有机会去探索。Novati 相信，每个人都在某件事上比大多数人强，而找到它，是高绩效的重要一环。

相比之下，努力是在你控制之内的。Novati 的一位朋友指出，天赋和运气不在你的控制之内，而努力在。Novati 说，如果你擅长自己的工作，并且喜欢它，你可以比相近的人付出更多，并很可能因此得到认可。

QNovati 的职业成长，有百分之多少是运气？

Novati 说，一半一半。来自加拿大的 Novati，在 Facebook 的第一天是个惊喜：Novati 拿了一台笔记本电脑，离开了入职培训，却被叫了回去，因为没有领手机。Facebook 递上了手机和配件，仿佛铺开红地毯，Novati 想，这一切到底是怎么回事。Novati 说，留在加拿大，大概也会发展得不错，但不会有同样的加速。

运气在于，在 Novati 加入的那个时间点，落在了 Facebook：与 Novati 当时的性格完美契合，价值观一致，而且代码与 Novati 能应付的东西相匹配。Novati 见过一些没有同样驱动力的人得到了运气，现在也做得很好，并说两个因素中的任何一个，都可能成功。Novati 说，在这里，两者都起了作用。

QNovati 会给刚毕业的自己什么建议？

Novati 看到许多人，包括那些准备面试的人，在寻求认可：一个绿色的对勾，一个满分。Novati 过去就是那样的人，想要一个 A+，却并不真正知道自己在学什么。正因为这样，Novati 把反馈当作一个用来评判的分数，而不是用来改进的输入，并给自己施压，下次要达到 100%，而不是朝着改进努力。

给那些想要满分的有野心的人的建议是：反思反馈，并突破舒适区，而不是把反馈当作评判。

Q那时你在职业生涯的什么位置？随着你做这些项目，它是怎样成长的？

Holly 说，早期的 Mozilla 有一种自选头衔的文化，Holly 为那个复杂的代码库选了“负熵”（negative entropy）。到 Firefox Quantum 时，Mozilla 有了一套更标准的职级阶梯。Holly 在 Quantum CSS 期间达到了资深 Staff，上线之后，Holly 和领导 Quantum 另一半的工程师，都被晋升为首席工程师（principal engineer），按 Holly 的估计，当时拥有这个级别的人可能不到五位。

Holly 的长期梦想，是成为像 Boris Sabarski 那样的人，他是 Mozilla 的三位杰出工程师之一，而路径，是在代码的尽可能多的部分里多产：WebRender、移动、多进程、布局。Holly 的经理，也就是负责工程的人，要求 Holly 每周留出一天不打开终端，并更广泛地思考影响力，而不只是直接的代码。Holly 当时很震惊，并说这不是一种自然的工作方式。

Q在业内，我听到两种关于成长的方式：先聚焦晋升，或者先培养技能和行为，让晋升随之而来。哪种更好？

Holly 有强烈的看法，并说要关注影响力，而不是头衔。这是 Holly 在决定提拔谁时看重的东西。有那种程度影响力的人，不需要像“晋升黑客”（promo hacking）所暗示的那样推销自己，那意味着让管理链条把获得晋升必须做到的事情逐一钉死。

坦率地说，Holly 觉得这很烦人，把它比作孩子要求为做了被要求的事换取奖励。Holly 也看到了一个实质性的问题。一个关注影响力的人会取得成就，而一个关注别人给出的那些勾选框的人，可能在技术上以打勾的方式满足了一个明说的条件，却错过了重点。影响力才是应当被认可和奖励的东西。

Q你专注于影响力，并有杰出工程师作为榜样。接下来的成长是什么样子？

Holly 继续做浏览器里最难的挑战，并在团队之间流动，假定达到 Boris Sabarski 那样的影响力，最终就意味着成为杰出工程师。然后当时的 CTO 把 Holly 叫来坐下。现有的杰出工程师，大约从 2010 年起就拥有这个头衔，此后没有再产生新的。CTO 说，Mozilla 将近十年来第一次要产生新的杰出工程师，而 Holly 不在其中。

Holly 有点意外，因为 Holly 认为，任何人都会说，虽然也许不到 Boris 的水平，但 Holly 比几乎任何人都更了解 Firefox 的代码。CTO 解释说，这是 Mozilla 传统的模式，而他现在想要一种围绕行业影响力的东西。

Q杰出工程师级别的影响力是什么样子？你能描述几位做出了令人印象深刻的工作的人吗？

Holly 描述了当时被晋升的三位工程师，作为 Mozilla 个人贡献者改变世界的影响力的原型。

第一位是 Martin Thompson，仍在 Mozilla，Holly 称他是国际标准方面的杰出人物。他的名字出现在 HTTP/2、QUIC 和 web push 等协议的作者栏里，Holly 说他深度参与了 WebRTC 和地理定位，并补充说 Holly 并不熟悉每一项署名。这是核心的设计工作，而不是编辑排版。通过设计更快的新协议，给业界一个采用它们的商业理由，同时泄露更少的元数据，安全问题也更少，他提升了互联网的隐私和安全。

第二位是 Luke Wagner，Holly 认为他是最以一己之力对 WebAssembly 负责的人。在浏览器里运行非 JavaScript 的代码，比如 AutoCAD，过去依赖插件，Holly 称这对安全和用户体验都很糟糕。另一位工程师的一个副业项目，把 C++ 编译成朴素的 JavaScript，能行，但非常慢。当时是 SpiderMonkey JavaScript 引擎首席工程师的 Wagner，想让它变得可行，于是这个想法变成：让工具输出 JavaScript 的一个受限子集，引擎可以检测、验证并更原生地运行它。这启动了一个飞轮，让编译出来的原生体验进入浏览器，随后又推动了一种真正的字节码格式 WebAssembly，它具有原生速度、沙箱化且可移植。谷歌当时在推动一种类似插件的替代方案 Native Client，所以 Wagner 处理了技术和政治两方面的事务，来促成浏览器之间的共识。

第三位是编解码器负责人 Tim Terbury。原生视频播放受阻，因为占主导地位的格式 H.264 受到大量专利的束缚，开源浏览器无法发布。Mozilla 花了数年开发免版税的编解码器。Terbury 的团队构建了 Opus 音频编解码器，然后是一种叫 Daala 的视频编解码器，它被纳入了 AV1，现在是开放媒体联盟（Alliance for Open Media）的行业标准。Holly 说，这驱动着今天的视频，而真正不受束缚的编解码器这一愿景，来自 Terbury。

Q你会给想成为杰出工程师的人什么建议？

Holly 的回答是写作，任何级别的任何人都可以练习。Holly 说，Mozilla，包括 Holly 个人，在这方面没有太多成熟的能力，而写作是最强大的技能之一。Holly 指出一份内部备忘录（现已公开），叫作“把事情写下来”（writing things down），它论证写作的重要性，既在于产物（它有助于协调、广泛的评审和反馈），也在于过程，因为写作就是在思考、提炼和阐述想法。Holly 称思维的清晰是最重要的事情之一，并说你只有逼自己把想法写下来，才能获得它。

作为及时的建议，Holly 说不要用大语言模型来生成你署名的文字。这相当容易看出来，而更重要的是，你失去了写作所迫使你进行的思考。

Q如果你能在刚进入这个行业时，给自己一些建议，会是什么？

Holly 的回答是要谦逊。Holly 说，年轻时的态度并不严格是关于自我，而是关于工程，认为工程师是宇宙的中心。随着时间推移，Holly 意识到，还有许多别的东西很重要，而且当你刚进入一个组织时，你并不理解为什么存在某些流程和职能，比如法务团队。走上领导岗位之后，Holly 对组织和行业里不同的角色培养了欣赏和同理心，认识到每个人都有一个观点和一个出发点，并且努力去理解人们从何而来，才是取得进展的方式。

Q从初级到 Staff，各个工程级别意味着什么？

Ricky 解释说，初级工程师在不少帮助下编写并交付代码。中级工程师工作更独立，但有时仍需要帮助。资深级别往往是一个终点，很少有人被期望走得更远。Staff 工程师为团队设定方向，并领导其他级别的工程师。Ricky 估计，从初级到中级大约需要两到四年，从中级到资深也差不多。

Ricky 说，有些公司采用“不升即走”的政策，没有达到下一级别的人要离开，而谷歌在这方面没那么激进。Ricky 估计（没有确切数据），90% 或更多的人能达到这些级别。几位讲述者说，levels 网站相当准确，只是股权薪酬会随股价变动。

Q实习生怎样才能成功？他们是怎样被评判的？

几位讲述者说，实习生是按三件事被评判的。第一是生产力：完成了被分配项目的多少，理想情况是在实习的一半时间里。第二是质量，体现为到最后代码评审的轮次更少。第三是沟通，包括在完成第一个项目之后，提出改进或一个新的项目。一位出色的实习生三样都做到。

Q你是怎样在二十多岁时，这么快就晋升到 Staff 工程师的？

Ricky 说，每个级别期望的是不同类型的工作。在当前级别上的许多项目，并不能赢得下一次晋升。一个处于下一级别、清楚地表明你已准备好的项目，价值更大。经理们常常把这些期望描述为行为。Ricky 和 Ryan 把精力放在能让他们升级的项目上，而不是放在不会让他们升级的瞎忙上。

Ricky 还说，每次晋升之后，Ricky 都会问经理下一个级别需要什么，然后去承担那类工作。经理解释了该培养哪些技能，Ricky 把快速的晋升归功于此。

Q职业上的成功，主要是运气吗？

Ryan 说，运气是很大一部分，但人们可以通过主动性来提高自己的运气。在亚马逊大约八个月之后，Ryan 觉得被卡住了，看不到通往下一个级别的路径。Ryan 申请了许多公司，除了一家，面试过的每家公司都给了录用通知。这促成了去 Meta。

Q几位讲述者会给出一条什么建议？

Ricky 说，主要的建议是多问问题，在工作中和实习期间都是如此。Ricky 曾告诉一位被指导者要不断地问，实习结束时，对方说 Ricky 其实并不是真心的。Ricky 说，快速成功的人与没有成功的人，最大的区别，是他们多快开始提问、学习，并自己扫清阻碍。害怕显得愚蠢，拖住了许多人。

Q最优秀的工程师，是班上最聪明的学生吗？

几位讲述者说不是。优秀的工程师需要扎实的技术技能，也需要软技能，比如说服和影响他人。工作是一个大型的团队项目，分歧很常见。告诉同事他们的想法很糟，并不能赢得他们。点出对方的沮丧，承认他们的观点，并提出一个折中的办法，更有可能让工作得以交付。几位讲述者说，这些技能的重要性，与编码大致相当。

Q这份工作实际上有多少是代码？

一位讲述者说，代码在工作中所占的部分，比应届毕业生预期的要小。写作占很大一部分。设计文档先于代码，一次改动需要一份书面说明，一个完成的项目需要一份结果总结。这位讲述者说，这种写作，是一个人影响他人的方式，所以人际技能往往决定了一位工程师能走多远。

Q有经验的工程师还会有冒名顶替综合征吗？

Ricky 说，冒名顶替综合征非常普遍，大多数人都会有。Ricky 在加入谷歌时，通过了面试和实习之后，就有这种感觉，并发现其他工程师非常强。即使在晋升之后，Ricky 仍然怀疑公司是不是犯了个错误。Ricky 的应对方式，是尽可能多地学习，并尽可能做好工作，理由是即使被解雇，也会有所学到。Ricky 说，这种感觉仍然一阵阵地回来。

Q你在工作中怎样为自己倡导？

Ryan 说，好的工作是必需的，但还不够，因为是人在决定晋升，他们必须知道这些工作。最后百分之几的努力，就是告诉人们。这可以意味着就一个结果写点东西，在会上展示它，或者告诉经理，某个里程碑提前完成了，下一个任务也准备好了。Ryan 说，一篇关于出色成果的清晰帖子，会让转正录用变得难以拒绝。Ryan 说，这一步常常被跳过，尤其是内向的人。

Q经理们怎样衡量影响力？

几位讲述者把影响力定义为工作所产生的具体的、可衡量的结果，比如收入、成本、速度或用户增长。衡量标准取决于团队。在广告团队，可能是金钱。在基础设施方面，可能是数据库的成本或延迟。在增长团队，可能是日活跃用户，或关键步骤的注册数。工程师应当向自己的团队和经理了解衡量标准，因为这就是他们的工作得到奖励的方式。

几位讲述者还说，一个改进了关键数字的小改动，可能比一万行修正拼写错误的代码更重要。他们的例子，是一行代码的改动，在某件重要的事情上带来 20% 的提升。

Q做工程管理需要 MBA 吗？

Ryan 说不需要，而 Ryan 就是一位没有 MBA 的经理。Ryan 描述了一张来自一家收集 LinkedIn 数据的公司的图表，涵盖几千位总监及以上的人。有 MBA 和没有 MBA 的薪酬看起来相当，没有的略低一点。Ryan 说，这是与一家公司一起做的研究，而不是一项发表的研究。

Q你们现在的目标是什么？你们当时有没有推动晋升？

Ricky 说，Ricky 最初并不是很有职业驱动力。Ricky 和 Ryan 是室友，现在仍然是。Ryan 会问，他们能不能以比通常的时间线更快的速度争取晋升。Ricky 看过每个级别需要多长时间的数据，而 Ryan 的推动，让 Ricky 去测试是否有一条更快的路径。

Ricky 说，Ricky 付出了努力，比平均速度更快地得到了晋升，并且没有为此放弃其他兴趣。

Q人们是否应该为了薪水或晋升，每两三年换一次工作？

Ricky 说，答案取决于具体情况。Ricky 在谷歌一直待在同一个团队，跟着同一位经理，同时仍在看其他团队。Ricky 指出存在幸存者偏差，因为离开的人，也许过得更糟。Ricky 建议每六个月问问自己，是否仍然想待在那里，机会是否仍然合适，团队和经理是否支持你。

Ryan 说，关于“为了晋升而跳槽”的常见建议，其实更微妙。职业早期，跳槽可能是最快的路径，因为势头不如达到下一个级别重要。在资深级别，它可能适得其反。Ryan 说，公司通常不会把外部候选人直接招进 E7 或 L7，那里的晋升取决于信誉和过往记录，而频繁的调动并不会建立这些。Ryan 的建议是，早期积极地跳槽，后期则更慎重。

Q招聘委员会里实际上发生了什么？从第一次接触到最终决定之间，有哪些人会接触候选人？

Austin 说，当一份资深级别的材料送到委员会时，Austin 读的第一样东西，就是行为面试。Austin 想看到这位工程师曾在什么样的职责范围里工作，他们的影响力、洞察力和沟通的水平，以及他们所在组织的规模。委员会由工程师和有影响力的工程经理组成，由像 Austin 这样的主席召集，与招聘部门一起做两个决定：录用与否，以及级别。Austin 描述了一个全公司范围的委员会，主要是对照跨公司的标准做一次直觉检验，并说在 Meta，由工程总监组成的最终委员会，做出招聘和定级的决定。

这条路径始于“寻源员”（sourcer），一份入门级的招聘工作，任务是寻找候选人或处理内推。寻源员查看职位描述、工作年限和过去的公司。随后的电话筛选，往往是一场编码面试，有时是一份用作预筛选的多项选择技术测验。一场明显出色的电话筛选，直接进入现场面试的安排。一场处于边缘的，则第一次来到招聘委员会，由其决定是增加一轮追加面试、让这个人往前走，还是暂时放弃。

对于专门的候选人，比如需要一场合适的系统设计面试的底层 C++ 移动工程师，以及在资深与 Staff 之间的选择，也会征询委员会的意见。这个选择会改变整套面试环节。Austin 说，在 Meta，Staff 候选人要经过两场系统设计面试，所以没有人可以不经过它们就被聘为 Staff，而首席和杰出级别的面试，还会增加更多的行为面试。现场面试之后，委员会决定录用、级别和追加面试。行为面试产生了大多数追加面试，因为 Austin 认为它们是最难做、也最难解读的面试之一。委员会成员有时会陪着招聘人员去找总监们，为给一位材料在某一方面薄弱、但在公司需要的某项特质上很强的人一个机会而争取。

Q主持人说，工程师常常以为行为面试那一轮可以临场发挥。候选人该怎么做，才能被定到 Staff 级别？

Austin 说，在任何行为故事里，以及与招聘人员的第一次交谈中，最重要的任务是确立职责范围：用技术解决的是多大的业务问题，处理了多少模糊性，以及候选人所处的是什么样的组织。招聘人员的电话，实际上就是一场行为面试，所以开头的“介绍一下你自己”，应当是简历的精华，带着指标，还有深度和复杂性。

Austin 对比了“我提升了 Facebook 应用的性能”，与这样一段叙述：在一个为期十二个月的性能项目里，组织了大约 100 位工程师，遇到了棘手的技术问题，需要好几位 Staff 工程师，最终归结为三条核心原则。候选人应当传达技术深度、组织深度和业务影响，因为面试环节里的每一位面试官，听的都是同样的东西。对这个开场做简洁的练习，是落入正确定级档位的第一步。

回应主持人关于 Staff 晋升也需要跨组织工作的说法，Austin 表示同意，并说为行为面试做准备，会让一个人成为更好的工程师。Austin 的大多数辅导客户，是把自己说得太少，而不是夸大。他们需要展示问题有多难，以及它对团队、代码质量和组织随时间产生了什么影响。把整个故事讲清楚需要准备，但这与每周一对一和高管汇报中用到的是同一项技能。

Q候选人在与招聘人员的薪酬对话里，最常犯的错误是什么？

Austin 说，自己不是谈判专家，并建议向专家寻求建议。Austin 自己的看法是，早期锚定是危险的：当被早早问到薪酬期望时，候选人应当小心，因为说出的任何数字，都会锚定接下来的整场对话。

Austin 告诉候选人要了解当地的法律，并说在加州和纽约，招聘人员被要求分享薪资和总薪酬的区间，候选人可以据此看出自己处于什么位置（这一法律说法是 Austin 的，未经核实）。Austin 认为，最大的错误是没有多个录用通知。没有它们，候选人是在弱势中谈判，所以 Austin 敦促候选人把录用通知的时间安排得差不多同时到达，尽管那样压力更大、工作更多。

Q如果一位只想要 Staff 岗位的候选人，发现自己被引向了错误的面试环节，能在流程中途纠正吗？

Austin 说，这取决于公司和流程，但这是一场值得与招聘人员进行的好对话。公司既会升级定级，也会降级定级，而招聘人员通常会尽量让人留在流程里。Austin 建议，争取在前期就为期望的级别，完成尽可能多的评估，这样就不需要追加面试和后期的变动了。如果某个团队只给出较低的级别，这取决于工作和总薪酬，但 Austin 会以表现出色为目标，然后请求以更高的级别来考虑。

Austin 点出了两种方法。第一，把每一次对话都锚定在更高的级别，从“介绍一下你自己”开始，然后是行为面试和系统设计面试，让面试官看到大职责范围的项目和影响，并重新设定他们对面试其余部分的期望。第二是选择故事。每个行为问题的背后，都有一个面试官真正在乎的问题：候选人是否在期望的级别上做事？面试官很快就会忘记细节。

Austin 说，自己的书给出了选择故事的四点考虑，职责范围排在第一位。候选人的任务，是在离开时，已经讲述了自己职业生涯里最重要的那些故事，而且因为面试官在主导，所以要把对话引向最能代表自己的信号。

Q资深、Staff 和首席的职责范围是什么样子？候选人应该怎样表达它们？

Austin 首先说，要研究具体某家公司对级别的期望，然后给出了一个适用于大科技公司风格的公司的简单评分标准，如下表所示。级别其实关乎一个人能处理多少模糊性。Austin 指出，一位实习生面对的模糊性，不同于一位首席执行官面对的模糊性，并说正是这种差异，区分了级别和薪酬。

Staff 与资深的区别，归结为影响的广度：是整个团队或几个团队，而不是一个小项目。故事涉及在大型组织里跨团队工作。出于这个原因，Austin 认为，创业公司的工程师很难达到 Staff，除非他们是创始人，因为几位工程师和一位利益相关者，限制了他们能展现的组织领导力。

Austin 还补充了两件需要量化或提及的事情。对于技术复杂度，候选人应当让人感觉到所涉及的时间、风险、咨询了多少人，以及要退出一个决定有多难。对于领导力，工程师往往忘记它，因为他们爱谈技术，候选人应当描述影响力、从其他团队争取到的让步、对齐路线图，以及指导他人以让团队和组织变得更好。Austin 建议回顾自己的职业生涯，找出是什么让它与众不同，并谈论这些东西。

Q到底是谁做出招聘决定？

Austin 列出了各个决策点。寻源员根据 LinkedIn 个人资料，决定是否联系某人，他与招聘人员是不同的，后者在电话筛选之后接手，负责谈判、组织面试环节，并在委员会面前倡导。电话筛选的人是另一个决策点，无论是寻源员的多项选择题，还是工程师的编码筛选。

然后由招聘委员会做决定，通常通过共识，有时通过投票，决定是否以某个级别录用、增加追加面试，或放弃这位候选人。委员会之上的两三位工程总监做最终决定，同样大多通过共识，有时通过投票。

QAustin 有没有在招聘委员会里见过偏见，比如任人唯亲？内推有多重要？

Austin 从未见过公然的任人唯亲或贿赂，却见过内推起到巨大的作用，尤其是当推荐人资深，或者出现在委员会会议室里替人说话的时候。推荐人的资历很重要：副总裁或总监是拿个人声誉冒险，而一句“我在学校认识这位候选人”的话分量很小。内容同样重要。一份说明这个人曾与候选人直接共事、并列出具体长处的内推，帮助大得多，所以 Austin 告诉候选人，要为推荐人写好推荐语。

Austin 说，内推对处于边缘的候选人最重要。Austin 自己的电话筛选表现不佳，Austin 相信，是因为一位曾与自己直接共事的前同学做了内推，才得到了一轮追加面试。

Q面试表现在多大程度上预测了工作表现？

Austin 说，委员会并没有跟踪一个人通过了多少场面试。它看的是面试官对一项“录用与级别”决定所表述的信心，而这种信心与后来的表现相关。Austin 把这解读为证据，说明那些主持过数百场面试的、经过校准的面试官，即使很难定义，也能感觉到什么是好，而评分标准在不消除直觉的前提下，减少了偏见。

Austin 还指出，有些候选人在面试中表现出色，随后却表现不佳，另一些则看起来磕磕绊绊，后来却做得很好。面试是一项独立于工作的技能，Austin 说，候选人需要花时间把它练好。

Q行为面试的评分标准是什么样的？候选人应该怎样使用它？

Austin 说，各公司不同。管理良好的大公司，常常雇用工业心理学的博士，称为“甄选科学家”（selection scientist），他们研究是什么让工程师成功，并把它整理成各个信号领域。按 Austin 所说，在 Meta 有五项：推动结果、拥抱模糊性、化解冲突、持续成长和有效沟通。这些并不是 Meta 的公司价值观。候选人应当提前向招聘人员索取评分标准，或者去搜索它。

Austin 把典型的五到八项，归并为八个更宽泛的信号领域，在自己的书里作了描述，并告诉候选人，按这些领域给自己的故事分类。在面试里，核心的循环是“解码、选择、表达”（decode, select, deliver）：弄清为什么问这个问题、它在探查哪个领域，选一个能提供该信号的故事，并生动地讲出来。在较小的公司，可能没有正式的评分标准。那里，Austin 建议依靠公司价值观，并询问招聘人员或团队成员，什么让工程师成功，以及招聘流程在寻找什么。

Q候选人应该怎样为 OpenAI 和 Anthropic 量身定制行为故事？

Austin 先把故事对应到八个通用的信号领域，因为大多数公司价值观都可以归结到它们，然后再加上公司自己的价值观所贡献的东西。对于 OpenAI，Austin 把“保持谦逊地行动”（act with humility）解读为成长：接受反馈，并改进自己和身边的人。“感受 AGI”（feel the AGI）则在这八个领域之外。Austin 把它解读为对 AI 能为世界做什么保持乐观。

对于 Anthropic，字幕把一条价值观写成“hold light and shade”，Austin 认为这意味着理解 AI 在正面和负面两方面的影响。一个关于在 Anthropic 使用 AI 的故事，应当提到候选人所想到的潜在危害，以及他们如何评估和缓解这些危害。Austin 说，没有这一点，面试官就不会放心地录用。在 OpenAI，一位不以 AI 为先、或对 AI 的新领域不感兴趣的候选人，对他们的吸引力会小一些。这些是 Austin 对这些价值观的解读，不是官方的定义。

Q资深工程师在行为面试中最常见的错误是什么？

Austin 列出了几条。第一，选错故事，即与目标职责范围不匹配的故事。第二，背景太多：资深的人是很好的沟通者，往往爱讲，但只有理解行为所需的背景才是有用的。如果故事里大约三十秒都没有出现一个行动，Austin 认为候选人给了太多的前情或技术细节。Austin 承认，工作故事并不精彩，所以行动必须不断推进。

第三，招来不友善的解读。面试资深领导者的面试官是规避风险的，所以候选人应当有防御性的思考。说代码库有大量技术债，听起来也许是个好故事，但房间里的一位资深工程师，会引出它是怎么变成这样的这个问题。Austin 建议加上这个情形背后的判断，比如团队当时是一家要完成下一轮融资的创业公司，所以接受了这笔债务，然后选择优先偿还它。

第四，对非技术工作讲得太少：指导、组织、授权、影响路线图、化解冲突、跨团队工作和向上管理。第五，漫长的、多年的故事需要一个有条理的形状。Austin 建议以一份简短的目录开头（业务背景，然后也许是五个部分，比如提出想法、让利益相关者对齐、解决难题和漫长的上线），这样候选人在被打断之后，可以回到关键的部分。

Q候选人应该怎样在编码、系统设计和行为这几轮之间分配准备时间？

Austin 说，大多数人在编码上花了太多时间，在系统设计和行为上花得太少，而后两者准备起来更模糊。对初级工程师来说，技术信号最重要，而行为方面的重点，应该放在思考、动机和尝试过的想法上，作为未来影响的信号，因为初级工程师的成就较少。

对于中级工程师，Austin 说，过去那种只关注技术工作、而在行为面试上不出岔子的做法，已经不再有效。Austin 给出两个原因：裁员带来了许多候选人，所以必须在所有类型的面试中都出彩；而且有更多的技术工作用智能体编码完成，所以雇主想要的是端到端拥有问题、并在工程快速变化时不断学习的中级工程师。Austin 说，这种主人翁意识和成长，会体现在行为面试里。编码练习应该尽早开始，因为编码测评排在最前面，但在现场面试前几周，候选人应当选定核心故事，研究价值观和评分标准，并确保每个关键领域都有一个故事。

Austin 说，从资深往上，主要就归结为行为面试。对于一份 Staff 的材料，Austin 直接去看行为面试，因为设计一个网络爬虫或解两数之和，就那么几种方法，而行为面试，展现了组织影响、影响力、处理冲突、职责范围和业务影响。在 Staff 及以上的级别，额外的几轮可能包括一位跨职能的搭档，比如产品经理，或者一次项目深入讲解。Austin 把那里的技术面试，视为需要通过的“打勾项”，而把行为面试，视为决定一个人能否被录用的东西。

Austin 认为，大多数人在行为面试的准备上投入不足，至少需要几周的时间。Staff 及以上的候选人，应该在开始刷 LeetCode 的时候就开始，打磨故事的定位，得到反馈，并与朋友或专业人士做模拟面试。对于 Meta、OpenAI 或 Anthropic 这类热门公司，Austin 建议找一位针对该公司校准过的模拟面试官，能让你感受到它的文化。

Q主观上的讨人喜欢有多重要？气场如何影响结果？

Austin 说，它随级别而放大。在大公司，针对初级工程师的行为面试，是有结构的，有表格，以减少“啤酒测试”（beer test，是否愿意一起喝啤酒）的影响。对于资深工程师，面试官期望这个人在工作中去影响别人，所以他们给人的印象很重要。Austin 描述了硅谷的一种“随性的卓越”（casual excellence）品质：看起来平静，却敏锐而有能力。一位邋遢或紧张的、无法稳住场面的候选人，传递的信号是他们将怎样出现在会议上、以及在 CEO 面前。

Austin 补充说，文化规范因国家和公司而异。这里的对话，针对的是一种硅谷或西雅图的风格，以轻松的玩笑开场，然后转向尖锐的问题，而候选人应当了解他们所申请地方的期望。

Q是第一印象更重要，还是最后的印象更重要？

Austin 说，如果非得选，是开头。Austin 常常在最初的十到十五分钟里，就决定是否录用，因为 Austin 以最大职责范围的问题开场（最喜欢的项目、最模糊的项目、引以为豪的事）。如果 Austin 想看到这样的表现，在组织里被复制，那么面试的其余部分，就是对其他领域（比如化解冲突和成长）的核对。

结尾仍然重要，主要通过候选人的提问。Austin 说，候选人常常准备了故事，却然后问一些泛泛的问题，比如工程师的一天是什么样的，这在各处都差不多。那些来自对团队、组织、产品和公司的真实思考、并有助于候选人决定是否加入的问题，会留下一个投入的候选人的印象。

Q用最少的力气讲好一个行为故事，最好的方法是什么？

Austin 说，一个故事需要一条弧线，有开头、中间和结尾，并且必须传递面试官所追求的信号领域：可以在新组织里重复的过去行为。STAR（情境、任务、行动、结果）是最广为人知的捷径。Austin 不太喜欢它，但说，任何在前一晚准备好了 STAR 故事的人，都应该用它们，因为它们提供了一条弧线、行动的背景，以及结果。

Austin 更喜欢 CALR：背景、行动、结果、反思（context, actions, results, learnings）。情境和任务的区别，在一个长项目里没有用，因为长项目有许多任务，所以背景加上行动更简单。对资深工程师来说，STAR 没有给反思、判断或学习留出空间，而 Austin 要看的，是候选人能否看出是什么让自己成功或不成功，并把它向前应用。

Q主持人请 Austin 从职责范围的角度，解释自己为什么在 Meta 被晋升为 M2。

Austin 说，要升到 M2，意味着解决招聘中的难题，其中最重要的是多样性。Austin 离开了一支为青少年构建产品的团队（Austin 称那是 Facebook 的艰难时期），去领导内部招聘产品组织里的几支团队，这个组织为候选人、招聘人员和寻源员提供支持。吸引 Austin 的，是一支努力招聘更多元工程师的团队，而 Austin 的动力，是把科技（Austin 称之为最大的财富机会）向更多人开放。

Austin 说，一个产品团队无法决定学校的课程，也无法决定所有的招聘决定，但可以通过改进面试准备，推动局面，并把这归功于帮助了 Meta 的多元化招聘。Austin 还支持其他团队，在 Facebook 的应聘者跟踪系统里构建高质量的候选人数据。主持人听到的是多支团队、一个模糊的问题，以及强烈的自我驱动。Austin 同意，并补充了领导 iOS 和安卓招聘流水线所带来的全公司范围的影响，这让 Austin 的影响力超出了直接管理的团队。这些是 Austin 对自己履历的叙述。

Q回顾大科技公司的经历，Austin 有什么遗憾吗？

Austin 不后悔离开，并说很享受与出色的人共事。遗憾的是，把焦虑带进了团队，也带进了自己的生活。Austin 指出，没有人在生命的尽头，会希望自己多拿了几个百分点的参与度数字，并说人们看重的是关系和联系。

Austin 说，自己有意识地选择了更看重生活体验而不是职业，但并不总是对自己诚实地面对薪酬、晋升和地位上的取舍。自从为了支持配偶的生意而离开大科技公司，收入下降了。离开之前，Austin 决定接受较少的现金流，换取更多陪伴孩子的时间和更多的社区志愿服务，并在钱紧的时候，回到这个选择上。Austin 希望自己能更早地做出这种由价值观驱动的决定。

QAustin 得到过的最好的职业建议是什么？

Austin 说，是创造职责范围的重要性。许多人等着别人给他们机会，但一位经理曾告诉 Austin，要得到 M2 的岗位，Austin 必须创造出一个 M2 职责范围的团队，并解决那种规模的问题。晋升并不意味着把同样的事情做得更好。它意味着做不同的事，也就是创造更多的职责范围，以及让组织成功的空间。

Austin 补充了一个检验：副总裁在怎么谈论你的项目？如果副总裁没有告诉同级或他们的经理，这是不是对的工作？候选人在面试中，已经从想展示的信号领域倒推，在晋升中，从想要的材料倒推。Austin 建议用同样的方式倒推：领导层应该怎样谈论这项成就，然后找到实现它的办法。主持人补充说，建立在自己创造的职责范围之上的晋升，是最令人满足的，因为它们不需要任何人的许可。

QAustin 会给刚毕业的年轻的自己什么建议？

Austin 说，冒名顶替综合征拖了自己的后腿。在完成计算机科学博士学位之后，Austin 的夏天都在做大学的研究，而同龄人在谷歌或 Facebook 之类的地方做行业实习，因为 Austin 不想经历面试、冒被拒绝的风险。Austin 热爱自己的职业，也不会改变太多，但说，这种恐惧，让来自学术界的自己，对大型组织和大型代码库如何运作的理解变慢了。

Austin 总结的建议很简单：不要向恐惧屈服。

让有用的贡献被看见

Feinberg 说，最强的信号，是构建了别人在用的东西的证据。对一个现有项目做出有用的贡献，给候选人提供了影响力的具体证明，并让他们的能力被可能与他们共事的人看见。

Q对于内部调动，比如一位基础设施工程师转到前沿团队，建议会有变化吗？

Feinberg 说，到目前为止的建议，假定的是外部招聘。许多大型组织并不构建前沿模型，却仍然使用它们。Feinberg 举了一位来自搜索方面的同事转到 Feinberg 的团队的例子。那位同事的做法，是帮助产品领域尽可能好地采用这项技术。Feinberg 说，在这样的组织内部，有效地应用和部署大语言模型，存在很大的差距。

Feinberg 说，成为填补这个差距的人，会创造业务价值，并提升组织的地位。这也让这个人成为研究一侧的天然合作伙伴，让模型在那个组织内部运作良好。Feinberg 说，转岗因此成了可选项。这项工作本来就已处于前沿，因为它把新技术放进了人们使用的产品里。

Q如果你能在刚毕业时给自己一些建议，你会说什么？

Feinberg 的第一条建议，是追逐人们今天面临的问题。Feinberg 说，一个人不应当回避一个大问题里更小的、不那么光鲜的部分，即使它不是花哨的研究数学。去做真正重要的事，会显示出什么在推动前沿。Feinberg 呼吁在如何对待问题上保持谦逊。

Feinberg 的第二条建议是职业性的：成为别人希望看到成功的同事。Feinberg 把这与那些为了短期结果而榨取人的职场领导者作了对比。Feinberg 说，最有效的人是善良的，并以第一位把 Feinberg 引入计算机科学的导师为例。

Feinberg 说，从职场博弈论的角度看，一种慷慨的方式可能显得天真，但它建立了合作和愿意帮忙的意愿。这种信任，对于需要几个人和多种技能才能完成的大型项目很重要。Feinberg 的总结是：做那种别人希望看到成功的人。

Q你怎样选择好的队友？

看已经展现出来的技能和项目，而不只是头衔。她会查看 GitHub 上的作品、活跃度，以及与拟议项目相关的经验。她还看重热情、努力、足智多谋，以及愿意尝试陌生事物。最好的资历，是有用的证据，说明这个人可以为这个具体的构建出力。

Q黑客松的社交部分是什么？

它既包括团队，也包括评委。在团队内部，整个活动期间的动力很重要：一个人放弃，会对小团队产生不成比例的影响。一位热情的队友，可以带动整个小组，而她看到过，当每个人都全情投入时，成绩最强。

Q你怎样向评委展示一个项目？

让路演保持简短：说明想法，解释它做什么，并把大部分时间用来演示它。观察评委是否理解，并让他们与成果互动。在她的经验里，许多评委的技术并不深，所以一份框架清单，不如一个他们能看到其价值的产品有说服力。

这并不排除技术上的雄心。一个复杂的项目，当它运行良好、展示又让它的目的显而易见时，可以显得清晰而简单。错误在于，以为单凭复杂性，就是它应该获胜的理由。

Q黑客松加强了你的主动性吗？

她本来就有一些愿意尝试不寻常事物的意愿，但认为这些活动有所帮助。学校有时让人觉得重复，而构建东西提供了更有刺激的出口。身处一个很少有人认真追求创业的环境，让这种尝试与通常的路径感觉不同。

Q一位在不太知名学校的学生，可以做什么来脱颖而出？

培养主动性和责任感：领导一个社团，参与决定一个重要项目的方向，或者让有用的工作被看见。她的意思，是成为一个做决定并把它们落实的人，而不是完全依赖学校的名声。

Q个人品牌对一位学生有什么作用？

它让之后的工作更容易被发现。展示给一个小圈子看的项目，只能触达那个圈子；而一批可见的作品，可以一次触达多得多的招聘人员或潜在的合作者。她把它看作提高了有用的机会找到自己的几率。

Q你是怎样选择在 Meta 的第一支团队的？

最初一个位于伦敦的选项，在发现跨地点的代码评审需要好几天之后，就失去了吸引力。Sash 随后遇到一个人，认为他兼具设计和工程的经验，适合一支要把设计师没被用到的原型变成已上线体验的团队。

那支 News Feed 的“愉悦”团队，优先考虑动画、好玩的互动和其他小小的愉悦时刻，一开始没有明确的指标要求。他很喜欢，但这支团队只持续了大约半年。回头看，他认识到，一个令人愉快、却没有持久的影响力故事的主张，在那个组织里，很难经得起审视。

Q一支偏设计的团队，怎样证明自己的工作是成功的？

Sash 回过头看，认为需要一位拥有可信的价值理论的高管赞助人。他回忆起一个调查指标，问人们是否觉得 Facebook 在乎他们，这为“愉悦”的工作提供了一个可能的联系。这个指标是主观的，也可以有不同的解读。

他认为，当公司高度关注效率时，更难为这样的团队辩护。这解释了他选择中的一种张力：他寻找自己觉得有吸引力的工作，即使它可衡量的回报并不确定。

Q你在选择团队时，优化的是什么？

起初，是乐趣。他追随人、直觉，以及看起来有趣的机会，然后事后再去理解由此形成的路径。随着时间推移，他变得稍微更有意识，但仍偏爱有风险的、从零到一的工作。

他注意到，许多优秀的工程师在开始之前，想要一个清晰的产品定义、示意图或设计。他在没有这些的情况下也能舒服地工作，这给了他一个有用的利基。广度积累了工具、关系和知识，在后来的项目里可能变得有价值，尽管这并不保证每一次转换都有成功的结果。

Q是什么让一位设计师格外好合作？

愿意持续地协作。最初的设计不必预见每一个工程上的约束，但团队最终必须解决缺失的数据、网络故障和其他现实世界的情况。工程也可以带来设计师可能没想到的可能性，比如传感器影响一次交互。

他看重短的反馈循环。在一个尚未发布的硬件项目里，他做了一条临时拼凑的流水线，能迅速把 Figma 的设计显示在设备上，这样设计师就可以修改，并立刻看到结果。双方都倾听、调整，比把一个所谓完成的想法交接过去，能产出更强的产品。

Q当你提交的代码这么少时，你的绩效是怎样被评判的？

早期团队的期望，围绕的是减少不确定性，而不仅仅是落地生产代码。团队配备了资深的人，他们明白一个有风险的项目，需要那种工作。Sash 把这描述为，一家大公司可以在不承诺晋升的前提下，鼓励探索的一种方式。

他还看到评审节奏中的一种张力：频繁的反馈是有用的，但短周期可能让人不敢押注那些要跨几个周期才出结果的赌注。他并不声称有一种评审流程，能完美地服务每一个人。在他的例子里，重要的一点是，所期望的贡献，与项目的探索阶段是对齐的。

Q是什么让那个项目里的资深后端工程师如此高效？

对现有系统深入的熟悉。这位同事知道怎样创建一个 feed，怎样让一篇没有图片的帖子行得通，并理解在应用其他地方的后果。他们的对话，迅速变成了 Sash 可以测试的、可运行的前后端改动。

大型的、成熟的原语也有帮助。一个高层的操作，可以提供默认值和集成，而无需每位工程师重新搭建底层。这位懂行的搭档，知道怎样恰当地使用这些设施。Sash 把它比作“副驾驶”，这个俏皮的比喻，强调的是准确的背景和判断，而不是字面上对这个人的替代。

Q分享原型，是否建立了带来新机会的声誉？

他无法确切知道别人是怎么想的，但相信，反复的内部演示，让人们把他与快速的、探索性的工作联系在一起。使用公司技术的原型不能公开分享，所以内部的帖子是一个重要的场所，即使当下的互动并不多。

用一个能运行的东西，去回应一个含糊的询问，也展现了主动性。早期的项目，受益于那些在没有完整的任务清单时也能行动的人。他认为，在大公司常见的会议和对齐工作中，这种行为很突出。

Q为什么原型比书面提案更能传达？

书面描述，依赖每个人构建出同样的心智模型。一张图能缩小这种模糊性；一段视频能缩小得更多。一个可交互的原型，让人们直接体验这个行为，并讨论一个具体的交互。

Sash 见过一些会议，进行了一段时间，参与者才发现自己想象的是不同的产品。原型可以及早暴露这种分歧，并缩短项目中模糊的阶段。它的保真度有助于对齐，而不只是宣传。

Q尽管频繁换团队，你怎样评估自己从 IC4 到 IC6 的成长？

留在同一个领域，通常会让定级更容易：专长、善意和关系，围绕一个已知的问题复利累积。他在一位多年留在原团队的同事身上看到了这一点。他常常觉得，那种连续性对他自己来说不那么有趣。

他的选择偏向愉快的项目和广度，而不是最大化晋升速度。它们积累了人脉和知识，其中也有一些走错的弯路。因为他工作时间长，所以乐趣对于维持这份投入很重要。

他明确拒绝把自己的路径变成普适的建议。正确的策略，取决于一个人想要的职业和生活。他最终的晋升，并不能证明反复换团队是最快的路径，只能说明这条路径，可以为一个有他那样偏好的人，培养出一个有用的利基。

Q你的路径与你最初新兵训练营小组里的人相比如何？

他记得同伴们有的成为经理，有的留在同一个应用或领域，总体都做得不错。他们更偏爱纵向的成长，而不是他那样的广泛探索。这种比较只是一个小规模的轶事样本，并不是哪种策略胜出的证据。

离开的时候，他发现很难找到一个替代的角色，因为他的角色几乎完全围绕原型制作。他认为，大公司的激励，自然会把大多数人引向可预测的影响力。但一家公司也需要一些人，准备好去测试不确定的方向。这种平衡，可能帮助它发现既有业务之外的选项。

Q只针对某一项指标做优化，有哪些局限？

Sash 提到了那个人们熟悉的问题：一项衡量一旦变成目标，就会变得没那么有信息量：人们学会了钻它的空子。他还认为，产品质量中重要的部分很难衡量，需要品位。

一个不断上升的局部指标，可能掩盖那些需要暂时的倒退或不同方向的机会。他认识到，把这个洞见转化为一个可扩展的框架是困难的，因为大型组织也需要可重复的流程。他对实验的偏好，是对这种张力的回应，而不是对指标的一个完整的替代方案。

Q你对十次换团队中的哪次感到后悔吗？

有些回报不如他期望的好，但他从中学习，并建立了关系。努力做一个好队友，让这些联系在两个方向上都有用：有人可能邀请他参与后来的项目，或者他可以带上他们。

在他离开 Meta 之后，这个人脉网络的规模变得格外明显，人们提出引荐，或者对他接下来可能构建什么表示兴趣。他看重冒险和人，把它们当作结果，而不是只用头衔的晋升来评估每一次调动。

Q你会给职业生涯开始时的自己什么建议？

把弱点处理到不妨碍工作的程度，然后投入到让贡献与众不同的长处上。一位经理帮助他看到，修补每一个缺点，不一定是价值最高的发展计划。

对 Sash 来说，这意味着选择一个能让他对模糊性的适应、与设计的协作和快速原型制作派上用场的环境。这条建议，是请一个人去理解自己的长处和适配，而不是照搬他具体的团队选择。

Q为什么要做一档关于资深工程师职业生涯的播客？

Ryan 想成为更好的演讲者，他相信这项技能，会影响职业、人际关系，以及别人如何看待一个人。Toastmasters 提供了有用的练习，但他发现，录音在其他优先事项之中，常常没有被回看。发布带来了更强的承诺：因为会有人听，他在剪辑时会审视每一个字。这些内容既是练习，也是反馈循环。

Q做播客，比普通的对话更难的是什么？

自然的口头回应，比如简短的赞同和倾听时发出的声音，在录音里可能会盖住嘉宾的回答。Ryan 不得不学会用点头来表达投入，同时克制打断。制作一个听起来令人愉悦的东西，需要一种与不录音的对话不同的倾听习惯。

Q你是怎样学会放手实现性的工作的？

Hejlsberg 给出了一个反例，反驳“放手总是进步”这个假设。在 C# 上，他的核心角色变成了语言设计和规范，直接做编译器实现的时间变少了。他逐渐发现，这离他所喜爱的、困难的编码问题太远了。

直接参与 TypeScript 的编译器，恢复了这种乐趣。他喜欢设计工作，但写代码，也是让他渴望开始新的一天的东西。教训是，授权时，不要意外地去掉那件激励自己的事情。

Q一位非常资深的工程师，怎样在满足广泛影响力的期望的同时，继续写代码？

他的影响力，来自作为团队一员所做的架构指导，同时他仍然参与一部分实现。这种参与，让他能注意到别扭的代码、浮现的重构需求，以及单靠规范无法揭示的实际问题。

他把自己所写的任何一行代码的影响，与因为贴近代码库而得到支撑的判断区分开来。把指导与直接的工作结合起来，让他能够理解人们所使用的东西，而不只是描述它的语法。

Q你会给职业生涯起点的自己什么建议？

更早地学会与他人共事。另外，不要自动接受别人关于一个技术目标无法实现的声明：他们的极限，可能反映的是他们自己的经验，而不是一种根本的不可能。

这条建议邀请的是调查和坚持，而不是证明每一个雄心勃勃的想法都会行得通。

Q你那次相当于资深 Staff 的晋升，背后做了什么工作？

嘉宾最初在 2015 年前后，参与一个估算 Facebook 某项业务使用情况的项目。在各自独立的数据流水线系统和机器学习系统之间切换很麻烦，所以他做了辅助脚本，让流水线工作可以放在编排环境内完成。合理的默认值去掉了重复的样板代码，同时为高级配置留有后门。他估计，在旧系统里需要大约 300 行的任务，用他的库可能只需要大约 20 行。

这段经历，把他的兴趣从单次分析，转向帮助分析师和机器学习工程师更快地工作。笔记本的环境配置是另一个反复出现的痛点：人们用过时的 wiki，手动安装 Jupyter 或 RStudio。在经理同意的情况下，他先花了两三个月探索自动化的配置，然后招募了其他人。最早的 Bento 只是一个配置脚本；更大的愿景，是一个可以通过浏览器访问、与内部库集成、最终支持其他语言的环境。

大约一年里，团队构建了这个平台，以及用户可以申请和释放、而不必自己维护服务器的按需实例。他还组建了一支六到八人的团队，邀请那些本来就喜欢在业余时间构建工具的工程师，全职来做这件事。他转入了技术负责人兼经理（TLM）的角色，并说他的 TLM2 晋升，在很大程度上取决于他个人的技术工作和 Bento 的愿景。主持人把这个级别解释为相当于高级经理或资深 Staff。

Q你是怎样把一个有用的内部工具，变成被广泛采用的东西的？

Bento 起初并不要求转换每个人现有的工作流程。团队瞄准了入职培训项目，那里的新数据用户，对遗留的配置没有依恋。在一家快速增长的公司里，这带来了许多用户；然后，现有的员工看到，越来越多的同事在使用新系统。

对于仍留在遗留笔记本上的人，团队在以前服务不足的渠道里，提供维护和支持。这在提出迁移请求之前建立了信任。当有人需要一个别扭的配置时，团队可以提供一份冗长的手工指南，或者更简单、有支持的 Bento 路径。

团队还与分析方面的负责人，谈论他们小组里具体的痛点。这些对话揭示了数据工具方面更大的积压需求。因为没有专门的团队服务这个领域，嘉宾就从核心数据科学转到了开发者基础设施，去创建一支。所以采用，是一个便利的切入点、为现有用户服务、与领导层的关系，以及合适的组织归属的组合。

Q当短期的绩效期望很严格时，你怎样去冒一个有前途的风险？

嘉宾认为，表现不佳的后果，比十年前更严重，但关键做法是一样的：在偏离正常工作之前，先就期望达成一致。他当时被分配去做数据咨询，而他提议的工作是基础设施，所以他请经理和隔级经理，把一次有边界的探索，纳入自己的工作。

如果这个工具成功了，团队受益；如果失败了，完成一次约定好的探索，仍然是被期望的。他认为这比消失三个月、然后带着一项没人知道取代了他正常职责的工作回来，要安全得多。

要过度沟通，并准备好听到“不”。他把功劳归于支持这次试验的一位经理，并记得后来领导层拒绝了的一些提议。这个故事并不保证每一个风险都能被谈判化解，也不保证一个探索性的项目一定带来晋升。

Q冒名顶替综合征耽误了什么？

第三位嘉宾会更早地信任自己的判断。成功的项目、良好的协作和反馈，最终建立了信心，但早期的焦虑，让他不敢尝试一些想法，因为害怕打破现状。后来，其中几个有颠覆性的项目都做得很好。他希望自己更早地测试它们，少花一些时间担心，同时让最终的信心，立足于经验，而不是声称每个第一反应的想法都是对的。

Q一组普通的长处，怎样组合起来变得与众不同？

一位嘉宾，钦佩设计和工程方面的专家，担心只在好几个领域里表现中等是行不通的。他真正的优势，是在这些领域之间进行协调。他会少关注成为某个单一学科里最好的人，而更多地关注自己能带来的那种不同寻常的组合。

他还会对分享想法更勇敢一些。他在学校里对公开演讲的恐惧，与他在推介一款自己在乎的产品时的从容，形成了鲜明的对比。把讲解材料当作对知识的考试，让他焦虑；而为一项想要促成的改变发声，则给了他一个不同的目的。热情并没有神奇地消除每一个挑战，但它改变了说话对他的意义。

Q除了做那个写被要求的代码的人之外，还有什么重要？

这位嘉宾把年轻时的自己称作 Dwayne，他会问：怎么知道，被要求的实现，是该构建的正确东西？他会争取参与这些决定，而不是只用自己能敲出的东西来定义自己的价值。这种更广阔的角色，本可以帮助抵消他早期的冒名顶替综合征，并明确想法和判断，可能比原始的产出更重要。

Q你怎样变得更勇敢，又不假装尴尬会消失？

下一位嘉宾把自己称作 Brian，他会更勇敢，并对失败少一些难为情。他马上把这条简短的建议限定为一场更大对话的开始，关于理解感受，而不是一条让感受消失的命令。他认为，更多地了解自己的情绪，也许通过心理咨询，对这个人和他们的人际关系都有帮助。

Q你怎样选择一个看重你长处的环境？

另一位嘉宾说，一位优秀的前端工程师，在后端团队里可能会吃力，或者一位热爱改进框架的人，在专注于产品交付的团队里，可能得到糟糕的结果。仅有活动是不够的：即使数百次改动，也未必服务于团队的优先事项。要认识到持续的不匹配，并寻找一支需要你擅长之事的团队和管理链条。原则是长处与被看重的工作之间的契合，而不是在任何环境里，仅仅多做自己擅长的一件事。

Q当一个组织继承下来的做法看起来很奇怪时，应该用什么来指引你？

最后一位嘉宾推荐常识。大公司可能有错位的激励，以及仅仅因为一直存在而被保留的流程。创业公司也需要对市场和用户究竟想要什么做出判断。他会信任并培养这种实用的判断力，而不是假定组织惯例已经回答了问题。

QE7、E8 和 E9 的工作有什么区别？

Philip Su 从影响的范围谈起：一个人能够可靠地完成多大、多有价值、或持续多久的工作？他给出了历史上大致的期望，比如在资深／接近 Staff 的级别上，影响大约十到十五个人，而在 E7 也许是五十个人。他明确警告，自己关于级别的信息可能已经过时。这些是他经验中的例证，并不是任何一家公司今天的晋升标准。

更高的级别，在质上也不同。一位异常深入的专家，可能解决几位较低级别的工程师无法替代的问题。一位知识广博的通才，对于一支小的或新的团队，可能比分开招聘的几个人，更有效地整合多种工作。单看人头数，就错过了这种区别。

他回忆起 E9 是在他最初晋升到 E8 之后设立的，早期的决定只涉及几位非常不同的候选人。这样一个小而多样的群体，使得普遍适用的清单不太可能。在顶层，来自同级和更资深领导者的有见识的判断很重要：他们是否认出了那个级别的工作，为什么？他把它比作学术资历所涉及的定性认可。重点不是所有的评估都是任意的，而是一份任务清单，无法完整地代表出色而多样的贡献。

Q如果一位优秀的 E7 身边没有 E8 或 E9 可以学习或评估他们，怎么办？

Su 认识到这个问题，既存在于小公司，也存在于大型组织里较弱的团队中。当地最强的人，可能扭曲自我校准，或者去掉观察更好判断的机会。他建议选择一个有空间与强大的同事一起成长的环境，而不是把“在当地最强”当作唯一的目标。

在非常高的级别上，单纯模仿另一位资深的人，可能行不通，因为他们的原型和长处，可能与你的不同。他赞成找一位参与相关晋升决定、并能给出定性评估的教练。这个人可以解释，这份工作还在哪里没达到标准，并帮助讨论更强的工作会是什么样子。所期望的输入是具体的反馈，而不是假定靠近一个有声望的头衔，就会自动产生成长。

Q什么样的职责范围，促成了你自己的 E9 晋升？

Su 帮助用十二个人启动了 Meta 在伦敦的工程团队，并在大约四五年里，把它发展到大约四五百人。他描述了随着站点的扩张，管理战略和组织上的转变。一支十二个人的团队，一位有能力的工程经理就能管得很好；而几个数量级的增长，让问题变得更多样，答案也更不明确。

一个例子，是根据预期的签证限制，会影响未来在门洛帕克的全职入职，来规划伦敦的实习生和人头数。他用数据，在后果出现的大约十八个月之前，就提出了决策建议。另一个例子，是考察站点的资历分布，以及工程师是否在以合适的速度成长，而不只是检查每个人名义上的级别。

增加的职责范围，既涉及受影响人员的广度，也涉及判断的时间跨度。他把这样一系列决定，当作晋升的故事，而不是点出某一次孤立的代码改动，或断言仅仅扩大一个站点就能保证同样的级别。

Q你在 Instagram 的第一次资深级别晋升，背后有什么故事？

在做完谣言方面的工作之后，Adrien 见到了 Instagram 的联合创始人兼 CTO。Facebook 在 2012 年 9 月收购了 Instagram，核心团队大约有 30 人。Instagram 没有个性化，也没有 A/B 测试。他从“探索”（Explore）标签页开始，加入个性化，并需要一种衡量它是否有效的方法。产品负责人说，在 Instagram 从 AWS 迁移到 Facebook 基础设施期间，他们有更大的优先事项。

他还是构建了这套测试系统，有一位产品经理给他撑腰。他重用了 Facebook 的系统。因为 Instagram 运行在不同的基础设施上，他增加了一个自定义的 Facebook API 端点，对 Instagram 的应用 ID 开了白名单，用来记录曝光。他称这很取巧，而且可能代价高昂。他还加入了用户哈希，把日志连到数据仓库，运行了一个服务端的 A/A 测试，并与移动工程师一起做了小型实验。

他说，自己当时并不知道有晋升这回事。他是 IC4，当他的经理宣布 IC5 的晋升时，他不得不问这个级别是什么意思。然后他把 A/B 测试系统，交给了一支新成立的、负责它的团队。

Q早期的 Instagram 团队与 Facebook 之间，有文化上的差异吗？

Adrien 说，他从未正式加入过 Instagram 团队。他的数据科学小组像顾问一样工作，嵌入其他团队，而他的汇报线保持不变，头几年里他有两位经理。Instagram 感觉像是创业公司里的创业公司。Facebook 大约有 2,000 名员工，而 Instagram 的 30 到 40 人的核心团队，一间会议室就坐得下，重点放在设计和工艺上，而不是数据。

Q你能讲讲你的 IC7，也就是资深 Staff 晋升背后的故事吗？

Adrien 做的项目，是把数据带给非数据团队。其中一个统计某款 Facebook 产品用户数的项目，需要机器学习和推断，但工具很差。他构建了一个库，在机器学习框架内运行数据流水线。他说，在标准系统里需要大约 300 行的流水线，用这个库可能大约 20 行。这让他相信，要构建帮助别人更快前进的工具。

公司里一半的人用 Jupyter，一半的人用 RStudio，而配置依赖过时的 wiki。他提议每个人都有一个 Jupyter 实例，向经理提出了一次为期两到三个月的试验，并构建了 Bento 的第一个版本。起初它只是一个配置脚本。愿景是把它连到公司的工具上，这样用户可以打开浏览器，输入 Bento，就得到一个已经备好内部库的笔记本。

Bento 按需版本，后来让用户可以申请一个临时实例，而不是使用共享的开发服务器。Adrien 帮助领导了这项工作，并通过招募那些本来就在业余时间构建工具的人，来组建团队。他成为了技术负责人兼经理，并被晋升为 TLM2，他说这相当于行业里的高级经理和资深 Staff 工程师。

Q把内部工具从一个想法，变成人人使用的东西，分步的过程是什么？

Adrien 说，Bento 没有试图在现有的工作流程里赢得采用。团队瞄准了新员工的入职培训项目（bootcamp），并告诉每一位与数据打交道的人，这就是配置的方式。公司当时增长很快，所以许多新人并不了解遗留系统，其他人则跟着同伴转到了新工具上。

团队还维护那些无人维护的遗留配置。这样做建立了与用户之间的信任。

Q你承担了一次绩效风险，去构建一个可能失败的东西。今天这样做是否更难？一个人应该怎样为了更大的回报去冒险？

Adrien 说，现在表现不佳的代价更高了，但做法是一样的。先与你的经理对齐，因为人们是按期望来评判的。他告诉经理，他会暂时放下分配给他的工作，并请求两三个月的时间来探索这个想法。他称这是团队同意的一次经过计算的冒险。

他认为，秘密地做自己的项目风险更大，因为三个月后你可能带着一个没人知道的结果出现。他的建议是过度沟通，并准备好听到“不”。后来，当他试图为其他想法建立共识时，有时被告知了“不”。

Q转入技术负责人兼经理的角色，背后是怎么想的？

团队正在构建的产品需要扩展，需要更多的人。Adrien 可以招一位有不同愿景的经理，或者自己试试管理。这次转变，是出于想领导自己组建的团队的愿望，而不是出于要成为经理的计划。团队需要一位经理，于是他成了这位经理。

Q对于在一个完全不同的领域快速上手，你有什么建议？

他从一次社交网络式的探索开始：与人交谈，并问还应该跟谁谈。不要害怕基础的问题，因为每个人都知道新人是新来的。他还亲自动手。虽然他从未正式做过固件，他读了代码，并做了几处改动。然后他选一个自己大致知道怎么解决的难题，因为他是在做中学。

Q什么样的职责范围，让你晋升为 IC8，也就是首席工程师？

Adrien 负责一台设备上的所有体验，涉及几十支团队和大约 35 位产品经理。合作团队拥有操作系统层。他的工作是协调、架构，以及达成里程碑。对于 Ray-Ban Meta 这样的产品，这些体验包括设备端的 AI、音乐、拍照，以及配套应用。

IC5 让他感到意外。对于 IC6，他请经理把自己推荐上去，而 IC7 花了几个评审周期。对于 IC8，他的经理从未推动过这个级别的晋升，所以他们一起想出了材料，Adrien 写了大部分。他很早就与几位副总裁建立了共识，并请一位总监每月核对一次他与那个级别之间的差距。六个月后，这位总监支持了这次晋升，因为他全程参与其中。

Q当一个角色仅限一人，比如一个项目唯一的技术负责人时，你怎样争取职责范围？

一位工程师是整个项目的技术负责人。Adrien 看到，体验方面的许多工作，可以由一个专注于它的人来处理。他把它从这位负责人的盘子里拿走，让负责人可以专注于更大的项目，同时负责人保留系统方面的工作。两人建立了信任。大约一年后，Adrien 请领导层正式认可这个角色，这样他就可以用一句话来描述它。

他拒绝“接手职责范围就是偷”的想法。只有当你不与那个人沟通时，才有问题。他先问了这位工程师，对方同意了，后来他又问了一次关于一个相关的领域。过度沟通，是始终如一的主题。

Q你的职业生涯，是一连串偶遇合适的人。你有没有关于如何最大化“人际机会”的运气的建议？

Adrien 说，他的工作没有一样是在真空中发生的。早期，他有棱角，也有强烈的观点，这对他没有帮助，而他学到了，人们是一起成功的。他说，信任和尊重意味着，当你需要时，人们会出现，但你不应该为了得到回报才去帮助别人。

他还说，不要害怕开口问。对于职业上的变动，他从来没有通过招聘网站申请过。他联系自己认识的人，请求小小的帮忙，并给出一个容易拒绝的方式。人们都很忙，所以沉默不是判决。关于运气，他说，多试几次，会增加几率。

Q如果你能回到在法国刚大学毕业时的自己，你会给什么建议？

他会说，要做一个好人，投资有趣的事情，投资与同事的关系。功劳没有看上去那么重要，因为每个人都会因为某件事得到功劳。他早期非常在意功劳。他还会告诉自己要有耐心，因为他有时在还没准备好时就推动晋升，并要保持好奇，享受工作。

Q你能讲讲你在赛门铁克（Symantec）的整体经历，以及你是怎样成长为 Fellow 的吗？

Nachenberg 大约在 1992 年，作为实习生进入 Peter Norton Group，后来被赛门铁克收购。他认为自己是那里的第一位实习生，并说公司没有给他安排办公桌，所以他在质量保证实验室工作。到 2016 年他离开时，他已经从最初级的人，成长为赛门铁克最资深的工程师。

Q赛门铁克的职业阶梯是什么样的？你加入谷歌时，像你这样资深的人，招聘是怎么进行的？

Nachenberg 说，从初级工程师到 Staff，级别与谷歌和 Meta 的大致对应。在高层则不同，赛门铁克有杰出工程师和 Fellow。谷歌告诉他，在不知道他在那里的表现之前，无法聘用一位 Fellow。他实际上被降为首席工程师，8 级，而他说，这在赛门铁克本来大约相当于 10 级和一个副总裁的角色。

Q最高级别的晋升是什么样子的？

Nachenberg 说，在赛门铁克，直到高级技术总监的晋升，都在组织内部处理，只要有一位副总裁或高级副总裁同意。杰出工程师和 Fellow，则交给由首席技术官领导的一个核心技术人员小组。该小组每季度开会，审阅申请，并让候选人展示自己的工作。目的是在整家公司里保持一致的标准，而不是一个部门一个部门地各行其是。

Q在通往 Fellow 的路上，是什么让你与其他工程师不同？

Nachenberg 把功劳归于有影响力的项目，而不总是技术上最难的项目。他寻找空缺：公司需要、却没有人站出来做的事情。赛门铁克在他早期，用他的话说是“狂野西部”，没有敏捷流程，也没有工程师测试自己的代码。他从未被交付一个框死的项目。因为作为实习生，他就已经了解这项技术，所以被告知自己去弄清楚要做什么并去做，他说，自己选择了那些能够落地、发布并转入产品的项目。

Q是什么让你在赛门铁克待了这么久？

Nachenberg 说，老实讲，是冒名顶替综合征。在赛门铁克，他觉得有安全感，因为在那里很出名。他担心自己的成功，来自在那家公司里长大，并且担心自己可能不足以去谷歌或 Meta。他留下来，是因为舒服，而且他抱怨很多。临近结束时，他不开心，因为资深的岗位带来更多的会议、更少的构建，他称之为“一大堆废话”（BS）。

QGoogle X 是什么样的？有文化上的差异吗？

Nachenberg 说，比预期的少。主要的差别是人的素质，他们非常聪明，而赛门铁克缺乏工程文化，至少直到大约 2016 年才开始形成。相同的是，许多人缺乏项目品位。他们很聪明，但他怀疑他们是否选了能落地或可行的项目。他说，任何公司的工程师都是如此。

Q你最终为什么离开了谷歌？

Nachenberg 再次提到冒名顶替综合征，另外还有想去创业公司工作，而不是一个更慢、监管更多的环境。他说，有一些他本可以接手的大问题，比如把 Chronicle 昂贵的存储设计，从 Spanner 这样的重型系统上迁走。他缺乏尝试的信心。资深级别的期望很高，而在谷歌，他觉得，如果一次持续几个月的尝试没有落地，领导层不会支持他。在赛门铁克，他的经理们认识他多年，给了他放手去做的空间。他也得到过其他角色的邀请，比如在加密数据上计算的安全数据库。他想要一些新东西，而在 X 期间与 Waymo 的人交谈，让他想去做自动驾驶汽车。

Q你是怎样成为加州大学洛杉矶分校的讲师的？你怎样让讲课引人入胜？

Nachenberg 在 1990 到 1991 年前后，在 Learning Tree 教过编程，包括教 DeVry 的员工。他还在大学本科时，在加州大学洛杉矶分校办过晚间的白板讲解。多年后，赛门铁克一位兼职在加州大学洛杉矶分校授课的同事，让他去申请。Nachenberg 以为，自己没有博士学位，就被排除在外了。几个月没有消息之后，当一位讲师退出时，加州大学洛杉矶分校慌忙打来电话，他只有两周时间，规划一门本科课程。那大约是 25 年前。

讲课时，他以班上大约第 30 到 50 百分位的学生为设计对象，并以自己（一个学得慢的人）为模型。他问自己，第一次接触一个主题时想知道什么，以及学生可能在哪些方面模糊。他说，他花了好几天时间，与 ChatGPT o3 一起简化概念，然后用 Gemini 核对并比较差异，因为他发现好的在线材料稀少，教科书也很差。他还希望学生喜欢这门课，所以加入了幽默、色彩和惊喜。

Q回头看，有什么你后悔的事或会改变的事吗？

Nachenberg 说，他本该更早离开赛门铁克。他的规则是，在你还在学习、培养技能、并觉得可以偶尔失败的时候留下。他在赛门铁克失去了这些，但留下来，是因为缺乏信心，而不是因为工作吸引他。他仍然看重待五年甚至十年，只要你在学习。换团队可以保持良好的声誉和组织内的知识。待得太久，会让你陈旧、安逸。

他还指出了离开的代价。在赛门铁克，他广为人知，因为 Stuxnet 而上过电视和主要报纸。在谷歌，没有人在乎他以前做过什么，所以他不得不重建信任和声誉，这很有压力。

Q如果你能在从加州大学洛杉矶分校毕业时给自己建议，你会说什么？

Nachenberg 说，没有单一的一条。第一，不要让对失败的恐惧拖住你。你可能比你以为的能做得更多，他说，如果他听从了这一点，也许会有更丰富的职业生涯。第二，专注于结果：谁会使用这项工作，他们在乎什么，以及他们怎样衡量成功。问题往往需要一个小小的方块，而不是一个完美的圆形东西。

他说，他曾向资深领导者展示一项技术，他们并不在乎算法是怎么运作的。他们想知道它是不是更快，快多少，以及对收入或人头数意味着什么。要说他们需要的，而不是你自己需要的。第三，找一位信任你、给你放手空间的好经理，因为一位经理，可以成就或毁掉你的职业和快乐。第四，学会协作，不要假定自己是对的、并告诉别人他们错了。他说，自己仍然在这一点上挣扎。

Q整体的晋升和薪酬时间线是怎样的？

Ricky 2017 年在实习之后，以应届毕业生的身份加入谷歌。他说，年薪大约是 180,000 美元，外加签约奖金，然后一年半之后晋升到 L4，约 250,000 美元，再过一年半到 L5，约 350,000 美元，三年后到 L6，约 500,000–520,000 美元。这些金额，是他自己情况的回顾性数字，包括股权的影响，并不是当前薪酬的保证。

他把功劳归于幸运的团队匹配，并认为三年内达到资深，比他观察到的典型路径要快。Staff 花的时间更长，涉及另一种责任。这个职业故事，结合了他有意识的工作，和他无法控制的机会。

Q从初级到中级的晋升过程中发生了什么？

在 Ricky 描述的评审体系里，评级每六个月一次。他起初是符合期望，然后是超出期望，并在晋升的同时，得到了更强的评级。他相信自己的影响力和独立性，已经与下一个级别相符，但担心任期短，可能对他不利。他的经理支持这次尝试。

Q是什么行为让第一次晋升成为可能？

独立性：以更少的手把手指导，完成项目，并找到办法自己扫清阻碍。这并不意味着拒绝向任何人求助。它意味着学到足够多，让项目往前走，而不要求经理替他解决每一个障碍。

Q朝着资深努力时，发生了什么变化？

他成了一个明确领域的负责人和首选人选，学习它的代码，并在那里交付了几个有影响力的项目。主人翁责任，意味着能够回答问题并推进这个领域，而不仅仅是交付更多孤立的改动。

Q你是怎样识别出真正处于下一个级别的项目的？

他研究队友成功的资深晋升，了解所期望的职责范围和复杂度，产生类似的想法，并请经理来校准。在晋升前大约一年，他提出了一份路线图，并问完成它是否能达到标准。

这给了经理一些具体的东西来评估，并让成长计划变得明确。这份路线图，是在 L4 之后大约六个月的探索之后产生的，而不是在那次晋升的当天立刻产生的。

Q当被要求做的工作无助于推进那份路线图时，你怎么做？

他学会对那些耗费时间却无助于自己成长的不相关项目说“不”。他把这与问责区分开来：他造成的 bug，或者他所负责领域里的 bug，仍然需要处理。如果一项新的请求，其影响和职责范围比现有的计划更强，也值得接受。

Q你是怎样学会判断哪些想法有影响力的？

首先要界定组织看重什么。在他的广告领域，收入是核心指标，同时还要看这项工作是否帮助了用户、广告主和发布商。其他团队可能在乎活跃用户或产品互动。运行实验，揭示了改进可以推动相关结果的空缺。

他发现，在关于项目价值的争论里，可衡量的结果很有说服力。他强调“数字说了算”，这属于他在一个用收入衡量的领域里的经验；不应该把它当作每一项工程贡献都能被一个数字捕捉的论断。

Q资深的晋升本身感觉如何？

它比第一次晋升更感到不确定。Ricky 认为自己领先于他周围通常观察到的时间点，并担心委员会可能想要更长的、下一级别工作的记录。他的经理支持提交，同时设定了现实的期望：它可能会失败。它第一次就成功了，Ricky 称这是幸运的。

Q成为领导者有没有成长的阵痛？

有。把项目的想法交给初级工程师，让他对实验能否成功感到焦虑；有些没有成功。他不得不习惯拥有一个想法的组合，而不是期望每一个都行得通。相对不错的成功率、指导，以及对他人项目的积极影响，支撑了这个论证，而信心则通过练习逐渐形成。

Q你有没有觉得，在等 Staff 时被卡住了？

他不是希望它来得更早，而是有时希望这个机会来得更晚。资深级别提供了更多休息和个人活动的灵活性，而更大范围的项目带来了会议和更死板的日程。他建议在断定这种交换是否值得之前，先看看身边 Staff 工程师实际的日历和工作。

Q你的资深级别和 Staff 级别的工作，最大的差别是什么？

在资深级别，他了解并拥有一个领域，并在其中交付项目。朝着 Staff，他挑战这个领域的边界，质疑既定的方向，并引导跨团队和职能的重要决策。有些改变，需要得到资深领导层的认同。了解一个领域，成了一个平台，用来塑造它该去往何处，而不只是在其内部有效地运作。

Q你是怎样找到 Staff 的锚点项目的？

深入的熟悉，让他质疑那些已不再说得通的做法。在一个例子里，既有的用户研究支持一个结论，但产品实验却与之相矛盾。他推动了这样的证据：另一个方向可能产生更大的影响。他没有披露具体的产品决策，所以教训仍然是审视假设、调和相互冲突的证据，而不是一种可复制的广告策略。

Q你是怎样影响其他团队和合作伙伴的？

他已经建立起一种善于发现有影响力的项目的声誉。他分享想法，在不试图取代别人的前提下协作，并把提案变成成功上线的项目。人际关系和反复取得的结果，让他的判断有了分量。

Q你为什么想尝试管理？

他本来就喜欢帮助同事成长、为他们寻找项目，并看着他们成功。在他表达了这种兴趣之后，出现了一个正式的管理机会，团队也支持它。从培养他人中得到成就感，是主要的动机。

Q从个人贡献者的领导，到管理，最大的变化是什么？

技术领导，提供了帮助人们成功的那些令人愉快的元素。正式的管理，增加了艰难的绩效反馈、写评审，以及校准的开销。同时，看到一位真正的下属被晋升，感觉格外有成就感，因为他对支持这种成长直接负责。

Q你后悔成为经理吗？

他主要希望这件事发生得更晚一些。在一个有大约二十位新员工的不寻常时期，他在非正式地帮助其中许多人；成为四个人的正式经理，缩小了这份责任，也让他腾出了一些时间。尽管如此，他仍然希望多享受几年资深级别的灵活性和较低的压力。

他现在更清楚地理解了更高层级的工作意味着什么：影响力的很大一部分，是通过别人实现的，所以无论是个人贡献者还是经理，会议都会增加。朝九晚五的日历，仍然可能是高度投入的一天，在午休或去健身房上几乎没有自主权。Ryan 补充说，白天零碎的会议，把他自己的技术工作，推到了达到 Staff 之后的晚上。应当对照头衔的日常体验，来评估它的吸引力。

QStaff 的晋升，与之前的申请有什么不同？

尽管持续获得最高评级，他又一次感到不确定。从资深到 Staff，可能感觉像换工作：作为一位影响力很高的出色资深工程师，并不自动证明你为更广泛的角色做好了准备。一位支持他的经理，以及第一次提交就成功，让这个结果成为幸运。

Q你能重复那条职业路径吗？还是说，运气解释了其中很大一部分？

他受益于喜欢被分配到的团队、组织的稳定，以及能够支持他的经理。重组、不合适，或者经理缺席，都可能延迟本来很好的工作。他把“机会出现”的机缘，与“准备好去利用它”区分开来。努力对第二项有帮助；对第一项则没有完全的控制力。

Q为什么在谷歌待了七年？

他定期重新评估，自己是否喜欢这份工作，以及团队是否仍然提供他想要的：成长、出差，以及足够有趣的工作。留下来是一个主动的决定，并不能证明他从没考虑过其他选择。他也承认存在幸存者偏差：没有得到可比的成长或契合的人，可能有充分的理由离开。

Ryan 描述了留在一个健康环境里的累积优势：人际关系、代码知识和组织背景，可以从一个领域的专长，扩展到许多个领域。这种势头，可以带来异常快速的成长，而换雇主则可以提供其他好处。他们并不把这个选择，简化为一条关于跳槽的普遍规则。

Q你会给刚毕业的自己什么建议？

更信任自己的判断，更早地尝试突破边界的想法。焦虑让他推迟了后来成功推行的想法。他相信，更早的信心，可以减少压力，并带来更多实验，尽管他的信心是通过结果和良好的反馈，逐渐形成的。

Q微软的级别体系是怎样运作的？级别从 59 往上，每个头衔大约对应两个级别。

Fowler 说，他无法解释为什么编号从 59 开始，并猜测较低的级别涵盖非工程类岗位。大学毕业生通常从 59 或 60 起步，取决于实习了几次、表现得如何。Fowler 把入门级，等同于其他公司的 SDE I。

一个头衔对应大约两个级别的范围，所以头衔并不能说明一个人处于哪个级别。首席（Principal）是个例外，跨三个级别，Fowler 说这个范围如此之广，以至于一位从资深晋升来的新人，和一位任职已久的首席，共用同一个头衔。首席之上是合伙人（partner）级别，Fowler 说有三个档位，然后是技术院士（technical fellow）。

Q在 NuGet 之后，你的绩效评估是什么样的？当时你还不是资深工程师。

Fowler 的第一次晋升，是在加入大约八个月之后，在 NuGet 之前。因为他实习过两次，所以带着大量的微软经验入职。在被分配的工作之外，他读论坛，了解对微软产品的反馈，构建功能来回应，并把结果展示给产品经理、架构师和团队。回头看，他说这些人成了赞助人，并让他处在构建 NuGet 的位置上。

Fowler 称自己是“先写代码，后问问题”的人，并说代码就是货币：一个能运行的示例，胜过一份 PowerPoint 或一份文档。一位总监曾告诉他，会把人派去找 David 聊，因为 David 有能量。

Q当动力完全来自自己时，别人怎样在大公司里开始这样的项目？

Fowler 一句话的回答是：你可以直接去做，人们现在称之为主动性（agency）。他不建议把每个夜晚和周末都花在项目上，但早期，他的目标是在软件工程上变得更好，而途径，就是构建一切可能的东西：游戏、网站、多种软件。

第二个习惯，是在团队里找一位他想要其职业生涯的人。Fowler 把自己依附在架构师 David Ebbo 身上，后者的角色横跨几个领域，并具有前瞻性，他模仿他的行为，并在一段时间里，替 Ebbo 的想法编写代码，这变成了独立去做。然后，他构建原型，并展示给一位倡导者，也就是架构师或产品经理，问它们是否有用。他说，他会构建一千样东西，也许其中一样会命中。

Q是什么促成了晋升首席？

Fowler 回忆起一位老板，在他升到资深时说，晋升会放慢。结果，晋升首席的那一跃很大。在 SignalR 之外，他构建了 Kudu，这是一个早期的 Azure 工具，让人们可以像 Heroku 和 AppHarbor 那样，推送代码并立即部署应用。然后，一位总监把他拉进了一个新项目，后来成了跨平台的 .NET Core。

Fowler 当时是资深工程师，他和另一位首席工程师，被选为架构师，负责大约 30 位工程师，拥有充分的自主权，他称这既令人惊叹又令人害怕。起初，他试图对每一处改动做代码评审，一年之内就累垮了，不得不学会信任别人，并把紧急与不紧急区分开来。同一年，他有了第一个孩子，并被晋升为首席。

Q在微软，架构师这个角色意味着什么？

Fowler 说，它是一个半正式的角色，向首席的中间档位开放。他刚加入时，看到了一位首席软件架构师，并决定那就是他想要的角色。他把它描述为广度胜过深度：监督整个系统的设计。顶层的其他原型，包括一位构建了大量代码的超级程序员，深度的专家，比如一位研究 .NET 垃圾回收器的顶尖垃圾回收专家，以及监督一个影响巨大的产品领域的人。

作为 ASP.NET Core 的架构师，他监督 Web 框架、Web 服务器，以及包的发布方式，审核那些可能持续 20 年的决定。他之前没有做过这个，是通过跟随做过的导师学来的。

Q作为杰出工程师，你花在写代码上的时间占比发生了怎样的变化？

Fowler 说，这个角色也许不再奖励每天写代码，但出于私心，他每天都写，并且目前在一个涉及 Aspire 的项目上，提交了很多拉取请求。他不想成为一个不了解代码、只下达指示然后消失的架构师。他想成为团队里的同伴，面对构建和测试。

Q晋升为杰出工程师的背后有什么故事？

Fowler 称这是他经历过的最疯狂的晋升。杰出工程师是合伙人级别里的最后一个级别，它通过一个正式的流程，而不是年度评估：由一组技术领导者对候选人进行同行评审。Python 的创造者 Guido van Rossum 与他处于同一级别，而 Fowler 称自己有最强烈的冒名顶替综合征。他还觉得自己对这个角色来说太年轻了，不过这并没有对他不利。

Fowler 说，早期的工作起了作用，因为这个角色需要一份作品集和过往记录，而不是一个好的年份。把他从首席晋升为合伙人的邮件，引用了 .NET Core（那时已有大约七年），他还曾作为架构师，帮助许多团队在内部采用新的 .NET。NuGet 和 SignalR，被视为他所帮助构建的东西，如何影响行业和公司的信号。他说，是院士们来决定。

Q最后一个级别，技术院士，是什么样子的？

Fowler 说，处在那个级别的人是各有不同路径的“独角兽”，所以有用的做法是寻找影响力的替代指标，而不是照搬谁。一位院士需要有全行业范围的影响力。他的例子：Anders Hejlsberg，他部门里的人都崇拜他，做出了 Turbo Pascal、Delphi、C# 和 TypeScript。Dave Cutler，Fowler 说他构建了 Windows NT、Azure 操作系统和 Xbox 虚拟机监控程序，是唯一的资深技术院士，Fowler 说这个头衔就是他自己的。

Fowler 补充说，微软最近聘请了一位发明了 RSS 的院士，并说一位队友曾经是蒂姆·伯纳斯-李（Tim Berners-Lee）的实习生，并且名列 HTTP 规范。这些是 Fowler 自己的说法，没有对照其他来源核实。

Q那位导师说了什么，让你产生了不同？

Fowler 说，许多职业建议很含糊，比如告诉人去做一个超有影响力的项目，而 Snover 则很直接。他建议去找做决定的人，包括 CTO，问这个角色需要什么。Fowler 觉得这很刺耳，因为没有人曾告诉他去问源头，但非常有帮助，因为它让他看到自己该做什么、不该做什么。

第二位导师，在 Fowler 收到经理和同事给他的一份反馈材料之后提供了帮助，上面列出了优势、弱点和压力下的行为。他的第一反应，是修补每一个弱点。导师说，要放大他的长处，因为没有人是因为平庸而被晋升到这些角色的。大约五年前，这改变了 Fowler 的工作方式。他现在围绕自己的短板来组建团队：他不安排会议，也不负责每一份发布清单，并确保有擅长这个的人来做。主持人把它比作幂律，Fowler 表示同意。

Q你敬佩哪些工程师？是什么让他们令人印象深刻？

Fowler 的团队里，有大约另外五位合伙人级别的工程师，在公司都超过 20 年，每一位都因不同的原因而出色：一位垃圾回收器专家，一位他说是真正的“10 倍工程师”的超级程序员，一位似乎对 C、编译器和操作系统里晦涩细节无所不知的人，还有其他人，对该构建什么有敏锐的眼光。

在 C# 语言设计评审团队里，Fowler 与 Hejlsberg 坐在一起，他说 Hejlsberg 的反馈从不居高临下，并始终务实，尽管 Hejlsberg 提交的代码，看起来像是在发明没人见过的理论。Fowler 还提到 Azure 的 CTO Mark Russinovich，他仍然写代码，最近还发邮件，谈到他写的一项性能改进。当资深工程师仍然写代码时，Fowler 会受到鼓舞。

他警告了会议的陷阱。成为合伙人之后，他整天开会，感到难过。一位导师告诉他，个人贡献者需要时间来思考和构建，并要每周至少留出八个小时。他花了一阵子，才学会拒绝会议。

Q你在推特上说，当被晋升为资深工程师时，你觉得别人更聪明，应该排在你前面。你从中得到了什么？

Fowler 担心自己被快速晋升得太早。他的团队里有四位来自麻省理工学院的人和两位来自卡内基梅隆大学的人，而他上的是佛罗里达理工学院，所以他靠非常努力地工作，来应对冒名顶替综合征。

这次晋升让他认识到，影响力不在于是否最聪明，而在于工作是否处于业务的最前沿，就像 NuGet 和 SignalR 那样。他一直觉得自己需要在某些技术上更深入，现在则会问，这是为了你自己，还是为了你的职业。他说，一位工程师不需要知道 TCP/IP 是怎么运作的，才被晋升为资深。这帮助他把“聪明”与“产生影响”分开。

同事们为他高兴，至少表面上是这样。当他问起其他快速晋升的人时，被告知每个人都知道那会发生，他补充说，你永远不知道自己属于哪一类。

Q你的一条大公司建议，是在换岗之前先问问上一次重组是什么时候。这背后的想法是什么？

Fowler 称大公司是机器，并回忆起听说过（也许是半开玩笑）高管们靠重组来表现动作。重组总是要来或刚刚发生，所以要了解上一次：领导是谁，是什么触发了它，组织将走向何方。他说，因为微软太大了，每一个新的组织，实际上都是一家新公司。那条推文大概是在一位连续被重组好几次的被指导者之后写的，或者是发生在他自己身上的事。

Q自从实习以来，是什么让你在微软待了这么久？

Fowler 把自己描述为千禧一代的一员，打破了婴儿潮一代父母“永远待在一个地方”的习惯，并说许多跳槽的朋友因此得到了不错的报酬。他最接近离开的一次，是他在资深级别时，一位已去了上市前的 Twitter 的老板，请他去那里面试。他面试了 Twitter 和 GitHub，两份录用通知都拿到了，经过反复考虑，留了下来。他补充说，Twitter 上市的那天早上，立刻带来了一种持续约一周的沮丧。

微软的还价不错，但不是主要原因。一位执行副总裁告诉他，他五年后会成为杰出工程师，Fowler 说这说得太满了。更重要的是，他构建了有影响力的、无须许可的东西，也获得了自主权，而离开意味着从头开始。人们忽略了自己已经建立起来的人脉和过往记录，而人和薪酬同样重要：不只是好的工程师，还有好相处的人。

他留下来，还因为大约每两年，他都能被设计成去做一件新的事，这让他不觉得需要去别处。

Q当萨提亚·纳德拉（Satya Nadella）成为 CEO 时，你有没有注意到内部文化发生了变化？

Fowler 说，这种变化是巨大的，但很难看出从史蒂夫·鲍尔默（Steve Ballmer）时代跳变过来的那一步，因为他亲身经历了，而且是逐渐发生的。一个重要的方面是，从历史上看，两支团队可以朝着同一个终态努力，其中一支会赢。在纳德拉治下，重点转向了协作，而不是抢先。他看到有的团队，在还不知道问题是什么之前，就在构建解决方案，不过不是在他自己的团队里。

他描述了会议、邮件和对远程友好度方面的变化。他记得，看到有人在 Teams 会议里举手，感到惊讶，因为他在一种“等一个停顿，然后开口”的文化里长大。早期的会议，常常是“薪酬最高的人的意见说了算”，一位大声的资深者，可能让别人觉得不安全，不敢发言。职业早期，他见过人们互相叫喊，并想知道自己是否也得喊。现在，领导者以身作则，比如邀请安静的人分享他们的观点。

协作也成了评审的一部分：回避其他团队工作的、或者克隆它的工程师，会被扣分。主持人把这总结为由绩效激励和自上而下的信息驱动的变化，而 Fowler 补充了领导者以身作则的行为。主持人回忆起 XKCD 的那幅漫画，把微软画成人们互相用枪指着对方。Fowler 说，真正的转变，是从“用枪指着”变成了冷漠，团队互不干涉，然后再到被奖励的协作。

Q如果你能在大学毕业、进入这个行业时给自己建议，你会说什么？

Fowler 的回答是谈判薪水。他在接第一份工作时，不知道这是可能的。应届毕业生应该拿到多份录用通知，并把数字往上推。来自巴巴多斯（Barbados）、对自己见过的最高薪水心怀感激的他，看到朋友们拒绝录用通知，并说要先看看谷歌或 Facebook，感到震惊。此后他参加过实习生的招聘委员会，发现看到一位候选人很好地把录用条件往上提，令人印象深刻。

Q是什么样的工作和团队背景，支撑了你异乎寻常的快速成长？

Simon 与同一支团队和同一位经理共事了大约五年半。在他对 Meta 的经验里，这种连续性并不寻常，但团队的职责发生了很大的变化。它做的是广告支付，起初改进支付体验和收入，然后支持一次大型的基础设施迁移，后来又回到产品工作。

产品背景很重要。收入提供了一个相对直接的影响力衡量，而当地的行为，则创造了具体要解决的问题：比如在泰国，人们通过 Messenger 购买，并交换银行小票作为付款凭证。所以他的职业故事，结合了组织上的连续性，与不断变化的技术和产品职责范围，而不是多年重复同一份工作。

Q你是怎样在入职的第一个半年里，赢得 IC3 到 IC4 的晋升的？

他之前在 Meta 的实习，降低了他学习定制内部工具的曲线。他估计，对 Phabricator 和任务系统等工具的熟悉，节省了四到八周。在全职加入之前，他还通过小项目探索过各种技术，所以新兵训练营的任务更容易，他还能帮助其他新人。

他是一支新的广告支付团队里的第二位工程师。这让他有了大量接触技术经理和有影响力项目的机会。Simon 说，他交付的项目，产生的收入，超过了团队半年收入目标的三倍。行为上的区别，在于对完整项目的主人翁责任：完成任务，寻找下一个相关的机会，调查令人失望的结果，把工作推到结论，同时在需要时求助。据他讲述，晋升是随着已经展现出的下一级别的行为而来的，而不是靠有前景的潜力。

Q为什么加入一支很小的产品团队？技术上的指导来自哪里？

他原本预期会加入一支基础设施团队，因为 C++ 基础设施是他的兴趣，也是他实习的背景。然而在新兵训练营期间，他遇到的第一位经理，把职业成长与收入影响联系起来，并为广告支付提出了有说服力的理由。这支团队也让人觉得很友好。

这位经理最近刚从 IC6 工程师转为管理，既能指导技术决策，也能指导产品实验。Simon 在第一个半年里做了 20 个实验，而整个更大的组织大约做了 50 个。他把这种速度的很大一部分，归功于直接的、有技术依据的辅导。

Q是什么带来了 IC4 的第一个“重新定义期望”的评级？

Simon 说，影响力是主要的推动因素。他的项目，超过了一个已经很有雄心的、以数千万美元计的团队收入目标。招聘和带新工程师也有贡献，随着团队的壮大，他把评审扩展到了 JavaScript、Hack、Android 和 iOS。

收入结果在一开始并不明显。一位优秀的数据科学家怀疑有机会，但最初的几个实验都是中性的。在其中一个里，付款失败的通知，并没有像预期那样帮助广告主；研究这个结果，带来了更好的定向和设计，之后这个项目贡献了他那半年影响力的大约五分之一。在另一个里，一个每日运行的脚本，改变了广告主的设置，但实验日志记录失败了。他读了代码，联系了实验团队，并与数据科学家一起弄清了失败的原因。重要的模式，是持续地调查，而不是宣布第一个中性的结果为定论。

他的代码评审，也是为了培养人。这需要校准：有些反馈说他的评审过于强势，而另一些反馈则说，这些评审让同事成为更好的工程师。他并没有把有益的评审，描述成从一开始就毫不费力或完美平衡。

Q你预期到这些早期的评级了吗？你是怎样解读它们的？

他对评级的标尺缺乏背景。作为刚从瑞典来的新人，他没有理解限制性股票会成为薪酬的重要组成部分，而且他也没有密切预测评级。第一次晋升，是通过他的经理那个惯例才得知的：带新晋升的下属去吃晚饭。

他对后来的最高评级感到高兴，但这么早就收到出色的结果，使得很难判断这些结果有多不寻常。他之前唯一的对照，是一次评级为“大大超出”的晋升。他认识另一个拿到最高评级的人，这也让它显得没那么稀有。他的叙述提醒，不要把一个人的早期期望，当作更广泛分布的可靠指南。

Q最高的绩效评级，怎么会没有伴随晋升？

在 Simon 的解释里，评级主要认可的是他达成了什么，而晋升问的是他是怎样达成的。IC4 的工作，意味着推动自己的项目。IC5 需要对他人及其项目承担更广泛的责任。他在帮助新人入职，却还没有为他们的成功负责，所以非常大的个人项目影响，本身并不能证明 IC5 的角色。

他和主持人强调，评级和晋升是相关的，但并不是一一对应的。重复大量当前级别的工作，可以产生出色的评级，却让下一级别行为上的差距没有弥合。

Q在新冠疫情期间评审暂停、以及你最终晋升 IC5 期间，发生了什么？

第一个新冠半年，用的是注释，而不是正常的评级，也不包括晋升。Simon 把自己的注释，理解为表明表现大大高于期望。他感到失望，因为他觉得自己在轨道上；当时，一个半年，占他职业生涯的很大一部分，尽管他现在认识到，职业生涯要长得多。

在下一个半年里，他又得到了一个“重新定义期望”的评级，以及从 IC4 到 IC5 的晋升。他对这个结果作了限定：评级被稍微上调，以认可上一个半年的工作，而他未经调整的结果，可能接近“大大超出”的边界。他并不声称，所有优秀的人都被自动提到了最高评级。

实质的变化，是带领一个大约四人的小组（pod），在一个没有划定范围的产品空间里，从最初的想法到完成项目。产品本身没有像期望的那样成功，但处理工作、人员，以及总监级别的升级上报，展现了更广泛的主人翁责任和沟通。所以晋升反映的是已改变的职责，即使产品结果并不完美。

Q为什么团队信任你在还是 IC4 时，就带领一个小组？

Simon 看到两个基础：强大的技术能力，以及对人的成长的兴趣。他在瑞典从高中起就学习计算机，并喜欢在各个平台上解决难题。他还在乎同事是否成功，帮助过人们进步，并在全面负责一个小组之前，已经做过一些冲刺规划。

他把排定工作的优先级，与拥有其结果区分开来。之前，他可以帮助规划任务，却不对项目或工程师的成功负责；带领小组的任务，增加了这份责任。

Q从 IC5 到 IC6，发生了什么变化？

他用两个半年赢得了下一次晋升。首先，一个小组变成了两个小组，大约七个人，迫使他把冲刺规划和招聘的跟进授权出去。他辅导新的小组负责人，以及做联络的同事，有时保留艰难的最初招聘对话，同时让别人在之后管理候选人。这些任务，也为接手的人创造了成长的机会。

他最初的授权有一个严重的缺口：他相信工作会成功，却没有足够好地跟踪，然后在半年快结束时，发现进度落后了。他后来学会了拉远视角，设定里程碑和目标，更早地发现停滞的项目或吃力的人，并针对具体的缺口介入，而不是等到出现危机。

他后来的职责范围，包括一支八人的团队，外加一个涉及大约 13 人的独立项目。这检验了他能否把路线图和人员领导，与深入的技术贡献结合起来。跨客户端和后端的详细评审，帮助他理解系统之间的交互，并发现不兼容的实现。在一个支付里程碑附近，他还调试了一条棘手的路径，横跨 Android 或 iOS、Instagram 的服务器、Meta 的主后端、C++ 的支付基础设施，以及一家外部的支付合作伙伴。他把功劳同时归于广泛的协调，以及深入一个困难技术问题的能力。

Q达到 IC6 之后，你是怎样决定是否追求管理的？

他仍然有野心，但管理带来了一个关于身份认同的顾虑：他看重做一位有能力的工程师，并担心离开技术工作多年之后，会让自己觉得没那么有用。不过这个机会，伴随着他多年的经理的支持而来。两人都已搬到伦敦，而他的经理领导着两支团队，直接下属太多。Simon 已经在技术上领导着其中一支团队。

他选择尝试管理，是因为在一位他钦佩的经理手下学习，似乎异乎寻常地有利。他希望成为一位类似的经理，而不是把这次转变，看作必然的下一次晋升。

Q是什么让那位经理格外有帮助？

Simon 强调的是对人、对项目、对影响力的关心；对 Meta 流程的熟悉；以及对快速的工程成长的亲身理解。这位经理在产品方向上也很强，设定清晰的路线图，并向上向下沟通。这让工程师们能够执行，同时学会如何对数据、增长和产品选择进行推理。

书面沟通是另一个重大的教训。Simon 相信，人们可以做出出色的工作，却因为只解释了自己做了什么，而没有解释它为什么重要、学到了什么，或公司得到了什么，而限制了自己的职业。一篇清晰的内部帖子，可以触达成千上万的人，并留待未来的决定使用。

Q什么让一份项目更新有效？

假定读者可能只花五到十秒。Simon 建议写一份真正简短的摘要，在任何“查看更多”展开之前就可见，并在有的时候附上有意义的数字。读者应当能够立刻认出结果及其重要性。

他围绕背景、影响和下一步来组织前面的部分，然后为专家提供技术细节。大多数广大的读者不会知道确切的子系统，但他们仍然可以关心成果和原因。主持人补充说，工程师常常以只有一两位合作者能懂的代码层面的调查开头；状态、指标的变化，以及为什么听众应该关心，先说这些更有用。

Q管理这次尝试，让你对技术工作和角色适配学到了什么？

他做管理不到一年，时间太短，无法知道自己的技术能力是否真的会退化。更直接的问题，是他很难停止做技术工作。下属请他退后；当他看到缺口时，他旧日技术负责人的本能，让他想去填补它。他承认，在回到个人贡献者之前，没有完全纠正这一点。

当时的情况也异乎寻常地困难。他的直属经理出了事故，缺席了几个月，他的隔级经理在休陪产假，而最近的可用领导，是一位刚结束长期病假回来、位于加州的总监。Simon 在伦敦，所以背景和时区方面的支持都很薄弱。他还不得不离开伦敦，并试图在一支小团队里，支持两位想要从 IC5 晋升到 IC6 的工程师。他相信自己承诺得过多：一位可以接手他以前的技术领导角色，但要为两个人找到同等的职责范围很难。

倦怠，以及支持网络的丧失，促成了转回去。当一位总监问他是否想回到个人贡献者的工作时，答案立刻感觉对了。他对以后再做管理保持开放。他的结论有所限定：更好的环境，也许能让他在管理岗位上待得更久，尽管他怀疑，自己可能仍然会回到工程。

Q你拿到的那份酌情发放的额外股权是什么？

Simon 把额外的股权，描述为由总监酌情授予的额外限制性股票单位。他拿到过两次：一次在 IC5 到 IC6 晋升前后，另一次是大约一年后，他转入管理的时候。第一次是通过一次意料之外的、15 分钟的总监会面到来的。他在薪酬群组的帖子里看到过这类授予，但认识到那些帖子偏向于异常好的结果。

他推测，留任和原先较低的应届毕业生股票授予，可能促成了第一次的奖励；他不知道决策者完整的理由。他把第二次，与在伦敦比预期更快地成功交付一款优先级产品联系起来。两次奖励合起来，实质性地提高了他的薪酬。当时很难作市场对比，因为 Meta 的股价下跌了。

Q根据你作为实习生、实习生经理和实习生总监的经验，什么有助于实习生成功？

他自己差点没拿到转正录用，后来管理过两位起点非常不同的实习生，并担任过实习生总监，监督大约十位实习生经理。这个总监的角色，涉及检查项目计划，并在三周时的上手情况、中期进展和最终评估时进行评审。

他把项目的完成和速度看作核心，并对范围划定不当的任务设置保障。一个常见的问题，是早期没有问足够多的问题。头几周，期望较低，询问基础的问题是合适的；拖到第六周，同样的缺口，后果就严重得多。他告诉实习生和应届毕业生，当一个小问题耗费了大约 30 到 60 分钟以上时，就来问他，而不要为了一个有经验的同事很快就能解决的问题，反复损失好几个小时。

同伴和经理同样重要。当一个人无法回答所有问题时，共享的群聊可以分散支持。同伴也提供重要的评估证据；了解实习生的项目和行为，有助于他们给出实质性的反馈，而不是迫使评审者去重构发生了什么。

Q什么样的工作量让你觉得是可持续的？动力如何影响它？

他估计平均每周大约 50 个小时，因为加州的会议和他的晨间习惯而有所变化。他喜欢这份工作和同事，但注意到，当他对这个产品领域的兴趣消退时，同样的工时开始让人觉得是一种苦熬。

经过反思，他转到了一支基础设施团队，并重新找回了热情，产出质量也更好。他和主持人，把工作带来的负担感，与兴趣和动力联系起来，而不仅仅是工时。这是他们的经验，并不是说，享受工作就消除了设定限度的需要。

Q回头看，是什么最能解释你的职业成长？

Simon 的核心主题是不断扩大主人翁责任。早期，它意味着确保一项具体的任务成功；后来，它意味着拥有一支团队的成功。好奇心是其中不可或缺的一部分：当另一个系统阻挡了你，就去查看它的代码和历史，理解为什么做出某个决定，并带来一个经过研究的问题或提案，而不是干等着。

他把 Meta 的那句话，“没有什么是别人的问题”，解读为调查的许可，而不是忽视别人的借口。跨职能的主人翁责任，需要同理心：了解合作方的目标和激励，包括你提议的改进，是否会损害他们被评估所依据的指标。技术调查和理解人，都有助于扫清工作的障碍。

Q工程职业成长中，有多少是技术技能，有多少是其他行为？

他没有给出数字上的划分。他相信，只要一位工程师能把工作高质量地执行，与设计师合作，使用数据，并有效地协作，那么扎实的技术基础，就可以支撑相当大的成功，包括 IC5。解决任何技术问题的非凡能力，并不是他对那个级别的最低要求。

他认为，人际技能对于赢得信任和成长机会尤其重要。他也对此作了限定：在某些情况下，非凡的技术才华，可以抵消其他的弱点。他的看法，是对他在 Meta 所见的一条路径的描述，而不是对所有角色的普遍规则。

Q为什么你到目前为止，整个职业生涯都留在 Meta？

人，以及灵活性，一直在满足他的需求。他最初的团队，从两位工程师增长到大约 16 位后才拆分，因为他帮助招聘了其中许多人，所以这个年轻而互相支持的群体，让人感觉很亲近。他继续看重同事们的同理心和技术能力。

内部流动，让他得以在好几个地方生活和工作，包括加州、伦敦和纽约，并在最近转入了一项重新点燃他兴趣的工作。当他的动力下降时，他确实考虑过离开，然后选择给内部调动一个机会。他承认，有些经历在 Meta 找不到，他的偏好也可能改变；他只是还没有到那一步。

Q当你作为应届毕业生入职时，你会对自己说什么？

及早问足够的问题，让自己变得有产出，然后继续探究系统为什么是现在这样运作的。要保持好奇，担起主人翁责任，并避免把每一个现有的约束都当作永久的。在一个大型的代码库里，过去的决定和被放弃的实验，可能已经不再说得通；理解它们的历史，可以揭示有用的清理，或绕过阻碍的办法。

他把这条建议，与对时间的意识结合起来。新工程师仍然需要速度，不应该无限期地消失在调查里。一旦基本的产出建立起来，好奇心就变得更有价值。

Q为什么专精于前端工程？

Marius 描述了自己对 Web 长久以来的热情，可以追溯到学校里的 HTML 课，以及他作为圣诞礼物要来的一本 CSS 书。他有意地寻找能让他构建 Web 应用的工作，包括在学习计算机科学期间做的外包工作。

这项专长，是对自己想做的工作的积极选择，而不仅仅是被分配到的第一项技术。这种偏好，后来帮助他判断，哪些机会和团队适合他的职业。

Q为什么出色的绩效评级，没有立即带来从 IC4 到 IC5 的晋升？

据他讲述，有一个行为上的差距，阻碍了这次晋升：跨职能协作。对自己想法的强烈信念，有时给人太过坚持或强势的印象。为一个提案倡导是恰当的，但他需要认识到，持续施压何时会适得其反。

他把对已交付影响的评级，与晋升准备度区分开来。一个人可以交付很多，同时仍然缺少下一级别所期望的一种行为。他的晋升，在他针对反馈做出改进之后，又遇到了疫情初期全公司范围的暂停。他把这些描述为不同的原因，而他最终的晋升，发生在 2020 年底。

Q你是怎样处理晋升被推迟的沮丧的？

他承认感到沮丧，尤其是在同事们反映有了明显的改善，而一项外部的公司决定仍然阻挡了结果之后。他提醒自己，职业生涯很长，半年的延迟，在这个跨度里意义有限。

他继续成长，并承担超出当前头衔的工作。在一个滞后的晋升体系里，拒绝在头衔到来之前展现下一级别的行为，本身就违背了这个流程的目的。工作和学习，即使在文书滞后时也可以继续，并最终得到了认可。

Q是什么工作，带来了“重新定义期望”的评级和 IC5 晋升？

作为 IC4，他在一个被认为是 IC6 职责范围的大型 Web 项目中，担任了领导角色。十多位工程师和几个合作职能参与其中。在疫情期间雄心勃勃的时间表下交付它，需要的远不止编码：解读产品的模糊性，划分工作流，协调人员，召开会议并传达进展。

运营上的卓越也很重要。一次搞坏系统的大规模上线，并不会仅仅因为提交了很多改动，就变成成功。这个项目没有出现重大问题就落地了，并关注了发布的规范。

Marius 并不声称知道校准讨论的每一个细节。他的解读是，超出他被分配职责范围两个级别的工作，让这个异常强的评级更容易解释。评级需要一条清晰的阐述：从预期的工作，到额外的贡献，而不是一句无法解释的“卓越”断言。

Q一位 IC4，是怎样被信任去做一个 IC6 规模的项目的？

这个机会，是通过一次人员安排上的多米诺效应出现的。一位资深工程师在休陪产假，而一项重大的优先事项，改变了团队的工作。另一位工程师填补了那个空缺，而 Marius 接手了一个本来可能交给更资深的人的项目。

时机上有运气的成分，但准备工作，塑造了谁会被考虑。他已经确立了自己作为 Web 专家的地位，想对那个平台负责，并有出色交付的记录。因此，一个相关的机会，是一个合理的匹配。他称这是增加“运气的表面积”，同时认识到，想要这个项目，并不保证就能得到它。

Q你一直对这项工作有雄心吗？

是的。理解 JavaScript 里的条件和循环，给了他一种早期的主动性：他可以让机器按自己选择的方式做事。从哲学上讲，Web 也吸引他，它是相互连接的文档，让知识广泛可得。

他后来的雄心，源自这种内在的兴趣，而不仅仅是晋升阶梯。这个区别，有助于解释他持续的努力，以及他对特定类型工程的偏好。

Q是什么带来了下一个“重新定义期望”的评级和 IC6 晋升？

他领导了另一个有时间压力的 Web 项目，它促成了一项更大投入的其他部分。错过它的硬性截止日期，会阻碍它们的影响。无法争取更多时间，其他人也已经被分配到重要的工作上，所以他必须用手头的团队，管理范围和质量。

他的偏好，是缩小范围，而不是轻易牺牲性能、可靠性和设计工艺。一个更小但做得好的成果，比一个宽泛但糟糕的实现更好。有些让步可能是必要的，但他希望它们是经过深思熟虑后做出的。

产品管理方面的支持有限，一些重要的问题仍未解决。他因为以产品工程混合体的身份运作而得到认可：厘清需要构建什么，让这个决定与产品和工程领导层对齐，界定成功，排定工作的顺序，然后大量参与实现。他把早期的模糊性，比作在工作变得可操作之前，探索一张被雾覆盖的地图。

Q在一切顺利的时候，为什么转去 Instagram Web？

他之前所在组织的优先事项，偏离了他想追求的工作。他已经认识到，Web 工程和产品质量（性能、可靠性和设计工艺）格外令人满足。在一个不那么契合的方向上保持成功，不一定是正确的长期选择。

Instagram Web 团队最近刚刚迁移了技术栈，需要高质量的工作。这个空缺与他的经验和兴趣相匹配。他从通知这一界面开始，它需要现代化，并与原生应用对齐，然后把大部分时间花在了产品基础设施上。

这一层，介于可见的产品功能与更深层的基础设施之间：代码结构、保障措施、测试和架构，帮助其他工程师有信心地迭代。随着对他自己影响力的期望不断提高，它提供了越来越大的杠杆。

Q你说的“工程杠杆”是什么意思？

杠杆，意味着塑造默认值和工具，让其他有善意的工程师无需每一个决定都亲自请教专家，也能成功。框架把他们引向一个好的结果。Marius 用前端可靠性和 React 的错误边界（error boundary）来说明，它把一次渲染故障，限制在界面的一部分。

增加一个缺失的边界，只修好一个位置。系统地审查整个网站，则解决了一个更广泛的问题。写一份指南，解释如何触发故障，以及如何区分主要、次要和第三级的内容，让其他团队能够自己应用这种方法。增加 lint 规则，可以让编辑器在改动提交之前，就对一个已知的不安全模式发出警告。

他用这个顺序来说明影响力的递增，同时把这些级别的标签，视为自己的实用解读，而不是一个官方的公式。更全面的解决方案，在他转去做性能或其他问题之后，仍然继续起作用。他无法亲自检查公司里每一款 Web 产品，所以方向和工具，延伸了他的贡献。

Q你是怎样开始做 Threads Web 的？

他的经理为他引荐了一个小型的、起初保密的项目。Marius 与它的招聘经理讨论了所需的 Web 工作，并成了大约头六到八周里唯一的 Web 工程师。职责范围起初有限，后来扩大了。

他珍视这个难得的机会，能在一家大公司里，从头开始帮助推出一款新应用。后来其他工程师加入了，所以成为第一个，并不等于独自构建了最终的整个产品。

Q是什么让 Threads 的工作成为一个令人信服的 IC7 晋升论证？

这项工作很紧张，但它的影响力故事很清晰。Threads 需要一个 Web 端的存在。Marius 打下了它的基础，帮助壮大和组织了团队，领导了交付，并写了大量的代码。职责范围从未登录状态下的浏览和分享，扩展到一个已登录的客户端，带有信息流、通知、设置、搜索和发帖。

上线和反响，让结果可见。他说，这是一份异常容易写的自我评估，因为业务需求、他的职责和已交付的工作之间的联系很直接。这种清晰，并不意味着这个项目很容易，也不意味着他队友的贡献不重要。

归因也要求资深评审者理解，他的参与实质性地改变了结果。清晰的主人翁责任，以及对结果的责任，比孤立任务的数量，更有说服力地提供了这种联系。

Q拥有一次上线，实际上需要什么？

Marius 在上线之前，先思考各种失败模式，并倒推去防止它们。一个新的域名，会引出 DNS 和基础设施方面的问题；应该由合适的专家来核实配置，而不是团队简单地假定它能行。其他可预见的风险，同样值得这样处理。

并非每个问题都能被预料到。运营上的就绪，包括错误上报、QA、发布规范，以及响应迅速的反馈渠道，这样一个出乎意料的、特定于某个浏览器的问题，才能被快速诊断。主人翁责任，涵盖的是这整套准备工作的结果，而不仅仅是写出这个功能。

Q作为直接负责人，是否意味着一切都要自己做？

不。他把产品划分成有意义的领域，由其他资深工程师负责。这些工程师对自己的领域负责，而他仍对整体的上线负责。授权一部分，并不允许整体的负责人，在产品失败时把责任推给那一部分。

困难的技能，是调整监督的程度。负责人应该给人们成长的空间，同时又不从工作中消失。他用驾驶教练作类比：在学员学习时，把手放在紧急控制装置附近，然后随着信任和能力的建立，逐渐增加自由度。这种关系，应该防止可避免的失败，又不把每一个决定都变成微观管理。

Q一位资深工程师，怎样在保持自己影响力的同时，分配职责范围？

Marius 赞成与人们的能力相匹配的合理的责任边界。一项“拔高”的任务，可以培养一个人；远远超出他们能力的工作，则可能让这个人和项目都注定失败。远远低于他们能力的工作，也可能是一种糟糕的匹配。

他并不指望资深 Staff 工程师写的每一处改动，都包含非凡的技术复杂度。有时，重要的贡献，是快速实现许多直截了当的部分，从而扫清一条关键工作流的阻碍。另一些时候，合适的角色，是协调跨团队或跨组织的工作。

价值，在于必要的结果，以及在达成它的过程中所扮演的角色。囤积工作，或者孤立地评判每一个 diff，都会错过让整体贡献变得重要的背景。他把快速编码和广泛协调，视为适用于不同情形的不同工具。

Q你正在考虑职业生涯的下一步是什么？

关于 IC8，他没有固定的答案。在这场访谈时，他已经从 Threads Web，转到了一个重要的 Instagram 服务端项目，有意地走出自己的前端舒适区，朝着更全栈的工作迈进。他觉得这既令人兴奋，又有一点令人生畏。

管理不是他偏好的方向，因为他喜欢深入的技术性个人贡献者工作。他希望自己的工作有意义、能带来学习，同时不假定下一个头衔必须是眼前的目标。他还推荐了《创：战纪》（Tron: Legacy）的原声带，作为专注写代码时的个人推荐。

Q当你达到 IC6 时，你是否立刻开始瞄准 IC7？

不像他达到 IC5 之后那样，立刻向前看。更资深的晋升，需要一个与这个级别相匹配的业务需求，也需要成功的执行。Threads Web 提供了一个契合这种形状的、恰逢其时的机会。

这个机会是必要条件，但不是充分条件：工作仍然必须落地。反过来，没有这样机会的工程师，即使有能力，也可能难以提出论证。所以他的故事，结合了交付、适配和时机，而不是把雄心单独当作解释。

Q更高级别的期望，有没有让你害怕过？

有。作为 IC4，他把 IC5 看作按他当时所理解的政策，最终被期望达到的目的地，对 IC6 感到忧虑，并且相信自己永远不想要 IC7。他的偏好随着成长而改变。即使后来，他也没有积极追求 IC8，因为这个角色需要契合，而且他不想失去太多自己喜欢的工作。

这段叙述提醒我们，一个人对下一个级别的看法，会随经验而改变。它并不规定要无限期地追求晋升，也没有确立适用于每个角色的当前公司政策。

Q你最异乎寻常的高编码产出是多少？

他回忆起，在 Threads 上线的那一年，有将近两千个 diff。这个数字显示出一段紧张的实现期，但他马上提醒，diff 的数量是可以被刷的，最多只是具有方向上的参考意义。

他认为，比如在一段时间里的三百次与四百次改动之间，没有有意义的自动区别：一个人可能只是把工作拆成了更小的提交。产出的数量，应当结合结果和背景来解读，而不是被转换成一个普遍的目标。

Q你会给刚进入这个行业的自己什么建议？

一切都会好的；不要增加不必要的压力。早期的雄心，让他每周发一篇博客，同时要兼顾学位、近乎全职的外包工作、朋友，以及一项要求很高的爱好。他有时在深夜写作，只是为了守住这个承诺。

他喜欢那项工作，学到了很多，并认为他公开的写作，帮助一位招聘人员找到了他。他不后悔。但他不再认为那种强度，是一种健康的默认做法，并会告诉年轻时的自己，现有的努力已经足够了。

他实践性的 Web 工作，也补充了大学的基础知识。理论给了他有用的概念，而多年构建应用，则提供了他每天使用的技术上的专长。教训是一种可持续的组合，而不是否定任何一种学习。

Q每位嘉宾，是靠什么项目走到 Staff 级别的？

Zach 是靠换公司晋升的。在 Netflix，每位工程师都有资深头衔，但 Zach 觉得，职责已经是 Staff 级别的了，后来 Airbnb 以 Staff 的级别聘用了 Zach。Zach 归功的项目，是 Netflix 的一个资产清单。Netflix 使用微服务，这给每个团队以主人翁责任，但也留下了成千上万个独立的应用，每个都可能有自己的漏洞。Zach 构建了一个图数据库，描述应用、代码库、数据集和员工，以及它们之间如何相互联系。这项工作花了大约两年。

Lee 也是以 Staff 级别被聘用的，而不是被晋升到那里。Lee 在加入 Meta 之前，在亚马逊管理人员大约三年。Lee 说，单靠技术工作是不够的。有些人指着一个自己独自交付的大型、复杂的项目，但 Staff 级别的准备度，还取决于他们是否规划了工作，把它拆成并行的工作流，并降低了风险，不把最难的部分留到最后。Lee 最难的技术项目，是一个自定义的类加载器，在谷歌支持之前，就让 Android 应用能使用多个可执行文件，这样亚马逊的视频应用（现在的 Prime Video）及其合并的应用，就不会碰到方法数的上限。Lee 不想让工程师为了适应一个技术限制，被迫写出糟糕的代码。

Ryan Peterman 描述了一个大型的效率项目，让 Instagram 的视频处理便宜了很多，有些基础编码便宜了 94%。Ryan 说，这个项目达到 Staff 级别，是因为 Ryan 创造了职责范围：Ryan 找到了问题，说服人们它值得做，获得认同，并带领执行。Ryan 只在风险最高的组件上亲自上手。好几位工程师做了大部分工作，而 Ryan 负责领导并评审代码。Ryan 强调，Staff 是最早把“影响别人”作为基本期望的级别之一，因为软件是协作性的。

Carly 说，这一步不只是技术上的才华。它归结为信任，以及成为别人所依赖的合作者。Carly 指出，一次向一位高管领导和 CTO 展示安全方面发现的报告。Carly 能够向不想坐在工程会议里的人，解释技术工作，并从那场会议上的一位领导那里，得到了一份工作邀请。这变成了一次内部调动，到了 Staff。Carly 说，这不是正常的路径。更宽泛的教训是，要知道你的数字，准备好向技术和非技术的听众陈述你的影响，并去做解决真正痛点的、大型的、跨业务的问题。决定晋升的人，往往同时属于这两类听众。

Rahul 提到在 Meta 的两个项目。一个是改进了产品调试的内部工具。Rahul 衡量过，它在一年里节省了数千个工程小时，而且其他工程师可以接入自己的调试工具，这让影响成倍放大。另一个是重新设计产品的通话架构，把它迁移到另一支团队的 API 集合上。Rahul 的教训是，要以“押注组合”的方式来思考。大科技公司有许多你控制不了的事情，所以把一个主要项目，与一个你能控制的较小项目配对，当一个被阻塞时就切换。两三个项目是现实的，不是十个。Rahul 补充说，公司也必须有足够的业务需求来支撑 Staff 级别的职责范围，所以有些人，仅仅通过换到一家需要自己技能的公司，就得到了晋升。

Q一位资深或 Staff 工程师，应该怎样在授权与亲自做之间取得平衡？（一位参会者 Brian 提问，Rahul 重新表述了这个问题。）

Zach 回忆起与一位 Airbnb 经理每周的对话，谈的是 Zach 在管理、授权和编码上是否做得够。Zach 喜欢整天写 Scala 代码，并说这样做有时对团队不利。Frank 与经理谈论时间是怎么花的，帮助 Zach 看到什么时候需要更多的领导。

Lee 说，每个人都应该了解自己的偏向。一位从管理岗位转来的工程师，可能在人员上花太多时间，而在降低技术风险上花得太少，而另一些人则偏向相反的方向。每周不需要五五开。Lee 还问，这位工程师是在身先士卒、找到路径并让别人沿着它走，还是在后面，只是给人们指出一个方向。答案因团队而异：同级组成的团队，不同于应届毕业生组成的团队。Lee 说，经理的意见在这里有帮助。经理可以指出，4% 的性能提升很好，但没人知道用了哪些工具，而如果这个人不在，也不会有任何东西被提交。在 Lee 看来，你怎样做事，与你做什么同样重要，而与初级工程师结对，能帮助他们理清脉络。

Carly 给出了经理的视角，以 Zach 为例。Carly 更希望 Zach 参与大项目的研究、设计和路线图，这样，一个有 Zach 那样深度的人，可以很快说出哪里会出问题，而其他人做深入的实现。当某件事非常复杂时，Zach 会介入。Carly 说，这种平衡很难把握，要在与经理的交谈中确定。

Lee 对此补充：最强大的工具之一，是在正确的时间问正确的问题。一位资深的人听到团队计划重新架构某样东西，可以说这不是正确的重点，现在可以先放在一个垫片层（shim）后面。这位资深者二十分钟的时间，可以节省两三个开发者年。Lee 说，人们的时间应该花在设计重要的地方，因为错过一次走廊里的谈话，代价可能很高。

QStaff 工程师在哪里找到、或者“编造”职责范围？

Lee 说，当你在自己的工作上比经理更强时，他们就看不到项目里的地雷或技术约束了。Lee 拒绝为了证明晋升而编造职责范围的想法，认为那是个糟糕的选择。工作是找出是什么在伤害团队、拖住它，提出来，并说服别人去修复。Lee 把这比作微积分是被发明的还是被发现的问题。Lee 说，大多数职责范围是被发现的：别人害怕的、看不到的、或者不认为有价值的工作，而你必须说服他们，它会加快接下来的三个项目，或者实现产品以前做不到的事情。它可能是通过翻看代码找到的，也可能是在有空缺的产品需求里找到的。

Lee 自己的习惯，是在没人愿意的时候举手。Lee 举了一个例子：一个没有人想碰的、陈旧而脆弱的系统。Lee 说，当有人提议把它关掉时，它可能其实创造着数亿美元的收入，所以值得进行渐进式的替换，比如“绞杀者榕树”（strangler fig）模式。Lee 承认，这有时会让人被困在某个糟糕的东西上。

Rahul 总结说，问“怎样找到职责范围来证明晋升”，本身就是问错了问题。正确的问题，是最迫切的问题是什么，经理、总监和其他工程师心里想的是什么，以及你能不能构建出帮助他们的东西。Rahul 把它比作创业公司：你从问题开始，而不是从解决方案开始。了解这些问题，需要建立关系，并嵌入到组织里。

Q你在与被指导者、技术负责人、经理和总监建立关系方面有多刻意？他们可能在评审时为你说话。（Rahul）

Carly 称这是极其刻意的。Carly 会找有共同问题或方法的人，并与他们组队。Carly 现在在各个业务部门都有朋友，包括很少共事的人。Carly 说，全职远程办公，使这件事比在办公室里难得多。Carly 描述自己是一个内向的外向者，并说人们必须克服不给别人发消息的冲动，因为如果没人认识你，就没有人会为你辩护。Carly 补充说，一个熬夜工作、显示为在线的人，并不会因此被注意到。人们会为那些他们见过按时、按范围、按预算交付的人背书，而等着被拯救，是错误的做法。

另一位嘉宾说，自己不擅长联谊活动，但工作的能见度很高，即使在疫情期间也得到了晋升。对他们来说，关键是把工作沟通出去：分享计划，获得认同，并汇报结果。写作和沟通是强有力的工具，因为在实践中，工作不会自己做营销。一位经理，只能当一段时间的啦啦队长。

Lee 说，被人所知，是困在 L5，与成为那个召集亚马逊各处 Android 工程师、并拿出数据说明应用何时会用光方法数的人之间的区别。然后人们会把别人介绍给这个人，而即使这个人没有答案，也能指出下一步。Lee 说，人际关系就是一切。Lee 在 Meta 远程工作，从没去过，没有成功。Lee 有不错的关系，但没有能见度，所以一旦出了问题，就缺少帮助。在疫情期间，Lee 开始在亚马逊的一个团队里，每天问一个与主题无关的问题。Lee 现在在谷歌两个组织的聊天室里这样做，并说人们认得 Lee 是“提问的人”，这让向产品经理求助变得容易。Lee 还建议，问经理团队里是否有人需要导师，因为即使得到“不”，也会改变他们对你的看法，并旁听产品经理的活动，以了解他们的流程，并提供开发者的视角。Lee 说，这听起来可能像政治，有时确实是，但这是工作的一部分。Lee 描述自己有自闭症，有许多社交上的挑战，并说 Lee 仍然必须这样做才能成功。

Rahul 提供了一个检验标准。如果你问一位队友，某个人以什么出名，他们能否连贯地回答，比如说那个人是某个系统的专家？如果不能，那就是一个糟糕的信号。

Q有哪些经验法则，能提高晋升到 Staff 的几率，比如选择团队、团队的规模，或者基础设施对比产品工作？（Rahul）

一位嘉宾建议，与 Staff 以上的人交谈，比如资深 Staff 或首席工程师，问他们如果有时间会修什么，然后去做那件事。一位支持你的文档的首席，作用很大。这位嘉宾还说，现在就去写晋升文档，不要等到觉得准备好了。把它给那些评审晋升的人看，问他们为什么会拒绝，然后针对这些差距努力。否则，一个晋升项目，可能结果并不是合适的那个，而那是候选人自己的错。如果反馈是你从没领导过任何人，那么下一个项目，需要展现领导力，而不是更多的代码。这位嘉宾说，不了解流程，就是把结果留给运气。

另一位嘉宾说，他们倾向于在每家公司里，做与流失和财务相关的问题，因为那是业务里痛点所在。

Zach 把与经理的关系放在第一位：没有它，即使是明星，也会吃力。对数据工程师来说，Zach 说，数据集必须是许多其他流水线都会读取的，比如主数据。只为一个可视化而做的数据集，不是 Staff 级别的。一位 Staff 分析工程师，则可能拥有从日志，到数据集，到可视化，也许还有模型的整条链路。

另一位嘉宾描述了三个常见的评分标准维度。一是工作流的规模，比如工程师的数量和持续时间。第二是复杂度：低一个级别的人能解决吗，还是需要分布式系统或 AI 这样的领域知识？第三是影响：它是否横跨几个团队，或触及重要的业务目标？这位嘉宾说，杠杆来自构建让其他工程师在其上构建的东西，这偏向基础设施和工具团队。领导一个非常大的产品举措，只限于少数几个地方，而且必须有人批准，所以这样的机会更少，也更难竞争。

Q观众提问：一旦到了 Staff 级别，你怎样保持超出期望？

一位嘉宾说，Staff 及以上的行为是相似的：通过他人施加影响，培养身边的人，以及承担最大的问题。变化的是，这些举措大了一步。要超出期望，就去找职责范围更大的东西，比如影响两个更大的组织，而不是一个大约 50 人的小组，或者为几百位工程师，而不是几十位，构建基础设施。

Zach 说自己在 Airbnb 的 Staff 级别上，获得了 2020 年的“超出”评级，并描述了两个部分。一是交付主要的“大石头”（big rock）项目，对 Zach 来说，是完善定价和可订性指标。另一个是更长期问题的设计工作，比如一份关于如何把数据从数据湖移回 Airbnb 应用的最佳实践的文档，由首席工程师就边界情况给出反馈。Zach 说，错过第一项，意味着根本达不到期望，而两项都做到，才能推动一个人朝资深 Staff 级别迈进。

Q观众提问（Alan）：有哪些资源，有助于技术沟通和寻找指导？

Rahul 说，核心技能是了解你的听众。在 Meta，Rahul 在发布更新之前，会看看一个内部 Workplace 小组里有哪些人：工程师、领导层，还是跨职能的混合。然后 Rahul 调整深度，避免细节过多或过少。在站会或会议之前，先弄清谁会在场，以及他们了解多少、在乎多少。Rahul 没有书或视频可推荐，并说，培养对不同听众的同理心的方法，是建立关系，这能让你感受到你所面对的各类人设。

Zach 补充说，在 Airbnb 期间几乎每天在 LinkedIn 上发帖，教会 Zach 把密集的信息简洁地说出来，因为这个平台奖励简短的帖子。Zach 推荐这项技能，用来成长。

Q观众提问（sesh）：一位资深工程师，在通往 Staff 的路上，是否应该先成为技术负责人？

Ryan Peterman 把技术负责人，看作一组可以在任何级别出现的行为，而不是资深与 Staff 之间的一个级别。一些团队里的资深工程师，会带领较小的项目。Ryan 建议查看公司自己的职级体系。

另一位嘉宾提醒，如果缺少的部分是领导力和能见度，那么当技术负责人，可能提供更多练习它们的机会。但它不一定是垫脚石，而且把这些行为做好，并不保证通往 Staff 的道路。还有一位嘉宾说，各个级别所期望的行为，应该在公司里被写下来。与你的经理一起用它，看看你在哪里超出、在哪里不足，如果没有这份文档，就去要，因为否则你只能猜。

Q观众提问（Sam）：一位数据工程师，怎样向一位并非日常负责人的经理，展示后端工作？

Zach 说，如果没有光鲜的前端部分，答案的一部分，是与在你的数据之上构建可视化的数据科学家或分析师合作。另一部分，是展示下游的影响。Zach 说，一个数据集，可以被推销为改善三类决策之一：高管的战略决策，数据科学家或分析师的产品决策，或者机器学习算法的自动决策。Zach 在 Airbnb 的定价和可订性数据集，喂给了 Smart Pricing，一个为房源定价的算法，对业务有很大的影响。

Zach 补充说，数据工程师也可以引用优化的数字，比如一条流水线快了 30% 或 40%。在 Airbnb，Zach 把定价和可订性数据集的大小减少了 90%，这样公司就可以使用小 10 倍的数据。Zach 承认，数据工程可能会落入阴影里，因为它缺少前端或一条 SQL 查询那种可以拿出来炫耀的特质。当收益只是能见度时，Zach 建议围绕它构建一个故事。

Q当 Staff 晋升需要足够的职责范围时，你怎样判断哪些问题值得解决？

Zach 描述了在 Netflix 的一次转变：从一个看起来太有野心的自动化威胁检测项目，转向一个其他团队在很多情况下都能使用的共享图数据库。这次转变，带来了更高的薪酬、更多的尊重，以及更大的领导角色。

Zach 补充说，职责范围并不是唯一的检验。可能永远不会有结果的高风险项目，同样浪费时间。资深工程师可以在投入之前，判断一个项目会有多大的影响，所以对他们提出的一个小请求，可能会躺在待办清单里。

Q给 Carly 和 Lee：一个人对想要达到 Staff，应该有多明确，又应该告诉经理多少？

Carly 管理 Staff 工程师，并说人们提出晋升的方式各不相同。按 Carly 的经验，大约一半想升到 Staff 的请求，来自还没准备好的人。另一半，则来自早就准备好、却很久之后才提出的人。Carly 看到两类人：很容易开口的人，有时在准备好之前就开口了；以及一直等到准备度得到证明的人，往往比准备好的时间晚了一年。

Carly 建议诚实地反思准备度，又不要把标准设得太高，以至于一位内敛的人退缩。

Lee 说，在大型科技公司，晋升往往滞后于表现，所以一个从不提这个问题的人，可能不知道缺了什么。Lee 建议直接说出目标：希望在技术路线上成长，而不是转向管理。问缺少什么，制定计划，并把证据写下来，这样当这个人准备好时，经理就有了材料。Lee 指出，并不是每个人都想要晋升，有些人更喜欢目前的级别。

Q一位高绩效者，对经理有筹码吗？

一位嘉宾说，表现出色的人，在公司内部有筹码，因为经理想留住能解决团队问题的人。从那个位置提出成长的请求，比从一个不那么核心的角色提出，更可能得到愿意接受的回应。

同一位嘉宾点出了局限。经理不能应请求就晋升一个人，因为涉及流程和其他决策者。经理仍然可以把项目引向晋升计划中所指出的那些差距。如果现有的团队无法提供那种工作，诚实的选择，是转到另一个团队，或者去外面看看。

Q在每个级别上，经理对晋升有多大的控制力？

Zach 说，在 Airbnb，直到资深级别的晋升，是由经理决定的，而从资深到 Staff 及以上的晋升，则经过委员会。Zach 描述了亚马逊在采用委员会做晋升之前的情形，在资深以上的级别，决定是沿着管理链条往上走的，经过隔级经理和总监，而不仅仅是直接经理。

Q一个人应该怎样判断，哪个团队是赢得 Staff 晋升的最佳地方？

一位嘉宾给出了一个粗略的检验。在一家有许多产品的公司里，做核心产品的团队，通常比做边缘产品的团队有更高的能见度。这位嘉宾开玩笑说，在 Garage Band 这样较小的应用上工作，不太可能带来晋升，而旗舰产品几乎不费力就能带来能见度。

另一位嘉宾说，能见度较低的团队，也能取得进展。找到拥有薄弱环节的团队，把问题在他们的代码里展示给他们看，并提出帮忙或与他们结对。与那个团队一起修复一个真正的问题，会让一个人成为强有力的合作伙伴，这不同于一个小小的表面改动。

第三位嘉宾说，在乎这份工作，与它的影响同样重要。在谷歌的一次面试中，这位嘉宾被提供了一个广告方面的角色，并说自己对此不感兴趣。一个人在乎的工作，会得到他们最好的努力，这也让他们更容易向别人为这款产品倡导。

Q产品团队还是基础设施团队，提供通往 Staff 更清晰的路径？

Ryan 说，Staff 级别的机会，在基础设施团队里更常见。Ryan 的看法是，产品工程师通常通过领导大型项目，来达到资深之上的高影响力，而这样的位置很少。基础设施的工作，内置了杠杆，因为基础性的技术，帮助许多团队更快地前进，这就创造出了更多角色。Ryan 说，Ryan 自己的基础设施团队，与其他团队相比，相当资深。

Q远程或混合办公的工程师，怎样与坐在经理附近的同事竞争？

一位嘉宾说，主要的答案是文档、沟通和证据。关于影响的书面证据，让经理和其他人无需依赖物理上的接近，就能看到工作。这位嘉宾只在完全远程的环境里工作过，所以混合办公的情况是一种外推。

QStaff 晋升需要异乎寻常的长工时吗？

嘉宾们给出了不一的说法。一位说，带来晋升的项目，每周需要 40 多个小时。Zach 回忆大约是 50 到 55 个小时，包括 Netflix 图数据库的构建。另一位嘉宾说，50 到 60 个小时很常见，但仍然留有睡觉的时间。还有一位嘉宾指出，有些人是在每周工作 40 个小时的情况下被晋升的。

转入管理的嘉宾们说，工时没那么重要。一位说，作为经理，这位嘉宾每周没有超过 40 个小时，而成倍放大别人的产出，比个人交付，用更少的工时就能体现影响力。另一位按目标而不是按工时来规划，一周工作大约 60 个小时，下一周大约 30 个小时。

Q创业公司被夸大的头衔，会导致在大科技公司被降级定级吗？

一位嘉宾说，当候选人没有达到公司所期望的级别时，就会发生降级定级。这位嘉宾认为无法避免，除非更强，或者面试得更好。创业公司的头衔常常被夸大，所以这位嘉宾建议，把工作的职责范围，与各家公司在每个级别上的期望作比较，而不是瞄准一个头衔。

另一位嘉宾说，头衔不如薪酬和有意义的工作重要。这位嘉宾从一家创业公司的中级角色，转到 Facebook 的初级角色，薪酬增加了大约 80%，并称这是一笔不错的交易。

Q资历能打开门，但更大的项目往往在晋升之后才来。你怎样打破这个循环？

一位嘉宾说，资历有帮助，但不如内部品牌重要。经理或总监在遇到难题时，第一个想到的人，通常得到这份工作，而级别往往与这种信任相对应。以能把事情做成而出名，即使没有资深的头衔，也会带来机会。

另一位嘉宾说，头衔是进门的一种方式，而不是唯一的方式。如果经理或资深的赞助人为一个人担保，他们可以被托付以超出头衔所暗示的职责范围，而他们自己的行动，建立了这种信任。总监级别的赞助人，可以为那份职责范围争取，但这个人仍然得自己去找它。

Q你怎样获得能见度，又不觉得是在自我推销？

一位嘉宾说，能见度对于向上走是必需的，即使感觉别扭，或者这个人比较内敛。能见度并不意味着为每一次胜利发帖。它可以来自在一次重大上线之后做技术分享，主持一个能把别人带进来的讲座系列，或者在内部论坛里回答问题。关键在于，为你说话的人，知道你做什么。

另一位嘉宾补充说，内部品牌，来自平易近人，并帮助队友扫清阻碍。一份晋升的论证，通常需要三四位能为这个人背书的同事的同行反馈。跨越不同的专业，比如与产品经理和数据科学家接触，会加强这个论证，因为一个只赢得一个群体的人，仍然没有在向上走。

Q寻求晋升的主要原因是什么：钱、头衔，还是工作与生活的平衡？

一位嘉宾说，主要原因是工作的类型。亚马逊的资深和首席工程师，做的是影响力很强的工作，比如指导别人，帮助工程师成长，并塑造自己团队之上的决策。这位嘉宾想要那份工作。薪酬是受欢迎的，但不是主要的吸引力。

Q一位 Staff 工程师，通常会影响多少人？

一位嘉宾考虑的是受影响的人数，而不是团队的规模。一位资深工程师，至少应该影响自己的团队，以及上面那位高级经理的职责范围。圆桌的粗略估计是，资深大约 20 到 30 位工程师，Staff 最多 50 到 60 位，首席则达到数百位，这可能意味着一位副总裁的整个组织。

另一位嘉宾回忆起 Airbnb 一个大约 75 位工程师的市场组织，其中大约有五位 Staff 工程师。

Q办公室政治怎样影响晋升？人们该怎么办？

一位嘉宾说，政治主要是关于人的。有些同事很难相处，有些人利用关系，以有害的方式出人头地。这位嘉宾并不指望一个人去改变或清除这些同事，所以更好的做法，是提高你自己的地位。如果环境真的有毒，正确的答案可能是换个地方。

同一位嘉宾补充说，当人们谈论政治时，他们往往指的是与高管或另一支团队沟通困难。这个差距是可以弥补的，而弥补它，是工作的一部分。

Q你并没有一个管理 Uber 所有有状态工作负载的宏大计划，那么你是怎样说服人们开始在 Docker 里运行数据库的？

Recht 把功劳归于早期 Uber 的自由，但它也带来了代价：有一次，有人数了一下，使用中的数据库技术大约有 52 种。因为需要批准的人很少，所以为 Recht 自己的团队采用这种方法很容易。更难的部分，出现在团队意识到应该对所有东西都这样做的时候。

Recht 说，他们有意没有试图一次说服所有人。他们先从丹麦办公室所拥有的开始，然后到其他部门朋友所拥有的团队，再到越来越抗拒的小组。他们也知道，平台在第一天无论如何都还没准备好。Recht 不喜欢强迫任何人，宁愿先构建出东西，确保它能行，并让怀疑者在别处看到它运行。Recht 说，这种渐进的方式帮助很大，也花了非常长的时间。

Q这是一场自下而上的努力吗？领导层是什么时候介入的？

Recht 说，这项努力，从下往上只能走到一定程度。Uber 有状态的这一侧，分成两半：在线数据库（MySQL、Postgres、Cassandra 及类似的），以及数据栈（HDFS、Kafka、Pinot 及类似的），后者处在一个完全不同的组织里，两条管理链条只在 CEO 那里交汇。数据栈一侧起初说，这个想法听起来不错，但他们不在乎。

随着时间推移，管理链条上有越来越多的支持，最终领导层宣布 Odin 是未来，并说团队将不再被允许运行自己的服务器。Recht 说，这项强制要求有助于推广，因为无论产品多好，总会有落后者，而单靠自己，很难达成完全的对齐。

Q对于关心职业层面的人，你的职业生涯在这每一步上是怎样成长的？

Recht 描述了一种自认为天真的希望：晋升并不总是公平的，但相当公平，并与工作的职责范围以及受其影响的人数挂钩，而不是通过直接的权力。Odin 遵循一种自然的扩展：先是在团队内部，然后是本地组织，然后是更广泛的平台，然后更远。Recht 说，把一个那种职责范围的项目运行到成功，会产生几乎自动发生的一连串晋升，并带动整个团队。

Recht 承认其中有一些运气：一个项目持续了很长时间，而许多人被调来调去，或者看到项目被取消，这让展现不断扩大的职责范围变得更难，尽管并非不可能。Recht 的晋升，与工作同步。背景工作在先，然后是平台的第一个版本，Recht 认为它赢得了一次晋升。随后扩展到标准的 MySQL 和 Cassandra，Recht 认为，这带来了首席工程师（头衔名称一路在变）。把项目交给团队，让 Recht 可以去做别的事情，带来了杰出工程师。Recht 说，晋升从来不是做这项工作的理由。

Q你说过，晋升通常是公平的，基于工作的影响。你说它们有时不公平，是什么意思？

Recht 在晋升委员会里坐了很长时间，并说形式发生了很大变化。第一个，涵盖了整个平台工程。经理、副总裁、高级总监和资深工程师，在一个房间里坐了一天，过一遍每位工程师，Recht 猜测人数有数百，没有准备，也没有书面材料。每位经理说每个人有多好，不出所料，认为每个人都应该晋升，所以临时搞了一套积分制。Recht 说，在那种设置下，结果取决于经理陈述论证的能力：一位薄弱的经理，意味着一份薄弱的论证，不过一位优秀的经理，也可能与薄弱的工作联系在一起。Recht 把这种不公平，部分地与 Uber 早期的文化问题联系起来。

结构有了改善，但 Recht 说，客观的判断是不可能的。一位工程师可能依赖于另一个从不交付的团队，或者一个快要完成的项目，被管理层因为不是这位工程师的过错的原因取消了。委员会就必须在“按没人用过的代码晋升”与“拒绝一位做了好工作的人”之间选择，在公平与动力之间取舍。一些工程师还觉得受到不公平对待，因为他们相比一支薄弱的团队表现出色，或者生活在一座孤岛上，没意识到其他小组强得多。Recht 回忆起 Uber 从 Python 和 JavaScript 转向 Go，而当时没有人懂 Go，委员会就判定一些小组的产出，干脆不够好。

Recht 说，对那些没有为自己所进入的环境做好准备的人来说，这感觉不公平。这就是为什么 Recht 写了一份关于在 Uber 做软件工程师意味着什么的指南，Recht 预期这与 Meta 或谷歌的不同。标题，类似“打败晋升委员会”，只是为了抓人眼球。Recht 为人们准备材料、收集同行反馈、一路上却没有得到纠正，最后却被拒绝而感到遗憾。

Q常见的建议是通过授权，成为一位不再写代码的技术负责人，来扩大自己的规模。你怎么看？

Recht 完全不赞同这个想法，并且经常见到。一部分是品位：Recht 一直喜欢写代码，并说即使没有工作，大概也还会做。但 Recht 也给出了理由。如果一位工程师不再写代码，系统会继续演化，而这位工程师就会与它失去联系。设计会变得更理想化，脱离现实，而当它们被交接出去时，实现者会纳闷，那个拿着白板和文档的人是谁，因为真正的问题是不同的。

Recht 把扩展自己，定义为让尽可能多的人高效地工作，而不是克隆自己，那很少行得通。当人们信任你，知道你理解他们的痛点，知道你的建议通常有效，知道你会倾听时，这会更容易。随着人员进进出出，一位不亲自动手的领导者，会同时失去与人和系统的联系。Recht 说，结果可能是敌意，人们不当着领导者的面说。Recht 个人不喜欢被一个没有利害关系的人告诉该怎么做，同时对意见保持开放，并承诺作为交换，不插手别人的工作。

Q你必须影响许多人，才能把你的项目推广到整个 Uber。你怎样影响其他工程师，又避免那种局面？

Recht 说，总有某个地方的某个人，永远不会被说服，而 100% 不是目标。Recht 相信以身作则：如果你说要构建什么，你就帮着一起构建，并承担很多痛苦。级别越高，越被告知要专注于只有资深者才能做的难事，但 Recht 说，那样的事很少。Recht 认为，提出想法的人，往往保留有趣的部分，比如新算法或好玩的工作，而大多数时候，艰难的工作应该授权给下面的人，给那些勉强能应付的人，并提供支持让他们不偏离轨道。资深工程师保留枯燥的工作，因为到了那个级别，没有什么需要证明的了。

Recht 说，承担苦活，能赢得很多信誉，也让别人成长得快得多，因为一支受到挑战的团队，工作和成长得更快。以身作则，主要意味着写代码，加上改进文档，或修复古怪的 bug，这通常没什么光彩。Recht 对此坚信不疑。

Q随着你的晋升，你的角色变得更政治化了吗？

Recht 先问政治化是什么意思，然后描述了什么发生了变化。更多的交谈，更多的争斗，因为你必须推广想法，也许更糟的是，倾听其他每个人的想法。同时也更多地暴露于现实。作为初级工程师，似乎有人有一个宏大的计划，一切都在掌控之中。后来，Recht 说，你会意识到没有人掌控着一切，决策可能基于淋浴时冒出来的一个愿景，或者与另一个同样不知道的人的一次交谈，而那就变成了战略。Recht 觉得，这对一位理性的工程师来说很可怕，并说这不适合每个人，自己一点也不喜欢。

Recht 的应对方式，是从中抽离出来，做自己的事。Recht 见过许多人被卷进好几周的规划里。因为 Recht 不需要别人告诉自己怎么做事，所以也不告诉别人。Recht 从来不是个职业规划者，并对看起来是死胡同的项目有强烈的反感，Recht 把它们留给别人，说了很多次“不”，在有些人看来也许太多了。这只有在自己的工作重要到足以填满自己的职责范围时才行得通。Recht 对花好几天谈论要做某件事、最后得到一份关于明年的模糊计划，耐心也很低。

Q你说最好的结果，是对方认为这个想法是他们自己的。你是什么意思？

Recht 说，这种事不常发生，但那些是最好的日子：几个月后，无意间听到有人满怀信念地论证一个 Recht 曾提出、而对方当时并不喜欢的想法，却没有提到 Recht。对 Odin 的抵制就是一个例子。一个必须重建自己已有工具的团队，起初只看到成本，后来在没有被强迫的情况下，逐渐看到了好处。

Recht 可能推动过几次，或者环境稍微改变了这个人。Recht 把那种感觉，描述为不是证明了自己是对的，而是为这些人现在走在正确的路上而感到自豪，而且是在没有强迫的情况下达到的。

Q据说你在自己的组织之外挑选被指导者，并把他们分散开来，以扩大你的影响。你是怎样挑选被指导者的？

Recht 说，指导听起来很有吸引力，但作为扩大规模的方式，效率非常低，因为是一个人对另一个人说话。因此，Recht 主要瞄准的是一个网络，以及双向的对话，其中对方也分享一些东西。在自己团队内部指导，会引出究竟谁在学什么的问题，而近距离的建议，可以在小组场合里非正式地给出。

与离得更远的人在一起，工作更多，好处也更多。Recht 可以了解他们做什么，对他们的工作提出意见，并播下种子。Recht 见过一些抱怨拿到糟糕项目的人，开始想到另一种工作方式可能是可行的，这可以在他们的团队内部产生影响，最终扩展到更广泛的组织。这就是为什么 Recht 更喜欢不那么亲近的被指导者。

Q体验 2017 年前后 Uber 的文化冲击是什么感觉？

Recht 说，丹麦和硅谷有很大的不同，并发现这些新闻令人困惑，因为原本以为每个人都只是在写代码、玩得开心。距离帮了忙。有九个小时的时差，办公室的白天保持安静，在人们离开或被解雇、董事会成员和 CEO 被逼走的同时，它仍然可以继续执行。

Recht 对 Uber 文化的印象是，绩效评估、晋升，甚至薪资谈判，都是关于个人，而不是团队，Recht 觉得这难以理解。丹麦办公室从未完全采纳这种心态，所以对他们来说，变化小一些。Recht 举出了他们无法理解的丑闻，比如滥用某人的私人数据，以及在一场骚扰丑闻之后的全公司直播里，一位董事会成员关于董事会里女性的言论。Recht 的心情很复杂，既庆幸有距离，有时又像在看热闹。在 2017 年之前去美国办公室访问时，Recht 觉得，周二下午被请喝威士忌很奇怪。

Q有了现在的了解，你会给职业生涯开始时的自己什么建议？

Recht 说，要去尝试，不要因为某件事看起来很难、或别人似乎好得多就害怕。他们也许更好，但你可以追上去；这不是火箭科学，只是计算机，任何喜欢计算机的人，只要坚持下去，就会过得很好。Recht 建议让好奇心带路，不要以为目前的工作是可得的最好的，因为更好的东西大概已经存在，或者很快就会出现。不要仅仅因为眼下的工作好玩，就放弃它。Recht 承认，很难判断什么比自己拥有的更好，所以有时只能赌一把。

Q为什么滑铁卢的合作教育（co-op）学生这么有效？

Grigorik 把功劳归于学期与工作期交替进行，而不是把行业经验，当作多年学习之后一次可有可无的打断。大约六次实习安排，提供了对行业、公司规模、角色和工作环境的反复试验。

一次短暂的实习，可以证伪一个先入为主的偏好，又不会在简历上留下反复离开正式工作的污点。想象过华尔街的人，可能发现那座城市、那里的人或工作并不适合自己。反复的选择，建立了更好的个人适配模型。

应用性的工作，也把理论工具放进了背景里。工程师必须在约束下解决一个真实的问题，并认识到什么时候，理论上很精妙的优化并不重要，比如当数组只有十个元素的时候。他希望更多的大学采用这种反复学习的循环。

Q为什么毕业后创办 PostRank？

他最初计划读研究生，部分原因是不知道该做什么。那个夏天，他探索了一个产品想法：链接可以标志有用的内容，而在更新的网络里，评论、点赞和其他社交互动，可以增加更多信号。PostRank 聚合这些互动，来给帖子排序。

他的产品上线，既带来了需求，也带来了实现上的问题。他回忆起好几个不眠之夜，因为服务器吃力，他承认，糟糕的代码也是原因之一。曝光引来了与投资人的交谈。

面对研究生项目的开学，他注意到，最吸引他的课程，都与创业有关。他可以在学术上研究这些想法，也可以在已经与投资人交谈的同时去学习。他推迟了那个项目，完成了融资，再也没有回去读完学位。这个选择，是一次与真实机会相关联的实验，而不是一个预先确定的创始人身份。

Q谷歌的收购对话是怎样开始的？

在一次会议演讲之后，谷歌分析（Google Analytics）的一位产品负责人，找到团队，邀请交谈。这场讨论是友好的、探索性的，从了解产品开始，并问是否能合作。Grigorik 后来明白，谷歌对 Facebook 及其社交举措的回应，创造了对相关人才和基础设施的需求。分析产品可以利用他们的经验来理解社交互动，形成了一个互相有用的联系。

Q你在谷歌分析的角色是什么？为什么放弃一条走向总监的轨迹？

他是以工程经理的身份加入的，因为他曾是创始人兼 CTO。他仍然致力于最初的目标，帮助发布商理解互动，并花了大约一年时间重建技术栈。当团队走上稳健的轨道之后，他考虑了另一个方向。

一位副总裁提供了一条通向总监的清晰路径，但谷歌的技术环境，吸引了他的好奇心。内部文档显示，那里的工作远远领先于已发表的论文，而工程师们有时缺的是时间，而不是分享这些进展的许可。他对为更广泛的 Web 生态系统做贡献产生了兴趣。

“让 Web 更快”（Make the Web Fast）小组，横跨蜂窝网络系统、协议、代理，以及衡量速度这个根本性的问题。Grigorik 选择平行调动到个人贡献者的工作，尽管他可能被降级，并重置了常规的管理路径。他看重更多的自主性、引人入胜的问题，以及他钦佩的合作者。

Q为什么后来又回到开发者关系领域的管理岗位？

他把个人贡献者与经理之间的往返，视为资深工程师中一种被低估的模式。一个人可能先独自发现一条路径，然后意识到，构建完整的解决方案，需要一支团队。他的比喻，区分了开辟一条小径，与修建一条高速公路。

他的性能工作，进入了浏览器标准和指标。一旦有了这些指标，瓶颈就变成了分析厂商和开源项目的采用。一个人无法完成所有这些外联。一支开发者关系团队，可以加速那些否则可能要几年的采用。

所以他回到了招募和组织人员，为这个问题服务。这次管理上的转变，是把工作带过一个新阶段的手段，而不是永久地宣布人员管理是唯一的成长方式。

Q在 Shopify，从首席到杰出的成长，需要什么？

他没有给出一份清单，也没有点出某一个晋升项目。首席工程师必须在模糊中找出有用的工作。他预期，进入一个陌生领域的人，要了解全局，建立合作关系，理解领导者的问题，并确定自己的技能适用于哪里。

对于杰出级别的工作，他强调的是在各个技术层面和业务需求上展现出来的广度。一个人必须理解底层的约束，重构真正的问题，并把它与产品和业务搭档需要的东西联系起来。

执行的模式，也随情形而变。一个前沿的问题，需要快速的实验来揭示未知；一个长期存在的平台 API，则需要对生态系统的后果慢慢考虑。无论哪种情况，探索都必须引向一项建议和有用的执行。他把这个角色的模糊性，比作一位副总裁收到较低层级解决不了的难题。

Q宽广的技能交集，会让通才与众不同吗？

他同意。一个对几个相关领域有足够了解的人，可以把它们结合起来，解决不寻常的问题，并随着情况的变化，改变自己的贡献。管理经验是另一件可用的工具：即使作为个人贡献者，他也能辅导、给出反馈，并与经理们有效地合作。他用概率语言作的类比，表达的是独特性；这场访谈并没有确立一个基于独立性的、关于职业成功的数学模型。

Q有哪些遗憾，是别人应该借鉴的？

不要让成功把尝试的门槛提得太高，以至于停止学习。他早期的写作和代码，现在看来让人尴尬，但发布它们，带来了反馈和鼓励，使改进成为可能。

更大的受众，会产生对出色产出的期望。这可能压制那些曾经会自由分享的普通观察和实验。他仍然在这个过滤器上挣扎，并鼓励有勇气犯错或被人不喜欢，而不声称什么都知道。

Q哪位作者或哪本书影响了你的职业生涯？

他推荐肯·罗宾逊爵士（Sir Ken Robinson）关于教育、创造力和找到自己天赋所在的书和演讲。这种理念，与关于合作教育的讨论产生共鸣：让人们发现自己的长处，并结合技能，而不是塞进一个僵化的、按年龄划分的工厂模式。他认识到，实施这样的教育体系是困难的；他的认可，针对的是它的方向，而不是一个现成的政策。

Q你会对刚开始时的自己说什么？

要珍视结合技能的能力，而不要因为朋友们在单个领域里更精深，就觉得自己不如人。早期对自己宽泛、但参差不齐的能力的不确定，最终让位于认识到它的用处。

他还会更勇敢，更少地自我过滤。公开演讲曾经让他恐惧；推介一款自己在乎的产品，与为一个班级表演知识，感觉完全不同。热情改变了他的投入方式。他没法预料，沟通后来会成为他工作的很大一部分。

Q当你到达杰出工程师时，你是怎么想的，你想要再晋升一次吗？

职业早期，Su 以为晋升会每隔几年继续一次，并没有考虑过会有一个终点。到了七级，他认识到，更高的角色需要更大的职责范围，而业务必须真的需要那种职责范围。一个组织，可能出于预算和组织上的原因，限制合伙人级别的职位，不论个人有多大的抱负。

当 Facebook 第一次设立九级时，最初被晋升的人，似乎格外有成就，并受到普遍的认可。他不认为再往前走是现实的。他的回忆挑战了这样一种想法：每一次晋升，都只是又开启了一个可预测的向上的台阶：角色会变窄，机会很重要，人们会遇到极限。

Q是什么让你在 Staff 及以上的阶段，仍然保持成长？

在他在微软职业生涯的大部分时间里，级别是他在学校里所喜爱的成绩和考试的替代品。职场工作几乎没有清晰的数字指标，所以晋升感觉像一个成就分数。他在三十出头时，一直积极地追求这个分数。

过了七级，他不确定自己是否会喜欢不断变化的工作，或者能否达到它的期望。他后来升到八级和九级，是他觉得有趣的工作的结果，而不是明确的目标。当时的 Facebook 还很小，使命导向；他说，他甚至不知道那里有级别，直到他的经理告诉他，他已经被晋升了。

Q是什么改变了你对晋升的看法？

回报变得不那么单纯了。一次晋升，带来了他不再确定自己能否履行的期望。留在一个他已经享受那份工作的级别上，开始让人觉得舒服，他也认识到，那也许就是他最后的级别。

他回忆起，在一位导师把他晋升到七级之后，他立刻问怎样才能达到八级。导师问，他们能否花一次会面来庆祝。多年后，Su 意识到，这位受人尊敬、更有经验的导师，自己就处在同一个级别。他现在认为，自己当时的反应不够谦逊：在现有级别上做出出色的工作，本身就是一项实质性的成就。

Q在寻求降级之前，你有没有要求过不要被晋升到 IC7 以上？

从七级到八级的时候没有：那次晋升让他感到意外，而当时较小的 Facebook，所涉及的组织开销仍然相对较少。后来，仅西雅图办公室一处，就从寥寥几张办公桌，增长到了两千多人。在一个大得多的组织里，资深的角色包含更多的协调，更少直接的技术工作。

他把令人愉快的人际工作，比如欢迎同事和创造协作，与政治、不快乐的同事和建设性的反馈区分开来。他觉得自己在领导 Facebook 伦敦站点时很有成效，但在后者的一些职责上，成效要低得多。即使是没有直接下属的资深个人贡献者，也被期望去改善周围的人，所以放弃管理，并不会去掉人际方面的要求。

Q是什么变化，让更高的级别更难维持了？

他的环境变了。在一家小公司里，他通才的广度是有用的：对于 Facebook 的视频通话，他写代码，谈合作伙伴的合同，处理测试安排，还跟媒体交谈。大公司则把这些任务，分配给专门的职能。他认为，资深的领域专家，更适合那样的环境，而他自己的长处，变得不那么相关了。

后来的一支团队，整整一个半年都在修一个内部工具的 bug。他愿意帮忙，但那不是让他觉得自己格外杰出的工作。与此同时，他厌倦了要满足资深期望的压力。早先，作为团队里最弱的人，会觉得兴奋，因为他在追赶；后来，这感觉像是一种反复出现的风险，而不是一个令人向往的挑战。

QPhilip 把在微软职级阶梯上快速攀升的功劳，归于什么？

Philip 点出了几个原因。一个是与非常优秀的经理和队友共事。微软的平板电脑团队大约有 20 人，其中有三位是杰出工程师，Philip 称这在微软非常罕见。Philip 很快从他们那里学到了很多。

另一个原因是非常长的工时。第一年，Philip 在办公室里放了一个睡袋，常常睡在那里。Philip 设了凌晨 3 点的闹钟，来效仿 Philip 所描述的达·芬奇（Da Vinci）的做法，即把睡眠分成两个四小时的时段，中间写代码。

Philip 把快速成长归结为运气、天赋和努力。运气意味着在合适的时间出现在合适的地方，比如在谢尔盖（Sergey）和拉里（Larry）在斯坦福的时候，也在斯坦福。天赋之所以重要，是因为 Philip 拒绝“任何人都能成为任何人”的说法：Philip 永远不会成为一名出色的篮球运动员，而一位糟糕的演讲者，可以变得过得去，但成不了西塞罗（Cicero）。努力之所以重要，是因为一个比同样有天赋、同样幸运的人更努力的人，会走得更远。Philip 补充说，Philip 并不向每个人推荐这样做。

QPhilip 为什么成为经理？为什么这个角色一直在变？

Philip 说，晋升到相当于微软 E7 的级别，是以经理的身份，此后 Philip 也在那个级别上做过个人贡献者。早期，Philip 非常有野心，并且来自一种文化，作为华裔，在那里经理更受尊重，也走得更远。Philip 现在称，“管理是下一个成长步骤”这种信念，有些误导。

在整个职业生涯里，Philip 在管理与个人贡献者之间，至少切换过六次。Philip 喜欢做个人贡献者，却常常被要求去管理，比如作为临时的经理。

Q一个人应该怎样在继续做个人贡献者与成为经理之间做决定？

Philip 对新的体验持开放态度，并总体上主张，如果你觉得自己可能喜欢或擅长管理，就去试试，但有几点提醒。

第一个提醒，是不要意外地穿过一扇单向门。Philip 已经大约六次回到个人贡献者，但说许多人做不到。他们成为经理们的经理，远离了代码，然后就不愿意接受较低层级的工作，或者无法在原来的级别上，满足个人贡献者的期望。Philip 即使在管理团队时，也一头扎进代码里，让这扇门保持双向敞开。

第二个提醒，是人们想管理时，往往只想着自己。Philip 的检验是：当你的团队会选你时，你就准备好了领导：“你愿意为你自己工作吗？”如果答案不是一个坚定的“是”，就有需要改进的地方。Philip 指出，没有人能真正让你去领导，因为团队可以拖慢进度或故意压低产出，所以人们必须愿意为你工作。Philip 预期，一旦做了这些改进，人们会请你去管理。

Q在两条路径之间切换，Philip 有没有损失进展？

Philip 说有，是有意的，也是心甘情愿的。当 Philip 从 Facebook 伦敦站点的负责人，转为 Oculus 的个人贡献者时，Philip 最终被从 E9 重新定级为 E7。Philip 接受了这一点，并说这是必要的，因为作为站点负责人所展现的技能，不同于在 Oculus 做一位好程序员所需要的技能。

Philip 说，许多人无法接受这样的一步，要么出于自尊，要么因为生活方式会膨胀到填满人们所赚的任何薪酬。那些不愿改变生活方式的人，把自己逼进了死角，能接受的工作越来越少。

Philip 还说，时机很重要。在职业的一两年里，平行转换，比如从初级软件开发转为初级产品经理，很容易，而且许多人会辅导你。在资深的 E5 前后，从 E5 软件开发转为 E5 产品经理非常困难，除非工程工作本来就涉及产品管理。在更资深的级别，技能又重新趋同，所以形状是一个菱形。据 Philip 描述，一位有效的 E8 个人贡献者，拥有技术愿景，了解基础设施的薄弱点，规划分阶段的迁移，善于辅导，并理解业务战略。Philip 的结论是，职业生涯的中段，是转换路径最难的时候。

QPhilip 是怎样处理从 E9 降到 E7 的？

当 Philip 第一次作为伦敦站点负责人，从 E8 晋升到 E9 时，就为此担心过。Philip 告诉当时的 Facebook CTO（字幕写作“Shrep”），因为 Philip 喜欢做个人贡献者，所以怀疑在回去写代码时，能否保持那个绩效水平。CTO 回答说，等它发生时再担心，不要因为将来可能回去写代码，就不给晋升。

回到代码里之后，Philip 明白，E9 的期望遥不可及。被调回 E7，也就是 Philip 大约八年前加入时的级别，感觉很好。Philip 说，在一个级别上表现出色，远比在一个让你有冒名顶替综合征、怀疑自己能否继续胜任的级别上勉强维持要好。Philip 也不想拿高于自己相对队友所应得的薪酬。

Philip 说，很少有人做出这么大的改变，它需要一种特别的自尊心。Philip 从管理一个大约 400 或 500 人的站点，变成向一位向另一位经理汇报的经理汇报。Philip 还必须避免对站点的运营发表意见，避免利用过去那种过大的影响力，这样新的领导者才能成功。

QE7、E8 和 E9 的工程师，通常做什么？

Philip 提醒说，Philip 的信息比较粗略，可能已经过时，因为它来自大约 15 年前开始在 Meta 工作的经历。一般来说，级别反映的是影响力的范围：一个人能够独自保证完成多大、多长或多有价值的项目。一位实习生可能保证一个小功能。E5 或 E6 的资深开发，应该交付大约 10 到 15 个人的工作量。在 E7，Philip 预期他们能定期影响大约 50 个人，为这个规模的团队推动技术方向，被产品和工程经理咨询，并亲自交付大约六个月的工作，而不需要中间的检查。一位总监可能影响大约一百人。

在个人贡献者这一侧，Philip 说，大职责范围有不同的形式。有些人很窄、但很深，深到别人无法匹敌，四位 E6 也无法替代他们。另一些人是广博的通才，对新团队和创业公司特别有价值，在那里，三位 E6 无法胜过一位出色的通才 E8。

Philip 强调，质上的差别最重要，无法用人力资源的要点清单来捕捉。处于这些级别的人，因不同的原因而出色，需要更资深的人来评判。当 Philip 第一次被晋升为 E8 时，E9 还不存在。Philip 说，公司后来不得不为像约翰·卡马克（John Carmack）这样的个人贡献者，发明这样的级别。Philip 回忆说（如果记忆没错），当第一批 E9 晋升被讨论时，公司有几千人，并在考虑三位工程师，每一位都是不同的原型。Philip 把这比作成为教授：没有公式，归根结底在于其他 E8 是否认为你是一位 E8。

Q是什么项目或职责范围，为 Philip 赢得了 E9 晋升？

Philip 带着 12 个人，开始了 Meta 伦敦办公室的工程部分，并在大约四五年里，把它发展到大约 400 或 500 人。Philip 说，一位好的六级工程经理，可以带 12 位工程师，但随着每一个数量级的增长，问题变得更难，解决方案变得模糊。这次晋升，基于处理更广泛的事务和更具战略性的决策。

一个例子：在 Philip 担任站点负责人的最后几次会议之一，Philip 向门洛帕克的人争论，要招多少实习生，以及那个夏天伦敦应该有多少人头数。这个论证，基于对 18 个月后预期 H-1B 数量的计算，涉及转到门洛帕克的全职录用。更早之前，作为 E8，Philip 是 Meta 各个站点中，第一个去看资历金字塔、并问人们是否以相应的速度成长的人。Philip 把这些描述为职责范围不断扩大的决定，无论是受影响人员的广度，还是必须考虑的时间有多远。

Q是什么让伦敦站点的工程文化如此强大？

Philip 点出两点帮助。第一，在伦敦之前，Philip 是 Meta 西雅图（公司在帕洛阿尔托总部之外的第一个办公室）招的第二个人，看着它从四张办公桌增长到 120 人，包括它增长方式中的错误。第二，在启动伦敦之前，Philip 面试了其他公司的站点负责人。其中一位是谷歌伦敦的前站点负责人 David Singleton，Philip 说他后来成了 Stripe 的 CTO。

Singleton 告诉 Philip，谷歌曾试验过“落地团队”（landing team），也就是被派去启动一个站点文化的小组，并得出结论：这支团队应当至少承诺两年。Philip 把它与那些派一支团队去三个月或六个月、然后让站点自行发展的公司作了对比。Philip 认为那是个错误，因为当新来的人，与来了三个月以上的人数量差不多时，文化很难维持。CTO 想要足够两轮完整面试的工程师，大约 10 到 12 人。

Philip 面试了公司里将近 50 位志愿者，以及他们的一些同事和经理，从中挑选出 12 位来承载文化。每个人都被要求带一个自己要领导的项目，而这个小组里有出色的个人贡献者，他们乐于做站点需要的任何事情。Philip 说，自己在选择上很幸运，并把功劳归于向做过这件事的人学习。

QPhilip 有没有与扎克伯格（Zuck）和博斯（Bos）共事的、最喜欢的故事？

Philip 在 Facebook 的第一位经理是 Bos，他后来成了 CTO，而在伦敦的那些年里，Philip 的经理是当时的 CTO，字幕写作“Shrep”。两人都给了很棒的建议和指导。Philip 只与扎克伯格一对一交谈过几次，所以 Philip 的见解有限，但 Philip 说，扎克伯格在领导方式上，让人感觉真诚。

最让 Philip 印象深刻的，是扎克伯格和 Bos 两人愿意并且有能力成长。Philip 33 岁时加入，当时公司的年龄中位数是 27 岁，而且在头七个月里，是西雅图办公室里年龄最大的人，所以 Philip 为之工作的大多数人，都比 Philip 年轻。与其中任何一位共事多年的人，都能确切地说出他们是怎样成长的。Philip 看到两人都对辅导持开放态度，可能还在寻求它，并有意识地努力改进。

Philip 的小例子，是扎克伯格的 AMA（问我任何事）。Philip 说，在 Philip 加入后大约两年里，他们进步了很多。Philip 很确定，有人指导过扎克伯格怎样摆放头部，因为早期他自然的姿势，头略微向上仰，而多年里，他有意地纠正，直到正面对着人群。

QPhilip 为什么要为全公司买一天的咖啡？

主持人记得这是全员免费喝咖啡的一天，并把成本估计在 23,000 美元以上。Philip 在这段回答里没有给出数字。Philip 说，这个想法始于 Facebook 的几年之后。在公司搬到门洛帕克园区之后，黑客广场（Hacker Square）开了一家咖啡店，有一年圣诞节，Philip 为所有人买了一天的咖啡。Philip 发现这种快乐很有感染力，而这家咖啡连锁店的首席执行官写信说，他们的员工从未见过这样的事。

离开时，Philip 想回馈些什么。Philip 强调运气。Philip 说，人们忘了，当 Philip 加入时，人们在说 Friendster 也许会卷土重来，Google+ 会碾压 Facebook，而 Facebook 在移动端永远赚不到钱。Philip 在微软工作了 12 年之后离开，Philip 说那段时间里，股价大约上涨了 15%，所以期望很低。Facebook 的结果，用 Philip 的话说，是“一大砖头的钱”（a brick of money），来自运气，而不是设计。Philip 说，Philip 把所有 IPO 的收益都捐给了慈善，因为觉得这是不应得的，并把运气归于出生在计算机科学有回报的年代，以及移民到美国。然后 Philip 与 Facebook 主要站点的咖啡店协调，大约五家，给店主们打电话，并说这很有趣、也很有成就感。

QOpenAI 与 Facebook 相比如何？

Philip 首先指出，阶段不同：Philip 加入 Facebook 时，它大约有 500 位工程师，而 OpenAI 大约有 120 位。带着这个提醒，Philip 称 OpenAI 是 Philip 共事过的所有工程师群体中，人才密度最高的。从微软到 Facebook，同事的平均素质有一个大的跃升，而 Philip 觉得 OpenAI 又高了一档。

QPhilip 是怎样培养出这么好的写作能力的？

Philip 说，Philip 在整个大学期间都是个糟糕的写作者，因为 Philip 不尊重沟通。来自一种看重拿 A 的文化，Philip 把硬科学看作是实在的，而把历史和英语看作是浪费时间，没有正确答案，所以没有在软技能上投入。

在微软，在业余时间，Philip 重读了高中时讨厌的经典作品。Philip 点出海明威和《了不起的盖茨比》，作为年长的读者，看到了不同的东西，并培养出了对语言的热爱。Philip 引用弗吉尼亚·伍尔夫（Virginia Woolf）的观点，要写得好，你需要读得好，并点出戴维·福斯特·华莱士（David Foster Wallace）、艾丽丝·门罗（Alice Munro）的短篇小说，以及《汀克溪的朝圣者》（Pilgrim at Tinker Creek），作为展示语言能做什么的写作。随后，Philip 开始把写作看作与硬科学技能同样有价值的技能，并开始下功夫练习。

Philip 说，除了读得好，还需要愿意重写好几遍，并把材料留在剪辑室的地板上，而 Philip 许多著名的帖子，都被反复重写过。Philip 还留意别人 Substack 里巧妙的修辞手法，并努力记住它们。最重要的是，Philip 说，改变来自不再轻视这项技能，并把它视为即使对科学家和技术人员也是必不可少的。

QPhilip 是怎样作为一位非常年轻的经理，赢得尊重的？

Philip 说，这很难，因为 Philip 缺乏谦逊，又过分有野心。Philip 说，Philip 不会为 24 岁时的自己工作。Philip 成为经理，是因为 Philip 是团队里最强的工程师之一，而团队觉得，让 Philip 去管理，是让一位优秀的工程师保持开心的更好办法。

在头一年，24 岁的 Philip，不得不解雇一位 40 岁的人。Philip 称这异常艰难，而意识到自己有多初级，让它更难。Philip 说，这个人因为没达到期望，是应得的，但他的级别比 Philip 自己高两级，而 Philip 说，自己太不成熟，不知道怎样管理一位更有经验的人。

Philip 说，Philip 起初是个相当糟糕的经理，却痴迷于成长：Philip 收集导师，征求反馈，并阅读关于管理团队和艰难对话的非虚构类书籍。Philip 说，即使在管理的最后一年，Philip 也犯了巨大的错误。Philip 点出的最大弱点，是给出反馈。Philip 会手下留情，讨厌冲突，并淡化反馈的严重程度，所以人们没有抓住重点。Philip 说，Philip 已经从非常糟糕，变成了勉强过得去，并不期望变得出色。一个长处是激励行动，因为 Philip 只加入自己相信的团队，而 Philip 的热情和愿景，会让人们兴奋。

QRahul 在 Pinterest 是怎么定级的？他是怎样选择团队的？

Pinterest 刚刚创建了一套职级体系，借鉴自谷歌和 Facebook。Rahul 以 L3，也就是入门级进入（L4 是中级，L5 是资深）。他从推荐系统和数据工程，转向了移动方向，他称这是一次职业重置。这意味着更长的上手期，以及后来一次被拒绝的晋升。

Pinterest 让新员工通过“大本营”（base camp）选择团队，那是 Facebook 新兵训练营的两到三周版本。Rahul 决定不做后端工作。他想贴近产品，能够端到端地构建东西，包括副业项目，并喜欢这样的想法：在安卓商店里有一个应用，他使用安卓手机的家人可以试用。他的创业公司没有移动团队，所以他把 Pinterest 看作一个与优秀的人一起，专业地学习安卓的机会，并双重受益，既在工作中，也在副业上。

Q在 Pinterest 晋升失败之后，Rahul 最终是怎样获得晋升的？

Rahul 称这是一段艰难的历程。第一次拒绝，大约在他加入一年之后。他认为这个反馈是公平的：他专业地做安卓只有大约九个月，并没有交付多少东西。六个月后他再次尝试，又被拒绝，他觉得这确实令人沮丧。他是通过人才并购（acqui-hire）进来的，预期自己会是最优秀的工程师之一，而为同一个晋升被拒绝两次，是一次真正的挫折。

Pinterest 有申诉流程，Rahul 与经理一起使用了它。申诉成功了。匿名的委员会，把他材料里一个被描述为 16 个月工作的项目，解读成缺乏紧迫感。Rahul 说，那不是真的。他的经理做了澄清，并为他倡导。他的教训是，要清楚文档说了什么，因为读者可能有不同的解读，并让有经验的人评审晋升文档和一对一的文档。

Ryan 指出，一个长期的项目，反过来也可能表示更大的职责范围。Rahul 同意，背景决定一切：与经理就叙述达成一致，并收集技术负责人的反馈，因为 16 个月可能看起来令人印象深刻，如果它只是一个别人预期三个月就能完成的小实验，也可能对你不利。他的结论是，不要假定别人会怎样评判你。软件工程是一项社会性的事业，所以要在评审之前，了解评估者对你成长领域的看法。

QRahul 为什么在 2017 年年中，离开 Pinterest 去了 Meta？

Rahul 给出三个理由：Meta 是一家大得多的公司，工程品牌更强；它给的薪酬更高；而他在 Pinterest 看不到一条快速成长的清晰路径。他想看看自己能否在级别或薪酬上得到一次有意义的提升。

他认为，跳槽在职业早期比后期更有效。他说，随着人们往上走，影响力主要通过影响他人来实现。一位 Staff 或首席工程师，很少写足够多的代码来证明这个角色的合理性；他们构建框架、工具和系统，让其他开发者更有产出，这需要多年的关系和信任。早期，展示你能写高质量的生产代码，也许就足以让你以更高的级别被录用。

Ryan 的经历与之吻合。Ryan 从资深到 Staff 的晋升异常迅速，是因为在一支团队里有长期的关系，而那些快速换公司的同龄人，这样的纽带更少。

QRahul 注意到 Pinterest 和 Meta 之间有哪些文化上和技术上的差异？

在文化上，Rahul 觉得它们相似，因为 Pinterest 的文化，是由前 Facebook 和前谷歌的人塑造的。他把 Facebook 描述为“真品”、“加强版”（on steroids）。在 Pinterest，每一处改动至少需要两位评审者，而 Herald 规则会自动添加阻断性的评审者。在 Facebook，一个“通过”通常就足以落地代码，这让他震惊。

他还发现 Facebook 的人更直接。他说，在 Pinterest，一个常见的批评是公司太“好人”了：人们回避艰难的反馈或优先级排序，所以不该留下的项目和人，一直拖着。在 Facebook，人们更爱直接说，一个项目没有意义，应该砍掉，而他察觉到一种更激进的绩效改进计划文化。

QRahul 是以 IC5 被聘用的吗？为了那一跃，他做了什么特别的事吗？

Rahul 是以 IC5（资深）被聘用的，所以从 Pinterest 过来，实际上就是一次晋升。他说，他没有做什么特别的事；这个级别，是 Meta 在面试之后提出的，而在那些面试里，他觉得自己几乎解决了每一个问题。

他也是从一个强势的位置出发：手里有几份待定的录用通知，有 Facebook 的实习经历，在一家受人尊敬的公司待过，而且安卓开发者的市场很火热，这一切都让 Meta 想给他一份有吸引力的录用通知。

Q是什么工作，带来了从资深到 Staff（IC6）的晋升？

Rahul 做 Portal。Facebook 已经在 Messenger 内部，有一套成熟的跨平台视频通话基础设施。Portal 的第一步，是分叉 Messenger，作为一次实验走自己的路。一旦 Portal 有了数十万日活跃用户，团队就需要回到正常的基础设施上，因为 Messenger 的 RTC 团队在不断改进它。Rahul 的主要项目，是把 Portal 的核心基础设施，迁回 Messenger 的，同时保留 Portal 的定制功能，并采用 RTC 提供的新能力。

他称这是有大量官僚程序的跨职能工作，涉及 Messenger 团队、Portal 的领导层和产品经理。他说，有些人在 Staff 级别可以只靠一个大项目，但一个“组合”对他很管用。第二个项目是调试工具，纯粹由工程驱动，是为他自己和队友构建的。他说，这两者合在一起，构成了一个清晰的晋升论证。

QRahul 为什么从 IC6 转为技术负责人兼经理（TLM）？

Rahul 说，他现在的公司，是关于帮助别人的，并把好的经理，视为真心想帮助别人成长的人。作为副产品，他说，他们可以有很大的影响，因为经理通常资深、受人尊敬。他也有背景和关系，所以这次转变感觉自然：一支不断壮大的团队，需要有人给出反馈，并让人们专注于高影响力的工作，而他已经表达过兴趣。

Q在哪个阶段，Rahul 觉得技能或职业成长最大？

Rahul 点出三个。第一个，是在 Pinterest 遇到那位导师：结对编程，潜移默化地学习，并发现自己有权改变环境。第二个，是在 Meta，领导迁移并构建调试工具，那是他第一次在大科技公司里，觉得自己创造了价值，来自他自己的一个想法，而人们选择采用它。在那之前，他常常觉得自己像一只工蜂，执行从上面传下来的工作。他说，这帮助给了他创办公司的信心。