聊聊 Meta E5 升 E6，感觉最重要的不是多干活
晋升
地里匿名用户A9ORZ
这篇不算成功经验，主要是结合身边见过的 case，再加上和 manager、senior engineer 聊下来的一些理解。
Meta E5 到 E6 应该算一个挺大的坎。E4 到 E5，很多时候项目做得不错，执行比较靠谱，impact 够，基本就有机会。E5 到 E6 不是简单地把项目再做大一点，也不是多写一点代码、多接几个项目。
我现在的理解是，E5 主要是证明一件比较复杂的事情交给你，你可以自己搞定。E6 则是这个方向本来都不太清楚，你能把问题定义出来，拉上需要的人，最后真正做出结果。
这里面有几个比较现实的点。
有些项目看起来很大，做了半年，涉及很多代码，也和很多团队合作，但核心方向是 manager 或 tech lead 定的，合作团队也是别人帮忙拉的，自己主要负责执行。
这种项目会是很强的 E5 impact，但不一定能支持 E6。
反过来，有的项目代码不一定很多，但一开始没人知道应该怎么做。你把问题找出来，提出方案，说服几个团队一起投入，最后还变成其他项目可以继续用的东西，这种更像 E6。
所以不能只问“我的项目够不够大”，而是要问：
这个项目里面，哪些关键判断是我做的？
如果没有我，这个方向还会不会以同样的方式发生？
但到了 E6，这种模式可能反而会限制 scope。
因为一个人再能写，产出也是有限的。E6 需要证明自己可以让周围的人一起产生更大的结果。比如把一个模糊方向拆成几个项目，让其他 engineer 可以独立负责；或者把几个团队各做各的东西统一成一套方案。
这不代表 E6 不写代码。技术深度还是要有，只是不能把“我写了很多代码”当成最主要的 promo evidence。
参加 sync、回复 message、帮其他团队解决问题，这些都算 collaboration，但不一定算 E6 influence。
真正有用的 evidence 一般是：几个团队原来目标不一样，或者对方案有分歧，你最后让大家接受了一套共同的方向，而且真的投入资源做了。
这里最难的是你对别人没有汇报关系，不能直接要求别人配合。只能靠技术判断、数据、方案和长期建立的 trust 推动。
所以 E6 的 cross-team impact，不是“我和五个团队合作过”，而是“因为我的工作，这五个团队改变了原来的做法”。
升职不是年底把过去一年的项目列一下，然后让 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，能不能给你创造合适的机会。
有些组业务稳定，方向都已经被 E7/E8 定好了，下面主要是执行。即使项目很多、工作很忙，也很难做出真正属于自己的方向。
还有一种情况是组里 senior engineer 太多，比较重要的问题已经有人 owner。E5 能拿到的经常是拆好的子项目，做得再好也很难形成完整的 E6 story。
所以如果目标比较明确，就是想升 E6，需要判断目前的 team 有没有空间。可以看看过去两三年组里有没有人从 E5 升到 E6，他们当时具体做了什么。如果一个都没有，或者成功的人都是从外面带着大 scope 转进来的，就需要认真想一下原因。
做十个互不相关的项目，每个都有一点 impact，最后可能还是看不出你在 owner 什么。相对来说，一条连续的 story 更容易被理解：
先发现一个重要问题，定义方向，做出第一版结果，然后拉更多团队加入，最后把它变成长期能力。
最好别人提到某个方向时，会自然想到你，而不是只知道你参与过其中一个项目。
我现在自己也在从 ranking 类项目转到 agent harness 相关方向。一个比较明显的挑战是，日常很容易被 UI、tools、integration 这些具体工作填满。这些事情当然都要有人做，但如果长期停留在“把需求实现出来”，很难自然长成 E6 scope。
更重要的是往上一层问：这个 agent 为什么不稳定？问题是在 tool contract、evaluation、orchestration，还是产品本身没有定义清楚？哪些问题不是当前一个 feature 的问题，而是后面所有 agent 都会遇到的问题？
找到这种问题，并且真的推动几个团队一起解决，可能才是有价值的方向。
比较实用的做法是平时简单记一下：
最后总结一下，我目前觉得 E5 升 E6 最容易犯的错误，就是继续按照以前的方式更努力地工作。
多做几个项目、多写代码、多救几次火，可能会让自己变成非常可靠的 E5，但不一定更接近 E6。
E6 更看重的是：能不能找到值得做的问题，能不能让其他人愿意跟着这个方向投入，以及最后能不能留下一个不依赖自己每天盯着也可以继续运转的东西。
Meta E5 到 E6 应该算一个挺大的坎。E4 到 E5，很多时候项目做得不错，执行比较靠谱，impact 够，基本就有机会。E5 到 E6 不是简单地把项目再做大一点，也不是多写一点代码、多接几个项目。
我现在的理解是，E5 主要是证明一件比较复杂的事情交给你，你可以自己搞定。E6 则是这个方向本来都不太清楚，你能把问题定义出来，拉上需要的人，最后真正做出结果。
这里面有几个比较现实的点。
- 项目大不代表就是 E6 scope
有些项目看起来很大，做了半年，涉及很多代码，也和很多团队合作，但核心方向是 manager 或 tech lead 定的，合作团队也是别人帮忙拉的，自己主要负责执行。
这种项目会是很强的 E5 impact，但不一定能支持 E6。
反过来，有的项目代码不一定很多，但一开始没人知道应该怎么做。你把问题找出来，提出方案，说服几个团队一起投入，最后还变成其他项目可以继续用的东西，这种更像 E6。
所以不能只问“我的项目够不够大”，而是要问：
这个项目里面，哪些关键判断是我做的？
如果没有我，这个方向还会不会以同样的方式发生？
- E6 不能只靠自己能干
但到了 E6，这种模式可能反而会限制 scope。
因为一个人再能写，产出也是有限的。E6 需要证明自己可以让周围的人一起产生更大的结果。比如把一个模糊方向拆成几个项目，让其他 engineer 可以独立负责；或者把几个团队各做各的东西统一成一套方案。
这不代表 E6 不写代码。技术深度还是要有，只是不能把“我写了很多代码”当成最主要的 promo evidence。
- Cross-team 不是多开几个会
参加 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，有时候比个人努力更重要
有些组业务稳定，方向都已经被 E7/E8 定好了，下面主要是执行。即使项目很多、工作很忙，也很难做出真正属于自己的方向。
还有一种情况是组里 senior engineer 太多，比较重要的问题已经有人 owner。E5 能拿到的经常是拆好的子项目，做得再好也很难形成完整的 E6 story。
所以如果目标比较明确，就是想升 E6，需要判断目前的 team 有没有空间。可以看看过去两三年组里有没有人从 E5 升到 E6，他们当时具体做了什么。如果一个都没有，或者成功的人都是从外面带着大 scope 转进来的，就需要认真想一下原因。
- 要有一条比较完整的 story
做十个互不相关的项目，每个都有一点 impact，最后可能还是看不出你在 owner 什么。相对来说，一条连续的 story 更容易被理解：
先发现一个重要问题，定义方向，做出第一版结果，然后拉更多团队加入，最后把它变成长期能力。
最好别人提到某个方向时，会自然想到你，而不是只知道你参与过其中一个项目。
我现在自己也在从 ranking 类项目转到 agent harness 相关方向。一个比较明显的挑战是，日常很容易被 UI、tools、integration 这些具体工作填满。这些事情当然都要有人做，但如果长期停留在“把需求实现出来”，很难自然长成 E6 scope。
更重要的是往上一层问：这个 agent 为什么不稳定？问题是在 tool contract、evaluation、orchestration，还是产品本身没有定义清楚？哪些问题不是当前一个 feature 的问题，而是后面所有 agent 都会遇到的问题？
找到这种问题，并且真的推动几个团队一起解决，可能才是有价值的方向。
- 不要等到 PSC 才整理材料
比较实用的做法是平时简单记一下：
- 当时的问题和背景是什么
- 哪个关键决定是自己做的
- 推动了哪些团队或者人
- 最后有什么可以量化的结果
- 有没有合作方可以提供 feedback
最后总结一下，我目前觉得 E5 升 E6 最容易犯的错误，就是继续按照以前的方式更努力地工作。
多做几个项目、多写代码、多救几次火，可能会让自己变成非常可靠的 E5，但不一定更接近 E6。
E6 更看重的是：能不能找到值得做的问题，能不能让其他人愿意跟着这个方向投入，以及最后能不能留下一个不依赖自己每天盯着也可以继续运转的东西。
已获得 70 大米
+2
共72条回复
✨ 您正在体验新版论坛UI
