概述

在大多数科技公司，你会在五到八年内成长为 Senior Software Engineer（高级软件工程师），这是软件工程师职业生涯中的一个成熟层级。到了这一层级，公司的职级体系不再要求你必须为下一次晋升而努力，继续往上晋升属于例外，而非常态。此时，你的职业道路会出现分岔：你可以留在当前层级，可以沿着技术精进之路继续前行，成为 Staff Engineer，也可以转岗进入工程管理。当然，具体的头衔因公司而异，你可以把“Senior Engineer”和“Staff Engineer”换成你们公司习惯的叫法。

过去几年，市面上涌现出一批解读工程管理职业路径的书，比如 Camille Fournier 的《The Manager’s Path》、Julie Zhuo 的《The Making of a Manager》、Lara Hogan 的《Resilient Management》，还有我自己的《An Elegant Puzzle》。管理这条路并不好走，但可以借鉴的地图越来越多。

相比之下，迈向 Staff Engineer，以及 Principal、Distinguished Engineer 等更高层级的转变，依然充满挑战，也少有人系统地记录下来。成长为 Staff Engineer 需要培养哪些能力？仅靠过硬的技术就足以胜任这个角色吗？大多数人是如何进入这个角色的？你的经理在这个过程中能起到什么作用？你会真正喜欢做一名 Staff Engineer，还是会为一个并不适合自己的角色辛苦多年？

在我的工程管理生涯中，我对这些围绕 Staff Engineer 角色的问题逐渐形成了越来越清晰的看法，但我的观点不可避免地受到自身经历的影响，我认为不能把个人的信念当作放之四海皆准的真理。在写作《Staff Engineer》这本书时，我访谈了十几位来自业界的 Staff 及以上级别工程师，了解他们的真实经历，并把他们的经验融入我自己的思考中，让这本书比我独自写作时更有细节、广度和视角。

如果你已经身处 Staff 及以上角色，希望这些文字能为你在这条管理线之外的领导者之路上注入能量。如果你正以此为目标，希望它们能为你的追求提供务实的帮助。这本书可以从头读到尾，但根据你更符合哪一种情况，也可以直接跳到你最感兴趣的部分。

• 概述——纵览 Staff Engineer 角色、它在不同公司的差异，以及头衔为何重要

• 以 Staff 的方式工作——拿到头衔之后，具体该如何开展工作

• 在现有公司获得头衔——如何在当前公司晋升到 Staff 及以上

• 通过换公司获得头衔——何时以及如何通过换公司来助力冲击 Staff 及以上头衔

• 亲历故事——来自 Staff 及以上工程师的故事：他们平时做什么，又是如何走到今天的

• 资源——模板和延伸阅读，如果你还想深入

每家公司都会给 Staff 及以上角色打上自己的烙印，所以其中有些部分可能和你的经历对不上。如果是这样，请取走能引起共鸣的部分，舍弃对不上的部分！

Staff Engineer 的四种原型

大多数公司的职级体系都会为 Staff 工程师定义一套统一的期望。清晰的角色期望对所有人都有好处，但职级体系作为一种工具，更适合描述群体，而不太适合描述个体。对于 Staff 及以上工程师来说尤其如此：一个头衔背后，往往掩盖着几个截然不同的角色，职级体系只是用同一个名字把它们轻轻盖住了。

和越来越多的人聊过他们公司 Staff 及以上工程师的角色后，我发现他们的经历逐渐聚拢成四种不同的模式。大多数公司侧重其中一两种模式，其中一种模式只存在于拥有数百甚至数千名工程师的公司里。还有少数公司没有任何技术领导模式，会把所有资深工程师都推向工程管理。在文学中，反复出现的人物模式被称为原型，比如“英雄”或“ trickster（捣蛋鬼）”，借用“原型”这个词来标注 Staff 及以上工程师的这些常见变体很贴切。

我遇到的 Staff 及以上角色的四种常见原型是：

• **Tech Lead（技术负责人）**负责指导某个特定团队的方法和执行。他们与一位经理紧密合作，有时也会在某个聚焦的领域内同时与两三位经理合作。有些公司还有 Tech Lead Manager 这一角色，类似于 Tech Lead 原型，但处在工程管理序列上，带有人员管理职责。

• **Architect（架构师）**负责某个关键领域的方向、质量和方法。他们把对技术约束的深入理解、对用户需求的把握和组织层面的领导力结合在一起。

