第 1 章 你在这里到底是做什么的？

Staff 工程师职级通道，或者说“技术通道”，对很多公司来说还是新鲜事物。对于最资深的工程师应当具备哪些特质、应该做什么样的工作，各个组织的看法并不相同。尽管大多数人都认同 Silvia Botros 所写的，技术通道的顶端并不只是“更资深的高级工程师”，但对于它到底是什么，我们并没有共识。所以本章先从一个存在主义的问题开始：组织为什么会希望留住非常资深的工程师？带着这个理解，我们再来拆解这个角色：它的技术要求、领导力要求，以及自主工作意味着什么。

Staff 工程师的角色形态多种多样，做好这份工作的方式也有很多种。但某些形态更适合某些场景，而且并不是每个组织都需要所有类型的 Staff 工程师。所以我会谈谈如何刻画和描述一个 Staff 工程师角色：它的范围、深度、汇报关系、主要关注点以及其他属性。你可以用这些描述来准确表达你希望怎样工作、你想成长为什么样的角色，或者你需要招聘什么样的人。最后，由于不同公司对 Staff 工程师该做什么有不同的看法，我们会努力让你的理解与组织中其他关键人物的理解保持一致。

我们先从这份工作究竟是什么说起。

Staff 工程师到底是什么？

如果唯一的职业路径就是成为经理（就像图 1-1 左侧所描绘的公司那样），很多工程师将面临一个严峻而艰难的选择：要么继续留在工程岗位上，不断精进手艺；要么转向管理，换取职业上的成长。

所以，现在很多公司提供“技术”或“个人贡献者”（IC）通道，让职业发展可以与经理角色并行，这是件好事。图 1-1 右侧的职级阶梯就是一个例子。

图 1-1. 两个职级阶梯示例，其中一个有多条路径。

不同公司的职级阶梯差异很大，大到甚至催生了一个网站 levels.fyi，专门对比各家公司的技术通道职级。¹ 这些阶梯的级数各不相同，每一级的名称也各不相同。你甚至会看到同样的名称以不同的顺序排列。² 但高级（senior）这个词经常出现。Marco Rogers 是一位工程总监，曾在两家公司设计过职级体系，他把高级这一级称为职级阶梯的“锚点”级别。用 Rogers 的话说：“锚点以下的级别是让人提升自主性的；锚点以上的级别则是扩大影响力和责任。”

高级有时被看作“终身”级别：你不必再往上走。³ 但如果你继续往上，就进入了“技术领导”的级别。高级之上的第一级通常叫作“Staff 工程师”，本书通篇都会使用这个名称。

在图 1-1 的双通道职级阶梯中，高级工程师可以选择培养相应技能，晋升为经理或 Staff 工程师。晋升之后，从 Staff 工程师转为经理，或者反过来，都被视为平级调动，而不是进一步晋升。高级 Staff 工程师与高级经理同级，首席工程师（principal engineer）相当于总监，以此类推；在公司的职级体系里，这些级别还可能继续往上延伸。（为了指代高级以上的所有角色，我会使用 Staff+ 这个说法，它是 Will Larson 在他的著作 Staff Engineer 中提出的。）

关于头衔

我偶尔听到有人坚持说职位头衔和职级不应该（或者并不）重要。持这种观点的人往往会说一些合理的话：他们的公司是平等的精英体制，对等级制度的危害保持警惕。“我们是自下而上的文化，所有想法都会被尊重。”他们说。这是个值得称赞的目标：职业生涯处于早期，绝不应该意味着你的想法会被忽视。

但头衔确实重要。Medium 的工程团队写过一篇博客，列出了头衔之所以必要的三个原因：“帮助人们认识到自己在进步；赋予那些可能无法自然获得权威的人以权威；向外界传达预期的能力水平。”

第一个原因是内在的，也许并不是每个人的动力；但另外两个原因描述的是头衔对他人产生的影响。无论一家公司是否自称扁平、平等，总会有人对不同级别的人区别对待，而且我们大多数人多少都有点在意地位。正如科罗拉多州立大学创业学临床教授 Kipp Krukowski 博士在他 2017 年的论文《员工职位头衔对客户所给予尊重的影响》中所说：“职位头衔起着符号的作用，公司用它们向公司内外的人传递员工的特质。”

我们无时无刻不在对他人做出隐性的判断和假设。除非我们花了大量时间和精力去觉察自己的隐性偏见，否则这些假设很可能会受到刻板印象的影响。例如，2015 年的一项调查发现，在受访的 557 名 STEM 领域的黑人和拉丁裔职业女性中，约有一半曾被误认为是清洁工或行政人员。

当一位软件工程师走进一场都是陌生人的会议时，类似的隐性偏见也会起作用。白人和亚裔男性软件工程师常常被默认为更资深、更“懂技术”、更会写代码，无论他们是昨天刚毕业，还是已经干了几十年。女性，尤其是有色人种女性，则被默认为更初级、能力更弱。她们必须在会上付出更多努力，才能被认为是称职的。

正如 Medium 那篇工程文章所说，职位头衔赋予那些可能无法自然获得权威的人以权威，并传达出他们预期的能力水平。通过锚定预期，头衔为他们省下了原本要一次又一次证明自己所花的时间和精力，让他们每周多出几个小时。

你现在的头衔还会影响你的下一份工作。和业内许多人一样，我每天都会在 LinkedIn 上收到招聘人员的邮件。在我的人生中，恰好只有三次，主动找上门的招聘邮件邀请我去面试比我当时头衔更高的职位。其余所有邮件推荐的职位，要么与我当时的级别完全相同，要么更低。

以上就是这份工作在职级阶梯上是什么样子。下面我们来看看技术领导级别为什么存在。我在引言中谈到了技术通道的三大支柱：全局思考、项目执行和整体提升。为什么我们需要工程师具备这些技能？我们到底为什么需要 Staff 工程师？

为什么我们需要能看清全局的工程师？

任何工程组织都在不断做决策：选择技术、决定要构建什么、投资某个系统或者废弃它。有些决策有明确的负责人和可预期的后果；另一些则是基础性的架构选择，会影响其他所有系统，没有人敢说自己确切知道它们会如何演变。

