聊聊 Meta E5 升 E6，感觉最重要的不是多干活

这篇不算成功经验，主要是结合身边见过的 case，再加上和 manager、senior engineer 聊下来的一些理解。
Meta E5 到 E6 应该算一个挺大的坎。E4 到 E5，很多时候项目做得不错，执行比较靠谱，impact 够，基本就有机会。E5 到 E6 不是简单地把项目再做大一点，也不是多写一点代码、多接几个项目。
我现在的理解是，E5 主要是证明一件比较复杂的事情交给你，你可以自己搞定。E6 则是这个方向本来都不太清楚，你能把问题定义出来，拉上需要的人，最后真正做出结果。
这里面有几个比较现实的点。

• 项目大不代表就是 E6 scope

这个应该是最容易踩的坑。
有些项目看起来很大，做了半年，涉及很多代码，也和很多团队合作，但核心方向是 manager 或 tech lead 定的，合作团队也是别人帮忙拉的，自己主要负责执行。
这种项目会是很强的 E5 impact，但不一定能支持 E6。
反过来，有的项目代码不一定很多，但一开始没人知道应该怎么做。你把问题找出来，提出方案，说服几个团队一起投入，最后还变成其他项目可以继续用的东西，这种更像 E6。
所以不能只问“我的项目够不够大”，而是要问：
这个项目里面，哪些关键判断是我做的？
如果没有我，这个方向还会不会以同样的方式发生？

• E6 不能只靠自己能干

E5 很容易形成一个模式：什么事情都自己做最快，别人搞不定的最后也自己接过来。短期看确实很有用，performance 也不会差。
但到了 E6，这种模式可能反而会限制 scope。
因为一个人再能写，产出也是有限的。E6 需要证明自己可以让周围的人一起产生更大的结果。比如把一个模糊方向拆成几个项目，让其他 engineer 可以独立负责；或者把几个团队各做各的东西统一成一套方案。
这不代表 E6 不写代码。技术深度还是要有，只是不能把“我写了很多代码”当成最主要的 promo evidence。

• Cross-team 不是多开几个会

以前我会觉得，和很多团队合作就是 cross-team impact。后来发现不是。
参加 sync、回复 message、帮其他团队解决问题，这些都算 collaboration，但不一定算 E6 influence。
真正有用的 evidence 一般是：几个团队原来目标不一样，或者对方案有分歧，你最后让大家接受了一套共同的方向，而且真的投入资源做了。
这里最难的是你对别人没有汇报关系，不能直接要求别人配合。只能靠技术判断、数据、方案和长期建立的 trust 推动。
所以 E6 的 cross-team impact，不是“我和五个团队合作过”，而是“因为我的工作，这五个团队改变了原来的做法”。

• Manager 非常重要

这个听起来有点现实，但确实如此。
升职不是年底把过去一年的项目列一下，然后让 manager 帮忙包装。比较有效的方式应该是很早就和 manager 对齐：
我现在离 E6 还差什么？
这个项目到底是 E5 scope 还是 E6 scope？
如果项目做好，能够形成哪些 E6 evidence？
哪些 senior engineer 或合作方最后可以帮我提供 feedback？
最好让 manager 给具体答案。比如缺的是 scope、cross-team influence、technical direction，还是 impact 不够稳定。不要只接受“继续做好现在的事情”“多增加影响力”这种比较泛的反馈。
如果 manager 自己都说不清楚这个项目做好后怎么支持 E6，那大概率这个项目本身就不够。
另外，不同 manager 帮人找 scope 和组织 promotion case 的能力差别挺大的。E5 以后不能只看老板人好不好、会不会给 autonomy，也要看他能不能直接指出你的 gap，能不能给你创造合适的机会。

• Team 里有没有 E6 scope，有时候比个人努力更重要

并不是每个组都有足够的 E6 scope。
有些组业务稳定，方向都已经被 E7/E8 定好了，下面主要是执行。即使项目很多、工作很忙，也很难做出真正属于自己的方向。
还有一种情况是组里 senior engineer 太多，比较重要的问题已经有人 owner。E5 能拿到的经常是拆好的子项目，做得再好也很难形成完整的 E6 story。
所以如果目标比较明确，就是想升 E6，需要判断目前的 team 有没有空间。可以看看过去两三年组里有没有人从 E5 升到 E6，他们当时具体做了什么。如果一个都没有，或者成功的人都是从外面带着大 scope 转进来的，就需要认真想一下原因。