• **Solver（攻坚者）**深入钻研任意复杂的难题，并找到合适的出路。有些人长期聚焦在某个领域，另一些人则在组织领导的指引下，哪里是热点就奔赴哪里。

• **Right Hand（得力助手）**延伸某位高管的注意力，借用他的范围和授权，去运营特别复杂的组织。他们为大规模组织的负责人提供额外的领导带宽。

这个分类更追求_有用_，而非_完备_，但到目前为止，我聊过的每一位 Staff 及以上工程师都能归入其中之一。诚然，有些人比另一些人更容易归类。

Tech Lead（技术负责人）

图 1：Tech Lead 原型的日历示例

出场故事（Tech Lead 原型）：Diana Pojar、Dan Na、Ritu Vincent。Tech Lead 是最常见的 Staff 原型，带领一个团队或一组团队，负责方法和执行。他们擅长拆解复杂任务，协调团队去解决，并在过程中扫清障碍。Tech Lead 往往承载着团队的上下文，维护着团队成功所必需的大量跨团队、跨职能关系。他们是团队产品经理的亲密搭档，每当路线图需要调整，第一个被叫到的人就是他们。

在职业生涯早期，他们亲手实现过团队中最复杂的技术项目，但到了这个阶段，他们默认把这类项目分派给团队成员去做。这既是为了培养队友，也承认了一个现实：Tech Lead 亲手写代码的时间越少，团队的整体产出越大。虽然写代码少了，但他们仍然是定义团队技术愿景的人，在复杂问题上推动团队内部对齐时，也会挺身而出。

对很多人来说，Tech Lead 是他们作为 Staff 工程师的第一段体验。几个因素共同促成了这一点。首先，Tech Lead 角色往往很早就出现在团队概念很强的公司里，在采用敏捷方法的公司中很常见，而大多数公司在某个阶段都会尝试敏捷。另一个因素是，Tech Lead 的日常工作和你做 Senior 工程师时的工作最为接近，转变相对自然。最重要的是，一个组织大约每八名工程师就需要一位 Tech Lead，因此它比其他原型常见得多。

容易混淆的是，有些公司把 Tech Lead 当作头衔，有些公司把它当作角色。在这组原型里，Tech Lead 是担任 Staff 工程师的一种方式，但以 Tech Lead 的方式工作，并不一定意味着达到了 Staff 级别的影响力。事实上，你会发现每个原型的行为都可能出现在非 Staff 工程师身上。成为一名 Staff 工程师不只是一个角色，而是角色、行为、影响力，以及组织对这一切的认可的交集。

Architect（架构师）

图 2：Architect 原型的日历示例

出场故事（Architect 原型）：Joy Ebertz、Katie Sylor-Miller、Keavy McMinn

Architect 这个头衔在很多公司已经不再流行，但 Architect 这个角色在 Staff 及以上层级依然鲜活。Architect 对公司内某个具体技术领域的成败负责，例如公司的 API 设计、前端技术栈、存储策略或云基础设施。要配得上 Architect，这个领域必须既复杂，又长期处于公司成功的中心。

有一种有害的刻板印象，认为 Architect 把自己关起来设计系统，然后丢给别人去实现。这种情况确实存在，但如果用这个刻板印象去套我访谈过的架构师，那就太失实了。有影响力的架构师会投入大量精力，深入理解业务需求、用户目标和相关技术约束。他们用这些洞见，在自己聚焦的领域内识别并倡导有效的做法，靠的是长期判断准确而赢得的组织权威。

Architect 角色往往出现在相对较大的公司、代码库异常复杂或耦合严重的公司，以及在冲向 product-market fit 的初期积累了大量技术债、如今急于偿还的公司。有些公司要求 Architect 深入代码库，另一些公司则明确要求 _Architect 不能_写代码：两种模式在各自的公司里都行得通。

Solver（攻坚者）

图 3：Solver 原型的日历示例

出场故事（Solver 原型）：Bert Fan、Nelson Elhage

Solver 是组织信任的干将，深入棘手的难题，直到问题解决才收手。

这个角色的人会被派到组织领导认定的关键问题上：这些问题要么还没有清晰的解法，要么执行风险很高。

大多数 Staff 级别角色都需要大量的组织协调，而 Solver 通常处理的是已经被认定为组织优先级的问题，因此相对不太需要做组织层面的“正骨”。另一方面，他们一般在问题得到控制后就会撤出，这容易带来一种漂泊感，需要用柔软的身段交接，避免激怒留下收尾、维护这个“已解决”问题的团队。

