正如大家所知，我最近换了一个新组。回顾过去几年，被坑的时候实在不少。从中我意识到了一些事情，故用这篇文章记录一下，也算再给自己的想法做个 snapshot。文章的三部分别讲项目、老板以及组的坑。最后再聊聊换组。
“坑”不仅指外界的坑，也指自己犯过的错。本文的适用范围还请读者自行判断，毕竟大到公司，小到组和部门，它们的差别都极大。 你觉得和你遇到的情况不符，请不要杠，这没意义 。虽然这么说，我觉得大部分内容还是通用的。另，有些英文说法没有翻译，但都不难理解。
我转组的原因之一是 2020 年做的大项目的失败。项目实现了规划的功能，架构也清晰合理，但没有达到预期的 impact，而我原本是指望用它来到 L5 的。为什么会这样呢？归根到底，这个项目并非来源于客户的直接需求，而是老板拍脑袋想出来的。我的（前）老板某一次和其它几个老板聊天，发现其它组都有一个工具。他觉得这玩意我们大部门也挺需要的，那就找人做吧。不是说它完全没用，毕竟我们最终还是找到了两个客户，但我们很想推的组没推动，并且未来大概也不会有更多用户。后来我才知道老板先问了我的 TL，TL 没有接，然后才找的我。TL 依靠丰富的经验避开了这个坑，但我就没那么好运气了。结论：需求不是直接来源于用户是一个巨大的 red flag。
这里仅讨论内部工具项目，不适用于面向外部用户的产品 。几年下来我有一个很直接的观察，成功的内部工具基本都是 2c，很少有 2b 的。可能有人会好奇，内部工具也有 2b2c 之说吗？有个很简单判断方法：一个工具or系统，如果工程师能自己用起来，那就是 2c；如果需要部门里 >1 人讨论并决定，那就是 2b。举两个例子：一个开箱即用的任务监控面板是 2c 的，而一个需要修改 release 流程才能使用的工具就是 2b 的。当然，我观察到的样本很少，所以结论未必对。但我真心感觉 2b 的东西想推动，要花费几倍于 2c 工具的时间，效果还未必好。总之如果你有的选，请尽量把时间花在 2c 项目上。
OKOK 我明白，世界上就没几个不需要跨部门合作的项目。但合作方式也是多种多样的。假入对方是你的客户，你需要和他们沟通来实现一个需求，又或者大家同属一个大组做同一个产品，这种就没问题。而当对方在你的关键路径上——比如你想做的东西没有对方配合就完不成，且你们又是跨部门，这种就有极大风险。如果你正在参与此类项目，请一定确保：
除了上面提到的那个项目，其实我曾有更好的机会升 5。我们组有个项目，本来由两个人分别负责前后端，但是后端哥们儿写一半离职了。后端是用 C++ 实现的，而我当时是组里唯一有 C++ readability 的人，如果申请接手，老板 100% 会同意。然而我当时埋头于自己的任务，完全不关注组里其它人在做什么（即使我一直帮他们 review 代码）。因为不了解，也没有意识到这个项目的潜力。后来这个项目交由前端哥们儿负责，并且成了组里的重点项目。我就这么错失了好机会。这说白了又是“选择大于努力”的例证。
于是我决定，进新组之后至少和每个人 1:1 一次，即使他们的工作看起来和你毫无关联。同时注意各种 PRD 和 design doc，了解其它人在做什么。除了寻找可能的机会，这也有助于站在更高视角全面理解当前的工作。
我当初之所以选择换到现在的组，主要是因为（前）老板答应我可以继续之前的工作——一个我很喜欢并认为有很大潜力的项目。时至今日，这个项目完全兑现了潜力，然而我却因此耽误了两年。如果当时抛弃对项目的感情，我完全可以找个更合适的组。转组的事之后会细聊。
之前和 Phil 做过一期节目聊了这个话题，不过我们遇到的情况不尽相同，感兴趣的可以去听一下。我只说我遇到的情况。
我的三任老板都有过很离谱的判断：
所以我认为，老板的话要听，但决策一定要自己做。这里面有个更本质的原因。自己做决策，即使错了，也可以复盘反思，并取得进步。而让他人做决定，自己将很难进步——对不知道对在哪，错也不知道错在哪。
我换组的另一个原因是发现老板有把我当工具人的倾向。在 Google，好的老板要能平衡组与组员的利益，既保证组的发展，又确保个人能够成长（说白了就是 promo/升职）。前两任老板虽说都给过我坑项目，但至少他们会和你聊个人发展并给出建议。这些我都看在眼里。现老板去年还是工程师，在前老板走后被提拔上来。一开始的感觉是他不太关注我的项目，即不了解也不想去了解。今年 Q1 快结束时，事情开始变糟。如之前所说，老板开始砍项目，并把我调往那个我曾经错过的项目。本以为老板打算让我从现在开始 own 它，然而并不是。老板的意思是让我 Q2 去实现一个比较重要的功能，后续安排再议。从我知道的情况看，这个项目中很有 impact 的一块已经被分给了一个即将到来的 intern——是的你没听错，intern。我问老板：明明这个 feature L3 工程师就能做（简单的 CRUD），并且对他们 promo 帮助很大，为什么让我来？老板说你擅长这块，你来做比较快。既然推不掉，那我只能跑了。
怎么判断老板有没有把你当工具人？我觉得有这么两点：
看老板给不给你做职业规划。好的老板会说：我觉得你想 promo，impact/difficulty/leadership 还不够，做XXX任务可能对你有帮助，或者我们一起想想能做什么。把你当工具人的老板不会给你规划。
看老板对你是否诚实。我曾对现老板说：我感觉做这个功能对我 promo 没帮助，impact 不够大。老板说不要紧，只要你做得快，拿 SEE（类比 3.75）是没问题的。在我看来这就是典型的不诚实，或者职场 PUA 话术。你再 senior，该花的时间还是得花，收集需求、设计、实现、测试，这其中有的时间是你无法控制的。Senior 工程师无非是做出来的东西稳定一些，考虑更周全，bug 更少，并不是一定就能做得更快——因为最快的方法永远是糙快猛。
如果是前老板，我觉得他会说：”虽然没法让你到 5，但我们有客户急需这个功能。我们可以规划一下之后的安排，比如让你顺势 own 这个项目，或者找一个更好的项目“。诚实是最重要的。不要骗我们，我们不傻。
当然，现老板也和我聊过 promo。他说如果我想 promo 就要自己想一个好项目。于是我想了一个 impact 很大的。写了 proposal 给相关组审阅，他们很满意。然后老板说我们不做这个，要 focus。我：？？？
组的坑既是最好聊的又是最不好聊的。相对来说，组的坑比较明确，容易提前识别。但另一方面，组的坑多种多样，且和老板和项目都有关联，难以穷尽。所以这里只说说我知道的那些。
有的组业务有前途，有的组技术有挑战，有的组两边都有，有的组两边都没有。两边都没有的铁定是坑组，这种组在大公司相当多，比如 Google 的 EngProd 组。当然，如果某个组做的东西就是你的兴趣所在，那就加入吧。
EngProd 具体怎么坑，我以后或许会专门写篇文章讲，但最根本的一点在于他们负责的是 fake infra。EngProd 全称 Engineering Productivity，现在的 title 虽然是 Software Engineer，但在 2019 年以前是 SETI（software engineer, tools and infrastructure）。有人一看到 “infrastructure” 这个词就被唬住了，以为做的是什么不得了的东西。然而，EngProd 虽然不负责业务，做的东西却跟 infra 一点不沾边，我称之为 “fake infra”。比如修改一下公司的集成测试框架给某个组用，帮某个组优化 presubmit/postsubmit time，减少 test flakiness，诸如此类的杂活是 EngProd 传统艺能。我理解公司设立这个职位的初衷就是把杂活分出去，让 SWE 们专注于开发。
Fake infra 和 true infra 的区别是什么呢？我觉得 true infra 一定是有技术挑战的，且至少要服务于某个大部门（比如 Search/Ads/Cloud），而不是一个或几个组。那些大家耳熟能详的技术都是 true infra，比如 Spanner，F1，Flume，Bigtable 等。有意思的是，做 true infra 组从来就不属于 EngProd，而 EngProd 也从来不负责 true infra。
记得第一任老板总是强调要了解 big picture，当时不懂，现在才发现说得真对。Scope 指一个组负责的工作或者产品有多大。比如前面说到的 true infra，他们的 scope 就是全公司，而 EngProd 组的 scope 则通常是一个部门（几十到一百人）。面向用户的产品更复杂一些，因为涉及到对前景的判断。比如 Gmail 和 YouTube 虽然有几十亿人用，但某个组负责的小功能却未必。这时候你只能依靠经验去判断。很多时候我们看不清，这不要紧，但至少有一些坑是可以避开的，比如 messaging app。
我第一次换组的时候也犯过错误，为了申 AR 方向的组花了很多时间去学图形学，导致都没怎么认真看其它组。回想起来觉得自己真蠢：在 Google 做 AR 没前途不是明摆着的么？到今天为止都没有一款面向消费者的成功 AR 产品，更不要说在这方面投入不多的 Google 了。而且说白了我也不是真的有兴趣，只是觉得这个技术很酷而已。当时犯的错误，现在要用几倍时间来还。
下面来聊聊换组。虽然和上一节相关，我还是决定单独拿出来说。很多公司不像 Google 有这么多换组机会，还可能面临老板不放人的情况。因此我不打算写换组的流程，而是把重点放到 “选组” 上，尽可能让内容通用一些。
只看产品选组还不够，具体的工作内容和大方向也很重要。比如一个明星产品组招人可能是为了是搞测试，而一个内容平台的年度 OKR 可能是加强审查。要了解一个组的方向，最简单的方法是去看它的年度 OKR。如果找不到，一定要和老板问清楚。
我遇到过这么一个组，他们有 hc 所以打算先招几个人，至于做什么等之后再分配。这也是一个 red flag。通常来说，一个职位的职责越明确，项目的风险和掉坑的概率就越小，也能让你做出更有根据的选择。
我实在不知道 impact 怎么翻译比较好，“影响力”这个说法其实不准确，所以我就不翻了。Impact 是否好兑现，我们可以通过举例说明（注意，好兑现和“大小”是两码事）：
好兑现的项目简单明了，只要做完了 impact 就实打实地在那，不需要费劲给人解释。不好兑现的则各有各的问题：
优先选择 impact 好兑现的组。一般来说，做新东西比较好兑现。
和老板聊天往往容易浮于表面，或者大饼满天飞。找到组里的工程师，一般他们都会毫无保留地告诉你真实信息。我会问很多尖锐的问题，比如“你觉得组里有哪些缺点”，“promo 速度如何”等，还会详细了解工作的细节。有个工程师直接告诉我，如果你想 promo，就不要来我们组——老板们断然是不会这么说的。如果你觉得在职员工讲话会有顾虑，也可以找刚转出去的员工。实际聊下来我没有发现太大差别，只要是工程师都会如实说明情况。
这个问题没有标准答案。我现在倾向于认为只要可以转（Google 的要求是待满一年），就可以开始关注新机会了。我们有个系统可以设置 filter，出现满足条件的内部转岗机会会自动给你发邮件。每周看一次邮件其实花不了几分钟，而且看机会并不意味着一定就要走。别看每天都有很多组在招人，实际上单看每一个组，招人的窗口都只占一年中的很小一段，甚至有的组几年都不招。很多机会错过就是错过了。
有种情况我会建议你立马开始看机会：人事变动。不论是老板离职还是 reorg，只要是人事变动，多多少少一定会影响工作。影响可能好可能坏，可能多可能少，你无法预测，所以最好未雨绸缪。尤其如果老板给你提供了很多支持，甚至本身就是项目的发起者，当他离职之后你的工作必然受到冲击。事情变坏往往就是一瞬间的事，如果没有准备可能会措手不及。
相信你现在也感受到了我这几年是怎么被坑过来的。我当然希望自己没有被坑，顺顺利利地升职。但既然事情已经发生，也必须总结一下引以为戒。祝大家职场之路顺利。
URL: https://laike9m.com/blog/jin-ji-nian-wo-zai-zhi-chang-cai-guo-de-keng,143/