好的决策需要上下文。有经验的工程师都知道，大多数技术选型问题的答案都是“视情况而定”。仅仅知道某项技术的优缺点是不够的——你还需要了解本地的具体情况。你想做成什么？你有多少时间、资金和耐心？你的风险承受能力如何？业务需要什么？这些就是决策的上下文。

收集上下文需要时间和精力。各个团队往往会为自身利益做优化；单个团队里的工程师很可能会全神贯注于实现本团队的目标。但很多看似属于某一个团队的决策，其后果往往远远超出该团队的边界。局部最优，即对单个团队最好的决策，从更广的视角看，可能根本算不上最好的决策。

图 1-2 展示了一个例子：某个团队要在 A、B 两款软件中做选择。两者都具备所需的功能，但 A 的搭建要容易得多：开箱即用。B 稍微麻烦一些：需要折腾几个迭代（sprint）才能跑起来，没人乐意等那么久。

从团队的角度看，A 是明摆着的赢家，他们为什么要选别的？但其他团队会更希望他们选 B。原来，A 会给法务和安全团队带来持续的工作量，而它的认证需求意味着 IT 和平台团队将永远不得不把它当作特例来处理。选择 A 这个局部最优解，团队在不知不觉中选了一个让整个公司投入大得多时间的方案。B 对团队来说只是稍差一点，但从整体上看要好得多。多出来的那两个迭代在一个季度之内就能收回成本，但只有当团队里有人能用更广的视角看问题时，这个事实才会显而易见。

图 1-2. 局部最优与更好的决策。

为了避免局部最优，团队需要这样的决策者（或至少是决策影响者）：他们能采取局外人视角——能同时考虑多个团队的目标，选出一条对整个组织或整个业务最好的道路。第 2 章会讲如何拉远视角、看清更大的全局。

与看清当下的全局同样重要的，是能够预见你的决策在未来会如何演变。一年后，你会后悔什么？三年后，你会希望自己现在就开始做什么？为了朝同一个方向前进，各个团队需要在技术战略上达成一致：投资哪些技术、在哪些平台上实现标准化，等等。这些重大决策可能非常微妙，而且常常充满争议，所以做出决策的关键在于能够分享上下文，并帮助他人理解它。第 3 章讲的就是如何作为一个集体来选择方向。

所以，如果你想做出广泛的、着眼未来的决策，你就需要能看清全局的人。但为什么不能由经理来做？为什么首席技术官（CTO）不能直接掌握所有“业务上的事”，把它们转化为技术成果，再把重要的信息传达下去？

在有些团队里，他们确实可以。对于小团队，经理往往可以充当最有经验的技术专家，主导重大决策和技术方向。在小公司里，CTO 可以深度参与每个决策的细枝末节。这些公司可能并不需要 Staff 工程师。但管理权威可能会盖过技术判断：即使存在更好的方案，下属也可能不太敢反驳经理的技术决策。而且，管理他人本身就是一份全职工作。一个致力于成为优秀人员管理者的人，用来跟进技术发展的时间就会更少；而任何一个坚持深入“一线细节”的经理，满足下属需求的能力也会打折扣。短期内这可能没问题：有些团队不需要太多关注就能继续走在成功的路上。但当团队的需求和技术战略的需求之间出现张力时，经理就必须选择把精力放在哪里。要么团队成员被忽视，要么技术方向被忽视。

这就是许多组织为技术领导和人员领导设立不同路径的原因之一。如果你有不止几个工程师，每个决策都要摆到 CTO 或高级经理的桌上，这既低效，又削弱了其他人的能动性。如果有经验的工程师有时间深入下去、建立上下文，并拥有设定正确技术方向的权威，你就能得到更好的结果和设计。

这并不意味着由工程师单独设定技术方向。经理负责为技术项目分配人力，因此必须参与重大技术决策。我会在本章后面谈到如何保持工程师与经理之间的一致，在第 3 章讨论战略时还会再谈。

那架构师呢？

在一些公司里，“架构师”是技术通道职级阶梯上的一级。在另一些公司里，架构师是抽象的系统设计者，有自己独立的职业路径，与实现系统的工程师分开。在本书中，我会把软件设计和架构视为 Staff+ 工程师角色的一部分，但请注意，这在我们这个行业里并非普遍如此。

为什么我们需要能领导跨团队项目的工程师？

在理想世界里，组织中的各个团队应该像拼图块一样严丝合缝地拼在一起，覆盖任何进行中项目的方方面面。不过，在这个理想世界里，每个人都在做一个漂亮的全新绿地项目，没有任何先前的约束，也没有需要迁就的遗留系统，而且每个团队都全身心投入这个项目。团队边界清晰，没有争议。事实上，我们一开始就采用了 Thoughtworks 技术顾问所说的“逆康威策略”（Inverse Conway Maneuver）：一组与目标架构的各个组件完全对应的团队。这个乌托邦式项目的难点之所以难，只是因为它们涉及深刻而迷人的研究与发明，而负责它们的人渴望迎接技术挑战，并享受解决问题带来的职业荣耀。

我想做那样的项目，你不想吗？可惜现实有些不同。几乎可以肯定，参与任何跨团队项目的团队，在这个项目被构想出来之前就已经存在了，而且正在做别的事情，甚至可能是他们认为更重要的事情。他们会在项目进行到一半时发现意想不到的依赖。他们的团队边界存在重叠和空白，这些都会渗透到架构中。而项目中那些模糊而困难的部分，并不是迷人的算法研究问题：它们需要你在遗留代码中摸索探险，与不想做任何改动的忙碌团队谈判，揣摩多年前就已离职的工程师的意图。⁴ 就连搞清楚需要改什么，都可能是个复杂的问题，而且并非所有工作在一开始就能知晓。如果你仔细看设计文档，可能会发现那些最需要达成共识的关键决策，要么被推迟了，要么被一笔带过。

