入职Meta6年，吐槽一段不太成功的工作经历

 

楼主入职Meta6年，一直在Product team摸爬滚打，止步于E5, 算是不太成功的经历吧 (和隔壁的3年3-6，4年3-7的经历没法比)。最近决定离职了，也过来吐槽几点我个人感受吧 （可能观点有严重的bias），看看有没有共鸣的同事。 （当然好的一面还是很多的，don’t take it wrong.）

以下感受仅限于 product team。 对infra/ranking team可能不适用。.--

吐槽：

一、作为一个social network的公司，对员工的要求也很social network。

1.1 leadership判断组里不同同事的impact大小，主要看我们发的post/notes/chats。
. 1point 3acres
- i.e.： 判断一个项目谁是主要leader/contributor，就看谁来organize的weekly meetings，谁来发的summary，谁来做的presentation。
- 这就导致了一个有趣的现象：为了抢在其他人前先发post，有人会在weekly meeting/tech design review前先准备好会有要发的post/todo items的内容，一开完会，赶紧发出来，发所有人+manager们 tag一圈。  如果组里其他同事已经发过了post，那就会把内容稍作修改，再发一次 / 或者发在其他相关的group里，再tag一次所有人。. 1point 3 acres

1.2  喊口号很重要

- 大老板在group里面发了个post，得赶紧在下面comment，表示支持.
- 时不时在group里面发post，说一说自己的findings or new ideas / initiatives, tag一圈身边的人，刷刷存在感。

1.3 代码 v.s. visibility

- 大家都知道光写代码是没法show impact的，impact的关键在于visibility，不在于你的代码的数量和质量。以至于，每写两个diff，就赶紧着酝酿一个post，或者schedule一个presentation show一下自己做的事情，以免晚些时候，被其他组员抢了credit。 （如果没做这件事的话，其他组员会把你做的事情合并到他的post/presentation里面）

1.4 People Impact / Direction.--

- Meta Perf对于Senior最重要的两个dimension： People / Direction， 很大一部分就来自于上述的一些操作。

二、一切绩效全看impact，specifically metrics。

2.1 升职快慢，几乎全看你组里的metrics

- 大家都知道，meta到这个阶段，其实能继续向上的空间已经很有限了。 10个new product initiatives，可能只有2-3个能成功move metrics的。 这就导致了运气占比很大，或者说找组的眼光吧。 有的同事进对了组，随便做做，3年3-6， 有的组的产品本来就半死不活，不管你怎么努力，也只能4年3-5.

2.2 metrics的top-down v.s. bottom-up

- 由于Meta独有的bottom-up的文化，很多非核心组（甚至一些核心组）的metrics都是bottom-up的，组里自己给自己定义metrics和goal。 这就导致了和更high level leadership想法脱节的现象： 一个组干死干活，终于move了metrics，结果D1/D2最后review的时候，说了一句“这个根本就不是我们想要的metrics”，那你就知道，你这个half最多只能MA了。 ..
- 所以说，我会更倾向于top-down的metrics，非要bottom-up的话，一定要了解清楚，至少D level 的 leadership是否完全 buy-in，因为他们有最终解释权。否则的话，是个选组的red-flag。

四、 move fast v.s. move slow

4.1 move slow： product launch move slow.

- 随着Meta越来越受外界的关注，出得事情越来越多。公司出现了需要让product team move slow的组，比如metrics/privacy/policy/integrity … 目前我看到的情况，engineer 开发两个星期，然后走 metrics/privacy/policy/integrity 各种review花上个大半年，然后如果组里还成功活下来了，没被reorg的话，才能真正launch产品。这些reviews的负责人永远不会说yes，只会说no，并且也不会告诉你解决方案，每次只能通过escalate到更high level的leadership才能解决问题。 还是解决不了？ 那就继续escalate吧，我们的产品就曾经试过escalate到VP level （ning姐里）
- 原意是为了减少Meta产品出现的问题。也确实达到了目的，但是实现方式不是通过高效及时的解决可能出现的问题，而是减少Meta launch的产品，launch的数量小了，出现的问题自然就少了，也不能说不对。
- 后来我也理解了，这些负责review的同事，他们的KPI是经手的项目不出问题，而不是成功launch多少个项目。并且每天都有很多互不相关的产品需要他们review，而他们既不了解背后的技术，也不了解这些产品，也不想承担风险。所以只能说no，也给不出解决方法，如果是我，我可能也会这么做。

