Ju Yang

在工作6年之后，我终于升到了staff engineer（资深工程师）的职位。在庆祝之余，我也借此机会对自己的经历进行一下反思和总结。

坎坷过程

在2021年的时候，我刚升到senior engineer（高级工程师），写了一篇文章 Senior engineer and then what?，畅想了一下senior之后的职业发展方向：继续做senior，升到staff，或者转管理岗。当时我就决定，可以往staff的方向努力。在我的导师（mentor）和老板（manager）的帮助和鼓励下，我2022年末第一次提交了staff的升职申请。我当时很犹豫，并不确定自己可以申请，主要是觉得我做senior的时间还不长，只有2年。一般做senior的职位3-5年之后才会申请staff，因为要积累升职所要求的各方面经验。我老板觉得，我的技术能力和项目经验足够申请staff，大老板（skip level）也觉得可以一试。我有些担心，如果我这次被拒了，会不会影响之后的申请？我问了公司里好几个从senior升到staff的同事，他们里有很多都是第一次被拒，第二次才成功。他们都鼓励我说越早申请越好，百利无一害nothing to lose, and much to gain。

我列举了一下是否申请升职的利弊：

利：第一，我们组内部觉得我的工作满足staff的要求，所以老板和skip都很支持我；第二，不试不知道，万一成功了呢！如果不申请，肯定不会成功，只有提交了申请，才有可能升职；第三，就算被拒了，这次写的升职申请也能够帮助我整理思路，下一次就不用从头写起了；第四，被拒之后，可以从评委会的反馈中知道我哪里做得不好，能够更好地了解要从哪里下手提高，从而能够更好地在下一次申请的时候有的放矢。

弊：第一，写升职申请非常花费时间和精力，会占用我的工作时间，我可能需要加班写升职申请；第二，如果这次被拒，下次申请最少是一年之后，因为半年之内不太可能满足评委会提出的要求。

我当时有一个跨组合作的项目正在进行中，还没有上线，所以我一开始觉得不急于这一时。距离申请的截止时间还有两个月的时候，我跟老板说自己没做决定。我当时心里其实就想着算了，与其花时间写升职申请，不如抓紧时间把我的项目做完上线，半年后再申请，更稳妥。就在这个时候，公司里上次升职申请的结果出来了，有同事成功升到了staff，我读了他的升职申请之后，觉得我的工作并不逊于他，瞬间自信心爆棚，当天就跟老板说，我决定还是要搏一搏，单车变摩托。于是2022年末我第一次提交了升职申请。

2023年2月，老板跟我说，申请被拒了。虽然我的确是抱着被拒的心态申请，但还是很沮丧。我看着评委会的反馈意见，有些意见我觉得说得有道理，有些意见我无法苟同。老板和同事都很支持我，听我吐槽，帮助我度过这段很沮丧的时光。无论如何，毕竟尝试了就没有遗憾。

事实证明，这次申请的反馈意见对我下次申请和职业发展的帮助是非常大的。塞翁失马焉知非福。第一，我以为半年就能做完上线的项目，最终因为种种原因没有上线，所以即使当时等了半年再申请，我的工作成果也并不会有太大不同。第二，为了满足评审会对于一些专业技术的要求，我老板把我转到了另一个更偏模型（modeling）的组，从而更好地体现我作为机器学习工程师（machine learning engineer）在模型方面的能力。在这个新组，我成功上线了一个很复杂的模型项目，跟公司的平台（infra）组合作。我学到了很多新知识，对我个人的职业发展很有帮助。第三，我老板鼓励我作为广告组的代表加入公司的机器学习顾问委员会。他一开始问我想不想加入的时候，我拒绝了，因为觉得这个委员会里都是公司各个组已经是staff的人，而我不过是一个senior，在级别上不够。我老板说，级别不重要，重要的是我的对广告组业务的了解，加入这个委员会也能够提高我的能见度（visibility）、跨组合作、以及战略思维（strategic thinking）。我同意加入，并参加每两周一次的会议，讨论公司内不同组对于机器学习技术的看法和前景展望。第四，我老板、skip和产品经理（PM）都全力支持我，推进我之前提出的一个跨组合作的项目，虽然只是原型（prototype），但也安排到产品路线图（roadmap）里，他们相信我的技术判断。 第五，我在跟不同人吐槽升职被拒的时候，被一个好心的主任（director）牵线搭桥，联系到其他组的一个senior staff做我的mentor，我受益匪浅。

