在你所在的公司拿到头衔

我听过的最好的建议是：晋升到 Staff 往往是运气、时机和努力的结合。—— Bert Fan

大多数科技公司都有一个“职业层级”（career level），它被视为大多数人能达到的最高级别。在大多数公司，Senior Engineer 就是职业层级。从初级工程师升到中级工程师太慢可能会被辞退，但大多数公司并不指望你一定能从 Senior 升到 Staff。在中级停留六年？那是个问题。在 Senior 停留二十年？没问题，很正常。

更重要的是，一旦你达到职业层级，公司的晋升体系往往会阻碍你继续往上走。有时已经拥有 Staff 头衔的人会担心头衔被稀释，从而维护其稀缺性。在另一些情况下，出于团队健康或预算的考虑，组织可能不愿意让同一个团队里出现多个 Staff Engineer。不过，我认为最大的阻力来自工作性质本身的变化：Staff Engineer 并不是更厉害的 Senior Engineer，而是开始承担某种 Staff 原型（archetype）所要求的工作的人。

即使你已经具备了成为 Staff Engineer 所需的技能，仍然还有最后一道坎：让公司授予你 Staff 头衔。对有些人来说，这个过程只是个小插曲，也许比预期的多花一两个晋升周期，但最终还是成功了；而对另一些人来说，在当前公司可能永远都拿不到。我调研过的 Staff Engineer 中，约三分之二是在当时所在的公司通过晋升拿到头衔的，剩下三分之一则是通过换公司拿到头衔的。

如果你 pursuing 的正是这类角色，那就把升到职业层级当作一次重新规划职业走法的机会。从那一刻起，就没有标准路径可走了。晋升和绩效体系不再围绕“按时晋升”来设计，有时甚至会给人一种设卡的感觉。

要想再往上走，_你_必须更主动地掌控自己的晋升节奏，本章分享的正是那些已经走通这条路的人验证有效的方法。

找到你的路

如果你一直靠经理来指引职业发展，那么转向自我主导的职业发展会让人觉得有些突然。讲软件职业管理的书很多，但大多只讲到从入行到 Senior Engineer，很少关注 Senior 之后该如何管理职业生涯，而本章关注的正是后者：

• **晋升材料包（promotion packet）**是你理解 Staff 晋升、找准个人发展重点、激活内部赞助人和人脉来支持你晋升的基础工具。

• 有一种广泛的看法，认为进入 Staff 及更高级别必须先成功完成一个 Staff 项目。本节会讨论一个现实：大多数 Staff Engineer 其实并_没有_ Staff 项目，同时也会讲，如果你所在的公司确实要求 Staff 项目，该怎么应对。

• 工程师们经常抱怨自己不在“房间”里——决策发生的地方，而他们通常是对的：确实有这么个房间，而他们确实不在里面。但更少有人承认的是：你不在房间里，很可能是有充分理由的。本节会讲如何进入房间，以及如何留下来。

• 最后，如果公司领导层不知道你是谁，你就不可能被提拔。如何在不抢占所有人氧气的前提下，在内部变得可见？

持续运用这些方法，你就在通往 Staff 头衔的路上了，尽管即使计划再周密，如果公司选错了，也会功亏一篑。

机会分布并不均匀

在追求 Staff 职位的过程中，你会遇到一个不太舒服的现实：在任何一家公司，机会的分布都是不均匀的。如果公司领导认为基础设施工程天生比产品工程“更复杂”或“杠杆更高”，机会就会向基础设施团队集中。如果你的组织强调交付功能，那么搞出一次故障再去修复，反而比预防未来的故障更容易获奖。如果你在本部办公，你的工作会比在分部办公更可见。

许多公司即使明知机会分布不均，也会假装机会是均等的，声称自己在这方面有既得利益。这让你很难确信这些规律真的存在，但当你收集到足够多的数据后，趋势就会变得清晰。

认清这些挑战之后，你要评估它们有多大程度上可以改变，以及你想把精力优先放在哪里。顺着这些暗流走，远比改道造就暗流的整条河要简单得多。如果你决定去解决不平等背后的成因，先找一位支持这件事的高级别赞助人。只有获得来自体系内部的赞助，你才能改变体系。

你应该尝试转管理吗？

能走到 Staff 及更高级别的人，大多数没有做过工程管理工作，但也有些人做过。很容易把这看作一个足以改变人生的重大决定，但这可能是想多了。如果你想试试管理，那就去试。大多数公司都明白管理并不适合所有人，也很乐意让你转回工程师岗位。