4.2 move fast：对于上层的leadership来说，move的却是很fast
. 1point 3 acres
- management level move up fast：最近management hierarchy inflation的问题越来越严重，这个是众所周知的。 我刚来Facebook的时候，离小扎大概6-7层level吧。  目前已经是11个level了。一般来说，一个合理的management hierarchy，是一个N叉树的形式，至少也是一个二叉树吧。 但是现在你会发现有很多org，是一个单叉树的形式： i.e. M1 <> M2 <> D1 <> D2 , 是一个1:1:1:1 的形式。这导致的现象就是，M1/M2说的话不算数，并且信息传递有很长的delay。 一个decision，需要等很久才能被leadership approve，然后开始执行。 又或者是一个执行到一半的项目，某一天突然被D2一句话拍回来，直接砍掉。这也是导致我决定离职的直接原因之一，因为作为Senior IC的我，对项目已经几乎没有了任何掌控权了。
- reorg fast：组里项目被砍完了？leadership有新的想法？那就reorg吧…  （M2有新想法？来，我们小范围reorg一下。 D2有新想法？我们200多号人重新理一下priority。VP有新想法？ 我们1000来人重新定义下direction。）you don't have a say on this, not even your manager.  每次reorg，之前的achievement/performance打回原地，一切又得从头开始。
- 我个人的猜测导致这种情况的原因是，作为management level的人来说，其能否继续往上升，主要就看手下团队带了多少人，带了多少个manager。 如果一个产品已经没有太多的上升空间，拿不到更多的HC的时候，那就只能走单叉树或者reorg的形式让自己往上爬了。

优点：（优点不详述了，和其他大厂差不多）

一、对于new grad来说，Meta确实还是很适合新人成长的

1.1 内部各种培训很齐全，想做machine learning / mobile development / infra 等内容的培训都有，适合想各种explore不同track的朋友。 并且对于开发的各种流程和规范也定义的很清晰，对于一个Engineer来说，这种规范性是很必要的，是直接能differentiate是否在大厂就职过的一个标准。
..
1.2 升职很稳定，由于5年必须到E5的政策，基本上不用担心升不上E5. 并且最近的观察发现，只要时间年限熬得够久，7-8年熬到E6基本也不成问题。

1.3 Mentorship/Friendship: 在Meta认识到了很多志同道合的朋友，也认识到了很多对自己成长很有帮助的mentor，这一点会使我终身受益。

1.4 眼界和经历比较丰富，在Meta的这几年，见识过一夜之间因为VP的一句话，整个org的产品被砍，100多号人纷纷转组，剩下30几号人被reorg进其他org的情况，也见识过Fiji从隔壁组一线PMM一路狂飙当上Facebook三把手的情况。另外，由于Meta的产品线众多，也可以很轻易的了解到不同产品线的状态，不会被单一的产品线局限了自己的眼界。见的事情多了，少了惊讶，更多的只剩下感概了。
. 1point 3 acres
二、作为大厂，各种福利确实很不错了。

三、对女性应该也比较friendly，貌似女性在Meta management level上的比例是比其他厂要多得多的。

 

1. visibility在meta确实非常非常重要，但好的leadership应该能从这些总结/post/note/summery中去问出有价值的问题来判断每个人add的value，我也见过无数生搬乱套claim credit结果被问题问死反而适得其反的情况。相反如果思考的非常清晰即使不是项目的具体执行人领导层一般也会认可。

2. impact在meta确实非常非常重要。楼主讲的问题其实普遍存在，主要问题并不是考核问题，而是领导基层和中层对于North Star的理解不深入而造成的，过优化短期指标而忽视长期损害而造成的，选组以及选leadership真的很重要，见过太多盲目优化指标把initiative做挂的情况，领导层的vision和strategy缺一不可。

3. Empire building是meta面临的最大的问题。这个culture在短期之内很难扭转，太多的VP, D靠着这项技能升到了现在的位置，即使考评规则变化执行规则还是那批人。一叉树或者二叉树是这里面临的一个典型现象。小扎可能已经认识到这个问题，但如何调动公司大量的中高层动作起来还未可知，只能走一步看一步了。

 

感觉楼主同时提到了Fiji和Ning姐，大概率是FAM的。不太像ABP或者RL。Anyway，ABP和FAM确实卷。RL在Occlus时代很乱， 后来感觉真心是性价比之选，包括有些经常露脸的网红，真以为自己是卷出来的。。。现在不确定， 毕竟是公司重点。

就像楼下说的， meta大家听到看到的有survivor bias，首先组和组差别就特别大，看org并不准确（即便在ads，组和组差别很大）。 而且DE的百分比是差不多的并且不高，很多升上去的人也并不一定能拿到DE（人多了老板也要考虑各种因素），而且在卷组里面就更难，所以性价比很低。
 

