前言

五年后你觉得自己会在哪里？这个经典的面试问题，相当于成年人版的“你长大后想做什么？”：它有几个社会上可以接受的答案，而且时间跨度足够长，你不必给出承诺。¹ 但如果你是一名希望在职业上继续成长的高级软件工程师，这个问题就变得非常现实了。² 你究竟看到自己将走向何方？

两条路径

你可能会发现自己站在一个岔路口（图 P-1），面前延伸出两条截然不同的路。走上其中一条，你会有直接下属，成为一名经理。走上另一条，你会成为没有下属的技术领导者，这个角色通常被称为 Staff 工程师。如果你真能看到这两条路上五年后的样子，你会发现它们有很多共同点：它们通向许多相同的地方，而且走得越远，你就越需要许多相同的技能。但在起点处，它们看起来截然不同。

图 P-1. 岔路口。

经理之路清晰明了，走的人也很多。对于任何能够清晰沟通、在危机中保持冷静、并帮助同事把工作做得更好的人来说，成为经理是一个常见的、或许也是默认的职业发展步骤。你很可能认识选择了这条路的人。你以前大概也有过经理，也许对他们做得好或不好的地方有自己的看法。管理也是一门被充分研究过的学科。晋升和领导力这两个词常常被默认为“成为别人的上司”，机场书店里摆满了关于如何做好这份工作的建议。所以，如果你踏上管理之路，它不会是一条轻松的路，但至少你对这段旅程会是什么样子有些概念。

Staff 工程师之路就没那么明确了。虽然现在很多公司允许工程师在不带下属的情况下继续提升资历，但这条“技术通道”仍然模糊不清、缺少路标。考虑走这条路的工程师可能从未和 Staff 工程师共事过，或者见过的担任这一角色的人性格类型太单一，以至于这个角色看起来像是遥不可及的魔法。（并不是。这些都是可以学会的。）这份工作的预期因公司而异，即使在同一家公司内部，招聘或晋升 Staff 工程师的标准也可能含糊不清，并不总是能付诸行动。

很多时候，即使你已经身处这个角色，它也不会变得更清晰。过去几年里，我和许多公司的 Staff 工程师聊过，他们并不太确定别人对自己有什么期望；我也和一些工程经理聊过，他们不知道该如何与作为下属或同级的 Staff 工程师合作。³ 所有这些模糊性都可能成为压力的来源。如果你的工作没有明确定义，你怎么知道自己做得好不好？甚至，你怎么知道自己有没有在做这份工作？

即使预期很明确，实现这些预期的路径也未必明确。作为一名新晋 Staff 工程师，你可能听说过别人期望你成为技术领导者、做出好的业务决策、在没有职权的情况下施加影响——但怎么做？从哪里开始？

Staff 工程师的支柱

我理解那种感受。在这个行业的 20 年里，我一直走在 Staff 工程师之路上，现在是一名高级首席工程师，在我们公司的职级阶梯上与高级总监平级。虽然我多次考虑过经理之路，但我总是得出同一个结论：“技术通道”的工作才是给我能量、让我早上愿意来上班的东西。我希望有时间钻研新技术、深入理解架构、学习新的技术领域。你在什么上面花时间，就会在什么上面变得更好，而我一直希望在技术方面不断精进。⁴

不过，在职业生涯的早期，我很难弄明白这条路。作为一名中级工程师，我不理解为什么在“高级”之上还有级别——那些人整天都在做什么？我当然也看不到从我当时的位置通往那些角色的路。后来，作为一名新晋 Staff 工程师，我发现了一些不成文的预期，以及一些我连描述都不知道该如何描述、更别说付诸行动的欠缺技能。这些年来，我从许多项目和经历中学到了东西——既有成功也有失败——也从出色的同事和其他公司的同行那里学到了很多。现在我已经理解这份工作了，但我真希望当初就知道我现在所知道的这些。

