一本讲 Staff 工程师的书，也是 FDE 的实战手册

多年来，企业奖励最优秀工程师的方式，往往是给他们一个管理岗位。Tanya Reilly 在 The Staff Engineer’s Path 开篇就点出了这一现象，随后用整本书描绘了另一条路。

这条路就是 Staff 工程师路径。按书中的描述，走这条路的工程师可以在资深层面做出贡献，比如成为他人的榜样，而不必转做管理。

书名里没有提到 FDE。但如果把前线部署工程师（FDE）的工作理解为：在客户侧主导大型、模糊、横跨多个团队的工作，却没有发号施令的权力，那么这本书几乎就是为这种处境写的手册。本文正是从这个角度来读它。

作者是谁？

据发行商 Ingram Academic 的页面，本书由 O’Reilly Media 出版，印刷日期为 2022 年 10 月 25 日。Reilly 此前因文章《Being Glue》为人熟知。她在文中给胶水工作（glue work）起了名字：那些衔接、支持性的任务，能帮到队友，让整个项目成功。

在 Reilly 看来，胶水工作正是项目成败的分水岭。

她并非这个话题的局外人。在本书的介绍页上，Reilly 提到，她为 Will Larson 的 Staff Engineer 写过序，也主持过 LeadDev 的首届 Staff Engineering 大会。

三个部分，一个问题：没人向你汇报时，如何领导？

Reilly 把全书概括为三部分：全局视野、执行项目、自我提升。第一部分教你理解公司的全局，再通过愿景和战略为他人重新描绘这幅图景，还讲到要有魄力做出那些卡住别人的重大决策。

第二部分讨论大型、模糊、跨组织的项目。无论多难，Staff+ 工程师都得把它们推过终点线。这部分讲如何熬过艰难阶段，以及如何在项目全程管理时间、精力和社会资本。

第三部分把 Staff+ 工程师看作力量倍增器，也就是让整个团队变强的人。直接影响来自指导、举荐和辅导，间接影响来自以身作则。这部分还谈到如何提升自己，以及如何把自己的工作“交接”给别人。

用在一个停滞的决策上

书中最值得带走的观点，是要主动拍板那些卡住别人的决策。设想一个场景：你在为客户部署一个 Agent，两周过去了，仍然没人决定 Agent 应该直接读生产数据库，还是读每晚的导出数据。数据、安全和运维三个团队都在等。

了结这个问题的办法是一页纸提案：列出两个方案、各自的代价、你推荐的方案和理由，并写明谁需要审批、何时之前审批。一个有负责人、有截止时间的决策，远比一场没有终点的讨论难以搁置。

常见错误有三个。等三个团队完全达成一致，问题就会无限期悬着。独自决定后直接宣布结果，又会疏远恰恰要负责运行这套系统的人。

第三个错误与第二部分的教训有关：事先把社会资本全耗在小事上。当你需要三个团队在一周内开放数据权限时，手里剩下的信任决定了他们帮不帮你。

决策做出之后，“交接工作”的理念提醒你把理由记录下来，这样客户团队下次遇到类似问题时，没有你也能处理。

这些观点要和《Being Glue》中的警告一起读：Reilly 写道，过早承担胶水工作可能限制职业发展，甚至把人逼出这个行业。实用的建议是：在简历或面试中描述衔接性工作时，要配上一个具体的技术成果。

按什么顺序读？

对于有 2–8 年经验的开发者，建议先读 noidea.dog 上的《Being Glue》。文章不长，可以先熟悉作者的文风。

等手头有一个真实项目可以对照时，再读第一部分。第三部分留到你开始指导别人时再读。如果想换个视角，Will Larson 的 Staff Engineer 涉及同样的主题，Reilly 正是为这本书写的序。

读 FDE 岗位描述时，留意“ambiguous”“cross-functional”“stakeholder”这类词。遇到这些场合，你需要一个像上文场景那样的故事：具体的决策、具体的审批人、具体的结果。

这本书写给想升到 Staff 级别又不想转管理的人。如果你选择的路是和客户并肩工作，这些能力会更早受到考验，这更是早点读它的理由。