2023年年末，我第二次提交了staff的升职申请。这次的升职申请，我自己都觉得比第一次更有料，内容更丰富。我不再只是试一试的心态，而是更自信，觉得自己在过去一年确实成长了很多。当结果出来的时候，我也总算松了一口气。

下面聊一下我个人认为staff升职申请中需要强调的4点。这些是基于我在现公司的经验，未必适合所有公司。

 

1. 量化影响 (quantify impact)

如果你牵头的项目直接给公司带来了10%的利润提高，这一项可能就足够你升职加薪了。大多数时候，我们项目的成果和影响都没有那么明显和惊人，甚至很难跟利润和钱直接挂钩。而评委会最看重的恰恰就是impact，这个词直译是影响，说白了，就是你给公司带来多少利润。量化你项目的影响，展现给评委会你对公司具体的贡献，用数字说话。

评审会是由公司里各个组的人组成的，他们并不熟悉你的工作领域和业务逻辑，也不能在很短的时间和有限的文字里了解你的技术细节和项目设计。他们第一眼看到的是业务需求(why)，第二眼看的是影响(impact)，最后才会看一下你具体干了什么工作(how）。比如，有一个项目是优化一个现有的模型，你作为项目执行者，试了很多不同的神经网络的参数，通过线下和线上的实验，最终上线了一个新模型，提高了准确度。这些描述都是how。但评委会想要看到的是why，为什么需要提高现有的模型，是模型不够好么？为什么提高模型是高优先级的项目？有什么商业需求（business need）么？他们更想看到量化的impact，就是有这个why之后，你做的东西对公司到底有多大用。准确度虽然也是结果的一种，但是模型的准确度跟具体的业务影响不够直接。这个新模型能给公司带来多大利润，能给用户带来多大好处，对公司的战略有什么帮助？同样的项目，如果从量化影响的角度，可以写成，现有的模型准确度不高，严重影响了用户体验（why），我通过改变模型实验（how），提高了准确度 by X%，增加了用户粘度 by Y%，提高了收益by Z%。关于如何把项目的影响量化，可以多跟项目的PM聊聊。

当然不是所有的项目都能直接跟利润挂钩，但基本思路不变。我有很多基础设施（infra）的项目，不是直接做产品，所以并没有直接带来利润或者改变用户体验。但infra项目的好处是对工程系统（engineering） 的影响很广，毕竟一个infra做出来之后，很多人都会用，这个内部的impact就显现出来了。如果能够通过infra的改变优化流程，提高效率，减少技术债（tech debt），把这些成果量化出来，也是很有力的内容。比如，有一个项目是migration，从一个infra迁移到另一个infra，你把这个migration做完上线了(how)，然后呢？可以写成，现有的infra有诸多问题（why），为了解决XYZ问题，我做了migration（how），缩短了debugging的时间by X%，提高了研发速度by Y%，也提高了员工满意度 by Z% 。

如果项目最终没有上线呢？虽然确实有苦劳，但是没有上线的项目很难描述功劳，以致于对于升职加薪和职业发展这些方面事倍功半。老板或者我们自己可能安慰自己说，无所谓，至少我在这个过程中学到了新知识，有了新体验。但公司不是学校，来上班的目的不是为了学习，而是为了结果。在实现结果的过程中顺带学习当然是好的，但是为了学习而忽视结果，就有点南辕北辙了。我们要尽可能地避免这些上线风险很大的项目，要有辨别项目的能力。

这些项目有的时候是老板画的大饼，虚无缥缈的高新科研项目，除非你是大公司专门搞R&D发文章的组，大多数码农的工作还是更偏应用和落地。追求新潮的项目，看到最新算法和神经网络的文章就要试一试，大多数时候是风险很高的。很多时候这些项目也不是必要的（must have），而是锦上添花（nice to have），所以做不做得出来其实都没人在意。也许你会觉得，项目就是要创新，要高新尖，要state of the art，才能有突破。但上班的目的并不是突破，打工不是读博，打工也不是创业。公司那么多人不能人人都创新，大多数人的工作还是螺丝钉，最多也不过是造锤子，不是让你发明火箭。这些高新科研项目，我个人觉得最多花10%的时间，抱着基本做不出结果的低期待，做出来就是中奖。

这些项目有的时候是权衡利弊之后觉得没有上线的必要。这个一定程度上是不可控的，比如你做了一个新模型，A/B测试之后发现对KPI的提高不显著。这个你在线下测试的时候未必提前知道。又比如，你老板跟你说要上线一个新功能（feature），你做了几个月之后，又跟你说这个feature要无限期延迟上线，因为用户研究（user research）结果不理想。又比如，你做了一个migration的项目，快做完了要上线，发现infra组突然要deprecate一个重要的API，导致migration无法完成，被迫回滚（roll back）。这些项目，有的时候可以通过开会、确认、沟通，确保项目各方的同步，在一定程度上是可以预估项目的进展和最终上线的可能。在没有明确路线图（roadmap）的时候一定要再三确认，跟老板、PM甚至其他有潜在合作的组反复沟通，保证项目有很高的优先级。但有的时候，作为基层码农，无法左右和控制这些项目的优先级变动，这个时候只能通过多样化来规避风险。也就是说，不要把所有的时间都花在一个项目上。我的一个mentor跟我说，对比“在一个没上线的项目上做老大”和“在一个上线的项目上做小兵”，虽然前者看着光鲜，但是后者才有实打实的impact。

2. 牵头跨组项目(lead cross-team initiatives)

Staff级别的码农需要展现跨组的领导力和业务能力。跨组的前提是要对本组的业务和工作有非常深入的理解和把握，这个一般是通过在一个组工作的时间（tenure），在不同组工作的经历，以及在其他公司相关领域的工作经验积累的。时间的积累和沉淀是必要的，没法急于求成。我记得我刚升到senior的时候，就跟我老板吐槽，说我没有机会参加跨组的会议，这些会一般都会邀请staff作为每个组的代表。我老板当时说，以后随着我经验的增加，这些机会都会有的。我当时只觉得他是在敷衍我。现在想想，他说的是大实话。跨组的会每个组有一个代表出席就够了，这个人一般就是staff，因为职责所在，staff大多数时候比senior对本组的业务有更深入的了解（当然不是所有的staff都如此）。一个基层码农确实需要花很多时间积累知识，了解公司不同组的业务，认识不同的人，这些都不是一蹴而就的。就拿认识不同的人举例，我刚加入公司的时候，觉得公司几千号人，我就认识我们组的这几个人，后来随着工作时间和项目广度的增加，我认识了很多其他部门的同事，还有很多其他组因为各种社交活动认识的人。随着我项目经验和名声（reputation）的提高，我逐渐被认为是我所在领域的专家，一些问题会自然地转到我这里，我也被更多地添加到一些会议里，这些都是在我还没有升到staff头衔之前就发生的。所以，从senior到staff，确实是需要时间的积累和业务的深耕。

时间并不等于经验本身。公司里大多数senior并不会升到staff，senior到staff并不是线性的，staff并不是技术能力更好的senior。也就是说，如果你还是按照junior升到senior的套路，是不能从senior升到staff的。就拿跨组项目来说，senior也会有跨组合作的项目经历，毕竟很多产品都由前端到后端很多组共同合作实现的。但跨组合作跟“牵头”跨组项目有很大不同。牵头的工作，包括在项目立项之前跟老板、PM、和其他组的tech lead计划讨论需求，在技术的角度提供产品设计和roadmap的意见，参加公司或者部门关于tech strategy和infra的讨论，在项目开始之后协调不同组的合作，保证项目的上线。这些所谓的“牵头”工作，是在写代码、系统设计、和写设计文档之外的工作。很多staff的日常，会更侧重于这些“牵头”工作，而更少地写代码。senior在还没有升到staff之前，往往需要同时完成自己作为senior的职责（写代码），还要展现自己具备staff的能力（牵头）。这段时间可能会觉得自己同时在干两份工作，又要高瞻远瞩，又要脚踏实地。

如果觉得这些“牵头”工作对你没什么吸引力，或者觉得比起开会讨论不确定的东西自己更喜欢写代码实现已经决定好的设计方案，那么也许staff这个发展线路并不适合你。从薪资的角度，虽然staff的均值比senior高一些，但其实也高不了很多。senior的范围非常宽，很多资深的senior薪资比staff还要高。纯粹从薪资的角度，如果自己不喜欢这些“牵头”工作，我觉得没有必要申staff。

那么怎么获得“牵头”工作的机会呢？首先你要明确跟老板说，自己想要有这样的机会，让老板把这些机会给你，而不是给别人。不管是相关项目的机会，还是会议的邀请，你不表达兴趣的话，老板怎么知道你什么想法呢？有些跨组高优先级的项目，要敢于报名参加，没有必要谦让，能干就干，直接说“我想做项目ABC，我对XYZ系统很了解，也想有跨组项目的经历和影响力”。其次，可以自己发现机会，比如无中生有地提出一些跨组的项目。当然这个无中生有并不是真的从零开始，可以多跟不同组的PM、老板和码农多聊聊，看看有什么痛点，想想有什么可以实现的新功能和流程infra的改善。老板给的机会大概占90%，自己发现的机会可能不到10%，可遇不可求。所以项目机会主要还是要靠老板支持。

3. 深度+宽度技能(T-shaped skills) 

从技术能力的角度，除了工作所要求的必备技能，也建议了解其他领域的知识，比如后端学习前端，机器学习工程师学些系统开发等等。很多产品上线，都不只是一个组的工作，而是需要多个组协调合作，了解其他组的技术框架和业务逻辑，才能够更好地牵头跨组项目。此外，沟通能力、报告能力、领导力，也是在自学和实践中不断锻炼的。

从领域专家的角度，多跟PM交流，特别是其他组的PM和部门的主管PM。很多产品的优先级和上线，是由PM主导的。从他们的角度了解商务逻辑，了解公司产品的发展方向，有助于我们更好地判断自己项目的上线率和重要性，从而更好地选择项目。

4. 培养别人(grow others)

随着经验的加深、能力的提高和工作时间的增长，你会发现有时候你是组里最资深的员工。在一个项目上，你干活可能是最快最好的，比起让其他人写代码然后你给反馈（code review）再改，你发现还不如你自己马上写完上线更有效率。甚至有时候为了追求效率，连设计文档（design doc）都懒得写，逻辑和设计全在自己脑子里。组里的人有时候觉得你资历深不好意思要求你写design doc，有时候觉得你懂得多不敢质疑你，毕竟你一直干活又快又好。这种独狼（lone wolf）风格，并不是理想的staff engineer。

首先，智者千虑必有一失。就算是10倍效率码农（10X engineer），也未必没有失误。三个臭皮匠顶个诸葛亮。其他的同事干活未必又快又好，也未必比你更懂系统设计，但通过集体讨论做出的方案，通常比一个人拍脑袋想出来的要更好更全面。何况如果没有设计文档，组里的同事对这个项目缺乏整体了解，不利于知识分享和系统维护。

其次，staff因为经验丰富，很多时候要同时兼顾很多项目。如果所有项目都要亲力亲为，所有设计都要自己做，所有代码都要自己写，纵使你有三头六臂加班加点，也分身乏力。staff要对自己的时间和优先级有更全面地掌握和分配，什么时候要自己上，什么时候要委派任务（delegate)，什么时候要拒绝或者举荐别人做。一个任务，也许自己确实能做到又快又好100%，其他人做可能只能做到80%或者要花2倍的时间，但是对于项目的上线也许已经足够了。通过委派任务，staff能够把时间分配在更多的项目上，从而有更大更多的影响（impact）。