这才是更现实的项目描述。无论你把团队多么仔细地覆盖到一个大项目上，总有一些职责最终无人负责，而另一些则被两个团队同时认领。信息无法流通，或者在传递中被曲解，从而引发冲突。各个团队都做出了出色的局部最优决策，然后软件项目就卡住了。

让项目持续推进的一种方法，是有一个人对整件事有主人翁意识，而不是只对其中某个部分负责。甚至在项目启动之前，这个人就可以划定工作范围、撰写提案。项目开始后，他们很可能是高层系统设计的作者或合著者，也是这个设计的主要联系人。他们坚持高标准的工程质量，用自己的经验预见风险、提出尖锐的问题。他们还会花时间非正式地指导或辅导项目各个部分的负责人——或者仅仅是为他们树立好榜样。当项目卡住时，他们有足够的视野去追查原因并疏通障碍（第 6 章会详细讨论）。在项目之外，他们讲述正在发生什么以及为什么，向公司其他人推销愿景，并解释这项工作会带来什么可能、新项目将如何影响每个人。

为什么技术项目经理（TPM）不能来做这些建立共识和沟通的工作？两者的职责确实有一些重叠。但归根结底，TPM 负责的是交付，而不是设计，也不是工程质量。TPM 确保项目按时完成，而 Staff 工程师确保项目以高工程标准完成。Staff 工程师负责确保最终的系统健壮可靠，并与公司的技术版图良好契合。他们对技术债务保持谨慎，对任何会给这些系统未来维护者埋坑的东西保持警惕。TPM 写技术设计，或为测试、代码评审设定项目标准，这是很少见的；也没人指望他们深入剖析遗留系统的内部，来判断哪些团队需要与之集成。当 Staff 工程师和 TPM 在大项目上配合默契时，他们可以成为梦之队。

为什么我们需要能发挥良好影响力的工程师？

软件很重要。我们构建的软件系统会影响人们的福祉和收入：维基百科上的软件缺陷列表值得一读，尽管读来令人清醒。我们已经从飞机失事、急救系统故障和医疗设备失灵中了解到，软件缺陷和服务中断可能致人死亡；如果天真地认为未来不会出现更多、更严重的软件相关悲剧，那就太幼稚了。⁵ 我们需要认真对待软件。

即使利害关系没那么大，我们做软件也总是有原因的。除了少数研发性质的例外，工程组织通常不是为了构建更多技术而存在的。它们的目标是解决实际的业务问题，或者创造人们愿意使用的东西。而且它们希望以可接受的质量、高效的资源利用和最少的混乱来实现这一点。

当然，质量、效率和秩序远非理所当然，尤其是在有截止日期的时候。如果“做对”意味着要放慢速度，急于上线的团队可能会跳过测试、偷工减料，或者在代码评审时走过场。而且，做出好的软件既不容易，也不直观。团队需要资深的人：他们磨炼过技能，见过什么会成功、什么会失败，并且愿意为做出能用的软件负责。

我们从每个项目中学习，但每个人可以反思的经历都是有限的。这意味着我们也需要从彼此的错误和成功中学习。经验较少的团队成员可能从未见过好的软件是如何做出来的，或者可能认为写代码是软件工程中唯一重要的技能。更资深的工程师可以通过开展代码评审和设计评审、提供架构最佳实践，以及打造让每个人都更快、更安全的工具，产生巨大的影响。

Staff 工程师是榜样。经理可能负责塑造团队文化、规范行为、确保达到标准。但工程规范是由项目中最受尊敬的工程师的行为决定的。不管标准怎么写，如果最资深的工程师不写测试，你永远不可能说服其他所有人去写。这些规范不仅关乎技术影响，也关乎文化。当资深的人公开赞赏他人的工作、彼此尊重、提出澄清性的问题时，其他人也更容易这样做。当职业早期的工程师把某人视为自己“长大后”想成为的那种工程师时，这会强有力地激励他们效仿。（第 7 章会探讨如何通过成为榜样来提升整个组织。）

也许你现在已经相信，工程师应该做这些看全局、做大项目、发挥良好影响的事情了，但问题在于：他们不可能在承担高级工程师编码工作量的同时再做这些。你花在写战略、评审项目设计或制定标准上的每一个小时，都不是在写代码、设计新系统，或者做软件工程师通常会被考核的那些工作。如果一家公司最资深的工程师整天只写代码，代码库会受益于他们的技能，但公司会错失那些只有他们才能做的事情。这种技术领导工作必须写进承担者的职位描述。它不是对本职工作的干扰：它就是本职工作。

哲学讨论到此为止。我的工作是什么？

Staff 工程师角色的细节会各不相同。不过，我认为这份工作有一些属性是相当一致的。我会在这里把它们列出来，本书其余部分都会把它们当作公理。

你不是经理，但你是领导者

首先要明确：Staff 工程师是一个领导角色。Staff 工程师通常与一线经理同级，首席工程师通常与总监同级。作为 Staff+ 工程师，你是同级经理的对等角色，人们期望你和他们一样，是“屋子里的那个成年人”。你甚至可能发现，自己比组织中的某些经理更资深、更有经验。每当出现“应该有人来处理一下”的感觉时，那个“有人”很有可能就是你。

你必须当领导者吗？中级工程师有时会问我，想要继续往上走，他们是否真的需要擅长“那些软乎乎的人际关系的事”。技术能力还不够吗？如果你当初投身软件工程就是因为想做技术工作，并不喜欢和人打交道，那么你的职业撞上这堵墙，可能会让你觉得不公平。但如果你想继续成长，仅仅深耕技术只能带你走到某个程度。要完成更大的事情，就意味着要与更大的群体合作——而这需要更广泛的技能。

随着你的薪酬增加、时间变得越来越昂贵，人们会期望你的工作更有价值、影响更大。你的技术判断需要把业务现实考虑进去，包括某个项目到底值不值得做。随着资历提升，你会承担更大的项目，而这些项目离不开协作、沟通和共识；如果你无法说服团队中的其他人相信你的方案才是正确的道路，那么你的绝妙方案只会让你沮丧。而且，无论你愿不愿意，你都会成为榜样：其他工程师会通过观察那些头衔响亮的人，来理解应该怎样行事。所以，答案是否定的：你无法避免成为领导者。

