很多工程师的技术能力其实已经达到了下一个级别，但为什么还是升不上去？原因很简单：没人跟你解释清楚这家公司这台“晋升机器”到底是怎么运转的。

你的主管给你的反馈往往是残缺的。他们只了解自己那部分流程，不清楚晋升委员会的标准，所以最后只能告诉你：“继续做你正在做的事，你离目标很近了。”这话听着挺对，但毫无用处，结果就是下一个周期你还是卡在原地。

今天，我们就根据四大科技巨头的公开资料、工程师复盘和职级数据，把这台“机器”重新拼凑出来。请注意，这不是你们公司的内部文档，具体细节还得找你自己的主管确认。

各家大厂的职级并不完全对齐

为了避免使用复杂的表格，我们用简单的列表来看看各大厂对应的级别和典型工作经验（YOE）：

• 入门级：Google (L3) / Meta (E3) / Amazon (L4, SDE I) / Microsoft (59-60) / Apple (ICT2) —— 经验：0-2年
• 中级：Google (L4) / Meta (E4) / Amazon (L5, SDE II) / Microsoft (61-62) / Apple (ICT3) —— 经验：2-5年
• 高级：Google (L5) / Meta (E5) / Amazon (L6, SDE III) / Microsoft (63-64) / Apple (ICT4) —— 经验：5-8年以上
• Staff级：Google (L6) / Meta (E6) / Amazon (L7, Principal) / Microsoft (65-66) / Apple (ICT5) —— 经验：8-12年以上
• 高级Staff级：Google (L7) / Meta (E7) / Amazon (L8) / Microsoft (67) / Apple (ICT6) —— 经验：12年以上
• 首席/杰出工程师：Google (L8-L9) / Meta (E8-E9) / Amazon (L10) / Microsoft (68-69) / Apple (Distinguished) —— 极其罕见

要注意，Google 的 L5 是高级工程师，而 Amazon 的 L5 只是中级。猎头在做职级映射时只是大致对应，所以年限只是参考，不是硬性要求。

这里有两件事比数字更重要。

首先，相邻级别之间的跨度不是恒定的。从入门到中级，主要是变得“靠谱”；从中级到高级，是变得“独立”；而从高级到 Staff，晋升阶梯就不再像个阶梯了，这其实是工种的改变，之前让你晋升的那些技能只有一部分能派上用场。

其次，每家公司都有一个“适合干一辈子”的级别。比如 Google 的 L5、Meta 的 E5、Amazon 的 SDE II 或 III、Microsoft 的 63 或 64。在这个级别之下，公司期望你不断往上爬，有些公司甚至给你倒计时；在这个级别之上，晋升是可选的，难度大得多，也没人会追着你升职。

晋升会议室里到底发生了什么

四家公司的流程差异很大，搞错对象白费一年。

Google 的流程最正式。你的案卷是一个“晋升包”：一份针对目标级别的自我评估、证据（设计文档、项目上线数据）和同事评价。一个由高级工程师组成的委员会会批量阅读这些材料并做出决定，这些评委从来没和你共事过。你的主管负责提名和背书，但不会坐在委员会里。结果就是：同事评价比自我评估更管用；如果你上线了一个项目却没写设计文档，这就是个非常弱的证据。

Meta 的晋升在一年两次的绩效周期内完成。自我评估、同事评价、主管评估一起综合考量。没有单独的申请流程。实际后果是：你的成果必须每六个月就能让人看懂。一个伟大的两年期项目如果在第12个月拿不出东西，在这个系统里就是个坑。你要把工作拆成看得见的部分。

Amazon 靠写叙述文来晋升，围绕领导力准则展开，并由“抬杠者”（Bar Raisers，团队外的高级工程师，专门为了防止降低标准而存在）审查。大家吃过苦头才知道两件事：项目太新对你不利，因为被拒的常见理由是“项目太新，还没看到结果”；可见性是工作的一部分，而不是锦上添花。

