不要成为瓶颈

本文是翻译,版权归原作者所有



你们团队是否有这样一位工程师,人们常常向他咨询某种问题?或许他是团队的高级工程师,编写了绝大部分代码库。或者,他是技术领导或管理人员,参与大部分设计方面的讨论,甚至很多项目中因历史原因形成的逻辑依据。或许,他是负责特定系统的核心人物,有着多年运作这些项目的经验。

我们常常被鼓励成为给人们解疑释惑的重要工程师,我把这种角色做为我们提供给团队的价值标识。像 Google 之类的公司,这部分能力甚至和晋升过程挂钩:那些初级工程师,成为了负责关键项目的核心工程师,经过论证后,常常更容易得到晋升。

这种鼓励看起来十分合理。根据供求关系,工程师的相关技能和知识越稀有,他或她对于团队的价值就越大。因此,成为很多项目核心人物的目标,貌似是合理的,对吧?

不幸的是,这种稀有的思维模式只能让我们更远地偏离轨道。

你对时间的把控决定了你的影响

当你步入太多项目的关键路线时,这种思维模式的问题就涌现了,对于激增的问题,你成为人们咨询的唯一人选。如果一个高优先级的 bug 被提交,你或许是留意到它的第一个人。如果产品经理对于某个功能的运作原理有疑问,你或许是唯一能够解答的人。如果另一名工程师需要对某个系统征询建议,你或许是他或她唯一能够提供咨询的人。在这些情况下,当你成为第一道或唯一一道防线时,那么在你能够有效利用时间方面,你就失去了灵活性。你的日程受制于外部因素,这限制了你所能创造的价值和影响。

这种问题不是寻常的,你越是资深,它就越严重。硅谷创业公司的一名早期工程师,给我分享了一下,他的多年经验使他赢得了对公司大部分 web 栈的精通。很多人认为,他的技能和经验将让他负责公司有影响的项目。然而,他经常被其他团队咨询,被各种问题轰炸,当起了救火队员。他看起来热爱公司和这份工作,他感到了倦怠的风险。在公司,他的经验已经变成咒语,他已经变成了很多项目的限制因素。

另一名工程师是 Google 的技术领导,就如何更好地帮助团队里那些给她发送代码审查的初级成员,寻求建议。她明白,尽快提供反馈将有更大影响——越早地应付糟糕的设计选择,意味着她的同事在深入错误的路途中就少花些时间。根据她的经验,她也明白,她是最适合给出有价值反馈的人选。但同时,做为代码审查的角色,阻碍了她在领导团队的其它方面投入时间:确认她的项目进度、检查同事有着正确的优先级以及搬走他们路上的所有拦路虎。她的资历让她成为了瓶颈。

任何时候,当你成了熟知某个系统的运行原理、或者负责某个项目的核心工程师时,你将蒙受一种间接税【注1】。根据专长或技能,你就处于帮助解决未来问题的位置。这种责任常常是软件开发不可或缺的一部分——每次,你自己开发了一些新的东西,你就开始成为了解该项目的核心工程师。有时候你或许从中学习、或如此地享受这种经历,以致于你想承担这种责任。这很好。

但是随着时间的推移,如果这种知识停留在你的脑子里而不和团队分享,它就会成为阻碍。如果一个让人激动的新项目启动了,你会被视作有影响力的人吗?如果你想尝试不同的东西和学习新东西,会怎么样?如果你的所有时间被用在了对增长的 bug、客户请求和各种项目其它问题的响应,你就剩不了多少时间专注在其它有影响的任务上了。你能创造的价值和影响将开始处于停滞状态。

那么,我们该怎么做才能避免自己陷入这种状况呢?

让你自己脱离关键路线

我谈到的两位工程师本可以更好地把某些责任委托给团队成员。最终,下面就是我给出的建议。

用你的时间选择做什么的能力,对于增加你的长期影响力,是至关重要的。为了增加你的灵活性,对于熟悉某些软件的操作方面,你可以主动采取以下步骤,减少你成为核心工程师的情形。你处于交互模型的辐射中心,每个人必须通过你来做出决定,你要缩小这方面的安排。

如果你成为瓶颈的情况是技术上的,就尽可能地自动化。比如,你可以这样做:

另一方面,如果你是瓶颈的主要原因在于你和团队其他人之间的技术差距,就要投入时间来弥补。根据下面策略,和更多人共享所有权:

当工程师步入大量项目的路线,债务变成了相当大的负担时,有时候他们会倦怠。或者他们觉得,赢回他们时间的唯一方式就是换个团队、甚至换家公司。

不要让这种结果发生在自己身上,赢回属于你的时间。

该谈谈你的看法了:你今天成为瓶颈的状况是什么样子的,为了让自己脱离关键路线你能迈出的一步是什么?在下面的评论分享你的答案吧。


译文:不要成为瓶颈 》| 腊八粥