试过管理的人视野会更开阔，即使回到软件工程师岗位也会受益。Dan Na 的经历就是如此：

我至今既喜欢写代码交付，也喜欢带团队，我认为两者都能做到高水平，对长期的工程成功至关重要。Charity Majors 有一篇非常棒的博客值得一读：“The Engineer/Manager Pendulum”。Charity 认为“管理通道 vs 技术通道”是个伪二分法，在两个角色之间来回切换会让你在两边都做得更好。这和我的亲身体会一致。我之所以能当个更好的经理，是因为我知道在一个计划糟糕的项目里当 IC 有多痛苦；我之所以能当个更好的 IC，是因为我知道项目出问题时该如何、何时拉响警报。

Ritu Vincent 有类似的看法：

我来回切换得挺频繁的，因为职业阶梯两边的很多事我都感兴趣。我对培养人感兴趣，很喜欢和招聘合作，我就是那种真的喜欢面试的工程师，我喜欢理解团队是怎么壮大的。但我也真的喜欢写代码，管了一段时间团队之后，就想回到代码里折腾一下。

有些人试了管理之后发现自己很讨厌。Joy Ebertz 就不太喜欢工程管理：

我在 Box 的中段时间里其实做了一年半左右的管理，发现自己很讨厌它（更多内容可以看我写的关于这个话题的博客）。不过话说回来，我发现大多数公司里管理和 staff+ 角色其实有很多重叠。

尽管 Joy 讨厌那段管理经历，她觉得这对长期职业发展可能还是有帮助的：

如果我没有绕去管理走一圈，我有可能更早升到 Staff。不过话说回来，我不后悔，学到了很多关于人的想法、组织如何运转、大项目如何排优先级的东西。这些一直帮我在 IC 赛道上做好工作，很可能还帮我进一步升到了 Senior Staff。我确实认为它可能拖慢了我到 Staff 的速度，但对下一级我反而不太确定——我觉得如果没有那段经历，我很可能会在 Staff 上停留更久。<-总之，虽然我走的不是最直接的路，但学到的东西长期来看都帮到了我。

对考虑转管理的人，我最后要提醒的是：人员管理远不只是最大化你通往 Staff Engineer 的 trajectory。你会深刻影响你支持的每一个人，如果动机不对，你会后悔这段经历——但你的团队会比你后悔得多。如果你是出于帮助团队成长和成功的动机，那就去做；如果只是为了自己，那就别做。

半透的边界

最后要提醒的是，Staff 及更高头衔都是领导岗位。如果现有领导团队不认为你是潜在的一员，你就很难拿到领导岗位。不幸的是，这意味着，那些_看起来像_已经是现有领导团队一员的人，凭借这种优势会轻松得多。

完成过渡会更容易。

如果你读完本章，越来越 frustrated，因为你_已经_在做这里说的每一件事，那么你可能正遭遇这种结构性劣势。我聊过的女性中，约有一半不得不靠换公司才拿到 Staff 头衔，而在和其他人的交流中，晋升阻力 generally 根本不是话题。

不要忽视这些经历——它们是真实的，很多人都因此感到受挫——但也要抱有希望：无论你是谁、想走哪条通往 Staff Engineer 的路，都有很多成功的榜样。

晋升材料包

有些人把晋升材料包看作拿到 Staff 及更高级别的压轴之作，但我见过很多人用相反的方法取得了成功：在觉得自己可能升 Staff 之前很久，就开始写第一版 Staff 晋升材料包，用法很像 brag document。这样用，你的材料包就成了实现目标的地图。

你的公司很可能有自己的晋升材料格式，_最终_你需要把材料翻译成那个格式，再提交给内部晋升委员会或流程，但不用着急。你花在把它当指南上的时间，会远多于把它当正式评审材料的时间，所以优先为前者优化。

朝着 Staff 及更高级别晋升，一个通用的模板是：

• 你的 Staff 项目是什么？你做了什么？项目的影响是什么（包括明确定义的目标）？项目的复杂性在哪里？写得非常简短，然后链接到支撑的设计文档

• 你用哪些高杠杆的方式改善了组织？

• 你的项目有哪些可量化的影响？（收入增加了 1000 万美元？客户支持工单同比减少了 20%？）

• 你指导了谁，他们取得了哪些成绩？

• 你为组织做了哪些 glue work？这些 glue work 的影响是什么？

• 哪些团队和领导熟悉并支持你的工作？他们看重你工作的哪一点？一句话，尽量带数据（比如调研数据）