Microsoft 使用 Connect 系统，主管在校准会议中决定晋升。它的模型单独给三项打分：你自己的成就、你如何借助他人工作、你如何促成他人成功。这个模型专门为了打破“各自为战”的文化，这意味着一个单独发布了优秀功能的工程师，得分可能低于一个发布了稍小功能但帮两个团队扫清障碍的工程师。

四家公司其实都在衡量同一件事

抛开那些行话，每个职级体系都在问一个问题：因为你的存在，有多大范围的世界变好了？有多可靠？

先是任务，然后是问题和团队，再是对组织的“持续影响”。这里的“持续”是关键。

一旦明白了这点，很多令人费解的反馈就读得懂了：

• “你需要更大的范围”：意思是你的问题都是别人挑好给你并限制在团队内的。
• 我们需要看到持续性”：意思是你做了一次下一级别的事，委员会想知道这不是偶然或主管给的照顾。
• “你做得很好，但是……”：几乎总是意味着你的工作在团队之外没人知道，或者你还在做去年同样大小的事，只是做得更好了。

最后一点是个陷阱。优秀的工程师卡住，最常见的原因就是不断做让他们升到当前级别的事。如果你因为快速干净地发布功能而升到中级，那么更快更干净地发布功能并不能让你升到高级。高级是另一种工作形态：选择做哪些功能、对结果负责、让周围的人更快。如果工作形态不改变，做再多也只会换来一样的评价。

另一半的真相是，晋升是滞后指标。Google 的“两个季度处于下一级别”，Amazon 的“持续超越”，Meta 的“持续”，都是同一个要求的不同说法。委员会不是在押宝你的潜力，而是在确认一个既定事实。

这就反转了大多数人的计划方式。问题不是“我需要做什么才能升职”，而是“下一级别的人每天都在做什么，我多快能开始做这些事”。一旦你能回答这个问题，升职就只是走个过场。

优秀工程师卡壳的六个原因

几乎每一个被卡住的晋升，都逃不出下面这一两条原因。诚实地对号入座吧：

1. 工作形态没变：你还在做让你走到今天的事。
2. 影响不可见：工作很实在，但没设计文档、没数据，团队外没人说得清它。
3. 没有赞助人：主管喜欢你，但没哪个有话语权的人愿意为你押上他们的信誉。
4. 成了没功劳的“粘合剂”：你把团队维系在一起，大家谢谢你，但不给你升职。
5. 证据时间不够：下一级别的工作三个月前才开始，结果还没出来。
6. 团队或主管不对：你现在的位置没有下一级别的工作，或者你的主管没法/不愿为你争取。

第四点特别值得拎出来说，因为没人会提前警告你。Tanya Reilly 的演讲《成为粘合剂》描述了那些保持团队运转但职级体系里却只字不提的工作：帮新人入职、更新路线图、跨团队协调、发现掉落的任务并捡起来。Reilly 引用研究指出，女性更容易被要求做这些不可晋升的工作，但任何认真负责的人都会掉进这个陷阱。记住这句话：如果你只做粘合剂，你就只会越来越擅长做粘合剂。

解决办法：向主管明确指出这些事，并附上花费的时间，因为大多数主管是真的不知道。把这部分写进晋升案卷里，贴上“技术项目领导力”或“团队赋能”等可见标签。如果晋升还是被卡，那就刻意转向一段时间可量化的技术工作。这听着不公平，但这招管用。

能解决大部分问题的两个习惯

大多数“不可见”的问题，都可以通过一个十分钟的日常习惯来解决：每周五给主管写一份书面更新。

已发布 / 已决定：一到三件已经完成的事情。尽可能带上具体数字。
进行中：正在推进的事情，以及是否步入正轨。是/否。如果否，原因是什么，你在怎么做。
阻塞 / 需求：你需要什么，作为一个带有截止日期的请求。比如“需要在周四前对X做出决定，否则我们会延期一周”。
帮助过的人：你为谁解了围，为谁做了代码审查，或教了谁。这是大多数人最容易漏掉的一行，但恰恰是构建“高级别”案例的关键。
下周计划：下周要达成的一个具体结果。

把这些记录都留存下来。它们是你晋升案卷的原始素材，这也意味着那个需要为你争取的主管，在需要开口之前就已经掌握了信息。