不过，Staff 工程师的领导方式与经理不同。Staff 工程师通常没有直接下属。虽然他们会参与并投入于提升身边工程师的技术能力，但他们不负责管理任何人的绩效，也不审批休假或报销。他们不能开除或提拔任何人——尽管团队的经理应该重视他们对其他成员技能和产出的看法。他们的影响通过其他方式发生。

领导力有很多种形式，其中一些你可能不会马上意识到那就是领导力。它可以来自设计“快乐路径”方案，让其他工程师免于犯常见错误。它可以来自评审其他工程师的代码和设计，并以一种能提升他们信心和技能的方式进行；也可以来自指出某个设计提案并不满足真实的业务需求。教学是一种领导力。悄无声息地提升所有人的水平是领导力。设定技术方向是领导力。最后，还有一种：拥有杰出技术专家的声誉，别人仅仅因为信任你就愿意支持你的计划。如果这听起来像你，那么你猜怎么着？你就是领导者。

是的，你可以内向。不，你不能是个混蛋。

“成为领导者”这个想法会让很多人有点发怵。别担心：并不是所有 Staff 和首席工程师都需要是“社交达人”。Staff 工程师这个领域有足够的空间容纳内向的人——即使是最安静的工程师，也可以凭借判断力和良好的影响力设定强有力的技术方向。你不必喜欢与人相处才能成为好的领导者。但你必须成为榜样，而且必须善待他人。

我们很多人甚至都有关于“那个工程师”的故事：因为太难相处，没人愿意和他打交道，于是被晾在了角落里。20 世纪 80、90 年代的技术文化（以 Usenet 之类的讨论为代表）热衷于那种难相处、令人不快的软件工程师的流行形象：同事们不仅容忍他们的行为，甚至为了避免和他们打交道而做出奇怪的技术决策。然而在今天，这样的工程师是一种负担。不管他们的产出有多高，很难想象有谁值得以其他工程师的产出和成长下降为代价，更别提当这位工程师拒绝跨团队协作时那些失败的项目了。选择这样的人作为榜样，可能会搞垮整个组织。

如果你怀疑同事们会觉得这个专栏说的就是你，可以看看《善意工程》（Kind Engineering），Squarespace 的 SRE 经理 Evan Smith 在其中就如何成为一个主动善待他人的同事给出了具体建议。你会惊讶地发现，难以共事的名声可以多么快地扭转过来。

你处在一个“技术”角色中

Staff 工程师是一个领导角色，但同时也是一个高度专业化的角色。它需要技术背景，以及那些来自工程经验的技能和直觉。要发挥良好的影响，你需要对卓越的工程是什么样子有很高的标准，并在自己构建东西时以身作则。你对代码或设计的评审应该对同事有启发作用，并让你的代码库或架构变得更好。在做技术决策时，你需要理解其中的权衡，并帮助其他人也理解它们。你需要能够在必要时深入细节、提出正确的问题并理解答案。当你主张某种行动方案或某种技术文化的变革时，你需要知道自己在说什么。所以你必须拥有扎实的技术基础。

这并不一定意味着你会写很多代码。在这个级别，你的目标是高效地解决问题，而编程往往不是你时间的最佳用途。更合理的做法可能是承担只有你才能做的设计或领导工作，让其他人去编程。Staff 工程师常常接手那些模糊、混乱、困难的问题，只做足够的工作让它们变得可以由别人来处理。一旦问题变得可控，它就成为经验较少的工程师的成长机会（有时会得到 Staff 工程师的支持）。

对一些 Staff 工程师来说，深入钻研代码库仍然是解决很多问题最高效的工具。对另一些人来说，写文档可能效果更好，或者成为数据分析大师，或者开数量多到吓人的一对一会议。重要的是问题得到了解决，而不是怎样解决的。⁶

你力求自主

刚开始做工程师时，你的经理可能会告诉你做什么、怎么做。到了高级，你的经理也许会建议你哪些问题值得解决，然后让你自己想办法。到了 Staff+ 级别，你的经理应该为你带来信息、分享上下文，但你也应该告诉他们什么是重要的，双向的程度不相上下。正如 Intercom 的首席工程师 Sabrina Leandro 所问：“你知道自己应该做有影响力、有价值的事情。但你要去哪里找那个装满高影响力工作的神奇待办列表呢？”她的答案是：“你自己创造它！”

作为组织中的资深人士，你很可能会被拉往许多不同的方向。如何捍卫和安排你的时间，取决于你自己。一周的时间是有限的（见第 4 章），由你来决定如何使用。如果有人请你做某件事，你会用自己的专业知识来做判断。你会权衡优先级、时间投入和收益——包括你想与求助者保持的关系——然后自己做决定。如果你的 CEO 或其他当地权威人物说他们需要你做某件事，你会给予适当的重视。但自主意味着责任。如果他们让你做的事情最终被证明是有害的，你有责任说出来。不要眼睁睁看着一场灾难悄然发生。（当然，如果你希望别人听你的，你就得先建立起值得信赖、判断准确的声誉。）

你设定技术方向

作为技术领导者，Staff 工程师的部分职责是确保组织有一个好的技术方向。在组织提供的产品或服务之下，是大量的技术决策：你的架构、存储系统、所使用的工具和框架，等等。无论这些决策是在团队层面做出，还是跨多个团队乃至整个组织做出，你的部分工作就是确保它们被做出、被做好，并被记录下来。这份工作并不是要想出技术方向的所有方面（甚至不一定要想出任何一个方面！），而是确保存在一个大家认同、充分理解、能解决其目标问题的方案。

你经常沟通，而且沟通得好

你越资深，就越依赖强大的沟通能力。你做的几乎每件事，都涉及把信息从你的大脑传递到别人的大脑，反之亦然。你越善于让别人理解你，你的工作就越轻松。

理解你的角色