• 你有没有真实存在或可能被认为存在的技能或行为短板，会拖你后腿？每一条打算怎么消除顾虑？每条一句话

花点时间自己写出这些答案是很有用的，但晋升到领导岗位不是单人任务——只有在一群人一路支持下才能完成。

我推荐的材料包迭代方法是：

1. 回答你为什么要做这件事。很多人选择不追求 Staff 级别，你应该有自己重视它的理由。如果没有，你很可能会发现自己困在一个并不喜欢的角色里。

Michelle Bu 提醒说：“我给工程师的第一条建议是，不要为了 pattern matching 去做自己不喜欢的工作。我现在的工作让我充满能量，和团队一起解决抽象的建模和设计问题。要经过很多轮反馈、一次次重来，需要相当大的韧性。说实话，这并不适合所有人。如果你更在意拿到 Staff，而不是让自己去做能给你充电的工作，很容易最后困在自己不想要的角色里。”

2. 管理好预期。 晋升，尤其是在这个级别，是按季度、半年、年为单位积累出来的。不要指望立竿见影。

3. 把经理拉进来。 带着 promotion packet 去参加下一次和经理的 1:1，告诉他们拿到 Staff 晋升是你的目标。和他们一起过一遍这份还空着的材料，问他们缺什么、该强调什么，要不要在流程里加步骤。目标是让他们知道你对这件事有兴趣，并请他们指导你的打法。

Ritu Vincent 建议说：“经常有人来问我，‘我接下来该做什么才能到 Staff？’我告诉他们的其中一件事是，对经理要非常坦诚，说出你职业上真正想要什么。我早期 1:1 犯过的一个错误是，只说我觉得经理想听的话，而不是我真实的想法。”

4. 写出 promotion packet。 现在就把材料包写出来

5. 改 promotion packet。 等两天，重读你的 promotion packet，从内容、清晰度、上下文三方面修改

6. 和同级一起改 promotion packet。 把 promotion packet 发给几位信任的同级征求反馈，最好是已经在 Staff 及更高级别的同级。同级往往比你自己更清楚你的长处和贡献，也比经理更接近你的工作

7. 和经理一起改 promotion packet。 把 promotion packet 发给经理请他反馈。重点请他列出还需要补的短板。问他能不能在下一次 1:1 里花点时间，讨论做哪些项目和争取哪些机会，既能补短板又能让材料更强

8. 和经理定期回顾 promotion packet。 在和职业、绩效相关的 1:1 里持续和经理回顾晋升材料包。你和经理都应该用它来指引你逐步达到晋升标准。如果你的直属经理换了，这一点尤其重要。留着这样一份文档并跨经理持续回顾，能缓解换经理后晋升进度归零的常见问题

如果你 methodically 照着做，就会在被提名前很久准备好第一版 Staff 晋升材料包。之后，你就用它来聚焦注意力，经营和经理的合作，一起朝目标努力。它不一定让你升得快，甚至不一定让你在当前公司升上去，但它会把你的精力和成长集中到朝目标推进的工作上。

等到真正要写正式材料时，只需要把积累的内容精简进官方模板，而不是去故纸堆里翻几年的工作。希望晋升流程一切顺利，Staff 头衔随之而来。

找到你的赞助人

有个赞助人确实很重要。我和经理的关系非常好，和 skip-level 经理的关系也很好。我觉得这起了很大作用。—— Ritu Vincent

和更多想拿到第一个 Staff 及更高头衔的人聊过之后，发现大多数人都会遇到类似的挑战。很多人对自己的影响力估计不准，其实还没做到那个级别该做的事：Staff Engineer 不是更快 的 Senior Engineer。但还有一大群人已经把事做成了——在组织里可见度很高，也准备好了很强的晋升材料——却还是得不到认可。

这些人常常为实际影响力和被认可的影响力之间的落差而 frustrated，去问经理和同级该怎么补差距。得到的回答往往是去做个 staff 项目，或者去给别人腾空间。对还没把事做成的人，这是很好的建议，但对已经做成的人，这些 checklist 反而是干扰：他们真正缺的是一个愿意推动认可他们已有工作的赞助人。

我们很容易把晋升体系类比成学校这类评价过我们的体系，但这就把绩效评估误当成了单人活动。无论你的公司是临时起意式晋升还是用 calibration 流程，晋升都是团队活动。正如当时在 Slack 的 Julia Grace 有次在我找工作时 khuyên我的：“别单打独斗地玩团队游戏，你会输的。”

找到你的赞助人

