核心组竞争压力大,抗公司的top line metrics,非常重要,但是非常难drive动,没有low handing fruit。整体上非常忙,生存难。
边缘组竞争压力小,搞自己的metrics,容易drive动,但是上面可能认为对FB不重要,如果你不能半年一年把用户搞到1千万或者1亿,整个组随时被关掉。
成熟组人员臃肿,好坑甚至一般坑早被占了,招你去就是做烂坑,说不定因为烂,上一个人刚走,才招新人来填。选组的时候要根据自身情况来选。
大部分人肯定喜欢选自己喜欢做的事情的组。这个不用说。不过你最喜欢的事情的组不一定是最好的选择。
除此之外,你必须考虑的是自己是不是能快速ramp up, psc能不能survive,未来是不是能有发展,比如升级
选组当然和你的级别(还有能力)有关系。
能力很强,有信心竞争过那些核心组里呆了好几年的人,可以考虑去核心组。否则你要考虑的是如何和队友竞争。
多数org/team都有10%的不能meet的名额,虽然不是硬性规定,但如果明显少于这个数,manager都得有充分的理由说明为什么。
级别越高,就要take更大的risk,因为well established的组很难有现成的大坑给你。级别低的可以考虑稳定一点的组。如果你要考虑升级,你必须按高一个级别找组。
要快速ramp up,你要找的是现成的projects和scope。还要评估你是不是能做,能不能drive你们组的metrics(还要看team goal是不是过于aggressive)。否则你光了解现状,提出projects就可能要花几个月。fb的code问题很多,所以很多时候你是想象不到会有什么烂坑和好机会的
ramp up根据级别,时间不同。e6一般9个月,e5一般6个月,e4 e3三个月最多。ramp up期间,你主要focus on delivery and impact,其他directions 和people可以慢一点(因为需要时间ramp up,不过越快越好)。
如果你找不到一个组能满足你所有的条件,我的建议是先把short term的事情照顾到, 比如ramp up,比如第一年survive,然后e3 e4的第一次升级。
几大 org里,fb app org 很大,总体比较忙,但核心组很忙,边缘组好不少。ig涨的比较快,但也很忙。msger相对边缘,不算太忙,也不算很核心。whatsapp的用户涨的快,但是因为不赚钱,team growth不快,以前比较轻松,现在没那么轻松了,不过也还行。arvr是公司长远投资,用户非常少,也就oculus还行,别的smart 硬件都用户很少,而且竞争对手很强。core ads不用说了,很核心很忙。integerity也非常忙,去年选举年非常重要非常忙,现在估计没那么重要没那么忙了。infra相对成熟稳定一点,不过机会一般也少一点,升级机会还是有,因为有技术深度,但是带人的机会不多了。
选组可以按这个顺序去了解:注意:很多fb manager喜欢说大话说好听的话,说他们多重要,growth多快. 不要轻易相信那些光说大话的em,要去了解实际情况。反倒是那些愿意说出自己组的缺点和实际情况的em,说的反而更可信。
这个组的历史?何时成立?做目前的东西多久了?是不是换过scope? 是不是reorg过?reorg频繁吗?
这个组的mission和vision是什么?这是一个business问题。这个mission/business在fb里有多重要?有没有竞争对手和合作伙伴?做成的可能性多大?
这个组的scope (具体的产品,system,还是就是metrics,等等)是什么?一个产品?多个产品?哪些是产品是这个组own的,哪些产品是别的组own? launch会不会被对方block? fb理论上没有明确的ownership,但人家已经做了的,就变成默认的owner。fb各个组overlap比较厉害。你得了解这个组的地位和竞争关系。谁和你是合作关系?如何分credit? 谁和你是竞争关系?如何竞争?谁优势大?如何分boundary
这个组如何measure success? team metrics, 和metric goal(过去一两个half和下一个half)是什么? 过去一年team metrics改过没有?每个half是不是meet team goal? 通常越 topline 的metrics越难drive,也没啥low hanging fruit了。
具体的roadmap啥样?都有啥projects? 每个人做啥projects?
会让你做啥projects? 难不难做?你能不能做?能不能drive team metrics? 第一个half 以及一两年内manager对你的expectation 是啥(psc的4个dimensions)?drive多少metrics? 做完多少projects? launch哪些东西?如果打算做最后的决定了,最好有个书面的expectation doc
team structure是啥样?几个pillar,每个pillar都有几个人,都是啥级别,tl是谁?overall tl是谁?你要跟谁做项目,或者带谁做项目?谁和你是合作关系?如何分credit? 谁和你是竞争关系?
最近离开组的人多吗?都去哪里了?
组的pulse score如何?三个dimensions,还有其中的intent to stay和wlb如何?pulse score 太低(50以下)或者太高(90分以上)都要小心了。pulse score影响因素很多。一般组里老人转走了新人多,就会分高,但不代表这个组就是好组。核心还是看组员是不是稳定,基本没人走,现在人的intent to stay也比较高。wlb/pulse score太好,也要小心,说不定这个组太轻松,很快会被上面干掉。
新的组似乎有坑,但是如果太新,还没证明整个组存在的价值,说不定很快就整组没了。
所以最好选中等重要,中等成熟度的组。第一保证组已经证明过价值,不会很快没有了,总体比较稳定,不是大量的人离组;第二这个组的team metrics容易drive动,;第三这个组的scope还有一些low hanging fruit和一些big bets可以再做几年;第四具体你可以做哪一块,是不是符合你的level和你升级的要求。
所以聊组的时候,一定要了解组的历史和情况,看看是不是满足以上几个条件。
看看过去几个half他们的team goal是什么,是不是都
beat了,再看看他们的road map,是不是有很多promising的确idea可以做。当然这些idea是不是promising,有经验才能判断。不过起码road map上东西还很多,而且你觉得里边很多东西你可以做,common sense也算靠谱
看多少组用你的的infra,还要看是不是有竞争对手组。谁更强
infra组你要问hm,他们组team mission和vision是啥,scope是啥,和客户是谁,有多少,如何measure success,现状如何,未来一年打算到啥样,主要的blocker是啥
新组有时候可以,如果做的产品和项目不是新的。或者产品不是新的,项目是新的,low risk的。
你如果是想升6,甚至7,是可以赌大的。
当然,核心问题是fb已经过了高速增长期。现在的新产品新组大概率会fail。新项目大概率会被已有的组抢掉。这和几年前不一样。
如果项目足够复杂,scope够完整,可以。leadership第一个不会要求那么多。第一个half主要是deliver impact,所以有现成的项目最好。
但要想升e6,要求比较高,要挖新的大坑大方向,带领全组。e5只需要在已有的坑里做深做细,搞小方向,带人。e4是独立完成中小project,但要想升级就得做e5 projects。e3就是分配啥小task,能按时做完就可以。
同E5刚rampup完,rating EE, my 2c:
- 第一个half最重要的就是你的deliverable。这个时候肯定你是和别人合作的,管理好和你合作人的预期,然后超出这个预期。
- 尽量提前高质量deliver手上的东西
- 参与到roadmap,design的讨论中去,主动管理项目,让和你合作的人基本不需要带你
- 自己找机会看看能不能提出新想法的东西然后claim在你主要deliverable之外的impact(可以让你从MA到EE);如果同一个half能把这个新的东西做完你就是SEE
如同上面所说第一个half就是看你deliver了什么,leadership之类的其它axis在自己项目内有体现就行了。处理好和你合作人的预期和关系非常重要,ta的反馈基本决定了你的rating。找到新机会(最好是复用你刚学到的经验的)可以提升你的rating。
第一个half还是很好的和所有人建立联系的时间,照着boz的onboarding plan和每个人约一遍1on1,下个half好带项目拉人
选组的时候不要选巨大在组,15个人以上的。那都是老组,坑不多。另外这么大的组,至少抓一个mm。新来的最容易被抓。
要去小一点的组,不到十个人那种。这种组一是坑可能多一点,而是有可能能全部ma+。因为对小的组抓一个mm的要求不高
首先,对于在选组、或者考虑换组的,请避开以下几个(大大小小的)组:
Marketplace(大家都说是个shit show;各种reorg,据说被MSFT/AMZ来的人搞得乌烟瘴气)
Search(同Marketplace)
Instagram某些产品组
(印度人多的) Computer Vision(排挤国人,开会都不带你的那种)
**做Fairness/Responsible AI的组
另外,谈到Integrity组,公司2017-2018年重点曾经在这,后来遇到数据泄密丑闻,重点转到Privacy。
Community Integrity还挺不错(WLB, 工作幸福程度、老板等等,解决的问题和scope明确),Site Integrity也还可以(没有听说很负面的新闻,解决的问题和scope明确),Business Integrity原来还不错后来进来一批奇奇怪怪的印度人,现在也是江河日下,不否认还有好组(比如BI Core ML)但赌不起,Connection Integrity (aka Feed Integrity) drama不少、没有明确scope、manager们评价很差(2018年夏天组里印度人歧视中国女实习生的案例就发生在这里,不了了之)。
工作体验:
work-life balance这种东西真的因组而异:有的产品组非常累而且做的是日复一日PHP工作,对个人能力没啥提升;有的产品组做ML则非常轻松,可能一天工作4-5个小时即可deliver expected impact,但是大部分产品组的ML真的只是洗洗数据、用内部傻瓜式ML组件拼凑一个GBDT然后上线,学习曲线非常非常平,而推动这个产品前进的却往往并不是Model,在选组的时候千万不要被manager给忽悠了;一些核心Infra组、Ads组也非常累,工作日10+小时是有的,周日下午很多同事也开始在线写文档、发帖子了
Ads Infra的确好一些,不要太担心,有的组甚至好评度95%
Instagram Feed or Ads ML组还不错的
我很看好AI infra和DAI 请大胆选择这种组然后去尝试新的scope
ads delivery之外其他组不懂了 感觉不够核心 但压力不会太大
Pulse Manager Dimension score
Pulse(员工半年度调查)是FB用来评价一个组的氛围的重要指标。它有客观和可比较的优点,对manager PSC都有直接影响,所以Pulse一个非常好的选组出发点。
Pulse分成三个维度:company,personal experience和manager。
- Company:对我们影响很小,基本可以忽略
- personal experience:可以参考,但是不同组的员工职业发展阶段不同,需求不同,所以得出来的结果偏差比较大。如果没有时间去详细的调查,这个data会有misleading。譬如,如果一个组在某个half,10个人,8个shoot for promotion,那么WLB就肯定不会好看,却可能是个好组。
- manager得分高,意味着员工对于这个manager很满意,认为自己抱到了好大腿。如果老员工都这么觉得,作为新人,是不是应该也去抱一下?要强调下,这个老员工“满意”和你找老员工了解组里的情况,他们告诉你“他们很满意”是不一样的。因为老员工们需要帮助招聘,很难把话说的很直接。Pulse survey就没有这个问题了。不满意,就直接打低分,反正是匿名的。
manger dimension还可以再分成三个维度:People,Collaboration,Team Impact
- People包括:manager是否关心员工的职业发展?是否给员工分配他喜欢并且擅长的工作?是否公平的recognize每个员工的贡献?得分高意味着,manager愿意花时间为员工着想。
- Collaboration:team和XFN的合作怎么样?得分高意味着,有好manager罩着,你和其他人合作的时候能够左右逢源。
- Team Impact:team的方向靠不靠谱?有没有impact?得分高意味着,team有重要的project。如果真的reorg,你的team也会相对稳定,而且有可能是从reorg中拿到更多的headcount,成为受益的一方。你积累的context和relationship,也就可以在更长的时间段发挥作用,有更好的发展机会。
怎么做?
收到reachout,要求manager把他们的pulse result share给你。manager dimension 90分以上的优先考虑。如果是新manager,没有pulse result,那就参考skip manager的manager dimensionattrition rate
真正的决定性factor是一个组最近一两年的attrition rate,越低越好。只不过一般人拿不到这个指标
engineer不走,尤其是呆满一年也没走,就是好现象。这个才是最好的single metric。平均数可能在10%-20%。高于20%就不好,低于10%就好。最好看最近一年到两年。当然, manager不会直接告诉你这个metric,你也不用问。有个内部tool可以看到历史,可以推断出attritions。自己看就好了。一个组几分钟的事情。
pulse score也要看,但我建议砍掉manager dimension 70%分以下的。因为实战中我发现机会不错的组很多在80%分上下。90%分上下的组并不比80%分上下的明显好好组/好项目的表现
这一部分无论大公司和小公司都会适用。里面可以说的东西太多了。如下排名不分先后,如果大家有什么想法的话欢迎补充。
3.1 团队操作流程和文档 (Team Process)
每个组都或多或少有non coding或者ops的工作。launch ticket(或者post),代码有什么merge的规范,monitoring或者oncall,release和rollback,做experiment,基本不需要多少coding,但是有具体的操作流程。一个好的组会把这些流程详细记录下来,做成一个正式的team page,实时更新。新人来了之后只需要照着doc就可以学会大部分流程。而一个不好的组,通常没有任何doc,哪怕有也都是过期了很久没更新过,这些流程基本都是需要老人来带,没老人手把手交个机会都不敢自己上手。
另外,文档是一个对于team velocity来说非常重要的东西。文档的作用在于把知识留到团队而不是团队中的某一个人身上。平时可能大家都不觉得有什么好写的,但是一旦有一个呆了几年的人想跑路,没有充足文档的情况下,老板最头疼的往往就是knowledge transfer有没有做到位,尤其是那些只有老人懂的legacy system。根据我的经验,很多项目走人之后一点点垮掉,就是因为有能力带这个项目的人,或者项目的owner跑路了,东西没人有能力维护,更没有人知道之后这个项目该怎么做。没了相关的知识背景,自然这个project就没人能做下去。虽然说所有软件系统最终都会慢慢腐蚀掉慢慢成为tech debt,但是没有好文档,知识全靠口口相传的话,这种项目垮的会更快,组里的tech debt也更多。
3.2 团队技术水平 (Team Professionalism)
如果想多学东西的话,团队技术水平很重要。如果一个组里有一个能打的大佬,学东西最快最好的方法就是抱紧这个大佬的大腿。一般一个组至少要有一个这样的TL,这个人要了解系统的每一方面,甚至需要了解的非常细致。对于组内的design review,TL可以提出很多建议,并且要至少把握住团队技术走向。TL不一定写多少代码,但是很多proof of concept,很多搭架子的东西都是这个人做的。有TL在,组里的product quality才有保证,大家做出的东西能对组对于org 的goal带来长期的好处,而不至于为了一个goal,做一个project, 不久就deprecate再换下一个。大公司内一个成员的主要工作还是拧螺丝钉,这样的TL可以保证大家拧的最有效率质量最高。
当然团队成员的平均技术水平也很重要,这个就不是很好评价了。不过可以通过大家交的代码,写的doc来略知一二。
3.3 团队满意度 (Team Satisfaction)
团队满意度有一个直观简单的标准,就是这个组的人员流动率。走的人多了自然肯定跟组里风气差,或者org搞事情有关系,但是如果大家promo都快,wlb不至于太差,并且老板对于组员很好的话,大部分人是不会换组跑路的。. check 1point3acres for more.
3.4 个人成长空间(Growth)
这个很大程度取决于个人需求。如果追求升职的话,L4进了一个全是L4L5L6的组自然是很吃亏,好的活论不上,想要论上也得等ramp up完或者做出点什么取得manager的信任,这时间大概率不会很短;但是如果主要想学东西的话,这种组反而很适合,L5 L6的人本身往往就很有经验,跟他们学东西会比自己摸索快得多得多,而且减少了很多试错的时间,往往他们解释问题的时候会解释为什么会产生这个问题,扯到一个项目的发展历史,去除糟粕留下精华的过程,这对技术水平的提升帮助是非常大的。
或者比方说想要自己出去做product,在公司内找一个product组,组里工作跟PM交流紧密,同时有完整的实验流程,对于feature该不该做,做出来效果好不好有详细的数据分析,launch之后也能给eng分一块蛋糕;想出去创业,就去一个新组,impact大的同时,还能了解一个新产品是怎么一步一步走起来,项目初期要怎么做需求分析,怎么和PM沟通,都需要哪些人参与什么项目,如何争取资源或者跟新转来的同时合作。
3.5 老板管理水平(Manager Management Skill)
对于刚进组的L3 L4,最重要的因素之一就是老板好不好。如果老板懂得如何管理组员,如何抢到好scope好project,如何让组员满意的话,对组员的帮助会非常大。我比较喜欢的老板能做到这些:
- 一般management style都偏向以组员为本,比如1:1的时候主要关心组员的心情而非着重于工作内容,因为工作内容在scrum meeting上面都能涵盖到。之前聊过一个老板的观念我很认同:他和组员1:1首先关心的是员工目前开心不开心(5分制),如果不是很开心的话,会具体问原因。我个人觉得对于老板来说,在公司最大的财富就是手下的组员。如果能调动组员的积极性的话,维持组员的好心情,对于一个组的效率提升有很大帮助。
- 如果组员遇到blocker,老板能够调动手边的资源,或者跨组和对面的老板协商把事情搞定;
- 能吵架,开会的时候有能力把好的scope都尽量抢过来分给组员;平时大家任务很多,老板心里面有一个非常清楚的优先级标准,并能组织大家把注意力集中到high priority的项目,对于优先级低的可以踢出去;
- Perf(PSC)上可以帮助你review你的package,并且以perf committee member的角度提出意见。我之前的老板看我的perf package就是good good good了事,现在的新老板我跟他1:1看perf讨论了一个多小时,他从他自己的角度对我每一句话每一点都讨论过一遍,并且能帮我把我的package和ladder requirement对上号,并且提出了不少我没想到的问题(尤其是中国人不擅长的书面表达,有些句子别人的理解跟我们的理解是不太一样的)。
- 了解每个组员的优点缺点,和大家的发展规划,并对每个人的规划都能有所帮助而非仅仅“知道”
- 对于组里有一个很清晰的核心价值和愿景。这两个东西概念很虚,但是用处很大。很多老板很多组往往是来一个项目做一个项目,在实现上也非常短视,能解决问题就行,能hack就hack,实在不行过一阵deprecate。个人觉得产品组可能会赶deadline,但是没有一个长远的发展目标和价值的话,所做的一切都在追求“局部最优”而非“全局最优”。不重视quality,不管eng累不累,东一耙西一耙大力出奇迹的管理方法迟早会让组里乱套。一个组应该追求的是,寻找组里在外部环境org的goal如何变动都能位处不变的东西(比如产品组的customer empathy,狗家一贯注重的quality,和提高组员生产力的collaboration和build trust),要这样才能让team相对良好地发展。
3.6 老板技术水平(Manager Technical Skill)
很多组里并没有专门的TL,往往老板就充当了TL的角色。这种情况下,老板的技术水平就很重要了。比如做product的组,经常拿到的项目都带有hard deadline,要在什么会上present,答应了customer什么时候ship,时间紧急的情况下,技术水平到位的老板能平衡项目的质量和速度。另外对于team growth,好老板往往对team有全面(不一定细致)的了解,知道项目以后可以怎么走,有什么样的发展点可以用上,更好的老板会对组里的目标有长远的(1-3年)规划,即使项目或者需求有变更,也能做到大方向不改变,不浪费eng hours。其他的跟一个好TL的评判标准相似,这里就不多说了。
- 制作打分表
每个人对于上述表现的评判标准都不一样。因为考虑的因素太多,为了避免比较过程过于主观,下面提供了一个量化的打分表模板 (还是上篇的那个表格,暂且不放出来,看看上篇是不是因为放了这个链接被审核了)
首先在这个Google Sheet的Scoring Template里面修改Weight一列。这里现在放的是我自己对于每一项的权重,对于好老板,好项目和有前景能学到东西的组我的权重都差不多,如果有额外看中的点(比如说做machine learning,是在某个你喜欢的org有你认识的人之类的),也可以单独加一条上去,别忘了改总分公式(Total一行)。每一项加权得分这里用原始得分(我一般会用10分制)乘以该项权重再除以总权重来算。
打分表模板做好了之后,对于每一个组都建议单独添加一个sheet,然后把打分表的模板复制过去。等背景调查和1:1做完之后,只需要填写Raw Score就能自动算出来这个组的加权得分。
- 项目背景调查
在1:1 和聊组员之前,有很多背景调查可以自行完成,通过背景调查就能把组里的事情大致了解的七七八八,还能交叉检验老板口中套到的信息。一般大公司内部公开的资料非常非常多,比如狗家的code review系统(和clstats),很多现成的query scripts,还有team公开的邮件列表,ticket system,g3doc文档网站,里面有太多东西可以自己挖了。在背景调查完成之后,可以结合自己的需求,给选组清单(见上篇)中每一个组打个分,排序后选得分最高的几个来跟老板安排1:1
5.1 团队工作压力
如果一个组有超过2个人是工作狂的话,对我来说是半个减分项。一般就看看大家交代码的频率和时间,如果有那种晚上6-12点还交一大堆代码,甚至交代码统计从早晨9点到晚上10点几乎平齐的这种人,一个两个无所谓,但是如果超过2个那这个组的工作压力可能就过大了。要么是事情太多,事情太多的根本原因是这个组planning做不好,揽来的活超过了eng capacity。一些eng主动加班是ok的,但是如果影响了整个组的风气,我个人不太喜欢。我自己有选择加班与否的权利,如果不加班我完全可以看看doc,做做别的系统的codelab,或者自己看看视频是什么的,如果因为peer pressure被迫加班,首先效率无法保证,健康肯定也有影响,同时完全失去了自我提高的机会(我认为习惯性加班对长期自我提高没有任何帮助,并且危害不小),这样的组我会给一个比较低的分。
5.2 团队成员技术水平
至于组员平均技术水平不是很容易看出来,并且每个公司怎么看出入也挺大的。狗家的我主要就综合看每个成员的level (FB看不到这个),交代码的comment数量(一般应该没多少,但是如果是TL review的话comment有可能不少。不知道除了狗家其他公司code review做的怎么样),各种doc的数量和质量(狗家非常重视doc,虽然给人看的doc往往写的烂的一笔,但内部很多不错的design doc,并且好的design doc和一般的design doc还是挺容易看出来的。外部doc烂主要是因为technical writer太少了),在组内的tenure,综合这些因素评判每一个人的技术水平。
5.3 团队满意度
狗家有一个内部公开的数据库可以查一个人谷歌内部所有的management chain历史,也可以查一个manager所有手下带过的人什么时候来,什么时候走的。这是了解一个组组员满意度最重要最直接的标准。好像FB也有这么一个地方查老板手下带过的人,知情的同学可以分享一下。另外,如果走掉的组员还在公司的话,可以ping一下组员了解一下为什么要走。看组员满意度看优点用处不大,但是了解缺点很重要。跟manager 1:1的时候,几乎没什么manager会提到组里有什么缺点,但是走掉的组员心里是最清楚的。可以ping一下他们,发个邮件,他们往往都会告诉你。有些人是因为家庭原因或者其他个人原因,但也有不少人是因为组里实在太差了。如果有两个以上的人对组里不满意,这个组的人员流动率也不会低。
另一个重要信息来源就是公司每年的survey。Google的Googlegiest,FB的Pulse,一般每个公司都会有这么个东西来让高层了解公司内部对于公司发展的满意度,并且根据结果来调整公司的管理策略。在谷歌,这个结果并非默认公开给所有人,但是换组的时候是允许向新的manager要这个survey结果的。好的manager会很爽快地掏出来,他们可能不知道怎么share,但是肯定会通过各种方式share(如果结果好看没道理不share)。如果跟manager聊下来感觉不错,但manager用各种理由推脱不交的话,就得小心了,好好的。在survey里只需要具体关注个team和technical相关问题的结果就行了。
- 和老板和组员1:1
. check 1point3acres for more. - 1 让老板了解你. 1point3acres
很简单,丰富自己的简历,如果是换组的话,着重突出在公司内部的贡献而非来公司之前的贡献,同时一定要假设读我们简历的人对我们简历上的项目了解为0 (有些人在简历上写了很多缩写写了很多和组内项目相关的代名词,别人大概率看不懂)。跟老板发邮件聊天的时候,也可以把简历内容稍微带一点点。
6.2 该问老板什么问题
这一步主要为了获取公开资料里没有的一部分,或者交叉验证一下之前背景调查获取的信息。比如组里如果很多人加班,但是老板说组里WLB很不错的话,那要么是老板根本不了解组里,要么就是老板故意隐瞒问题。不过我不建议在1:1时做太多的交叉验证,因为本来1:1就只有半个小时,大部分时间应该花到了解组内成员和工作范围上面。
一般除了和老板1:1,我也会至少选择1-2个组员聊,其中一个是组里相对元老的或者比较偏TL的成员,另一个会是跟我等级差不多的组员。和TL聊天主要聊一聊组里技术的发展方向,之后有没有什么重点要做的东西,同时也问一问组里tech debt之类的问题。跟等级差不多的组员主要聊他们现在在做什么,对组里的满意度,老板怎么帮助组员成长之类的问题。如果条件允许,我还会找一个之前从这个组换走的人发个邮件,大致问一下从组里离开的原因。
和老板1:1之前,我给每个老板都准备了一个问题清单,让老板大致准备一下我想要了解的东西。有些比较好的老板甚至会在开会之前就把他们的对问题的看法提前写到我的清单里。
Team
- [Team Scope] What is the scope of your team, (or how do you divide your scope into)
- [Team Goal] What are the goals for this year? How do you prioritize them?
- [Team Goal] What is the vision (near future / 1 yr / 3 yr ?):
- [Team Process] What are the current tech debts, how do we mitigate them?
- [Team Process] Do you have oncall / onduty?
- [Team Process] Link to your Team page?
- [Team Satisfaction] What is the team member rotation rate?
- [Team Process] In case people leave, how do you keep his knowledge and ramp up a new team?
Project - [Project Description] What will I be doing in the first half year
- [Project Description] What will I possibly work on in two years
Growning - [Member Growth] Growth plan for Ln to Ln+1
- [Personal Growth] What can I learn from team members
- [Member Growth] Your own growth plan (career plan)?
Management - [Management style] What is your management style?
- [Management style] What topics do you talk with team members in 1:1
- [Management style] How do you see the balance between shipping fast and shipping w/ high quality?
- [Management style] Your Googlegiest/Pulse/Survey result?
Others - Any questions you recommend adding onto this list?
很多问题如果在team doc或者某些slides里面已经能找到答案的花我就不会问了。每一个问题我考察的点在于:
Team Scope + Goal:
老板对于一个组当下状况和日后的大方向是否有把握。大部分组都会遇到需求频繁变更,无法把握大方向的问题。我认为,好的老板能至少了解整个org的大方向,甚至能有一个以文档形式存在,和组里senior,TL,大组manager或者director讨论过的大方向。有时有deadline赶deadline没什么问题,但如果一直在赶ddl,那就有问题了。或者如果有些老板没有这样一个文档,但是对之前org的发展历史了解的很清楚,知道之后org的大方向的话也可以。除了定大方向之外,定goal,调整优先级也是个很重要的项目。可以问一下老板最近有没有什么项目是优先级很重要,为什么有这么高的优先级之类的。
Team process:
一般这个内部搜索都能找到,比如文档啊,oncall的频率,oncall ticket多不多,不知道的话问一嘴也没什么大问题。另外tech debt每个组都有,但是好的组里面,老板会想让组里会尽量减少tech debt,并且有计划地处理先前的tech debt。
Team Satisfaction:
我一般都会先查好这个组的人员流动情况,然后1:1也会同时问问老板之前组员离职率做交叉检验。有些离职率高的组,一整组的人两年内都跑光了(就是我们组之前的状况。。。)。另外也看到过有些组,3年内几乎一个人都没走过,并且来了好几个人也都没走,这种就比较好了。另外这里一定要要公司调查的结果,就是类似于Pulse,Googlegiest这些能详细反映组员对组里满意度的资料,我认为这个survey的结果和内部查到的组员流动情况是对这个组组员满意度最好的资料。
Project description:
基本就是检查一下老板对项目的描述和内部posting上面的描述是否一致了。有些posting其实写的非常不清楚,也没怎么说进组之后会做什么,用什么样的技术,多大的项目什么时候要做完之类的。往往可以用1:1跟老板要一下项目的详细介绍。
Growth:
一对我来说老板的个人水平非常非常重要,所以这是我用来考察老板个人水平的一个很重要的问题。一个好的工程师要对自己的职业发展有个清晰的规划,那一个好老板肯定也要有对自己的职业规划。有些老板可能会把这个问题误解为对组员对这个组有没有什么发展计划,这时候要提醒老板,我们问的是老板对自身的职业规划。
Management:
老板的管理水平几乎就决定了这个组是否有前途,同时对组内技术栈的了解程度也为扩大自己组能拿到的项目,和在定goal会议上吵架有不小的帮助。老板和组员接触最多的时间就是每一周或者两周的1:1,对于组员来说这是跟老板交流的最好时机。我会大致了解一下老板在1:1的侧重内容。我不太喜欢在1:1纯聊工作的老板,首先我自己对我自己项目的时间和进度规划肯定有充分的把握,而且一般老板也不可能了解组里面每个人每个项目的进展,很少能有老板对组里每个人都了解的很细。我比较喜欢相对更关心组员的老板。扯扯生活上的鸡毛蒜皮可以让老板了解你的心理状况,同时如果有blocker我认为也没必要只在1:1提(除了是1:1上面突然想到的)。现在这个老板对于1:1的态度是,先让我把我想说的想问的都说完,等充分解决了我的问题之后再聊他想知道的问题,这我觉得挺不错的。另外一个老板的技术水平其实和他在组里的工作年限关系不小。工作的久了,积累的不仅是经验,拿到问题知道该是哪个人,哪块项目有关;更关键的是积累了充分的人脉,大家都认识你,知道遇到这个问题该找你,相信你能帮忙,这种信任也是一个老板能力的体现之一,并且年限短的老板很可能就没多少这样来自同级之下其他组的信任。
另外,记得要Pulse的结果。
6.3 和组员1:1
这一章节是临时加上来的,突然想起来和组员问的问题与和老板问的问题不太一样。放一下我自己的问题列表:
- What is the ramp up process?
- How are your tasks assigned to you? Anything that is forced to be assigned to you?
- Do you have a clear roadmap?
- How often do your team hit hard deadlines?
- Anyone working overtime?
- How much does your manager talk with you about your career in your 1:1?
- Does perf look fair to you?
- Are you happy with your team?
- What did you learn here
一般组员对与大组发展方向了解的都不深,所以这里主要问组员对于这个组方方面面的满意程度。组员的回答会更加主观一些,但是因为组员提起某些问题的时候。他们往往有发生在这个组里的活生生的例子,所以我认为这些回答的价值更高一些。我主要会问组员对于组里工作压力,升职预期,项目分配等问题的看法,最后了解一下组员对这个组是否满意,有没有对自己有所发展。如果你有其他看法,可以多加一些你自己的问题。
Task tool - Owner is a direct report of any of: MANAGER
This is an actual agenda that I sent to managers when I was looking into different teams to join. Everything after the ‘-‘ on each line was not included in the agenda, it’s a note to the reader of this paste.
I) Assuming we absolutely crush it as a team, how is Facebook better off a year from now? - How connected is the manager to the vision of the team? Are they passionate? It should be pretty easy to tell whether the manager is genuinely stoked about the project from their answer to this.
II) What’s could prevent us from getting there? - If they were really passionate about the vision of the team, are they realistic in being able to execute on it? This separates the good talkers from the good executors
III) What role would I play in getting us there? - What’s expected of me? I usually ask follow-up questions to make sure they’ve seriously thought about the scope of the role.
IV) Roleplay - Going over some scenarios from the last year and how you would’ve helped me through them. This may or may not be useful, I’ve never changed teams before so I’m not sure. I think one of the things that is helpful in a manager is being able to help me figure out what I don’t know and so I’m trying to get signal on that. Open to suggestions on better ways to do this. - The explanation of what I’m trying to get out of this question is literally in the question. I’ll bring up some mistakes that I’ve made, and/or an example of something that I thought I did well on, and see what kind of questions they would’ve asked to help me debug it. EX: “For task X, looking back, I feel like I should’ve probably tried to get somebody from team Z to do it because they had more context on the problem. I have a strong reflex to jump in and help, which is preventing me from scaling. How would you help me get past this?” If they ask questions that I haven’t thought of before, or change the way I think about the problem, this is good signal.
V) What do people like about working on your team? What do they dislike? (I follow this up by asking “What do you like about working on this team, what do you not like abbout working on this team?” to folks on the team to see how well-aligned answers are!)
VI) How would I know I’m not meeting expectations on your team? Feel free to make up or re-use a past scenario and walk me through it. - The goal of this question is to figure out “When push comes to shove, would this person be OK having a tough, awkward conversation with me?”
VII) Does having a bunch of new people change the way you manage a team? - This team in particular, more than half of the people had been hired in the last 6 months. Do your research on the team, read group posts, look at some diffs, ask questions.
- What is the most impactful thing you’ve learned in the last year?
IIX) There’s probably some other things that will pop up. - Making sure they know I’m not a ruthless checklist agenda follower
IX) Feel free to add your own agenda items :D!
X) Do agendas with roman numerals make meetings more productive?
TEAM
Team meeting structure
Workplace groups and team’s tasks
Size and location
Relationship with Tech Leads and XFN partners
Typical work/life balance
Oncall requirements for team
Hiring Manager leadership style
PROJECTS
Project current state and life cycle
Cadence of diff and bug review
Personal passion toward nature of work and project
Roadmap
POSITION
When in the Jobs Tool, ensure roles you’re considering align with your interests, skillsets and experience level.
Only consider roles which have immediate availability of headcount
Consider alignment of personal skillset and alignment of team needs
If unsure, clarify with the Hiring Manager BEFORE taking on a task. This ensures time in team selection is used effectively.
GROWTH & IMPACT
What personal and/or professional growth opportunities does the role offer?
What level of Mentorship would you ideally receive in role? Is the team able to accommodate?
What are your future ambitions in-role? Does the role in consideration align? (Tech Lead, Management etc)
What’s the 1-5 year plan for the team?
How does the role you’re considering align to these goals?