原本没打算写这篇文章，纯粹是前年升职后才突然发现原来在大厂有这么多台面之下的规矩，于是打算记录这些本该早些知道的，却一直无从知晓的，又或是曾经看过但毫无体会完全记不得的，大概可以被称之为心得的东西。
微软很大，也很老，下面说的内容主要是出自我自己在微软互联网工程院 M365 组的工作感受，未必适用于微软其他的组，更未必适用其他大公司，所以请谨慎当作自己的职业发展参考，看一乐就好。
关于升职加薪的小疑问
在我刚加入微软时，我惊诧于即便是相同 level 的 IC 同事，技术水平竟然参差不齐得厉害，毕竟在我当时的理解中，同属 IC 岗位（纯开发岗），level 和技术水平当然是关系最大的，所以只要 level 一样，技术大概就是差不多。
但事实上尽管 level 一样，有的同事对许多基础知识和工程实践掌握深刻，对前沿的学术进展也都很了解，还有一些同事则了解极少，甚至连 GitHub 账户都没有，他们的 level 真的应该一样吗？公司或领导在判定级别的时候是不是有一些什么问题？其实我无意评价同事们的技术水平，毕竟并不是每个人都喜爱并追求它。但职级作为世俗意义上大部分人都会在意并追求的目标，身为员工，或许还是搞清楚一点会比较好。
在微软互联网工程院（我想对于其他大公司大概也差不多），升职其实只取决于两件事，提名和预算。
先说预算，预算其实很容易理解，因为升职意味着会加薪，这部分钱并非凭空而来，而是根据预算来的。虽然目前我还不明确预算分配的具体单位是什么，是产品（例如 M365，Bing，Edge，Xbox，或是更小/更大的产品范围），还是业务组织架构（例如 C+AI，E&D 这样包含多个产品的组织），还是什么别的（例如汇报给某一个 EVP 或者 CVP 的员工），但总之，有足够的预算是升职最基础的前提。
之所以提到预算分配单位，是因为它牵扯到预算的多寡，毕竟赚钱多的组织当然预算更多。但是 A 组织赚的钱是不是只用作 A 组织员工的加薪预算呢？我认为是否定的。考虑到公司不同组织天然存在差异，有的业务生来目标就是赚钱，而有的组则是纯做公益，项目纯开源赚名声赚吆喝，或是为未来做长远打算，所以公司层面肯定是会把 A 的盈利也匀出来一些给 B 组织用作加薪预算。就像大家熟知并惊讶的微软打算收购动视暴雪并打算并入 Xbox 一样，以过去 Xbox 的市场占有和收入是绝不可能完成这样的全现金收购的，所以这个钱显然是公司的盈利业务（Windows，M365，Azure，LinkedIn 等等）赚来的。
当然作为一个整体，微软除了会做组织间的预算分配，还会根据世界经济情况来决定公司层面的态度。就像整个2023年经济状况都不好，公司层面的预算就受到很大影响，就算赚钱多的组预算稍好一点，但整体上应该都没有给大家升职。
所以在预算上会看两点，组织的盈利能力和公司层面的宏观调控。
再来说说老板的提名。虽然我不是 manager，但种种信息表明，在每个季度的升职节点上，manager 们会向上面汇报本组员工的升职提名，一般来说会由直属老板先直接指定。对于低 level 往往直属老板（M1）汇报提名后都会批准通过，对于稍高一些 level，往往还需要老板的老板（skip manager，M2）在 M1 提交的提名上再附加提名意见。通俗一点说就是你老板给你提名：“小王做得不错，我决定这个季度提名他升职”，然后你老板的老板也很认可你，于是在你老板的提名意见后面写：“确实，我也+1”。更高 level 升职可能同时需要更高级别，或是跨部门的领导的提名，不过大致思路应该还是一样的。
所以你的老板是怎么给你提名的呢？虽然各个老板都有自己提名下属的理由，不过程序其实是一样的。老板在提名时，其实需要写一个小作文，比如“小王最近做的不错，他把 X 做好了，完成了 Y，最后让某某核心指标提高了 Z%”，而这个数字 Z% 才是老板提名小作文的核心内容。
这份提名小作文的目的也比较简单，是你的老板写给其他人看的，旨在向大家说明，你的确是值得被升职的。
当然提名也不一定总是会被批准，一个常见的例子是假如这个季度公司按照经济形势和组织盈利，给 A 组批准了升职预算 X，A 组下面各个 manager 们分别按照下属的表现提名了三个，最后只批了两个，另一个可能因为预算不足，或是可能因为小作文说服力还是不够而被驳回。
到此终于可以来解释前面最开始提到的疑问，为什么 level 相同的 IC 同事，技术水平可以差别这么大？因为从业务角度来说，他们可能都实现了某些老板们很看重的指标，而指标这件事与技术能力许多时候其实关系并不大。你做到了，就可以，至于你是用什么手段，用什么方法，不那么重要。
项目大过天
还记得刚才上面提到的提名小作文吗，作为游戏核心任务物品，那玩家自然要继续搞清楚它从规划到编写再到提交的始末，这次我打算举个例子。
你叫小王，2020 年 6 月从华东某 985 硕士毕业，作为校招生加入了微软某组 A。入职之后直属老板给你分配了项目 B，你吭哧吭哧做了一年后项目终于上线，于是你在 2021 年夏天升职了，从 59 （本科/硕士的校招职级）升到了 60。
上面就是小王校招入职后的第一年的升职经历，虽然简单但其中不少细节仍值得一聊。
作为校招生入职，很多时候是没机会去选项目的。倒不是说不能选，而是选不出。一方面是因为能做出选择的前提是需要了解，而茫茫大的微软组织项目和技术历史又怎是一个校招生能在短短几天搞懂的呢？更别说通常入职之后就需要在几天内先选组，再选项目。另一方面是因为多数人加入时会抱着“我刚来，还是应该是学习为主，不管什么项目都是值得学习的”的态度。所以就算公司层面支持自由选组，做自己感兴趣的事，但员工实践起来困难重重，实际情况约等于入职等分配。
于是稀里糊涂进了大组，懂非懂地听各小组老板们的校招宣传，多番比较后在纠结和盲目中卡着 deadline 选了小组，最后在一脸懵逼中开始跟着 Tech Lead 开始上手干活，是大多数校招生的入职第一个月的常态。我个人觉得不太好，但我也想不出更优的解决方案，毕竟让每个校招生都去各个组轮岗一遍也不现实。
那么加入组 A 和接手项目 B 这件事会对小王产生什么影响呢？其实从校招入职选完项目的那一刻起，未来提名小作文中的 80% 就已经写完了。听起来有点匪夷所思，活儿还没开始干呢，怎么就写完 80%了？
细想其实原因也不难理解，因为这个项目能不能做成，会遇到什么样的困难，未来上线后能获得多大影响，是否会遇到其他项目的负面牵连而不能上线，这些影响小作文的重要条件在冥冥之中早就已经标好，项目在设立之初就已经配好了小作文模板。与其说是你选项目，倒不如是给这个小作文安排了一个人，这一点，你的老板比任何人都要清楚，而你只能选择接受。这就是我想说的项目大过天。
下面我想以问答的形式来讨论剩下的 20%。
如果我能力极强，是不是就可以提前完成项目或是打破老板的预期？
答案当然是可以的，但是在一家成熟的大公司，个人能力会被不同程度拉平，这种拉平的结果就是这些“更好/提前”的可能性大大降低。如果你不理解拉平是什么意思，我举一个例子。
两个技术水平不同的新员工，如若让他们各自独立工作，最后的交付成果差距必然是巨大的。但是在微软这样的大公司，别说技术选型，工作流程中的 95% 都是不能改变的，用什么框架，用什么协议，用什么存储，在开发过程中的 Engineering System，甚至连编辑器都不能自由选择（倒不是说 Vim 完全不能用，但是种种许多特殊要求会给你制造困难，不得不使用 Visual Studio），再加上在大厂每天少说也有四分之一的时间会被用作开会，写方案，写文档，真正生产代码的时间会被进一步压缩，规范化和流程化让生产变得稳定且可能。结果就是让技术一般的同事也能跟着已有的选型完成可靠交付的同时，也让技术极强的同事失去了独立成长和发挥的空间，这就是拉平。
既然个人力量如此渺小，倘若拿到的是棘手项目岂不是升职无望？
那倒也不必担心。虽然理论上的确存在这种可能，事实上也的确发生过，但绝大多数情况应该不用为此过分忧虑。这个问题其实可以从老板的角度来思考，一方面各组低级别员工的升职情况是特别容易被拿来横向比较，另一方面没有老板是不在乎自己组的名声，所以校招低级别入职，不管什么组大概率都是吃大锅饭，分到的项目不会差太多。只要按部就班做，就能按部就班升。给你升得太快，同期的其他校招生会觉得异样，给你升得太慢，上面的老板也会质疑。
但是大锅饭现象随着职级提升会渐渐减轻，毕竟当年的项目在几年之后会发展成什么样根本没人知道，一点点差异在时间的积累下会被渐渐放大，更别说公司内部会有各种机会，像是 reorg 或是得到老板支持开始自立新项目等等。总之，低级别校招入职大概率吃大锅饭，几年之后看个人造化和机会。
组 A 和项目 B 哪个更重要？
组往往决定了业务方向，例如大数据存储组，网络基建组，搜索服务组等等，而 B 则决定该组中的某项目，例如网络基建组的 DNS 解析项目，或是搜索服务组的分片存储项目。
组和组之间差距极大。例如对于 M365 这个 org 来说，做个人用户的 Word/Excel/PowerPoint 组，做企业用户的 Outlook/Teams 组必然是赚钱大头，也扮演着季度财报重头戏。反过来，假设现在 M365 同时也有一个组做某款协同编辑图片的工具，那它目前显然不属于 M365 的核心业务，只能算加花。
类似地，这个概念也可以放到小组当中，例如对于 Outlook 这个小组来说，影响邮件收发/搜索的业务毫无疑问是核心，但给用户做个性化美化的业务就不是。
其实 A 和 B 这两个变量很难完全分开来讨论。经济形势好的时候，大家都很会按照前面说的情况升职加薪成长。不过以我目前就着 2023 财年裁员动作的观察看来，当预算紧缩的时候，组级别会承担的风险则会更大。举例来说，做纯加花业务的组可能会全裁，80% 加花的业务裁员 50%，影响核心体验的业务则暂时安全。当然加不加花，加多少花都是相对的，以及也只是最终影响的程度不同而已，毕竟覆巢之下无完卵。
未完待续