指引你晋升的团队里，最重要的人是你自己，第二重要的人是你的组织赞助人。Lara Hogan 写过很多关于赞助（sponsorship）的文章，大意是：在有影响力的场合、在争取稀缺资源（比如加薪预算）时，为你的工作发声的人。

你可能会有多个赞助人，但在晋升——尤其是晋升到 Staff 及更高级别——这个语境下，这个人几乎一定得是你的直属经理。他们会把你起草的晋升材料转成公司格式；会在 calibration 会议上，当别人深挖你的资质时为你辩护；也会和你坦诚地聊，你离强有力的晋升候选人还有哪些差距。

虽然直属经理必须作为赞助人深度参与，但你可能还需要额外的赞助。如果你的经理以前从没提拔过人到 Staff 及更高级别，过程中很可能会意外掉链子。花点功夫和你汇报链上更高层建立关系。你不需要和 skip-level 经理花太多时间，但如果两个月后的一场会上，他们连你的工作影响都想不起来，你就不太可能升到高级别。

激活你的赞助人

激活赞助人的第一步是明确说出你的目标。“我希望被认可为 Staff Engineer”就是个很好的开头。Ritu Vincent 说这是她给想拿 Staff 及更高级别的人的首要建议：

经常有人来问我，“我接下来该做什么才能到 Staff？”我告诉他们的其中一件事是，对经理要非常坦诚，说出你职业上真正想要什么。我早期 1:1 犯过的一个错误是，只说我觉得经理想听的话，而不是我真实的想法。

很多人找到赞助人后就觉得万事大吉了：重活都该赞助人去干。这通常会失败！赞助人是组织资本比带宽多的人，只有你把事情都铺排好，他们才能最好地帮你。问问赞助人你可以怎么支持他们的赞助工作。经营职业生涯不只是索取。当然索取是其中一部分，但更多是去促成事情发生。

和赞助人一起协作回顾晋升材料包，是开启这个对话的好办法。问差距时要注意方式，别逼着赞助人编答案。大多数人忘了自己可以说“我不知道”，被追问不确定的问题时反而会编出没用的答案。如果你总听到“做更大、影响更大的技术项目”这类回答，说明你问的方式、问的问题或问的人不对。

一个开场问题可以是：“如果这一轮我没升上去，可能的原因会是什么？”另一个值得问的是：“做什么最能让我成为更强的候选人？”不过，最好的问题都很具体，而且替回答者做了大部分功课。想想下面两个问题哪个更难回答，对比“这个季度我做了 API 重构，本以为能证明 Staff 级别的工作，但排期拖了很久，产品经理因为自己的工作被耽误很恼火。我当时怎么做会更好？”后者即使回答者不太了解项目细节，也更容易给出有用的回答。

最后记住，激活赞助人不是晋升前做一次的交易。花时间经营关系，在他们需要支持时也出力，和他们的目标保持对齐。如果他们需要人加入某个工作组，主动报名并投入干活。这些人身边求办事的人很多，他们很清楚谁只在晋升前才出现。我以前有个同事平时很少来办公室，但每次做晋升决定的前一周_一定_来。大家都看在眼里。

如果行不通怎么办？

如果你和经理合作不顺——这和喜不喜欢对方还不是一回事——那你就不可能升到领导岗位。经理对你的影响力和被感知的影响力都影响太大，合作不好就不可能晋升。同样，你可能和经理关系极好，但他离职了。你不至于_没救_，但和新经理重建关系很可能让你的晋升时钟归零。（有时反过来也成立：新经理为了向你证明自己，会卖力替你争取。）

和经理一有摩擦就换团队或换公司，会坑了自己。公司 generally 不允许未经经理同意的转岗，你可能烧掉自己正站着的桥，桥对面还什么都没有。更重要的是，你会失去锻炼一项能力的机会：和气场不合的人共事。这项能力练起来不好玩，但领导力_永远_需要影响和团结目标、风格冲突的人。

如果你已经主动努力了六个月去经营这段关系，那大概是时候考虑换团队，甚至换公司了。这正是和 skip-level 经理搞好关系极有用的场景之一：即使你和经理合作不畅，他也能帮你找到新团队。

Staff 项目

没有明文规定，也没在任何地方写成正式要求，但大家都默认你要完成一个 Staff Project 才能晋升。我想不起有哪个 Staff 晋升是没有一个很强项目的，通常是多人项目，晋升的人担任 Tech Lead。—— Ritu Vincent