如果你已经走上了 Staff 工程师之路，或者正在考虑，欢迎！这本书就是为你写的。如果你与 Staff 工程师共事，或者管理着 Staff 工程师，并想更多地了解这个新兴角色，这里也会有很多适合你的内容。在接下来的九章里，我会分享我所学到的关于如何成为一名出色的 Staff 工程师的经验。我现在就要提醒你，我不会对每个话题都给出明确的规定，也不会回答每一个问题：大量的模糊性是这个角色固有的，而答案往往是“视情况而定”。但我会告诉你如何在模糊中找到方向、理解什么是重要的，并与你共事的其他领导者保持一致。

我会通过我所认为的 Staff 工程师角色的三大支柱来拆解这个角色：全局思考、项目执行，以及提升与你共事的工程师。

全局思考

全局思考意味着能够退后一步，以更广的视角看问题。它意味着看到眼前细节之外的东西，理解你所处的上下文。它还意味着超越当下去思考，无论是启动长达一年的项目、构建将来易于下线的软件，还是预测你的公司三年后会需要什么。⁵

执行

在 Staff 级别，你承担的项目会变得更加混乱、更加模糊。它们会涉及更多的人，需要更多的政治资本、影响力或文化变革才能成功。

提升

资历每提高一级，你就要承担更多的责任，去提高你周围工程师的标准和技能，无论是你所在的团队、你所在组织的同事，还是整个公司乃至整个行业的工程师。这份责任既包括通过教学和指导施加的有意的影响，也包括作为榜样而产生的无意的影响。

我们可以把这三大支柱看作支撑你影响力的东西，如图 P-2 所示。

图 P-2. Staff 工程师角色的三大支柱。

你会注意到，这些支柱立在由技术知识和经验构成的坚实地基之上。这个地基至关重要。你的全局视角包括理解什么是可能的，以及拥有良好的判断力。在执行项目时，你的解决方案需要真正解决它们要解决的问题。在充当榜样时，你的评审意见应该让代码和设计变得更好，你的观点需要经过深思熟虑——你得是对的！技术能力是每个 Staff 工程师角色的地基，你会一直运用它们。

但仅有技术知识是不够的。在这个级别上取得成功和成长，意味着要做到仅凭技术能力做不到的事情。要擅长全局思考、执行更大的项目、提升身边的每一个人，你需要“做人”的技能，比如：

• 沟通与领导力

• 驾驭复杂性

• 正确看待你的工作

• 指导、举荐与授权

• 以能让他人关心的方式来阐述问题

• 无论你是否觉得自己是领导者，都要像领导者一样行事⁶

可以把这些技能想象成哥特式大教堂上的飞扶壁（如图 P-3 所示）：它们并不取代墙壁——或者说你的技术判断——但能让建筑师建造更高、更宏伟、更令人叹为观止的建筑。

图 P-3. 领导力技能就像飞扶壁，让我们能够保持宏伟建筑的稳定。

三大支柱中的每一个都需要一组技能，而你对每一项的天赋各不相同。有些人在领导并完成大型项目时如鱼得水，却对在两个战略方向之间做选择感到发怵。另一些人对公司和行业的走向有很强的直觉，但在处理事故时很快就会失控。还有一些人能提升与他们共事的每个人的技能，却难以围绕一项技术决策达成共识。好消息是，所有这些技能都是可以学会的，你可以熟练掌握全部三大支柱。

本书分为三个部分。

第一部分：全局

在第一部分，我们将探讨如何在思考工作时采取宽广的、战略性的视角。第 1 章会先就你的角色提出一些大问题。别人对你有什么期望？Staff 工程师是用来做什么的？在第 2 章，我们会把视角拉得更远，获得一些全局观。我们会把你的工作放在上下文中审视，学会在组织中找到方向，并弄清楚你的目标是什么。最后，在第 3 章，我们会探讨如何通过制定技术愿景或战略来丰富全局。

第二部分：执行

第二部分转向战术层面，讨论领导项目和解决问题的实际操作。在第 4 章，我们会探讨如何选择做什么：我会分享一些技巧，帮你决定把时间花在哪里、如何管理精力，以及如何以不使其减损的方式“花费”你的信誉和社会资本。在第 5 章，我会讨论如何领导跨团队、跨组织的项目：为项目的成功打好基础、做出正确的决策、保持信息流通。第 6 章会探讨如何应对一路上会遇到的障碍、如何庆祝一个成功完成的项目，以及在项目被取消并干净利落地关停时如何复盘（但仍然要庆祝！）。