Solver 在把个人而非团队视为规划和归属基本单元的公司中最常见。在这类公司里，常见的是 Solver 取代了 Tech Lead 的位置。在传统的管理型、 sprint 为中心的公司里，你不太会遇到这个角色，除非公司已经大到或老到积累出了自己品种的技术债。

Right Hand（得力助手）

出场故事（Right Hand 原型）：Michelle Bu、Rick Boone

Right Hand 是最少见的原型，出现在工程师规模达到数百人的组织中，类似于不带直接管理职责的高级组织领导者。Rick Boone 把自己的角色比作《权力的游戏》中的国王之手，以及《白宫风云》中的 Leo McGarry，借用资深领导者的授权来行事。而借用授权的前提，是与那位领导者的方法、信念和价值观保持深度对齐。

这个角色的人会参加其领导者的 staff 会议，帮领导分担重要问题，从而放大领导的影响力。

图 4：Right Hand 原型的日历示例

这个层级的问题从来不只是纯技术问题，而是业务、技术、人、文化和流程的交汇。Right Hand 经常是扑进一场火里，调整打法，把执行交给最合适的团队，然后转身去扑组织别处的下一场火。这种角色的乐趣在于，你只处理最重要的问题；悲哀在于，等问题真正解决时，你已经奔赴下一个战场了。

哪一种适合你？

在思考哪种原型适合自己时，先反思什么样的工作能让你充满能量，再看看你们公司有哪些角色可选。

所有公司都需要能填补 Tech Lead 角色的工程师，这让它成为拿到第一个 Staff 职级最容易触达的原型。强调个人归属而非团队归属的公司，往往很早就长出 Solver。而严格按 sprint 或敏捷方法运转的公司，往往很晚才长出这个角色，甚至永远没有。在近一批快速成长的科技公司里，Architect 和 Right Hand 一般分别在组织达到一百人和一千人时才出现，在此之前根本不存在。文化基因不同的公司，长出它们的时间可能更早，也可能永远不会。

要在这几个角色上取得成功，保持投入感是关键，一定要弄清楚什么样的工作能让你充满能量。Tech Lead 和 Architect 往往和同一批人、围绕同样的问题共事多年，形成紧密的团队感和共同使命。有些月份，他们的焦点会是公司的头号优先级，有些时候他们顺风顺水，好到高管都忘了这个团队的存在。

Solver 和 Right Hand 则从一场火奔赴另一场火，和每周共事的人更多是事务性的交集。他们与高管优先级高度对齐，也更容易因为解决了领导最头疼的问题而获得认可。另一方面，虽然他们名义上也在某个团队里，但团队成员各自聚焦的领域一般很少重叠，归属感和社区感往往比较弱。

每种原型下，你都会遇到热爱它、觉得收获满满的人，也会遇到觉得这份工作让人绝望的人。瞄准适合自己的原型很重要，但也值得记住：在三四十年的职业生涯里，你有足够的时间把每种原型都体验一遍。

Staff 工程师到底做什么？

Staff 及以上工程师的角色很大程度上取决于团队需要什么，也取决于这位工程师本人的优势。就我的经验，Staff 及以上工程师的职责会随时间变化。但通常，他们的主要精力都放在对公司有战略价值的项目上，一边推动技术设计，一边提升团队水平。——Diana Pojar

被亲戚在聚会上围住、追问软件工程师_到底是干什么的_的人都知道，解释这份工作有多难。你可能已经练出了一套应付亲戚的说法，但当同事探过头来问“Staff 工程师是干啥的？”，很多人的大脑还是一片空白。

最直接的回答是：Staff 工程师还在做让他们成为 Senior 工程师的那些事：建关系、写软件、协调项目。但这个回答有误导性。Staff 工程师做的还是那些事，但以前那些是工作的核心，现在它们成了辅助。日常安排因原型略有不同，但所有原型都有共同的底座：制定并修正技术方向、提供指导和举荐、把工程视角注入组织决策、探索，以及 Tanya Reilly 所说的做“胶水”。

制定技术方向

当我能推动为某个领域确立技术愿景，并带动大家朝那个愿景前进时，我觉得自己最有影响力。我想大家都会认同，我们希望代码的架构更好，总有这样那样的改进空间。但我发现，

人们常常只是模糊地觉得“要更好”，却说不清想要的那个“好”到底是什么。我喜欢帮大家对“我们到底要去哪里”（其实永远到不了也没关系）形成共识，再拿出一个大致的路线图，规划怎么走过去。——Joy Ebertz

