作为一名 Staff Engineer，我为何无视聚光灯

从纸面上看，很符合他描述的模子：我是 Google 的一名资深主任工程师（Senior Staff Engineer）。然而，读完他的文章，我心头却挥之不去一种不安感。起初，我把这种感觉归咎于他有些愤世嫉俗。但在反思之后，我意识到问题不在于 Sean 的写作，而在于我自己的解读。

Sean 并没有悲观厌世；他是在精准地描绘如何在一个工程师被视为可替代资产、优先级按季度变动的世界中生存。但我的工作与其描述的大相径庭，而且我在内心深处很清楚，如果我试图在那种环境中工作，或者按照他描述的方式行事，我会在**几个月内**就职业倦怠。

相反，我选择了一条不同的路径，一条**重系统而轻聚光灯**，**重管家精神而轻随时可替**的优化之路。

我们生活在不同的世界

导致我们分道扬镳的根本原因在于，Sean 和我是在截然不同的世界里运作，各自受到不同法则的支配。

从 Sean 的简历来看，我的理解是他主要在面向外部客户构建产品的产品团队中工作 ¹。那里的业务目标按季度调整，成功与否通过收入或月活跃用户数（MAU）来衡量。在这种环境下，追求“聚光灯”是完全合理的。大型科技公司的产品开发就像是一个拥挤的房间：副总裁（VP）、产品经理（PM）和用户体验设计师（UX designer）都有着强烈的个人观点。为了取得成功，你必须保持敏捷，并确保自己做的正是高管们当前所关注的事情。

另一方面，我的整个职业生涯都更多地处于幕后：在开发者工具和基础设施团队中度过。

我所在团队的客户是 Android、Chrome 以及整个 Google ² 的数千名工程师。Google 产品的最终用户甚至不知道我们的存在；我们的工作重点是确保开发者拥有必要的工具，能够收集产品与性能指标，并利用详细的追踪记录来调试问题。

在这种环境下，我们与领导层的关系截然不同。我们从来都不是“人人都想参与的热门项目”，所以高管们不会争着要把我们纳入麾下。事实上，我的团队历来都很难招到 PM（产品经理）。Google 的 PM 晋升阶梯鼓励那些能够制造轰动效应的外部发布，而我们无法为他们提供这种用来晋升的“好素材”。此外，我们的反馈直接来自于工程师。如果在中间加一个 PM，反倒会造成信息失真，从而拖慢原本紧密、高带宽的反馈循环。

所有这些因素综合起来，意味着我们团队是以“自下而上”的方式运作的：并非由高管告诉我们“你们应该做 X”，而是由我们自己去弄清楚哪些事情对客户影响最大，然后着手构建相应的功能和工具。高管们通过考量我们对那些更面向产品的团队所产生的影响，来确保我们是在*真正*解决问题。

管家式管理的复利回报

在 Sean 描述的产品开发环境中，目标每季度一变，功能特性常带有实验性质，在这种情况下，**速度**就是终极货币。你必须在市场风向转变之前发布、迭代，并常常需要迅速转向。但在基础设施和开发者体验领域，**上下文情境（context）** 才是货币。

将工程师视为可替代的资产会破坏这种上下文情境。你或许能获得新鲜的视角，但却丢失了关于系统实际上是如何崩溃的隐性知识。管家式管理（Stewardship）——即长期坚守一个系统——能够解锁在短期轮岗中无法实现的复利回报。

首先是通过**模式匹配**带来的效率提升。当你在一个领域深耕数年，新的需求很少是真正“崭新”的。我不仅仅是在调试代码；我是在调试我的工具与成百上千个不同工程团队之间的交集。当一个新团队带着一个“独特”的问题来找我时，我通常可以回溯过往：*“我们在 2021 年这相继团队尝试过这种方法；这里是它失败的确切原因，而这里是实际行得通的架构。”*

但更有力的回报在于**系统性创新**。如果你每年都轮岗换团队，你将局限于解决那些*当下*显而易见的急迫故障。然而，有些问题的全貌，只有在长周期中才会显现出来。

以我最近领导的 **Bigtrace** 项目为例；这个解决方案之所以能出现，完全是因为我在这个领域待得足够久，才得以看清了问题的全貌：