第三部分：更上一层楼

第三部分讲的是提升你的组织。第 7 章会探讨如何通过示范优秀工程师的行为方式来提升每个人的水平、如何公开地学习，以及如何建设心理安全的文化。我们会探讨在事故或技术分歧中如何成为“屋里的那个成年人”。第 8 章讲的是更有意识地提升同事技能的方式，比如教学和辅导、设计评审、代码评审，以及推动文化变革。最后，第 9 章会探讨如何提升你自己：如何持续成长，以及如何思考你的职业生涯。在当前的角色之后，你要去往何处？我会讨论一些选项。

在继续之前先提醒一句：这是一本关于留在技术通道上的书，而不是一本技术书。正如我所说，你需要坚实的技术基础才能成为 Staff 工程师。这本书不会帮你打下这个基础。技术能力是领域相关的，如果你正在读这本书，我假设你已经具备——或者正准备去学习——成为你所在领域最资深工程师之一所需的任何专业技能。无论“技术”对你来说意味着编码、架构、UX 设计、数据建模、生产运维、漏洞分析还是其他任何东西，几乎每个领域都有大量的书籍、网站和课程可以为你提供支持。

如果你认为技术能力是唯一重要的能力，那么你不太可能在这里找到你想要的东西。但讽刺的是，你也可能正是能从这本书中获益最多的人。无论你的技术知识多么深厚或高深，你都会发现，当你能够说服别人采纳你的想法、提升身边的工程师、轻松穿过那些拖慢所有人的组织僵局时，工作就会变得不那么烦人。这些技能并不容易学，但我保证它们都是可以学会的，我会在本书中尽我所能为你指路。

你想成为 Staff 工程师吗？不追求更资深的工程师角色也完全没问题。转到经理通道（或者来回切换！），或者留在高级级别、做你喜欢的工作，也都没问题。但如果你喜欢这样的想法：帮助实现组织的目标，在持续锻炼技术肌肉的同时，让身边的工程师在技艺上变得更好，那就请读下去吧。

O’Reilly 在线学习

40 多年来，O’Reilly Media 一直提供技术和商业培训、知识与洞见，帮助企业取得成功。

我们独特的专家和创新者网络通过图书、文章和我们的在线学习平台分享他们的知识和专长。O’Reilly 的在线学习平台让你可以按需访问直播培训课程、深入的学习路径、交互式编程环境，以及来自 O’Reilly 和 200 多家其他出版商的海量文字和视频内容。更多信息请访问 https://oreilly.com。

如何联系我们

有关本书的意见和问题，请寄给出版商：

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938（美国或加拿大境内）

707-829-0515（国际或本地）

707-829-0104（传真）

我们为本书提供了一个网页，上面列有勘误、示例和其他补充信息。你可以通过 https://oreil.ly/staff-eng-path 访问该页面。

如需对本书发表意见或询问技术问题，请发送电子邮件至 bookquestions@oreilly.com。

有关我们图书和课程的新闻与信息，请访问 https://oreilly.com。

在 LinkedIn 上找到我们：https://linkedin.com/company/oreilly-media。

在 Twitter 上关注我们：https://twitter.com/oreillymedia。在 YouTube 上观看我们：https://youtube.com/oreillymedia。

致谢

感谢许许多多帮助这本书成为现实的人。

感谢 Sarah Grey，这是我所能想象的最好的开发编辑，也感谢 O’Reilly 所有其他出色的同仁，包括组稿编辑 Melissa Duffield、制作编辑 Liz Faerm、文字编辑 Josh Olejarz、创作了精彩封面的 Susan Thompson，以及插画师 Kate Dullea，她把我的铅笔涂鸦变成了精美的插画。这是我第一次写书，是你们让这件事不再那么可怕。

感谢 Will Larson 的鼓励和支持，也感谢他帮助 Staff 工程师社区第一次找到彼此。还要感谢 Lara Hogan，当我出现在她的私信里，满心都是“可是我能写一本书吗？？”的时候，她给了我热情的鼓励并帮我引荐。感谢你们两位向我展示了举荐是什么样子。