第二个习惯是你如何记录项目。委员会相信数字，不信任形容词，所以每个项目都应该按固定格式写：范围，然后是你具体做了什么，最后是发生了什么改变。

• 弱：“领导了计费服务到新平台的迁移。”
• 强：“负责计费服务（每天1200万请求，4个依赖团队）迁移到共享平台：编写设计文档，与支付团队谈判API契约，在零客户可见错误的情况下完成双写切换。结果：P99延迟降低61%，每周两次的待命告警消除，该模式在下个季度被另外两个团队采纳。”

“结果”这一部分是大家最容易漏掉的，而这正是 Amazon 所说的“太新”的意思。如果你还填不上结果，说明这个项目还不能作为证据。规划时要确保它能出结果。

如果你觉得没有数字可写，可以去这些地方找：仪表盘（延迟、错误率、吞吐量、成本）、工单系统（告警、事故、解决时间）、采用率（使用该功能的团队、被解围的工程师）、算出来的节省时间，实在不行，就引用受影响人员改造前后的真实描述。

谈话，以及何时进行

大多数工程师的晋升谈话都太晚、太模糊，或者根本没谈。正确的时机是你预期晋升前的 9 到 12 个月，正确的姿态是请求一个计划，而不是索要头衔。

你可以这样开场：“我的目标是在大概【时间范围】内达到【某级别】的运作水平并被提名。这是一份对照职级标准的自我评估，我认为这里还有差距。我想听听你最真实的看法，然后我们能不能一起定义一下什么叫‘准备好了’——需要做哪些项目、什么证据、你需要看到什么。”

然后问三个问题，并把答案写下来：

1. “你需要看到什么才愿意把我推上去？” 逼问细节。“范围要更大”不是答案。“端到端拥有 X 项目并被 Y 团队采用”才是。
2. “你看到的最大差距是什么？” 听着，不要在当下反驳。这是你一整年能听到的最有价值的一句话。
3. “这个团队在未来一年有下一级别的工作可做吗？” 如果诚实回答是没有，那问题就不一样了，再怎么努力也修不好。

当天用书面形式跟进：“感谢刚才的交流，这是我所听到的我们达成的共识。”一个在书面上同意了计划的主管，如果不跟进就会显得很尴尬。然后每个月都把它放进议程里。

当答案是“不”的时候

大多数工程师至少收到过一次“还不行”，而你在接下来一个月的做法，比那个“不”本身更重要。

拿到书面且具体的反馈。“需要更多范围”必须翻译成“需要拥有像X这样的项目”。如果你的主管做不了这种翻译，让他们去找校准会议要。

然后对原因进行分类，因为原因只有三种：
– 工作不够 —— 找个更好的项目就能修。
– 证据不够 —— 通过写文档和选对评审人来修。
– 没有赞助人 —— 只能慢慢修，有时只能换团队。

设定一个日期：“如果我做了X和Y，你下个周期会把我推上去吗？”写下来。

不管你做何决定，不要闷声不响。被拒后六个月低头干活且没有任何沟通，是最容易把可以修好的“还不行”变成永久“不行”的方式。

一个诚实的告诫

Staff 级别是一个完全不同的职业。最清晰的信号是时间怎么花：基于调查的描述显示，Staff 及以上级别写代码的时间大约只占一周的五分之一。其余时间都花在写作、审查、对齐、决策和教学上。

Charity Majors 认为“管理是职业的改变而不是晋升”，这同样适用于 Staff 轨道。所以，如果你宁愿把一周时间花在代码库里，而不是花在替别人做决定上，那最好在花一年时间准备案卷之前就弄清楚这一点。上面提到的所有公司里，高级以上的级别真的都是可选的。

一个有用的测试是诚实地回顾一周：在一个你几乎没写代码，但有三个人因为你的存在而取得了原本无法取得的进展的星期结束时，你感觉如何？如果觉得这是个好周，那继续往下做是有意义的。如果觉得这周被浪费了，那就把高级做好，让别人去准备那个晋升包吧。

直达网址：https://ginocorp.gumroad.com/l/bvbpog