• **2023 年初（观察）：** 我开始注意到某种模式。Google 内部的各个团队都在收集 TB 级甚至 PB 级的性能追踪数据（performance traces），但在处理这些数据时却举步维艰。工程师们不得不编写脆弱的定制流水线来解析数据，且经常抱怨在分析这些数据时迭代速度慢、体验痛苦。
• **2023年的大部分时间（研究）：** 我没有急于构建一个生产级系统。相反，在处理其他项目的同时，我花了这一年的绝大部分时间在后台静悄悄地进行原型开发。我从那些抱怨过的工程师那里收集反馈，正因为我已经建立了长期的合作关系，他们给了我诚实且深入的反馈。我了解了他们对用户体验、延迟和吞吐量的具体要求，并想出了满足这些要求的方法。
• 2023 年底至 2024 年初（执行阶段）： 我们构建并发布了 Bigtrace，这是一个用于链路追踪（Trace）的分布式大数据查询引擎。如今，它每月处理超过 20 亿条追踪数据 ，已成为 100 多位工程师日常工作流中不可或缺的一部分。

如果我听从了“追求通用性（即为了追逐新项目而在 2023 年转组）”的建议，Bigtrace 绝不会诞生。

相反，我会在调研阶段离开，而我的继任者看到的只是一样的“噪音”——工程师们的抱怨。但由于缺乏历史背景来识别那一块缺失的拼图，我认为他们很难构建出像 Bigtrace 这样的系统。

说“不”的力量

追逐“聚光灯”最诱人的理由之一，是它能确保获得资源和高层的关注。但这关注度是一把双刃剑。

高曝光度的项目往往充满变数。它们伴随着高层反复无常的想法、内部政治博弈，并常常陷入为了短期生存而牺牲长期质量的境地。对某些工程师来说，驾驭这种混乱是一种刺激。但对于像我们这样在乎系统稳定性的人来说，这感觉就像是个陷阱。

做好“管家”角色的优势在于，它能产生一种不同形式的资本： 信任 。当你经年累月地交付可靠的工具，你就积攒了政治资本，当聚光灯威胁到产品时，你才有底气对它说“不”。

最近，聚光灯打在了人工智能上。每个团队都面临着整合 AI 的压力。我们也被反复问到：“你们为什么不在 Perfetto 里集成 LLMs？” 如果我仅仅是为了追求曝光度，答案显而易见：做一个 LLM 的外壳，向领导层演示，然后声称我们是“AI 优先”的。这对我的职业生涯来说将是一场轻松的胜利。

但作为系统的守护者，我深知 Perfetto 的核心价值观之一是**精确性**。当内核开发人员正在调试竞态条件（race condition）时，他们需要的是准确的时间戳，而不是凭空捏造的数据（hallucination）。用户信任我们，当我们告诉他们“X 是问题所在”时，那实际上*就是*问题所在，他们才不会在接下来的一周里白费力气，去调试一个根本不存在的问题。

但重要的是不要矫枉过正：怀疑主义不应变成阻碍主义。对于 AI，答案并非“永远不行”，而是“等到能正确实施时再行”³。

一位追逐聚光灯的工程师可能会将这种做法视为错失良机；而我则将其视为在保护成就我们产品的根本：用户信任。

影响力的另一种货币

工程师对于离开“聚光灯”最常见的恐惧就是职业生涯停滞。他们的逻辑通常是： 如果我不能在 Google I/O 大会上发布耀眼的新功能，而且我的工作也没有进入副总裁的前五项重点清单，我怎么可能晋升到 Staff+（主任工程师及以上）级别呢？

确实，你会失去“高管可见度”这一筹码。但在基础设施领域，你会获得另外两种同样有价值，甚至可能更稳定的筹码。

影子层级

在产品型组织中，你通常需要给自己经理的经理留下好印象。但在基础设施型组织中，你需要打动的是**你客户的经理**。

我称之为**影子层级（Shadow Hierarchy）。**你不需要让*你的*副总裁（VP）去理解你代码里的细枝末节。你需要的是*其他*关键部门里的 Staff+ 工程师（资深及以上工程师）**离不开**你的工具。