就像在那本著名的童书里，Lorax 为树木代言一样，Staff 工程师为公司的技术代言。技术不会自己说话，需要有效的代言人。能真正推动技术前进的人都很务实、审慎，更关注长期进步的趋势，而不是把每个具体决策都当成生死攸关的危机。可以把这看作兼职做技术的产品经理。

有些 Staff 及以上工程师被明确招进来负责某个领域，比如 API 设计，另一些则是在广泛范围内修正和对齐做法。所有角色的一个共同点是：制定技术方向的现实，更多是理解并解决你周围组织的真实需求，而不是优先去玩你个人想学的新技术。在早期的角色里，你可能还试着把决策往自己感兴趣的技术上引；在高级别位置上，你首先要对业务和组织负责，其次才是自己。

指导与举荐

在现在的角色里，当我举荐过的人宣布交付了成果，或者当我看到自己影响了某个工程团队对重要问题的认知模型时，我会感到充满能量。真正日复一日辛苦建造和维护技术的是这些团队，而不是我。我用他们的进展来衡量自己的影响，更重要的是，看进展的方向是否正确，看他们的工作是否和公司目标对齐。——Michelle Bu

有一种流行的英雄式领导叙事，主角是生产力惊人的个体，他们的决策改变了公司的未来。这类叙事大多是公关团队精心编出来讲好故事的。比起个人英雄主义，培养你身边的工程师，更有可能改变公司的长期走向。而培养身边人的最好办法，是建立起积极的指导和举荐实践。

有时人们看到职级体系里要求指导他人，就机械地去“打卡”，这很可惜，因为指导是 Staff 及以上角色中最有价值的活动之一。分享你的经验和建议，并通过持续的关系去理解对方的上下文，是高影响力的工作。最高效的 Staff 工程师会搭配适度的指导和更多的举荐：直接把拇指按在天平上，推进和支持身边的人。如果你还没读过，Lara Hogan 写过一篇讲举荐和指导区别的经典文章，What does sponsorship look like?（举荐是什么样的？）

提供工程视角

在单个项目和团队之上的更高层工程讨论中，我有一席之地。我们有定期的 Staff 工程会议，讨论跨团队的问题，既有技术的，也有非技术的。——Dan Na

高效的组织会把常规决策流程化。一个好例子是评审潜在企业客户的合同。早期，难免签下一些产品和工程团队不愿支持的合同。吃过几次亏之后，评审环节会拉入更多利益相关方，久而久之，合适的人会在合适的时间出现在合适的位置。

即使是擅长常规决策的公司，遇到意料之外的决策时也常常吃力。这类决策既紧急又重要，甚至在必须拍板之前，都来不及把对的人凑齐。组织重组开会时缺了本可改变结果的关键输入，这种事很常见。同样，为低频岗位——比如高管，或者处于早期阶段的公司里的 Staff 及以上工程师，这种一年可能只招一个人的岗位——安排面试时，漏掉某个重要维度也很常见。对有些公司来说，连路线图规划都属于这一类。

Staff 及以上工程师，常常就是被临时拉进这种决策房间的人。这给了他们机会，在还来得及改变结果时，把工程的上下文和视角注入决策。这些在关键决策上的短暂输入，影响力大得不成比例，能补上原本会被错过的工程视角。只是要记住，你代表的是整个工程组织的利益，而不只是你自己。

探索

在孵化器现在的角色里，我整天都在做原型；但之前做 Tech Lead 时，我什么都干。——Ritu Vincent

爬山算法是一种简单的优化算法。想象你站在一座山上，想登顶。你原地转一圈，找到附近最高的点，走过去。到了之后再转一圈，从新位置找到附近最高的点，再走过去。一直重复，你就能登上你所在这座山的山顶。但如果是个大雾天呢？因为看不远，你走到附近最高点后，可能会发现稍远处还有高得多的山峰，只是之前看不见。

爬山算法解决不了所有问题，但它足够有效，以至于很多公司难以采取别的做法。可能是一家消费导向的公司迟迟啃不下企业订单，也可能是一家成熟公司在发布节奏上拼不过小竞争对手。还可能是你现在的业务太赚钱了，以至于排不上优先级去做新业务，哪怕赚钱业务的增速已经一路下滑。

长期看，公司要么学会探索，要么走向衰落，这不是可以忽略的挑战。直接让一支爬山高手组成的团队去做探索性工作，远非十拿九稳，于是很多公司换了打法：找两三个能力全面、值得信任的人，给一些资源，几个月后再回来看看发现了什么。其中一位工程师，常常就是 Staff 工程师。