• 要有一条比较完整的 story

Promo packet 不是项目数量越多越好。
做十个互不相关的项目，每个都有一点 impact，最后可能还是看不出你在 owner 什么。相对来说，一条连续的 story 更容易被理解：
先发现一个重要问题，定义方向，做出第一版结果，然后拉更多团队加入，最后把它变成长期能力。
最好别人提到某个方向时，会自然想到你，而不是只知道你参与过其中一个项目。
我现在自己也在从 ranking 类项目转到 agent harness 相关方向。一个比较明显的挑战是，日常很容易被 UI、tools、integration 这些具体工作填满。这些事情当然都要有人做，但如果长期停留在“把需求实现出来”，很难自然长成 E6 scope。
更重要的是往上一层问：这个 agent 为什么不稳定？问题是在 tool contract、evaluation、orchestration，还是产品本身没有定义清楚？哪些问题不是当前一个 feature 的问题，而是后面所有 agent 都会遇到的问题？
找到这种问题，并且真的推动几个团队一起解决，可能才是有价值的方向。

• 不要等到 PSC 才整理材料

很多事情过几个月以后，自己都记不清当时到底解决了什么问题。
比较实用的做法是平时简单记一下：

• 当时的问题和背景是什么
• 哪个关键决定是自己做的
• 推动了哪些团队或者人
• 最后有什么可以量化的结果
• 有没有合作方可以提供 feedback

尤其要保存关键 feedback。不是让同事硬夸，而是项目结束后正常问一下合作体验，以及自己在哪些地方真正帮到了对方。
最后总结一下，我目前觉得 E5 升 E6 最容易犯的错误，就是继续按照以前的方式更努力地工作。
多做几个项目、多写代码、多救几次火，可能会让自己变成非常可靠的 E5，但不一定更接近 E6。
E6 更看重的是：能不能找到值得做的问题，能不能让其他人愿意跟着这个方向投入，以及最后能不能留下一个不依赖自己每天盯着也可以继续运转的东西。

简单讲就是舔+没有底线

以我这么些年的经验，除非你做了整个org甚至整个公司都出名的东西黑都没法黑的那种，不然升职就是说你行你就行说你不行你就不行。甚至同样一个项目可以变成有的人的promo项目，有的人的PIP data point。不想帮你升职，你做再多老板都能找出gap。职场爬梯子就是个游戏，有机会就冲一下，没有就放好心态，不用到处反思是不是impact还不够大，劳心劳神

公司这么大，根本没有统一标准，况且meta promo bar的下限低到令人发指，你多问问肯定有一堆人能找到5升6的case根本达不到你这些标准

辛苦码字，求各位好心人赏米脱贫

说句扫兴或者抬杠的话：说你行你就行不行也行，说你不行你就不行行也不行。IC5开始，靠tech来promote是缘木求鱼

我们组E4->E5老板还给画饼说要direction，要自己initiate项目
之前做的项目都是cross team的
我看组里的senior都没自己起项目

H1psc写deliver了E5impact结果rating还是大锅饭，就给了H2promo的饼
吃不下吃不下，准备跑了

升不升完全看老板😃

E6 is the new E5, 升6已经逐渐从选拔优秀工程师变成安抚牛马卷王了

我来输出一点负能量。。。。。
楼主写地很用心很不错我也全部认可,但是不知道这样decent的方法现在还有多少组在honor.
看见越来越多的资质平平但是靠老板/skip包装硬拉上去的. 见过一个最离谱的case是一个org里臭名昭著的人什么也没做，硬生生靠M2把别人的项目说成是这个人e2e lead的，离大谱。。。
Meta现在频繁的reorg 和 layoff，不知道有多少组还能有稳定的report chain可以support 2-3 个half 5-6. 想想都觉得绝望

说这么多 其实现在就看上面有没有大腿

Meta感觉只要想都能升6，之前更是容易，前几年ng 5年内都是闭眼升6。。。