当一位 Pixel 部门的高级主任工程师（Senior Staff Engineer）告诉他们的副总裁，*“如果没有 Perfetto，我们根本无法调试下一代 Pixel 手机”*时，这句话的分量极重。它会沿着他们的汇报链向上传递，在总监/副总裁这一层级进行跨部门交流，然后再传回到你的经理那里。

这种支持之所以强有力，是因为它是基于技术而非政治的。这很难造假。当你是一个关键系统的守护者时，你的晋升材料里会填满公司里最受尊敬的工程师们的证言，他们会说：*“此人的工作成就了我们的成功”。*

效用账本（Utility Ledger）

虽然产品团队可能在钻研日活跃用户数或营收数据，但我们依赖的是追踪**工程健康度**的指标：

• **实用性：** 每一个使用我们的工具修复的漏洞，都代表着一位工程师觉得我们有用。这是衡量实用性最纯粹的标准。
• **关键性：** 如果 Pixel 团队使用 Perfetto 调试导致发布受阻的卡顿问题，或者 Chrome 团队用它来修复内存泄漏，我们的影响力就与他们的成功隐性地绑定在了一起。
• **普及度：** 覆盖相当大比例的工程师群体，证明你已经创造了一种技术上的“通用语”。当你看到公司内部互不相关的部门通过分享 Perfetto 追踪记录来进行协作，并将其作为一种“每个人都看得懂的参考”时，这一点就变得尤为明显。
• 规模： 摄入 PB 级数据或处理数十亿条追踪记录，比任何设计文档都更能证明架构的弹性。

当你将重要性 （VIP 团队需要这个）与实用性 （正在修复漏洞）结合起来时，你就构建了一个能够免疫高层重组影响的晋升案例。

原型与能动性

Staff 工程师原型

关于“成为主任（Staff）软件工程师有多种途径”这一观点，我绝非在此方面有所观察的第一人。威尔·拉尔森（Will Larson）在其著作 《Staff Engineer》 中，将主任及以上级别的工程师归纳为四种截然不同的原型。

Sean 描述的是**问题解决者（Solver）** 或**左膀右臂（Right Hand）**：这类工程师充当高管意志的代理人，在紧急事态中空降救火，一旦问题稳定下来便迅速抽身。而我所描述的是**架构师（Architect）** 或**技术负责人（Tech Lead）**：这类角色的定义在于对特定领域的长期所有权以及深厚的技术背景。

关于“运气”的反驳

我已经能听到批评的声音了：“你只是运气好找到了那个团队。我们大多数人没那样的福气。”

对于这篇文章中我给出的所有建议，有两点需要说明。首先，我目前采用的策略需要一家利润丰厚、足以支撑长期基础设施建设的公司。这种路径通常不存在于初创企业或早期成长型公司中；它是专为科技巨头（Big Tech）优化的。

其次，运气在进入一个好团队的过程中确实起到了作用。从外部很难准确评估团队和公司的文化。但是，虽然找到这个团队可能包含运气的成分，但在那里待了近十年却是一个选择 。

而且，至少从我的经验来看，我的团队并不算特别特殊：光是在 Android 部门，我就能列举出另外五个这样的团队 ⁴。当然，他们可能会时不时换个总监，或是换个副总裁，但核心使命和工程团队始终保持稳定。

这些团队之所以显得稀有，并非因为它们不存在，而是因为经常被忽视。由于它们既不具备产品发布那种快速、显眼的“胜利”，也不是在开发那些“光鲜亮丽的新功能”，因此吸引的竞争也较少。如果你是被“将产品推向数十亿用户”或者“看着亲朋好友使用你开发的东西”所激励，你在这里是找不到那种满足感的。这就是入场的代价。

但是，如果你想要构建长期的系统，并且愿意用外部认可来换取深度的技术所有权，你只需要看向幕后即可。

结论

科技行业热衷于告诉你要快速行动。但还有另一条路。在这条路上，影响力源自深度、耐心，以及建立让即便他人也能据此立足的基础所带来的那份静谧的成就感。

你不必在大公司里追逐聚光灯才能拥有充满意义、高影响力的职业生涯。有时，你所能做的最雄心勃勃的事情，就是安于当下、深耕细作，并构建那些经得起时间考验的事物。比如花数年时间与一个问题空间为伴，直到你对其了如指掌，足以构建像 Bigtrace 这样的系统。