这也不总是业务问题；可能是任何含混不清、但公司现有体系不擅长应对的重要问题。可能是把基础设施成本降一个数量级，可能是找到一条用六个月而不是三年实现多地域战略的路，也可能是突然发现主数据库的磁盘只剩三个月，而又升不了更大的规格（以我的经验，在快速成长的创业公司里，这问题多得惊人）。

这是公司做的回报最高、风险也最大的工作之一。能被托付这类工作，需要极高的组织信任，包括业务层面足够尊重你：万一失败了，那是问题本身难，而不是你不行。

成为“胶水”

Tanya Reilly 写过一篇好文，Being Glue，精准捕捉了成功 Staff 工程师的另一个核心要素：去做那些必须有人做、却常常隐形的工作，让团队不断前行、把东西交付出去。不光鲜，但高影响力的组织里，往往有一位或多位 Staff 工程师在幕后加速最重要的工作，确保它们落地。

但你还会写代码吗？

聊 Staff 工程师角色，不回答那个经典问题是不礼貌的：Staff 工程师聚在一起，第一句话就是“你还有时间写代码吗？”答案当然是，看情况！

Ras Kasa Williams 说：“我还是会定期写代码，当然比团队里其他工程师少得多；但保持‘手放在键盘上’对我很重要，这样我的技术战略（和其他宏观决策）才能扎根于团队其他人的实地经验。”

Katie Sylor-Miller 说：“我是前端架构师，但我最近写得最多的居然是 SQL，因为我在做大量数据分析。我在看性能指标，找改进空间，判断修哪些最有影响力、对性能和业务指标提升最大。偶尔也会写点 JS 或 PHP，但主要是帮团队解阻塞，或者做小的性能实验。”

Joy Ebertz 说：“越往上，工作和代码的关系越远。当然，和管人的人不同，你还是有很强的技术属性，即使到 principal，也多半还会写点代码。但层级越高，工作越是关于指导和培养身边的人（以及更大范围的人），通过打造公司的技术品牌来建设团队，发现值得改进或纠正的大技术趋势，帮团队或公司确立技术愿景，并为技术债项目争取资源。”

大多数人还写一点，有些人完全不写，但没人像职业生涯早期那样高产。偶尔会有纯写代码的一周，但那不是常态，如果太频繁，往往说明在挑舒服的事做，而不是重要的事。即使写得不多，你也会读_大量_同事的代码，做相当多的 code review。

缓慢但有回报

Staff 及以上工作的一个共同主题是，时间尺度更长。职业生涯早期，很容易迷上软件开发的快速反馈——写、测、发、重复，而这个层级的大部分工作，都把反馈周期拉长到了几周、几个月、几年。刚进入 Staff 及以上角色时，这种拉长会让人出乎意料地沮丧。身为 Staff 及以上工程师，忙一天却觉得什么都没干成，很正常——坚持下去！

影响力和个人成长都藏在这些更长的时间尺度里。我聊过的每个人都说，希望偶尔能多写点代码，也承认有些日子会担心自己没干出什么，但没有一个人后悔转到现在的角色。

头衔真的重要吗？

如果你正安稳地待在 Senior Engineer 的舒适区里，可能会问：值得去追 Staff 头衔吗？那要投入大量时间和精力，还得有点运气。这笔投资划算吗？

答案当然是，可能划算！Staff 及以上头衔带来的三个稳定好处是：

1. 绕过非正式的资历标尺，

2. 更容易走进“房间”，

3. 当下和整个职业生涯的薪酬更高。

潜在的第四个好处是，有些人发现头衔带来更大的选项目自由，但也有人发现，自由的增加被同步增加的对业务的责任吞掉了。

非正式的资历标尺

当我和 Nelson Elhage 聊到 Staff 层级是否让他能接下新的工作时，他回答：

“让不让”是个有意思的问题，可能问得不太对，因为几乎没有什么明文规定谁能做什么样的角色，更多是靠非正式的资历标尺。

很多科技公司自称追求精英管理，也就是为有才华的员工自然脱颖而出创造条件。但既然并不存在公认的个人能力度量衡，这类公司就会依赖 Nelson 所说的“非正式的资历标尺”。这些标尺自以为在客观评价想法，实则因为过于非正式，成为偏见的温床，常常把自信当能力。免于一遍遍重新自证能力，是 Staff 头衔常被提到的关键好处。这些非正式标尺不是每位 Staff 及以上工程师都提到，但不符合公司“资深技术人”刻板印象的人，几乎都会提到。