这些公理应该能帮助你开始定义自己的角色，但你会注意到，它们省略了很多实现细节！事实是，一位 Staff 工程师的日常工作可能与另一位截然不同。你角色的实际情况取决于你所在公司或组织的规模和需求，也会受到你个人工作风格和偏好的影响。

这种差异意味着，你可能很难把自己的工作与身边或其他公司的 Staff 工程师进行比较。所以在本节中，我们将拆解这个角色中一些更多变的属性。

我们先从汇报关系说起。

你在组织中处于什么位置？

对于 Staff+ 工程师如何向工程组织的其他部分汇报，我们这个行业还没有确立任何标准模式。有些公司让最资深的工程师向首席架构师或 CTO 办公室汇报；另一些公司则把他们分配给各个部门的总监、不同层级的经理，或者以上各种的混合。这里没有唯一正确的答案，但根据你想达成的目标，可能存在很多错误的答案。

汇报关系（见图 1-3 中的例子）会影响你得到的支持程度、你能接触到的信息，以及在很多情况下，你所在团队之外的同事如何看待你。

图 1-3. 在组织层级的不同位置汇报的 Staff+ 工程师。即使这些工程师的资历级别都相同，A 也会比 D 更容易掌握组织上下文、参与总监级别的对话。

汇报得“高”

在组织架构图中汇报得“高”，比如向总监或副总裁汇报，会给你带来更宽广的视野。你得到的信息会是高层次的、有影响力的，你被要求解决的问题也是如此。如果你的汇报对象是一位非常称职的资深人士，观察他们如何做决策、主持会议或应对危机，可能是一种独特而宝贵的学习经历。

话虽如此，与有一位本地经理相比，你能得到的经理时间可能会少得多。你的经理对你的工作可能缺乏了解，因此可能无法为你争取利益或帮助你成长。一个与单个团队紧密合作、却向总监汇报的工程师，可能会感到与团队其他成员脱节，或者可能会把总监的注意力拉进本应在团队层面解决的局部分歧中。

如果你发现你的经理没空、没时间了解你的工作，或者被拉进了那些并不值得他们花时间的底层技术决策，不妨考虑一下：换一位关注点与你更一致的经理，你也许会更开心。

汇报得“低”

向组织架构图中层级较低的经理汇报，也有其自身的优缺点。你很可能会得到经理更集中的关注，也更有可能有人为你争取利益。如果你更喜欢专注于单一技术领域，与一位贴近该领域的经理合作可能对你有利。

但被分配到单个团队的工程师，可能很难影响整个组织。不管你喜不喜欢，人们都会关注地位和层级——以及汇报关系。如果你向一线经理汇报，你的影响力很可能会小得多。你得到的信息也更容易被过滤，并且集中在那个特定团队的问题上。如果你的经理接触不到某些信息，你几乎肯定也接触不到。

向一线经理汇报，也可能意味着你的汇报对象比你经验更少。这本身并不是问题，但你能从经理身上学到的东西可能更少，而且他们可能对你的职业发展帮助不大：很可能他们并不知道如何帮你。如果你的一部分管理需求在别处得到了满足，这一切也许都没问题。⁷ 特别是，如果你的汇报对象在组织层级中较低，一定要和你经理的经理进行跨级会议。⁸ 想办法与组织的目标保持连接。

如果你和你的经理对于你如何发挥最大作用有不同的看法，这可能会造成紧张。你可能会陷入我前面提到的局部最优问题：你的经理希望你处理团队最重要的事情，而组织内部存在更大、更需要你的问题。当一个人负责另一个人的绩效评级和薪酬时，技术或优先级的争论很难在真正公平的环境中进行。如果你发现这类争论经常发生，你可能需要争取向更高一级汇报。

你的范围是什么？

你的汇报关系很可能会影响你的范围：你密切关注并负有一定责任的领域、团队或多个团队，即使你在这个领域中并没有任何正式的领导职务。

在你的范围内，你应该对短期和长期目标有一定的影响力。你应该了解正在做出的重大决策。你应该对变更有自己的看法，并代表那些没有足够话语权、无法阻止影响自己的糟糕技术决策的人发声。你应该思考如何培养和发展下一代高级工程师和 Staff 工程师，并留意和推荐能帮助他们成长的项目和机会。

在某些情况下，你的经理可能希望你把大部分技能和精力投入到解决他们领域内的问题上。在另一些情况下，某个团队可能只是你的大本营，而你会把一部分时间花在组织其他地方的救火或机会上。如果你向总监汇报，可能存在一个隐含的假设：你在高层次上运作，把组织中正在发生的所有工作串联起来；也可能你被明确分配到总监下属的某些团队或技术领域。要弄清楚是哪一种。

在危机时刻，要准备好抛开你的范围：例如，在服务中断期间，根本不存在“不是我的活儿”这回事。你还应该能够坦然地走出日常经验之外，在需要时挺身领导，学习需要学的东西，修复需要修的东西。Staff 工程师的部分价值就在于你不会只待在自己的车道里。

尽管如此，我还是建议你非常清楚地知道自己的范围是什么，哪怕它是临时的、可能会变。

范围过宽

如果你的范围过宽（或者没有定义），可能会出现几种失败模式。

缺乏影响力

如果任何事都可能是你的问题，那么所有事就很容易都变成你的问题，尤其是当你所在的组织资深人员不够的时候。总会有另一个支线任务：事实上，人们太容易把一个角色做成全是支线任务，根本没有真正的目标。⁹ 小心不要把自己摊得太薄。你最终可能会发现，自己的工作缺乏一条主线，无法让你（以及雇用你的人）觉得你取得了什么成就。

成为瓶颈

当某位资深人士被视为什么都做的时候，惯例就可能变成每个决策都需要他们在场。你非但没有让组织运转得更快，反而拖慢了它，因为离开你他们就玩不转。

决策疲劳

即使你逃脱了什么都想做的陷阱，也要持续承担决定做哪些事情的成本。我会在第 4 章谈到如何选择你的工作。

缺少人际关系

如果你与非常多的团队合作，就很难保持足够的定期接触，建立那种让事情更容易办成（也让工作更愉快！）的友好关系。其他工程师也会因此吃亏：他们得不到那种由“本地”Staff 工程师参与其工作而带来的指导和支持。