关于拿到 Staff 及更高级别，一个反复出现的流行说法是：首先，你要成功完成一个“Staff 项目”——一个足够复杂、足够重要的项目，做成它就证明了你是 Staff 工程师。不管这个说法多流行，如果你在 pursuing Staff 及更高级别，一定要戳破这些项目的神话，把注意力放在走过这条路的人的真实经历上。

关于 Staff 项目的简短回答是：大多数工程师在拿到 Staff 职位的过程中并_没有_完成这样一个项目，不过有相当大的一批人完成了，尤其是那些在同一家公司成长起来、靠内部晋升拿到头衔的人。对没做的人来说，通常要么是靠长期积累的成功记录、没有单一的压轴之作，要么是靠换公司拿到头衔。

我们从几个角度深挖 staff 项目：

1. 没做 Staff 项目的人

2. 做了 Staff 项目的人，包括项目不如预期的情况

3. 如何识别和着手你的 Staff 项目

进入 messy 的细节吧。

不需要 Staff 项目

当我问大家有没有 Staff 项目时，有些回答相当简洁：

• Joy Ebertz：“我其实并没有什么 Staff Project。”

• Diana Pojar：“没有，我没有被指派过‘Staff Project’，Slack 的晋升流程里也没有这个东西。”

有些人甚至对 Staff 项目这个概念整体持怀疑态度。Nelson Elhage 说：

我本能地对这种 staff 项目的想法有点警惕，部分原因是，我见过的 Staff Engineer 原型里，有一类人并不亲自操盘大项目、做大事。他们就是特别厉害的 guru 和 router，让整个工程组织运转得更好。

也有像 Dan Na 或 Damian Schenkelman 这样绕道工程管理拿到头衔的人。Damian 描述了自己如何跳过 Staff 项目：

我没有。因为我在 Auth0 的成长路径，我算是“跳过了那一段”。作为一家创业公司的 Director，我有机会从技术上主导很多重大关键项目，但并没有某个明确的“staff/principal 项目”。

从这些故事可以清楚看到，凡是告诉你_必须_完成 Staff 项目才能拿到 Staff 及更高头衔的人都是错的：不做 Staff 项目也能走到 Staff 及更高头衔，路很多，去工程管理轮岗一圈就是其中 prominent 的一条。

需要 Staff 项目

但同样真实的是，很多公司要求 Staff 项目，或在内部晋升中非正式地执行，很多人也确实在转型过程中承担了一个 Staff 项目。

Ritu Vincent 讲了她在 Dropbox 的经历：

我 definitely 有个 Staff Project。当年 Dropbox 最初是个消费者产品，要下载安装到电脑上。当我们推出 Dropbox for Business 时，有个需求是个人账号和工作账号同时可用，切换账号不需要登出再登录。最初的实现赶工痕迹很重，跑了多个 Dropbox 进程：个人账号一个，工作账号一个。我的 Staff 项目就是让单个 Dropbox 进程支持多用户同时登录。难的是项目从内核一直贯穿到用户界面，我必须理解 Dropbox 系统的每一层。最初以为六个月能做完，最后花了十八个月，Desktop Client 团队相当长时间里大部分资源都耗在上面。

Ras Kasa Williams 加入了一个进行中的项目，后来成了负责人，这个项目成了他的 Staff 项目：

我以 Senior Engineer 加入 Mailchimp，立刻被放进一个项目组（包括一位 Engineering Director 和两位 Principal Engineer），要做 Mailchimp 第一个内部自助分析平台。

这个项目的关键是高效、高水平地执行。好也罢坏也罢，有另外两位 Principal Engineer 在，对我的期望可能本来就不高。

但我立刻上手，几乎不需要他们扶，就开始给核心部分做贡献；到最后，我成了团队的关键贡献者之一。后来我被正式任命为 tech lead，继续带领这个项目，直到它被吸纳进我所在的 Data Services 工程组。

很少有公司把 Staff 项目要求写下来。它们更像是晋升会上冒出来的“软门槛”，有时连经理和准 Staff 工程师本人都措手不及。发现这些要求最可靠的办法是：一次十拿九稳的晋升没被批——但这不好玩。几乎同样可靠、但没那么折磨的办法是：提前维护晋升材料包并征求反馈。

为什么你应该做 Staff 项目

有时很难分清门槛和评估之间的精确界线，而 Staff 项目的前提就处在这个模糊地带。接下一个 scope 巨大的项目，在模糊中穿行并成功交付，是区分达到 Staff 及更高影响力的人的有效方式，但同样清楚的是，很多人没做这种项目也拿到了 Staff 及更高级别。

