过去两年频繁Reorg的心塞

Facebook产品组，分享一下过去两年的Reorg
* 2019年H2 - 小型Reorg x1，本来想好的Roadmap得改
* 2020年H1 - 大型Reorg x1，整个组之前的项目整个移到别的组，Manager带着人去开新坑
* 2020年H2 - 大型Reorg x1，上次reorg做的项目再一次整个移到别的组，Manager带着人去开新坑
* 2021年H1 - 小型Reorg x3，每次都影响到组里面的一部分人/项目，人来人往，一些人连1:1都没有过就再见了，好几个项目也各种辗转

每次Reorg都需要重新build relationship，重新ramp up技术栈，没什么深耕的机会，Promotion更是一种奢望。更难受的有时花了好长时间带/mentor的engineer刷的一下就换组/跑路了，在mentorship上invest的时间也没有回报。

. From 1point 3acres bbs想听听大家的想法和data point——这样频繁的reorg是否普遍，如何minimize reorg带来的负面影响等等。

另外lz如果非常在意深耕和专注的话，我不建议产品组，产品组的特征就是快速迭代试错，一旦上级觉得这样不行，马上砍掉项目或者reorg走别的方向。
FB比其他公司厉害的一点就是它的infrastructure非常强大外加各种工具深度定制，使用非常方便。前端feature开发效率极高，我可以这么说，FB每天前端工程师的代码贡献基本上是中型公司程序员2周的量。infra不强大的公司的前端工程师会浪费非常多的时间调试API，处理多线程，各种authentication，permission和本机debug问题，而在FB前端开发人员只需要专注产品逻辑就行了，剩下的infra全部给你解决。
但是换句话说，在FB搞前端开发，很难深耕技术，因为各种可能发生的问题都给你在infra解决并封装好了，你只需要调用接口就行。

我们公司曾经和 Facebook 某 team 有过五个月的合作，结果五个月你们 reorg 了两次，负责人换了三个……

只能说贵公司太喜欢 reorg 了，别的公司没见过这么频繁的。

同产品组，reorg不多，priority每个half都在变，有时候half内都会shift。我感觉这种变化从“深耕”讲，确实不利，但是利用好仍然可以提现IC的价值，比如快速ramp up，快速在新的space里找到impact，在新的ambiguity里找到方向等等。即使一直有变化，老人如果熟悉了这些，应该还是有优势的，management也会相应器重。所以靠“深耕”升职不行，换个思路试试。

不知道在FB正不正常。确实就是很影响，也有那种不管老板怎么动自己都不动最后人走完了成了专家那种，前提是项目还在。。。也有人就喜欢ramp up学东西。。。
不喜欢就赶紧找个大环境稳定的组。

是core growth吗？

Promotion更是一种奢望

好奇这跟“多少时间必须升到XX级”矛盾吗，如果一直不promote，会被pip吗，虽然是reorg导致的会不会转嫁到员工身上

concessions 发表于 2021-7-9 18:34
好奇这跟“多少时间必须升到XX级”矛盾吗，如果一直不promote，会被pip吗，虽然是reorg导致的会不会转 ...

FB对低级程序员一直都有要求的：
3->4 24个月进redzone
4->5 33个月进redzone

5开始属于terminal level，可以混日子不用担心非升即走了

当然redzone并不100%代表pip，但是你会在performance review的时候被强制按照下一个level的标准来审核，例如你是4,33个月因为各种原因无法升职，在下一个review的时候会按照5的标准来审核你的贡献。通常来说审核是过不去的，因为5的最低要求都比4的最高要求高蛮多，尤其是direction方向。就算过去了，拿的钱也是4这个level的，非常不划算。