在一个你可以做任何事情的工作环境中运作是很难的。更好的做法是选择一个领域，建立影响力，并在那里取得一些成功。投入时间彻底解决一些问题。然后，如果你准备好了，再转向另一个领域。

范围过窄

同样要小心把自己的范围划得太窄。一个常见的例子是 Staff 工程师隶属于单个团队，向一线经理汇报。经理们可能真的很喜欢这样——他们得到了一位经验非常丰富的工程师，可以承担大部分设计和技术规划，也许还能担任某个项目的技术领导或团队负责人。有些工程师也会很喜欢：这意味着你可以深入钻研团队的技术和问题，理解所有的细微之处。但要警惕范围过窄的风险：

缺乏影响力

你有可能把所有时间都花在一件并不需要 Staff 工程师的专业知识和专注力的事情上。如果你选择深耕单个团队或单项技术，那它应该是核心组件、关键任务团队，或者其他对公司非常重要的东西。

机会成本

Staff 工程师的技能通常非常抢手。如果你被分配到单个团队，在组织其他地方需要解决问题时，人们可能不会首先想到你，或者你的经理可能不愿意放你走。

遮蔽其他工程师

范围过窄可能意味着没有足够的工作让你忙起来，而你可能会盖过经验较少的人，夺走他们的学习机会。如果你总有时间回答所有问题、承担所有棘手的难题，那其他人就得不到这样做的经验。

过度设计

不忙的工程师可能会倾向于给自己找活儿干。当你看到一个简单的问题配了一套极度过度设计的方案时，那往往出自一位本该被分配去解决更难问题的 Staff 工程师之手。

有些技术领域和项目足够深，一个工程师可以在那里度过整个职业生涯而永远不缺机会。只是要非常清楚，你是否身处这样的领域。

你的角色是什么形态？

只要大家普遍认同你的工作是有影响力的，你在如何开展工作上就应该有很大的灵活性。这包括在一定程度上由你来定义自己的工作是什么。下面是几个可以问自己的问题：

你做事是深度优先还是广度优先？

你更喜欢专注于单个问题或技术领域吗？还是更倾向于横跨多个团队或技术，只有在某个问题离开你就无法解决时才专注于它？深度优先还是广度优先，很大程度上取决于你的性格和工作风格。

这里没有错误答案，但如果你的偏好与你的范围相匹配，你会过得更轻松、更愉快。例如，如果你想影响组织或业务的技术方向，你会发现自己被那些能以更广视角看问题的机会所吸引。你需要出现在做决策的会议室里，处理影响许多团队的问题。如果你在被分配去解决单个深入的架构问题的同时还想这样做，那谁都不会满意。另一方面，如果你的目标是成为某个特定技术领域的业界专家，你就需要能够收窄焦点，把大部分时间花在这一个领域上。

你倾向于“四项修炼”中的哪一项？

Twitter 的杰出工程师 Yonatan Zunger 描述了世界上任何工作都需要的四项修炼：

核心技术技能

编程、诉讼、内容制作、烹饪——无论这个角色的典型从业者做的是什么

产品管理

弄清楚需要做什么以及为什么做，并为这项工作维持一条叙事主线

项目管理

实现目标的实际操作：消除混乱、跟踪任务、发现哪里受阻，并确保障碍被清除

人员管理

把一群人变成一个团队，培养他们的技能、发展他们的职业，提供指导，并处理他们的问题

Zunger 指出，你的级别越高，你所运用的这些技能组合就越与职位头衔不相符：“你越资深，这一点就越明显，人们就越来越期望你能在这四种工作之间轻松、流畅地切换，并在任何场合都能发挥作用。”

每个团队、每个项目都需要这四项技能。作为 Staff 工程师，你会用到所有这些技能。不过，你不需要样样精通。我们每个人的天赋不同，喜欢或回避的工作类型也不同。也许你很清楚自己喜欢哪些、希望永远用不上哪些。如果你不确定，Zunger 建议你和一位朋友逐一讨论每一项，让他们观察你谈论时的情绪反应和精力状态。如果有哪一项是你真心讨厌的，确保你身边有一位热衷于做这部分工作的人。无论你是广度优先还是深度优先，如果只靠核心技术技能，你都会发现很难继续成长。

超级专家的职业路径

在少数罕见的情况下，一位身处对业务极其关键的领域的优秀高级工程师，可以不做前瞻规划、不影响身边的人，也能取得成功。Zunger 把这称为“超级专家”（hyperspecialist）角色，但也指出：“随着时间推移，你的影响力会减弱。在高级别中，纯粹的超级专家岗位其实非常少。这不是人们通常需要的东西。”Pat Kua 把这条路径称为“真正的个人贡献者通道”，并指出它仍然需要出色的沟通和协作能力。根据公司的不同，“超级专家”路径可能被视为 Staff 工程师角色，也可能完全独立。

你想要（或需要）写多少代码？

这里的“写代码”，你可以随意替换成你迄今为止职业生涯中的核心技术工作。正是这套技能很可能把你带到了今天的位置，而感觉自己的技能在生疏或过时，可能会让人不安。有些 Staff 工程师发现自己最终会阅读或评审大量代码，但几乎不怎么写。另一些人是项目的核心贡献者，每天都在写代码。第三类人则会想办法找理由写代码，承担一些非关键的项目，这些项目有趣或有教育意义，但不会拖延整体进度。

如果你不每天写代码就会坐立不安，那就确保自己不要接手那种宽泛的架构型或影响力型角色，因为你根本不会有时间写代码。或者至少要计划好如何满足这份瘾，这样你才能忍住不去抢编码任务，而把更大的问题晾在一边。

你的延迟满足能力如何？

写代码的反馈周期快得令人安心：每一次成功的编译或测试运行都在告诉你进展如何。这就像每天都有一次小小的绩效评估！

转向那些没有内置反馈回路、无法告诉你是否走在正确道路上的工作，可能会让人灰心。