我的建议是：虽然不做 Staff 项目也能拿到 Staff 及更高级别，但它们是特别宝贵的自我锻炼机会。这种项目对你_个人_的拉伸和成长，是其他 Staff 级别工作给不了的。

Keavy McMinn 讲了她的 Staff 项目如何帮到她：

我没听过这个名字，但我懂这个意思。

我确实主导和设计过这类项目——解决棘手的工程问题，给公司带来很大影响——做好几次，但不幸的是，它们都没让我升职。不过它们确实推动了我的职业发展。这些项目给了我经验、知识和信心，让我能换个姿势定位自己。甚至能去公开技术大会演讲，或者知道“我做成过 X，还能再做成 X”。

虽然每个项目都不一样，但有一些典型特征，说明了它们为什么这么锻炼人：

• 复杂且模糊——职业早期，你拿到的问题定义都很清楚，但越往深走，遇到定义不清甚至完全没定义的问题就越多，而 Staff 项目一般都始于一个 scope 不清、但复杂且_重要_的问题。你的项目可能只始于一句断言：公司老化的单体应用正在拖累产品开发。从这样宽泛、模糊（甚至可能是错的）的陈述出发，你要找到一条切实可行的路。

• 利益相关方众多且分裂——最轻松的项目始于组织在问题和解法上都已对齐，但你的 Staff 项目很可能两边都没对齐。可能是管理层视为生死风险的领域，很多工程师却觉得够用了；也可能是所有人都承认是问题，但在路线上 faction 分明，比如走服务化路线还是继续给现有单体加码，争得不可开交。

• 挂名的赌注，失败了要紧——它会重要到高层在全组织或全员大会上都谈起。这意味着很多人盯着你的工作看，失败会非常显眼。成功也会高度可见！

如果都对上了，那大概就是 staff 项目了。这些都挺让人紧张的，也正因如此，它们才这么锻炼人。

如何拿到 Staff 项目

决定要做 Staff 项目只是第一步，你还得_拿得到_这些项目，这取决于你的管理链是否足够信任你、敢在你身上押注。

这取决于三个因素。

1. 第一是学会和领导团队保持对齐，策略见 Get in the room 和 Staying aligned with authority。

2. 第二，你得让人知道你有搞定手头问题的技术功底，这需要 Being Visible。

3. 第三，不太由你控制，就是公司得正好有个 Staff 级别的问题急需解决，这需要一点耐心。

你应该追求 Staff 项目吗？

总结一下，如果你想在当前公司晋升，而且以前没拿过 Staff 或管理头衔，那你很可能需要做一个 Staff 项目来证明自己到了那个级别。其他情况则很可能不需要。

无论如何值得记住的是，不管这些项目是不是硬性要求，它们都是你能找到的最有挑战的工作之一，是能把你拉伸成更好工程师的工作。为了短期拿头衔，避开这些项目可能是最优的，但为了长期的自我成长，它们无可替代。

进入房间，并留下来

我从工程师那里听到的最常见的 frustration 之一是：他们不在重要决策发生的房间里。他们看不懂公司决策，手里的重要上下文似乎被漏掉或无视了。Staff 及更高级别的工程师经常把能进“房间”列为级别的一大好处，头衔确实会增加你参与影响自己的决策的可能性。

但重要的是，根本没有唯一的“房间”可进。进入正确的房间不是一次性挑战。进房间会是持续的、反复的职业挑战。这意味着值得练好这门功夫！

职业早期，它可能是和 tech lead、产品经理一起的 sprint 排期会； later 可能是季度规划会、架构评审、绩效 calibration、工程领导团队，甚至高管团队。永远有下一个房间要进。要走到高级别，不仅要会_进去_，还要会_留_在这些权力房间里。

进入房间

要进入房间，你需要：

• 给房间带去有用的东西…… 可以是关键项目的细节、关键团队的上下文、和房间议题相关的领域专长、在上家公司操盘类似项目或团队的经验、和关键客户的关系，或者其他完全不同的东西。

• ……而且是房间里还没有的东西。 光有用的东西不够，还得是房间里现有成员视角之外的东西。小 group 比大 group 好使，所以运作型会议一般都为效率牺牲冗余和代表性。要被纳入这些房间，你得带来和现有成员不一样的东西。

• 房间里的赞助人。 这些房间名额有限，还要作为一个整体运转良好。要进去，你需要有人赞助你的成员资格。赞助人是在拿自己的 social capital 为你背书，你在房间里的表现会连带影响别人对他的评价。这些房间里往往 seniority 混搭，所以经常是赞助人的经理在房间里，根据他赞助_你_的决定来评价_他_。

