经济不景气当下，如何通过观察周围的蛛丝马迹判断被裁：
.--
managerial的岗位
1. 不断被要求hand off一些人事信息给同事
2. 人事会议中发言被略过或者没被邀请. Χ
3. 已知要裁员的情况下，老板没有问自己要组员的performance名单
4. 组里的工作优先级被降，突然边缘化. 1point3acres
5. 组里进来一个类似的manager，并且自己的组员被调过去. Waral dи,
6. 被要求确认提交最近的PTO的request.
IC的岗位
1. 个人的工作量被缩减或者长期不排新活
2. 被经理提过一些工作上的建议，且是一些无事实根据的建议或者吹毛求疵的建议
3. 自己的大组被一锅端的情况下，会发现manager开始更新Linkedin或者开始三天两头PTO(其实是去准备面试). 1point3acres
4. 被无故问及关于是否去旅游，是否打算搬家等近期打算的事情
5. 被无故要求knowledge transfer一些工作或者要求提交近期project的white paper.
6. 周围的senior同事都在换组或者找工作
7. 被要求确认提交最近的PTO的request
都manager多少年了，你肯定给IC写过performance report和promotion doc吧。请问你难道一次都没有被自己的上司要求在某个时间紧的deadline前上报performance report过吗？你当manager很多年，肯定是知道performance report是用来干什么的吧？不然HR和VP都是看谁的名字好听看谁名字好记来决定裁谁的吗？
我的skip在裁员前一个月就开始不准大家travel，不管多重要的理由或是会议，都不准。. Χ
.
然后开始跟我老板说某个重要的案子现在大家都不准碰，理由是他要跟cross functions厘清一些问题跟界线画分，如果我们私底下不听话，依旧尝试去get involved into the project ，就会收到咆哮信。
另外裁员前三个月，我老板叫我们做了很多次job scope的描绘，我们至少写了3-4次自己在做什么的叙述给我老板，之后我老板不知道拿着这些去给谁看了。.google и
最后我老板跟他底下整个team都被雷了，只留下两个人收尾，而选择哪两个人被留下，我相信VP level是不知道怎么选的，我的skip最清楚要选谁，被选的也是skip本来就偏爱的同事。
说裁员名单只有VP知道，我觉得只是要让VP背锅，不要让大家扩大仇恨范围。我相信很多director 甚至有办法一点的manager 早就知道名单，端看这些人跟VP的交情到什么程度。有些组可能真的全是VP决定，但有些组我怀疑VP有询问下面意见拟定名单
简单来说，公司没钱了，正在想方设法逼员工自愿resign节省severance package呢。
强制RTO、砍福利、砍津贴、缩减工作空间、增加工作强度、必须自费配备…
这些都还不够，现在就是削减饭堂，未来还有更多的操作法，看你们要如何苟得住。
ReplyDelete我肯定不知道Sa****sh的想法，甚至VP的想法都不知道。
不过我可以提供一些细节：
定名单是在VP层面，如果VP管的人太多时间太紧来不及，D2是可以帮忙提交一份名单归VP审核的。
所以任何D1或者M告诉你要怎么layoff都属于猜测，他们目前肯定不知道。.google и
哪怕是D2也要管几百号人，从里面挑几十个也是很辛苦的事情。.
通常D2的初始名单会比较简单粗暴的按照两个标准（perf，项目）划，或许还会加上别的比如level和tenior，who knows。
注意从D2和VP这个层面，是不知道具体某一个人在做哪个项目的，他们只知道这个项目有多少个人在做。因此我认为通过砍项目来凑人头，再加通过perf来定人选是比较公平，科学和快速的做法。
简单粗暴的划出来以后，其实名单就定了90%，剩下的就是微调了。
ReplyDelete比如上次裁员AI Infra的VP就走了，然后AI Infra陷入了很长一段时间的混乱状态，到现在都没有完全理清。
但是一个infra org如果砍一半的人，在我看来和全砍了没啥区别，那就属于公司要放弃这一块了。所以肯定不是DI或者AI或者PPI这种critical path上的大组。更像是比如commerce infra，HR infra（假如有的话）这种support一个business unit的infra组。
各种消息和signal已经很多了。比如RDS要砍一半以上剩下的并进Product DS，RL好几个项目要全砍，Infra和XI也是受影响比较大的org
ReplyDeleteSafe org的signal和rumors也有，比如IG ENG受影响很小，WhatsApp Business几乎不会动。另外收到GenAI reach out的应该不用太担心了. 1point 3acres
还有一个传的比较多rumor说是tenure and seniority是很重要的因素，6+受影响最小，4受影响最大之类……
这次裁员和上次不同，是按照org来，所以org高层是有完全的掌控权的。
ReplyDelete我了解到的处理方式应该是：
1 按 perf，上次MM的基本💊，如果没有这么多MM，那么就看perf history，长期处于MA的也会被带进去。据说之前连续好几个EE，但是这次因为一些不可控原因没拿到好rating的不会被影响到。总之就是以前的持续高光表现非常重要。
2 按 项目，那种自己都没办法自圆其说的项目，或者高层认为完全没用的项目会整体砍掉，人员可能会被裁大半。这种在蓝色app production组尤其多，很多项目都是自己想自己编的。
Blind上troll太多了，有人说这有人说那的，都不太可信。
ReplyDelete说到底，Infra很重要所以必须保留，不至于团灭，但是到底是不是需要这么多人来做这个事情，不好说。. From 1point 3acres bbs
Production则是相反，当红炸子鸡项目肯定0 impact，但是过气没人用的项目多半要被团灭。
ReplyDelete正经写code的只有两万多，19000多SDE，2000多Research Scientist，2000不到的machine learning eng。
你不能把DE也算进去，就算算进去，DE也就2000人。
XFN的那帮人疫情期扩招的比SWE还疯狂，不然小扎怎么会说 这次的目的之一是return to a rational IC/XFN rate?
PM, TPM, DS, DE, URX, Designer, privacy XFN(PXFN)...etc 这些都算XFN
ReplyDeleteXFN = cross(X) FunctioN
基本特点就是归属于XFN TEAM而并非Business Unit Team。
日常工作属于多线操作，并不归某一个team管辖，以DE为例：
本月Ads某个team的人需要一些数据，就跑去Ads Team写些pipeline做一些数据分析
下一个月infra某个team的人需要一些数据，就跑去Infra Team写些pipeline做一些数据分析
等等
目前在Meta， Engineer和XFN的比例基本上是1:1.8， 疫情前好像是1:1都不到。
ReplyDelete是这个道理，本来一年PSC，你至少可以计划一个9个月的比较大的项目，还有点buffer。现在半年一次，也就是个3个月风险很小的项目了。
在meta的评估体系中
1. 项目/feature上线是关键因子。哪怕你累死累活大半年，解决了数不清的技术难点，但最后种种原因（肯定不是你的）没有上线，或者延后了，那你最多就是MA
2. 项目越大，固有风险越大，中间的变数也多，成功的几率指数下降
3. 以H1为例，planning最快也是从1月中开始的，而且项目肯定涉及多个组吧，你如果是upstream的还好说，你要是在中游下游的workstream，你就是再committed，说了也不算，看前面的老大能不能按时交差。有的组3月还在讨论H1项目呢，你说能做出什么来？
4. 之前reorg的影响到现在还没有完全消除，各个team都有大量人员移动，一些模块也没人知道内情了。新接手的都非常头痛。现在再来一波，情况更会恶化。
block by xfn是很明显的问题了。. Waral dи,
ReplyDelete我只说我合作过的一部分XFN，在PSC driven的驱动下干了不少恶心事。
假如你是一个XFN，手上同时有3个组的项目ABC需要帮忙
最开始你的精力可能基本均分。.1point3acres
但是过了3月，事情开始有了变化
A项目一切顺利，看起来有提前release的可能
B项目有一些小risk，看起来可能需要加加班，正常release希望也有
C项目出现了alignment的大问题，需要很多功夫才能back to track，甚至努力了也可能fail. 1point3acres
从公司角度自然希望你多帮助C，正常帮助B 少帮助A让他们全部release
但是XFN的角度看可不是这样：. .и
A马上成功了，我得想办法拖慢A的进度，再它上线之前多加一些自己的贡献 -- 我拼命在会议上raise concern，说明如果不暂时先pause release，让我的跟着贡献进入release，项目会存在这个那个风险。
B我就正常跟进，甚至因为A那边和release组撕逼扯皮，我的精力跟不上B了，会导致B从可能fail变成大概率fail，到时候我站出来说这个项目需要descope就行了
C去死吧，谁管它啊...fail了反正大锅不归我背归engineer背， 有A，B的贡献我足够Meet甚至Exceed了，平时看会做做样子把，爱去不去。
结果就是C一定fail， B大概率fail，A也无法提前release。
ReplyDelete一个PXFN Review涉及10+人，还有些人在英国。交流基本上需要等半天。. Χ
更搞笑的是一个大姐结婚去了，工作也没交接给别人，只好等2个星期。幸亏她不是度蜜月一个月。
更恶心的是Permission管理，我们组自己创建的数据表，我访问还需要request permission。request被发到一个莫名奇妙的contigent worker，他唯一的作用就是让你把business case写好，他对于业务和数据都是0理解，然后还可能把这个request发回到我们的oncall或者em看。这样折腾需要1天。WTF。这个权限可能14天就过期了，你下次访问还得再走一遍。
这都是为了合规发明出来的东西。
我原来一直不明白为什么一直说meta的PSC有毒，直到身在其中才明白。所有人做事都是PSC驱动，有impact，容易发post的就做，那些吃力不讨好，做出来没法showoff的就放一边，系统performance的root cause根本没人关心，改改参数看的过去完事。现在改回一年两次，加上天天悬在脑袋上的裁员压力，更加没人好好干活，全tm跟着leadership做fake work
ReplyDelete四月这批包括所有的对项目有直接贡献的人。-baidu 1point3acres
ReplyDeleteEngineer, Tech Manager, TPM, PM, DS, DE, URX, UI Designer...etc
. From 1point 3acres bbs
五月是To B的那批人，都是只谈contract不写代码不参与deliver项目的。
.--
另外小扎说过了五月那批才是main impact，结合已有数据（一共layoff 一万人左右，3月layoff了1400）可以推断出四月的这批裁员人数大约是3500-4000，其中Engineer目前大约是23000-25000人，我猜可能会被影响10%。剩下的从XFN和Manager里面出。
据说小扎原本想回到2017年两万多人的时候，后来被多方打听劝阻，估计回到covid之前，五万人左右。这一轮砍完还剩六万多，还得再砍一万来人
ReplyDelete
ReplyDelete佛系了，meta根本就不至于非要再裁10k的地步，结果这还不算完，PSC又改半年，明摆着H2还要再来一轮，leadership已经完全不管下边人死活，只要股票好看就行，爱tm尼玛谁谁