在长期项目或跨组织项目中，或者在推动战略或文化变革时，可能要过好几个月——甚至更久——你才能得到一个明确的信号，知道自己所做的是否奏效。如果在反馈周期较长的项目上你会焦虑紧张，那就请一位你信任的经理定期、坦诚地告诉你进展如何。如果你需要这种反馈却得不到，可以考虑那些在较短时间内就能见效的项目。

你是否还有一只脚踏在经理通道上？

虽然大多数 Staff 工程师没有直接下属，但也有一些人有。技术主管经理（TLM），有时也称为团队负责人，是一种混合角色：Staff 工程师既是团队的技术领导者，又管理这个团队。众所周知，这是一份很难的差事。同时为人和技术结果负责，却不觉得自己在其中一方面失败，是很有挑战的。也很难找到时间在任何一方面投入、提升技能，我听过不少 TLM 感叹因此失去了职业上的进步。

有些人会先做几年管理，然后做 Staff 工程师，每隔一段时间来回切换，以保持两方面的技能都不生疏。¹⁰ 我们会在第 9 章进一步探讨这种“钟摆”以及 TLM 角色。

这些原型中有适合你的吗？

在他的文章《Staff 原型》（Staff Archetypes）中，Will Larson 描述了他所见过的 Staff 工程师角色的四种不同模式。在定义你现在的角色或想要的角色时，你可以参考这些原型：

技术负责人

与经理合作，指导一个或多个团队的执行。

架构师

负责某个关键领域的技术方向和质量。

问题解决者

一次深入解决一个难题。

左膀右臂

为组织增加领导力带宽。

如果你在这些原型中都看不到自己，或者你的角色横跨了不止一个原型，那也没关系！这些原型并不是规定性的；它们只是给了我们一些概念，用来清楚表达我们喜欢怎样工作。

你的主要关注点是什么？

至此，我们讨论了你的范围和汇报关系：你在组织中运作的大致边界，以及你在组织中的位置。我们还了解了你的天赋：你喜欢怎样工作、被哪些技能所吸引。但即使你理解了这一切，对自己角色的形态有了清晰的认识，还剩一个问题：你要做什么？

随着你影响力的增长，你会发现越来越多的人希望你关心某些事情。有人在为组织的代码评审方式编写最佳实践文档，想听听你的意见。你所在的部门正在加大招聘力度，需要你帮忙决定面试考察什么。有一项废弃工作，如果有一位 Staff 工程师去争取高层支持，就能推进得更快。而这还只是周一上午。你该怎么办？

在某些情况下，你的经理或其上级会对你应该关注什么有强烈的意见，甚至可能就是专门为了解决某个特定问题才雇用了你。但大多数时候，你在决定什么最重要这件事上会有一定的自主权。每当你选择做什么，你也在选择不做什么，所以要深思熟虑地决定你要承担哪些事。

什么是重要的？

在职业生涯早期，如果你把一件最终被证明不必要的事做得很出色，你仍然是做得很出色。但到了 Staff 工程师级别，你做的每件事都有很高的机会成本，所以你的工作必须是重要的。

我们来稍微展开一下。“你的工作必须是重要的”并不意味着你只应该做那些最炫、最光鲜的技术和副总裁亲自支持的项目。最重要的工作往往是没人看得到的工作。甚至连清楚表达它的必要性都可能很费劲，因为你的团队还没有关于它的良好心智模型。它可能需要收集尚不存在的数据，或者在十年没人碰过的陈旧代码和文档中摸索探险。还有无数其他必须有人完成的脏活累活。有意义的工作有多种形式。

要清楚你正在处理的问题为什么具有战略重要性——如果它并不重要，那就去做别的。

什么需要你？

类似的情况是，资深人士投身于任何中级工程师都能承担的编码项目：你会把它做得非常出色，但很可能还有一个“资深尺寸”的问题，是那位中级工程师无法解决的。借用我孩子某天说出的一句颇有深意的话：“你不会在你唯一的桶里种草。”

警惕选择那些已经有很多资深人士参与的项目。摸清还有谁在处理这个问题，以及他们看起来是否有可能成功解决它。有些项目甚至可能因为多了一位领导者加入而变慢。¹¹ 总的来说，如果扮演理性智者的人比真正在敲代码（或你项目中的同等工作）的人还多，那就不要插手。尽量选择一个真正需要你、并且会因你的关注而受益的问题。第 4 章会给你一些工具，帮助你决定承担哪些项目。

在范围、形态和主要关注点上达成一致

到现在，你应该已经相当清楚自己角色的范围是什么、它是什么形态，以及你现在在做什么。但你确定你心中的图景与其他所有人的一致吗？对于 Staff 工程师是什么、你有多大的决策权，以及无数其他重大问题，你的经理和同事的期望可能与你的大相径庭。如果你是以 Staff 工程师的身份加入一家公司，最好一开始就把这些都理清楚。

我从朋友 Cian Synnott 那里学到的一个技巧，是把我对自己工作的理解写下来，并分享给我的经理。回答“你在这里是做什么的？”这个问题可能会让人有点发怵。万一别人觉得你做的事毫无用处，或者觉得你做得不好怎么办？但写下来可以消除模糊性，你也能及早发现自己对这个角色的心智模型是否与其他人一致。现在发现总比到绩效评估时才发现要好。

下面是一份角色描述的示例，描述对象是 Ali——一位广度优先、架构师原型的 Staff 工程师，他正在协助（但不领导）一个大型跨团队项目。

Ali 是做什么的？

概述

本文档列出了我未来一年的工作计划。我的主要关注点是零售销售工程部门的成功。我预计会把大约一半的时间用于该部门的技术方向，大约 30% 用于为 NewMerchandising 项目做贡献，其余时间分配给跨组织的工作（API 工作组、架构评审）和社区工作（面试、指导高级工程师）。作为事故指挥官轮值的一员，我预计每 10 周中有 1 周值班。

目标

1. 通过引导技术方向、参与组织目标制定以及预见风险，让零售销售取得成功。

2. 作为 NewMerchandising 的顾问/力量倍增器，助力其成功。识别威胁项目目标的工程实践风险或缺口。