然后升的快这事儿，除了个人实力/努力（而且努力/卷这并没有值得诟病的，付出没回报才是有毒），其实不光在Meta，其他公司也是一样的，就是很看你能分到什么活，在你的team/project中能抢到/分到什么位置。Meta也不外乎一些新兴的effort，这里说的新并不一定是新产品， 而且重点在兴，如果新产品挂了，也未必能捞到好处（这个case by case，但是in general还是得搭上上升的快车），而且也可以是一个成熟org里面新兴的方向。 再就是能报上manager的大腿， Meta的制度其实又一点像麻，manager的权利比较大， 好处是可以move fast，但是升职加薪上会很受manager影响。 尤其是后来公司大了，很多开疆拓土的事情做完了。

补充内容 (2022-10-10 11:08 +8:00):
还有人提到了ins， 感觉INS是另外一个story，因为可以做的东西比较多，对于deliver的要求in general很高（主要是产量和速度），质量和文化和FB没啥区别。而且因为本身的区别， 很容易justify重新造轮子的要求，所以很多人还是搭上了快车。 后面成熟了肯定fb该有的毒和压力都不会少。 

 

1、超级卷王：快速升职+拿超高refresher，收入可能比去🐶要高一倍都不止

2、机缘巧合在WLB超级好的组里混日子刷简历。收入还过得去性价比爆棚，遇到reorg可能就要考虑去养老厂了
. Waral dи,
3、跟着老上司抱大腿：老上司去哪我就去哪儿，干什么不重要，有人罩着最是第一位。就算偶尔出了工程质量问题，上面睁只眼闭只眼不会在psc里提起就过去了。一年转组三四次也是小case，跟着老领导走准没错

 

 我觉得bottom-up的优势是下面engineer可以牵制一部分的决策权。毕竟领导是领导，他们说reorg或者换项目下面人都得照做。但bottom-up额外有个好处就是领导可以给下面人一些发挥的自由。固然会有你提到的沟通不畅导致做了半年的metric被枪毙，但这种沟通不畅其实任何地方都可以有。Top-down情形下的问题可能是上面给你一个奇怪的metrics非常不合理，然后PM权力巨大又不管技术直接拿metrics压。

 

 
她去rl就是个错误，impact driven的老fb根本无法适应rl那种全看manager关系的环境。. From 1point 3acres bbs
rl整走了好几个老fb的vp，之前horizon走那个也是在fb很多年，一直挺好的。

 

论坛里大多都是survivorship bias，大家看到的都是那些升得快的没看到更真实的大众。我认识的买它就真是这样，大家抢着发group贴抢着回复点赞，manager也是push发post叫你分享。。。真的累。大部分组都很卷很累。大家都很忙，所以人与人之间也没有很纯真的分享和帮助，都在算着这个能不能在people impact上加点分。

 

这么看来狗家politics还算少的，至少我这里没有什么会后抢发summary，抢功这种破事。感觉还是个人scope不够大，太多overlap，人浮于事，才有抢功这一说，不然自己做自己的东西都忙不完，别人的project压根不会碰，也没时间去碰。隔行如隔山，隔project也差不多。细节都看不太懂，怎么抢啊？领导层离底层engineer比较近，我们org决策层（launch approver) 到小兵也就3-4层。也没有老板发个post就要去comment这种骚操作。平时做的new initiative也都是快launch时才组会上present一下。平时基本不会主动说。刚开始做也不知道最后怎么样，能不能launch，哪敢吹出去献丑。评级也并不是完全metric至上，还是部分承认功劳（launch, metric）和苦劳（fix bug, refactor，continuous improvement之类）的区别的。这点很重要。很多project launch的时候metric很好看, 新feature launch，0% ->80% 也就几个月的活。但是后面的improvement就难得多了，80%-90%可能要做一年，90%-95%要两年甚至更长。有些老东西，想再improve 1%都是难上加难，但是总要有人来做。

 

我就看过一个m2发了一篇“休假一周的人生感言”，说这周ta如何如何学习到了（休假一周能学习，exm？），然后ta如何如何被这一周改变了，如今回来工作如何如何比以前更好更enthusiasm了。。。仿佛这个休假改变了ta的一生。。。
底下有一堆manager和ic点赞，几十个转发，“您说的真的太好了”，“您这篇note对我帮助很大”，“这就是我们需要的，大家都看看”。。。我勒个去，也不知道是真这么觉得，还是抱大腿。。。
这就是能在meta混的平步青云的人，不到这个水平不要抱着三年升6的幻想来met

 

还有meta讲究一个一鸡多吃，你写planning doc他发post再来一个人update wp chat，人人都有业绩刷，不过这个需要同事的共识。

 

 不行，不要burn the brigde，这direction credit新人拿去没有任何用处。E3和E56需求维度是完全不一样的，新人要的是根据plan的execution credit，老人要的是direction和people，大家好好合作争取双赢

 

 hire freeze之前empire building已经快要到疯狂的程度。有些manager甚至不知道组内具体在做什么（不过好像有的最近已经let go了），更别说从各种post提取信息了。想争取好的PSC得非常主动才行，白天开会+胡言乱语，晚上写代码。