我很幸运，在这段旅程中有两位我所认识的最睿智、最有洞察力的工程师同行。Cian Synnott 和 Katrina Sostek，过去一年里你们的审阅和反馈让这本书变得好太多了。我尤其要感谢你们针对那些行不通的部分提出的周到建议。建设性的批评总是更难的，我感激你们付出的时间和精力。

许多人慷慨地抽出时间与我讨论想法、提供反馈，或者教会我一些东西。我特别要感谢 Franklin Angulo、Jackie Benowitz、Kristina Bennett、Silvia Botros、Mohit Cheppudira、John Colton、Trish Craine、Juniper Cross、Stepan Davidovic、Tiarnán de Burca、Ross Donaldson、Tess Donnelly、Tom Drapeau、Dale Embry、Liz Fong-Jones、Camille Fournier、Stacey Gammon、Carla Geisser、Polina Giralt、Tali Gutman、Liz Hetherston、Mojtaba Hosseini、Cate Huston、Jody Knower、Robert Konigsberg、Randal Koutnik、Lerh Low、Kevin Lynch、Jennifer Mace、Glen Mailer、Keavy McMinn、Daniel Micol、Zach Millman、Sarah Milstein、Isaac Perez Moncho、Dan Na、Katrina Owen、Eva Parish、Yvette Pasqua、Steve Primerano、Sean Rees、John Reese、Max Schubert、Christina Schulman、Patrick Shields、Joan Smith、Beata Strack、Carl Sutherland、Katie Sylor-Miller、Izar Tarandach、Fabianna Tassini、Elizabeth Votaw、Amanda Walker 和 Sarah Wells。还要感谢许许多多（真的很多！）其他通过私信、电子邮件、走廊闲聊或在热烈的 Slack 讨论串中与我交流的人。你们让这本书变得更好，我很感激你们。

感谢一起喝下午茶的朋友们：你们每天都在展示社区的力量。感谢 Rands Leadership Slack 上 #staff-principalengineering 频道的每一个人，感谢你们始终如一的支持，以及谦逊地分享自己的经验。非常感谢我在 Squarespace 的同事们，以及散落各处的前 Google SRE 们。我从你们所有人身上学到了很多。我还要感谢 Ruth Yarnit、Rob Smith、Mariana Valette 以及整个 Lead Dev 团队，感谢他们与世界分享的那些精彩的技术领导力内容。感谢你们所做的一切。

感谢 Hillfolks 们，包括那只非常乖的狗狗。能有你们这样的朋友，我既幸运又荣幸。感谢你们让我在你们的房车里写作（还有在我感染新冠时让我在那里隔离！）。我期待着未来几十年的友谊，也期待看着你们种下的小橡树长大。

最后，感谢我的整个家族——我的父母 Danny 和 Kathleen，以及整个大家族——感谢你们在过去一年里我仿佛从地球上消失时的耐心。

当然，还有 Joel 和 9 岁女士！我期待着周六能再和你们在一起。感谢 Joel（是他想出了“做人”的技能就是“飞扶壁”这个比喻），感谢你和我关于工程组织和打造好软件的精彩对话。也感谢你做的所有三明治。还有 9 岁女士（我写这本书初稿时她还是 6 岁女士！）：谢谢你的绝妙点子、画作和拥抱。我爱你们这两个小笨蛋。

1. 不过在面试时，你可不能回答“一个同时也是宇航员的动物园管理员”。成年人的生活真是处处受限。 ↩

2. 为了简洁起见，本书通篇都会说“软件工程师”；不过，如果你是系统工程师、数据科学家或任何其他技术从业者，我想你也会发现本书与你相关。欢迎所有人！ ↩

3. 这种情况正在改变。Will Larson、LeadDev 等人一直在做出色的铺路工作。我会在全书中给出相关资源的链接。 ↩

4. 我保留以后改变主意的权利。 ↩

5. 本书在谈到雇主时会使用“公司”一词，但你当然也可能在非营利组织、政府机构、学术机构或其他类型的组织中工作。请替换成对你来说合适的说法。 ↩

6. 还有更多。可以看看 Camille Fournier 的文章“An Incomplete List of Skills Senior Engineers Need, Beyond Coding”。 ↩