3. 主导零售销售工程部门各团队的架构评审。

4. 通过参与其他销售部门的架构评审，改进跨工程部门的规划。

5. 在需要时（例如事故或冲突期间）充当额外的领导力带宽。

示例活动

• 提出应对零售销售风险与机会的 OKR。

• 就 NewMerchandising 的目标和交付物达成一致，并确保各团队保持一致。

• 为整个组织的各团队提供架构咨询。推荐架构方案并为 RFC 撰写部分章节，但不太可能担任任何 RFC 的主要作者。

• 指导/辅导高级工程师。

• 面试高级工程师和 Staff 工程师候选人。

成功是什么样子？

• 零售销售正在构建能支撑未来五年扩展的系统。

• NewMerchandising 项目持续取得进展，四个团队对目标有共同的理解。

不要执着于把它写得完美：写得足够对就行。描述你的目标并不意味着你被禁止做其他事情。但它能很好地提醒你原本打算做什么，并帮助你留意自己是否真的在做你声称是自己本职的事情。

你可能会发现，你的关注点需要比预期更早地改变。外部状况可能变化，你的优先级也可能转移。如果是这样，就用新的信息写一份新的角色描述。清楚表达你对自己的期望，可以确保大家步调一致。

那是你的工作吗？

你的工作是让你的组织取得成功。你可能是技术专家、程序员，或者隶属于某个特定团队，但归根结底，你的工作是帮助组织实现其目标。资深的人会做很多不在其核心职位描述中的事情。他们最终可能会做一些放在任何人的职位描述里都说不通的事！但如果项目要成功就需要这么做，那就考虑去做吧。

我在 Squarespace 的一些同事讲过这样一个故事：2012 年的某一天，他们的数据中心停电了，他们把燃油扛上 17 层楼梯，以维持数据中心在线。“搬运柴油桶”不会出现在大多数技术岗位的职位描述里，但那正是保持网站在线所需要的（而且奏效了！）。多年前我在一家 ISP 工作时，机房被淹了，工作内容就变成了用垃圾桶组成一条水桶传递链来降低水位。2005 年，Google 的一个项目进度落后，我们又没有足够的硬件人员可用，于是我有几天的工作就是在圣何塞的一个数据中心里给服务器上架。为了让项目成功，你需要做什么就做什么。

当然，这种“不是我的活儿”的工作通常没那么戏剧化。它可能意味着进行十几次对话，来疏通你的团队所依赖的项目；或者注意到你的新工程师迷失了方向，去关心一下他们。再强调一遍：你的工作归根结底是你的组织或公司需要它是什么，它就是什么。在下一章中，我会谈谈如何理解这些需求是什么。

回顾

• Staff 工程师角色在定义上就是模糊的。由你自己去发现和决定你的角色是什么、对你意味着什么。

• 你很可能不是经理，但你处在一个领导角色中。

• 你所处的角色也需要技术判断力和扎实的技术经验。

• 明确你的范围：你负责和施加影响的领域。

• 你的时间是有限的。要深思熟虑地选择一个重要的、不浪费你技能的主要关注点。

• 与你的管理链保持一致。讨论你认为自己的工作是什么，了解你的经理认为它是什么，理解什么被看重、什么真正有用，并明确设定期望。并非所有公司都需要所有形态的 Staff 工程师。

• 你的工作有时会是一种奇怪的形态，这没关系。

1. 我也推荐 progression.fyi，它收录了大量由各家科技公司公开的职级体系。 ↩

2. 我听说有一家公司的职级按资历从低到高依次是“senior”“staff”“principal”，后来它被另一家公司收购，而收购方用的是“senior”“principal”“staff”。一片混乱。收购方把所有的“staff”改成了“principal”，把所有的“principal”改成了“staff”，结果没有一个人满意：staff 和 principal 都觉得自己被降级了。头衔很重要！ ↩

3. 我很喜欢我的朋友 Tiarnán de Burca 对高级工程师的定义：在这个级别上，一个人可以停止晋升，在余下的职业生涯里保持当前的产出、能力和成果，而如果他离职，公司仍会将其视为“令人遗憾的流失”。 ↩

4. 他们当时到底在想什么？这真的是他们本来想做的吗？当然，未来的团队也会这样问我们。 ↩

5. Hillel Wayne 的文章《我们并不特殊》（We Are Not Special）指出，很多过去需要仔细调校物理设备的工程方案，如今都改用“软件凑合”来实现了。我真心一直很惊讶，到目前为止由软件引发的重大致命事故竟然这么少。我可不想指望我们一直走运下去。 ↩

6. 这就是为什么我不赞成让有经验的 Staff 工程师参加编程面试。如果你已经做到了这个级别，要么你代码写得很好，要么你已经学会用其他“肌肉”来解决技术问题。重要的是结果。 ↩

7. 我推荐 Lara Hogan 关于组建“经理战神金刚”（manager Voltron）的文章。 ↩

8. 如果跨级会议在你的公司并不常见，你可能需要讲清楚，你并不是想架空你的经理，也不是要去“打小报告”；你是想了解更大范围团队的优先事项，并建立能帮助你发挥最大影响力的联系。理想情况下，你的经理会理解跨级会议的价值，并帮你安排。 ↩

9. 支线任务是电子游戏中与主线任务毫无关系的部分，但你可以选择去做，以换取金币、经验值，或者只是为了好玩。想象一下大量这样的场景：“呃，我正要杀进那座戒备森严的要塞，去打败那个一直祸害这片土地的恶魔，不过行吧，我可以先帮你找猫。” ↩

10. Charity Majors 的《工程师/经理钟摆》（The Engineer/Manager Pendulum）是关于这个话题的一篇极好的文章。 ↩

11. 你会听到有人引用布鲁克斯定律：“向一个已经延期的软件项目增加人手，只会让它更加延期。”虽然布鲁克斯本人称之为“一种过分的简化”，但它确实有一定道理。参见 Fred Brooks 的《人月神话》（The Mythical Man-Month，Addison-Wesley 出版）。 ↩