聊聊初级工程师如何扩大自己的impact

上一篇帖子发表后，收到了很多朋友的点赞和大米，感谢大家的支持和鼓励！想继续把这个系列写下去，分享自己的感悟和所学，也欢迎大家的建议和反馈。

今天我想聊一聊对于初级工程师而言，怎么样可以更好地提高自己的影响力，也就是"impact"。大家平日里肯定经常听这个词，想必是非常熟悉了。但是这个词又很抽象和陌生，特别是对于刚工作不久的同学， 我们常常有这样的困惑：“我就一个小小的螺丝钉，干的都是一些scope有限的活，能有多大的impact?”“好活美差都被别人抢走了，巧妇难为无米之炊啊”。

其实，在你的老板评估你的impact的时候，是以你这个级别/职级或者是将要晋升的职级为标准的。所以作为一名初级工程师，你不会因为没有给公司带来几百万几千万盈利增长或者是没有带领几十人的团队开发出一个百万日活的应用而被认为是low impact。此外，一些看起来普通的事情，如果多留心，可以发现潜在的high impact。想清楚这两点，我们就可以开始专注于从自己的日常工作中寻找提高impact的机会。

在我看来，impact简单来讲就是你的工作成果如何让他人收益。这里他人可以是客户（不管是external还是internal的），也可以是你的团队或者其他团队。越多的人收益，你的impact就越大。那么我们从哪些方面着手呢？

1. 养成data driven的习惯，用数据支撑你的成果和引导你发现潜在的机会。现在大家都喜欢摆数据，因为数据就是最好的证明，所以我们要特别留意在项目过程中寻找可以帮助量化我们的成果的地方。举个例子，你为你们组负责的web app写了一个新的feature，即使代码已经成功部署了，你怎么知道这个feature在多大程度上帮助了用户呢？你花了一个月时间写的feature会不会根本就没达到你们预期的效果？这就要求我们在开发过程中在重要的地方插入日志和metrics追踪，同时设置好对应的监控。这样我们可以很容易量化impact，比如这个feature平均每天有xxx用户使用，错误率稳定保持在xxx%以下。如果这个feature使用率很高，那是最好。但即便效果不好，你也可以通过数据去分析原因和思考下一步的行动，最终达到一个理想的结果。当你给老板汇报时，这比单纯的“实现了某某feature”有说服力得多。当然有的feature一旦完成，本身就是一个很大的impact，比如一些核心产品的新功能成功上线。但是背后的数据可以进一步放大impact，毕竟好的数据往往对应着着更多的用户和利润。类似的，你写了一个新的wiki，你不能只是在群里吼一嗓子说“Hey朋友们我写了一个wiki”, 你要有针对性地“推销”给其他同事，甚至是其他组并确保他们有应用。这样你的成果就可以被量化为：在解决某问题时，该wiki被X个人，Y个组使用。

2. 在Livesite (on call)上下功夫. 很多人讨厌oncall，认为它耽误了自己做开发的时间（还有睡觉的时间），但其实oncall是一个提高自己visibility和impact的机会。毕竟对初级工程师而言，相当一部分的开发任务是limited scope，也就是说本身的impact就相对有限。这种任务基本就只有你和你的老板知道context，有时甚至你的老板都不咋知道，自然难以凸显你的影响力。但当你oncall，特别是Sev 2时，你有机会接触到更多的人，特别是当周的incident manager。对于涉及多个service的ticket，你还可能接触其他组的oncall engineer，而且他们中往往会有更senior的人存在。如果你能很好地处理这些ticket，你会给他们留下好印象。你自己的组就更不用说了，每个老板都会特别关注livesite的情况，这也是整个团队日常工作中非常重要的一环。等于说你oncall中的任何亮点，从熟练处理Sev 2，到增加新的监控，优化日志都是直接影响你的团队。如果还需要涉及到和其他团队协作，那更是cross-team impact。我自己以前就不是很专注oncall，每次有问题都是想着能基本解决就行，后来promotion的时候我老板和我说其他的manager反映我在livesite这一块没有给他们太多印象，所以建议我在这一块继续加强。