再次，培养别人是staff的工作职责之一。独狼作为senior也许没有太大问题，但是作为需要跨组协调合作的staff，是大忌。培养别人，可以是通过委派任务，或者组里的code review和知识分享报告，也可以是通过正式的mentorship项目，帮助其他组员的职业发展。如果一个staff每天都在单打独斗，不帮助培养其他组员，那这个staff是不合格的。

炫耀档案（brag doc)

在准备申请staff的这些年，我参加了公司的职业培训项目，读了关于staff engineer的书，结识了不少有相似经历的人。这其中对于我帮助很大的一个工具是炫耀档案。

炫耀档案是一个记录自己项目和成就的文档。我用的是Google Doc，没有什么模板，有点像有列表的日记。主要是记录工作专业发展相关的内容，比如项目、会议、做的报告、同事的反馈、绩效评估、培养别人等等。项目的描述侧重量化影响。文档里可以添加各种链接，比如报告的PPT、协调项目的会议记录等等。我一般会至少半年整理一次炫耀档案，跟每次的绩效评估时间一致。这个文档一方面能防止你自己因为时间太长忘记自己干过什么，另一方面能够敦促你对自己的过去进行一个小结，查漏补缺，看看是不是缺少某方面的能力和技术发展机会，是不是有太多没有上线无疾而终的项目。也可以以这个文档为参考，跟老板讨论未来的职业发展方向。当然了，炫耀档案作为记录自己职业生涯的参考，对于更新简历内容也是非常有帮助的。