Keavy McMinn 分享说：

有了头衔，就不用老把资历摆上台面。它帮别人快速建立上下文。从一开始你就更受尊重，这一点特别明显。

Staff 及以上头衔让你把过去花在自证上的精力，重新投回真正决定你绩效的核心工作。如果你发现自己几乎不用自证，那很好！也许你在现公司待得够久、自证过足够多次，已经不是问题了。如果你发现_大量_时间都耗在一次次自证上，这个头衔会把可观的时间还给你，拿去做真正重要的事。

走进“房间”

Staff 及以上头衔的另一个常见好处是“走进房间”。Dan Na 这样描述：

在单个项目和团队之上的更高层工程讨论中，我有一席之地。我们有定期的 Staff 工程会议，讨论跨团队的问题，既有技术的，也有非技术的。举个例子，如果我觉得工程 onboarding 流程有短板，在这种会上提出来就很自然。

任何重要决策，都有拍板前的酝酿期和拍板后的执行期。位置够高时，你常常正好在场，能在改动成本还很低时给出输入，否则你的反馈再有价值，也可能因为发布或实施已经走得太远而无法采纳。

薪酬

小公司的薪酬往往比较随意，涨薪靠和经理直接谈。在这种公司升到 Staff 及以上，可能连加薪都没有。不过，大多数公司在到一两百人时，就会给每个层级设定薪酬带，薪酬带一般会保证薪酬随层级上涨。

任何公司薪酬最高的都是高管和高级管理岗。公司长大后，通常会在管理和工程序列之间建立薪酬映射，走到 Staff 及以上（有时是 Sr Staff 或 Distinguished，而不是初阶 Staff）会显著涨薪。

即使你现在的公司给 Staff 及以上工程师的薪酬和 Senior 差不太多，有些公司差很多。在整个职业生涯里，你可以选择奔向那些公司，带着 Staff 及以上头衔去，会显著提高一生的总收入。

接触有趣工作的机会

很多人以为拿到 Staff 及以上角色就能接触最亮眼、最刺激的工作。这话对了一部分，但取决于你们公司盛行哪种 Staff 原型。比如 Solver 确实常常拿到最有意思的工作。反过来，Tech Lead 如果这么干，多半是在坑团队。

在我聊过的人里，最稳定地拿到有意思工作的方法是被招进来干它，比如 Ritu Vincent 被招进来启动 Dropbox 的产品孵化器，Keavy McMinn 被招进来设计 Fastly 的 API 战略。

这也不总能如愿。有时有意思的工作明摆着，却够不着。你对业务的义务太重，没法追个人兴趣。早期角色里，你也许还能把这类项目偷塞进 backlog，现在你要以身作则。即使项目对公司最有利，你也常常会把它让给更需要这个机会的工程师。

不同，而非更好

头衔确实重要，但不意味着你就该去追。即使你喜欢 Staff 及以上头衔的特权和福利，也要认清它们背后是一份很不一样的工作。Michelle Bu 给追 Staff 头衔的人的建议是：

如果你满脑子都是冲上 Staff，而不是让自己去做能点燃你的工作，很容易最后困在一个自己不想要的角色里。做 Staff 及以上工程师，尤其做覆盖面很广的 Staff 及以上工程师，和做 Senior Engineer 是很不一样的工作。退一步想清楚，这到底是不是你真正想要的工作，很重要。

高级别头衔的好处是真实的，对有些人来说，这些好处把职业生涯从求生存变成了具备成功的前提。但也有很多人发现，Staff 角色更高的期望，挤掉了曾经让他们兴奋的工作。职业生涯里很少有没代价的选择，这个也不例外。

实实在在，但并非魔法

偶尔会遇到这样的工程师，觉得挡在自己和重要成就或机会之间的，只差一个头衔。他们会抱怨：“要是有了 Staff 头衔，我就能给团队定技术栈了。”

更高的组织授权确实给了新的解题工具，但在管理良好的组织里，要保住组织授权，需要极大的分寸感和克制。如果你觉得只差头衔，告诉你：打磨方法和能力，比头衔有用得多。头衔能在你接近门槛时推你一把，但它干的活永远比你期望的少。

这条规则有个一贯的例外：女性和少数群体常常发现，拿到 Staff 及以上头衔后，花在自证上的时间和精力显著减少。头衔没有给她们解锁新能力，但卸下了她们职业生涯一路背负的一部分重量。