• 你的赞助人要知道你想进去。 你的赞助人大概身处很多不同的房间，做梦都想逃掉其中大多数会。他们不会默认你想进某个会，甚至可能默认你根本不想去。如果你想被带上，一定要让他们知道。

怎么给房间带去有用的东西，完全取决于你和你想进的房间：没有单一套路可循。有没有和你背景相似的人已经在房间里，也取决于你的具体处境，有些时候唯一的选择就是等，或者找另一个房间进。

反过来，有时提高你对房间价值最简单的办法是降低带你进场的成本。一些有效的做法是：

• 和经理保持对齐。 大家评价领导时，会看他的团队和他宣称的方向有多对齐。如果他宣称转向持续部署，团队却天天喊着要 release train，大家就会怀疑到底谁在领导谁。如果你和赞助人高度对齐，就更容易被赞助进房间。如果_特别_对齐，他们甚至更愿意把自己的位子让给你，自己不去了。

• 为整体优化。 Stripe 当年的运营原则之一是“Optimize for Stripe”，这种广泛为他人优化的心态能建立信任，让人相信你的判断。

• 说话清楚简洁。 学会简洁：说话越精炼，同样时间能贡献越多想法。学会清楚：如果别人听不懂你的提议，再好也没用。记住，被听懂是你的义务，不是别人有义务听懂你。

• 低摩擦。 很容易掉进一个陷阱：把每次讨论都当成阻止迫在眉睫灾难的最后机会。抱着这种心态，每次讨论都像救火，情绪拉满。这类讨论通常都在消耗 frustration，而不是推进进展。如果你以能顺畅处理 hard 对话著称，就更容易被带上。

• 做准备。 有些公司把工程师当小孩，默认即使很资深的工程师也不会看议程、做预习、为讨论做准备。被容忍和被奖励之间有巨大鸿沟，如果你愿意花时间在每次会前整理想法，会很出挑。同样重要的是，说到做到，会后跟进你认领的事。

• 专注、在场。 进了房间，就要到场、要参与。专注投入。你想干的别的事，都可以等等。

• 主动认领低-status 的活。 如果需要人记笔记，举手。如果需要人跟进行动项，主动接。优先做有用的人，尤其是那些不那么出彩的活。

要进入房间，分子分母要一起做：一边持续打磨独特有用的视角，一边让自己更会开会，在会议的约束里交付这个视角。

留在房间里

进了房间只是第一关，第二关是留在房间里。最重要的是继续做让你进来的那些事：带重要上下文进房间，呈现 polished 的自己，简洁，灵活。

有几种 pattern 会稳定地让你被踢出去：

• 搞错房间的用途。 每个房间都有自己的用途，如果你逆着现有群体的意图用房间，就会制造摩擦。外界对某个房间功能的认知（“领导团队会上做所有决策”）和房间对自己的定位（“我们不做决策，只抛问题讨论”）相去甚远，是很常见的事。花时间理解房间怎么运转，带着对初衷的尊重融入进去。

• 教条。 房间越 senior，要聊的话题越敏感（薪酬、裁员、晋升、收购等等），每周一起干活的时间却是固定的。如果你教条，就会制造摩擦，拖慢讨论，妨碍群体推进。

• 拒绝 consent。 高效的群体由愿意 disagree and commit 的个体组成。你可以用 withholding consent 把群体逼向你的观点，但群体的速度会慢到停滞，你也很可能被移出去。

• 吸走房间里的氧气。 有的讨论是 brainstorm，来什么想法都要；有的时刻已经切到执行模式，要给项目执行 unblock，得会读房间现在是哪一种。通常这出于想证明价值的冲动，但记住，你进房间是因为带你进来的东西，不是因为进了房间就会 magically 把你变成全新的人。

• 让赞助人难堪。 记住你进房间是因为房间里有人主张带你。

• 不靠谱、不规律出席。 名额就那么多，主持会议的人会优先给到场的人。

话说回来，我觉得在这事上太焦虑没必要。有时更值得想的是这个房间值不值得你花时间。

离开房间

要记住，虽然房间无限多，但没有哪个房间里在干真正的活。如果你精挑细选留哪些房间，影响力会最大。我见过很多人 resent 自己不被放进某个心心念念的房间，但从没见过谁后悔太早离开某个房间。如果某个房间觉得没用，就离开。离开时，把你空出来的机会赞助给别人。