3. 总结你完成的项目并分享给团队。随着你经验的增长，老板会开始分配给你更有挑战性的任务，这种任务的一个主要特点就是有open question，没有一条clear path去完成，需要你自己摸索。在这个过程中，你会有一些亮点，也难免会犯一些错误，走一些弯路。如果你能够把这些记录下来，当任务完成之后，你就可以很快对其进行总结：什么做得好？哪些地方需要改进？是什么原因导致了这些问题？以后如何规避这些问题？在这个不断dive deep的过程中，问自己这些learnings能不能让我的团队受益？要知道，很多你遇到问题往往能反映团队存在的问题，如果你的经历可以给团队带来启发和改进，那么这个impact就相当可观了。我之前做的一个项目就存在partner API 交代不清楚、在没有完全理清楚unknowns和mitigation plan之前贸然开始代码实现的问题。项目结束后，我发现组里虽然提倡写design doc，但是对于如何写，哪些因素需要考虑没有明确规定。于是我总结出了一份design doc的模板，里面列出了在设计阶段需要考虑的常见问题。同时我还写了一份postmortem进一步总结整个项目过程中我们的亮点和改进机会。这些成果也被我的老板推荐到我们org的demo day中展示，受到了很多其他manager的好评。之后也一直在被组里采用。整个项目的impact和visibility就被进一步放大了。

4. 做好communication。抓住项目中report/presentation的机会，因为领导不会那么了解fancy的设计模式或者高级的算法，他们在乎的是进展和结果，而这些直接从communication中体现出来。如果你是那个作报告的人，那么和领导直接沟通的就是你，那自然对你有更深刻的印象，认为你在积极drive这个项目。我们在做好幕后的代码实现的同时，也要敢于承担台前的角色。我们常常对那些只说不做的人嗤之以鼻，但其实说和做并不矛盾，那我们能不能试试一边说，一边还把事情做了？

5.  多与别人交流，不要闭门造车。每个组都有自己的问题，不管是技术上的还是管理上的，但同样的问题在其他组可能就处理得很好，如果我们注意平时的积累，不断扩大自己的圈子，和更多的同事建立联系，我们可以得到很多知识和启发。如果可以应用到自己的组，那对我们自身就是一个很好的机会，因为如果你的点子得到了老板的支持，你很大概率就会成为那个drive的人。此外，这些来自他人的先进经验可以极大提高你自己项目的完成质量，因为你可以直接奉行“拿来主义”，而不用自己重复造轮子。做出来的东西又快又好，以后自然会得到更多机会。

如果你很幸运在一个核心组，有一个牛逼的老板，总可以拿到high impact的活，那么恭喜你已经赢在了起跑线上。但是如果你没有这样的运气，也不要灰心。做好你能控制的事情，积累自己的知识，扩展自己的人脉，多发现，多思考，或者多刷题也行^^。机会往往会青睐有准备的人！

其实最主要的就是做好本职工作的情况下多跟人聊，机会都是聊出来的，尤其跟组里的老板和TL明确表示要更多scope一般都会愿意培养..我作为TL就喜欢下面人要更多活

写得很好，机会都是聊出来的。
对第二点的补充就是junior不要害怕去做脏活累活，在debug的时候去逐渐熟悉自己组own的service/repo，尤其是legacy的东西。就像交朋友，你对它们越熟悉他们就会越帮你，你就越清楚哪里可以做优化，pm让你去实现一个功能你知道在哪里加最好。慢慢的慢慢的你就变成这一块的togo person了，来找你的人多了机会自然也多了。然后慢慢从自己组的service扩展到兄弟姐妹组的再到整个公司的，你的scope和impact就会越做越大。

讲的不错，说的含糊一点，就两点，1.把活干的踏实一点 2.让别人看到

说的好好 谢谢楼主

希望能留美的猫 发表于 2022-9-17 11:53
说的好好 谢谢楼主

谢谢鼓励！

匿名用户 发表于 2022-9-17 07:38
其实最主要的就是做好本职工作的情况下多跟人聊，机会都是聊出来的，尤其跟组里的老板和TL明确表示要更多sc ...

是的。多和人沟通，不要只一门心思干自己的活。

提高能力，impact是side effect

很不错，收藏了

感谢分享！