如何找到好组好老板————公司换组选组攻略(上)

今年三月份左右，org内经历了一场大变动，陆陆续续走了很多人，我们组的TL和一个很能打的IC也被拆走了，加上年初又走了两三个人，我也开始找组换组。
大概看了一个月，聊了五六个老板之后选定了一个组，但是不巧因为covid，换组没有被director批准。本来打算perf后继续换组，但是发现新老板人很好，对组里的观念也和我很相似，所以想take challenge，帮助组员和老板在一个前景不甚光明的org内把这个几近整个换血的组带起来。

当时换组最后也找到了几个不错的老板，加上最近估计不会太操心换组的事情了，所以趁有时间有闲心，想把这些经验分享给需要的人。

===================

本文适用对象：
本文主要适用于大公司内部换组，同时半数以上内容也适用于入职大公司team matching，对于小公司帮助会稍有欠缺，不过核心问题什么是好组好老板上面，应该是四海皆准的。

核心问题：
选组换组是一个双向选择：我选择老板，老板选择我。
1. 我选择老板：什么是好组，什么是好老板
2. 老板选我：老板为什么要选我， 我能为组里解决什么需求，我能为组里带来什么。

本文重点讲第一个问题：
* 一个好组的判断标准是什么
* 通过问老板什么样的问题，还有什么额外的方法，来判断一个组的好坏

概要：
* 1 明确你的需求
* 2 选组清单
  * 2.1 内部搜索
  * 2.2 朋友或者老板熟人推荐
* 3 好组/好项目的表现方式
  * 3.1 团队操作流程和文档 （Team Process）
  * 3.2 团队技术水平 （Team Professionalism）
  * 3.3 团队满意度 （Team Satisfaction）
  * 3.4 个人成长空间（Growth）
  * 3.5 老板管理水平（Manager Management Skill）
  * 3.6 老板技术水平（Manager Technical Skill）
* 4 制作打分表
* 5 项目背景调查
  * 5.1 团队工作压力
  * 5.2 团队成员技术水平
  * 5.3 团队满意度
* 6 和老板和组员1:1
  * 6.1 让老板了解你
  * 6.2 该问老板什么问题 （question doc）
  * 6.3 完成打分
* 7 总结
* 8 参考资料

1. 明确你的需求

换组选组跳槽，大多数都事出有因。很多换组的同学都是因为老板或者组实在是呆不下去了，老板不帮忙，排挤，组里TL把组往阴沟里带，学不到东西，整天倒水搬砖填天坑等等。一个好组通常也会有一些问题，比如技术栈复杂老旧代码多，老板管人太多不会在每个人身上放太多时间，组里做新产品新功能压力大deadline多等等。没有一个组是完美的，所以要明确需求，看自己需要什么，对于什么样的问题可以忽略不计。

下面这些核心问题是我觉得必须要想清楚的
* 你的长久计划是什么
* 你在这个组想要学到什么
* 你在这个组会如何成长。不止是技术上的成长，也有沟通技能，管理水平，大局观之类的非技术技能的成长
* 你对这个组的项目有多感兴趣
* 你在这个组会不会待得开心

其中最难的问题应该是长久计划，这个问题明确了，之前的问题也能迎刃而解。比如有些人想走技术选TL路线，或者想走产品路线，或者管理路线，需求都是非常不一样的。在完成接下来的选组看项目聊1:1 之前，一定要把自己的需求明确好。

2. 选组清单
接下来就是在内部换组的网站里面挑选自己可能想去的组了。一般大公司都会有一个内部job posting的网站，我在选组的时候，第一轮我没有给自己选定方向，大概除了不做纯frontend不做machine learning，只要符合我的level，工作地点在南湾， 是software engineer的岗位我都大致看了一下。除此之外，之前的TL和走掉的大manager也非常nice，给我推荐了好几个组，并且他们还告诉了我哪些org内部相对混乱不要去，哪些比较好推荐的。最终筛选出来30多个candidate。虽然这第一轮选下来的很多，但是我谈的组并不多，具体就是因为下一轮的打分和筛选只留下了几个最想去的组。

建议把这些组和信息放到一个Google sheet里面方便管理，也方便追踪自己选组谈组的进度。里面列举了项目名称，地点，manager，项目类型，每个老板1:1 question doc 的link，还有初步打分和最终打分，详情请移步这个Google Sheet
https://docs.google.com/spreadsh ... nhuqa9So/edit#gid=0

3. 好组/好项目的表现
这一部分无论大公司和小公司都会适用。里面可以说的东西太多了。如下排名不分先后，如果大家有什么想法的话欢迎补充。

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不至于太差，并且老板对于组员很好的话，大部分人是不会换组跑路的。

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的评判标准相似，这里就不多说了。

==========================

本文还有后半部分内容没有完成，我会尽量在三天小长假内把下篇写完。关于如何以公司内部公开的资料完成项目和团队背景调查，如何问老板问题，如何作出最终选择，欲知后事如何，且听下回分解。

如果大家有新的想法，有补充的内容，或者有之前换组选组的经验等等，我会把有用的回复都补充到主贴里，谢谢🙏


补充内容 (2020-9-7 16:32):
下半篇地址：https://www.1point3acres.com/bbs/thread-667021-1-1.html

从楼主分析的条例和评分的客观程度，感觉是一个好老板，或者有好老板的潜力。感谢分享

question list真的太给力了

想问下lz， in general 来讲的话，是不是小的组机会promotion 机会更多？ 如果想尽快4-5 的话 选组上应该prioritize哪方面呢？ 可以在bootcamp的时候就和manager表达清楚自己想尽快升职么？

感谢lz 很多我对我现在的mgr/组的困惑lz都有提到

很有用的信息！

好帖 mark！

谢谢楼主分享～

好帖Mark，谢谢楼主

好帖，感谢分享

我想问一下，转组跟hiring manager聊之前需要准备一个内部简历吗，还是直接找老板聊就可以了？

cortexxx 发表于 2020-09-10 09:28:21
我想问一下，转组跟hiring manager聊之前需要准备一个内部简历吗，还是直接找老板聊就可以了？

最好准备一个简历，老板能提前看到你做过什么，这样给1:1省时间同时也能让老板更了解你，不亏的