变得可见

找我问建议的人，特别是女性和非二元性别者，我觉得他们都以为我要讲怎么成长为技术 leader，听到我说“你的技术功底大概已经够了，你要做的是经营你在公司的 reputation”都会很意外。是好是坏，不经营好名声到不了 Staff。—— Katie Sylor-Miller

Bert Fan 给想拿 Staff 及更高级别的人的最好建议是：“晋升 Staff 往往是运气、时机和努力的结合。”时机是一种特殊的运气，还可以进一步简化成运气和努力。

如果你幸运，就不用刻意谋划通往 Staff 及更高级别的路：你已经在做公司最高优先级的事，有站位好、愿意支持你职业发展的经理，还在本部办公室办公。如果你开局三样全无，晋升会相当 hard，但也别把自己判死刑：人很容易低估自己在变幸运这件事上的作用。

变幸运最有效的方法之一是在组织里更可见。当然，肯定有又快又负面的出名办法，所以精确一点：目标是以最小的组织带宽消耗，因为好事被知道。

为什么可见性重要

Katie Sylor-Miller 把可见性描述为晋升 Staff 的关键一环：

有一件事我讲得还不够：沟通和透明。晋升 Staff 的很大一部分是确

保你的工作可见，大家知道你的名字，你有个好名声。

Staff 及更高级别是_领导_岗位，公司授予你这样的职位，就是把你吸纳进领导团队。现有成员要确信，相信你这个新人，才能放心扩员；如果他们根本不认识你，就无从相信。

如果你在公司没什么可见度，这看起来就像小圈子或 gatekeeping；反过来，如果你在内部广为人知，这就像给接领导岗位的人维持一套一致的期望和标准所必须付出的成本——连工作都不了解，怎么保证标准一致？

顺带想一下，包容的组织如何缓解“验证新人配不配进领导团队”中的负面 gatekeeping：答案是设计机制，确保_所有_潜在领导者都能被将要评估他们的人看到。反过来，不那么包容的组织会无意中把机会让给最会自我推销的人。

内部可见性

建立内部可见性最好的办法，是去做对公司和公司领导重要的事。这条路也和一家管理良好的公司评估你贡献的方式最对齐。

但有时光这样还不够，还可以试试：

• 写更多长寿文档并传播，比如架构文档或技术方案。

• 主导（其次是参与）公司论坛，比如架构评审、全员会、学习小组。

• 在 Slack 上为团队和同级的工作喝彩。

• 也可以用邮件而不是 Slack 喝彩。

• 每周把工作小结分享给团队和利益相关方，让感兴趣的人能看到。

• 给公司博客投稿。

• 参加甚至主持你团队或组织 的 office hour。

找到适合自己的组合：发挥长处，别去已经人满为患的渠道，做自己觉得 authentic 的事。如果你以前很少对外讲自己的工作，自我推销会觉得别扭。别扭感永远不要全丢——克制是好事——但多少得习惯一点。

高管可见性

要升到领导岗位，最重要的内部可见性是高管可见性。用晋升材料包，你能在经理那里建立可见性，但值得再往上走一步。特别值得找机会和经理的经理建立关系，在那一层所有正面的可见性都会帮到你。

这些人往往就在审批 Staff 及更高级别晋升的房间里，他们很少支持自己不了解工作的人。

外部可见性

在做内部可见性的同时，补一点外部可见性也有帮助。很多成功的 Staff 及更高级别工程师没有任何外部名气，但很多人发现外部可见性对职业有贡献。

和只做内部比，建立外部影响力的一个好处是：找 niche、立名号的空间大得多。内部努力最后往往变成和同级抢注意力，外部则完全不会。

至于怎么做、怎么让自己和工作被看到，可以是像 Keavy McMinn 或 Dan Na 那样做大会分享，像 Michelle Bu 那样上播客，像 Katie Sylor-Miller 那样把问题做成网站和书 ohshitgit，或者像 Stephen Whitworth 那样做邮件组 High Growth Engineering。

你** **应该聚焦可见性吗？

你在组织里的可见性永远可以更高，但过了某个点，你刷可见度就是在挤占别人建立可见度的机会。内部可见性不严格是零和的，但受限于你想触达的人的注意力。

我的建议是：用晋升材料包练习判断一下，可见度不足会不会在晋升流程里拖你后腿。如果会，就补到过线，别多太多。可见性是 transient 的货币，学习和自我成长才是永久的货币；过了最低线，就聚焦后者。