“10x 工程师”：如何让身边 10 位同事效率翻倍？

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：人人都想要战斗力超强的工程师，也就是所谓的10x工程师。但是究竟什么是10x工程师呢？是完成任何任务都比别人快10倍的工程师吗？还是能让10位队友效率提高1倍的工程师？Ofer Karp根据自己管理团队的经验，提出了两种类型的10x工程师。看看这是不是你们所需要的10x工程师。原文标题是：Playmaker: The Reality of 10x Engineer

“我们要踢得像个 整体，我们要成为一支真正的团队，要想走得远，这是唯一的办法”（弗朗西斯科·托蒂）

有时我挺为我们的招聘团队感到遗憾的。他们花了很多年的时间想要找到摇滚明星式的开发者，到头来才意识到自己应该要找的开发者其实是忍者。当他们终于找到忍者开发者住的地方并学会说忍者的语言时，他们的目标又一次转移了。现在，他们的猎物是所谓的10x工程师。但是10x工程师究竟是什么？怎么才能认出这样的人？

如果换个方向来看的话，作为软件工程师，如果有那么多的雇主都在找10x工程师，而且有些人还愿意开出5倍甚至更高的薪水的话，自然谁都会想要成为其中的一员。但是10x工程师究竟需要具备什么呢？是不是有特定的技能集或者某种“10x标准”？

定义x：

我是个10x工程师,x是指我原先的估计

如果你问猎头公司10x工程师是什么意思，他们可能会说“生产力！10x是指完成任务比别人快10倍的工程师。”听起来不错，但是在支付5倍薪水之前，我有两个简单的问题想问一下：

1. 当我们说“快10倍”的时候，我们的基准是什么？我们在跟谁进行比较？

2. 这个“快10倍”是指团队的任何任务呢，还是指特定任务？

不要误会我的意思。我的确相信，会有能够对我们的产品、我们的团队乃至于最终对我们的业务产生巨大影响的软件工程师。在某些情况下，有没有这么一个独一无二、才华横溢的工程师会是成败的关键。我就看到过这种情况，我会在本文分享两个例子。我也可以分享一下自己的经历，作为一名团队规模颇大（目前在WalkMe，我们有200多名工程师）的工程经理，我把大量的时间都用在寻找有才华的工程师，并帮助他们做出最佳的职业决策，也就是加入我们的团队上面的故事。但是我要找的不是完成任何任务都比别人快10倍的工程师。我要找的是另一种魔法。

“妈妈说这是我的魔法鞋子，它们能带我去任何地方”（《阿甘正传》）

有两种10x工程师：

我的看法是，有两种类型的10x工程师。我会解释我的理论，而且更加深入地研究这两种类型，我还会给出具体的例子，都来自我一起共事的人以及我带领的团队。

首先，我要说这两种10x工程师都很有价值，大多数工程组织都需要这两种人。要我说，在这两种类型的10x工程师里面你会找一些共同的性格特征和行为模式。但是就他们卓越之处而言，这是两种完全不同的类型。

类型＃1：广而浅：

让我们回到2012年。当时我还在HP工作，带领研发小组进行一款名为UCMDB的产品的研发。这款产品的主要价值主张是为运营人员提供他们所维护的基础设施以及应用拓扑的近实时的画像。

我们收集和存储的数据非常有价值，唯一的问题是，要想让这些数据真正发挥作用，用户必须既是图论专家，又要对我们专有的数据模型有深入的了解。实际上，这条学习曲线太陡峭了，以至于我们大多数的客户最多都只有3个人懂得对这些数据进行查询。所有其他潜在的数据用户都必须“提交请求以获取UCMDB视图”，并等待那3位尊敬的管理员为他们做好准备。对于使用实时数据来说，这可不算很有效的办法。

UCMDB原先的查询生成器

后来，我们试着对查询语言进行简化，并进行一系列外观精美的UI更改，但这些变更尝试都失败了，最终也没法让更多的用户熟悉这款非常高级的应用的使用，于是我们决定换个方向：

• 我们现在的应用过时、笨重（庞大的java applet），只能在性能强劲的桌面机器上使用，与其这样，不如改成可以在任何设备（包括平板电脑和智能手机）上运行的现代的、轻量的Web应用。

• 我们希望实现一种基于自然语言搜索的简单查询创建体验，而不是基于有向图模式匹配的那种超复杂的查询创建体验。

• 相对于原来有多个选项卡以及庞大结果表的老式的查询结果使用界面，我们希望用一种更现代界面，只呈现重要的数据点，然后帮助用户进行导航以及析取更多的信息。

• 我们希望能够持续发布新功能并缩短反馈周期，而不是原来那种缓慢的发布周期（每6个月一个版本）。

UCMDB浏览器（又名“Mitzi”）

但是，怎么才能做到这些呢？我们的目标不是向市场推出那种渐进式改进的产品，而是改变游戏规则的那种功能，这会让我们的产品适应新的用例和角色。显然，这样的计划要想取得成功，我们就不能还采用在产品其他领域所采用的技术栈、体系结构和开发方法。我们需要完全不一样的东西。

这就是“广而浅”的10x工程师大放异彩的地方。在组建一支全功能的团队之前，我们给他分配了一项任务，那就是搭建新应用的框架。现在我知道这听起来会有些奇怪。一个人怎么能成为这么多领域的专家呢？但是实际上，大约4周后，我们就有了一个不错的应用框架，里面包含了一个搜索引擎，可以把自然语言的搜索词转换为现有的拓扑查询，还有一个简单的开放了RESTful API的后端，以及一个基本的Web前端（用GWT实现，这在当时还是很不错的东西）。所有这些都用很好的CI / CD工具打包好，还有一个测试框架（单元测试，组件测试，E2E测试），基本上都是用适合我们持续交付要求的思路和工具搭建出来的。

由10x工程师搭建的此应用框架还没有为生产做好准备。不应该是这样的。但这为整个功能开发团队提供了一个很好的起点。搭建框架的10x工程师可不只是把东西丢给团队就了事。相反，他之后便成为了团队的一部分。此时，他的任务是提高不同团队成员对他选定的技术栈和架构的熟悉程度，让他们成为专家和产品的主人。一般来说进行一对一的会议最好（这样可以根据每个团队成员的领域专业知识和技能组合量身定制）。

我们在做UCMDB的时候，这种做法就非常有效。我们的团队迅速成长起来。他们接受了应用框架所采用的众多想法和方向，同时也做出来一些改变。对于某些团队成员而言，这是学习新技术的机会，而由一位经验丰富且充满才华的工程师进行指导更为重要。经过由8名工程师组成的团队3个月的专心工作，我们面向市场推出了一款名为UCMDB Browser的新产品。无论是从业务角度还是从工程角度来看，这个产品都是一个巨大的成功。

类型2：专且深：

在众多致力于成功产品和快速发展业务的工程团队当中，我发现他们都有一种共同的模式。这种模式很难解释清楚，但通常的情况是，产品的某个领域曾经是你的优势之一，甚至是跟竞争对手不同的核心差异化所在，但却慢慢变得难以支撑和维护。在很多情况下，你很难识别出这种模式，并且承认这发生在你身上，尤其是对一直以来都是团队一员的人来说。但是，当在分析如何分配资源时，就会意识到团队很大一部分人（开发人员、支持工程师、专业服务工程师）正在花费大部分时间去维持过去曾经是核心产品优势的东西。

在我目前的WalkMe团队里面也出现了这种模式。我们平台的优势之一就是能够以高效、可靠的方式识别托管应用（运行WalkMe的应用）的GUI元素。

成功就会壮大规模。更多的客户、更多的数据、更多的用例。在GUI元素标识领域，会增加复杂性的因素是支持新的UI技术（单页面应用、Shadow DOM等）的需求以及支持高度个性化应用的要求，针对不同用户展示的GUI可能因用户的角色、所处的地理位置或偏好而有所不同。我们的“Find Element”模块足够灵活，可以满足这些要求，但是让这台机器维持运转所需的工作量正在逐渐（但不断地）增加。

“也许时间给煤炭下的定义是钻石”（纪伯伦）

识别出这种模式当然很好，但是怎么搞定才是真正重要的事。我们知道，我们需要开发下一代的GUI元素标识解决方案。主要目标是提高元素识别的准确性和健壮性。最重要的是，我们需要的解决方案不仅可以识别单个UI元素，还可以理解上下文并发现应用的用户流。就像在“泛而浅”的例子一样，很明显，这并不是对现有产品的渐进性改良，而是要完全替换掉我们产品的核心引擎之一。

但是，当汽车在全速行驶的时候怎么才能更换发动机呢？这就是10x工程师可以发挥巨大作用的地方了。实际上，在我们的案例里，是2位10x工程师。这一切都始于我们对一家名为DeepUI的小公司的战略性收购。被收购的这家公司并不是专门开发WalkMe所需的那种东西的，但是开发出DeepUI的2名工程师是用机器学习来理解GUI的顶级专家。

下一阶段是研究。分析现有的解决方案，并了解其在不同用例下的表现。这是为了定义新的解决方案的“最低需求”，整个过程可能需要几个月的时间，具体要取决于系统的复杂性。只有这样，你才能设计出新的解决方案并开发初步原型。跟所有的“替换引擎”项目一样，能够在生产环境下基于实际数据跟现有解决方案并行运行的新解决方案具有巨大价值。这是验证新解决方案的优缺点的最佳办法。显然，开发出这样的解决方案并不容易，但这正是你需要10x工程师的原因。

然后就进入到真正棘手的部分。你已经成功对新解决方案进行了验证，现在你希望把这个产品化，然后开始把客户从旧解决方案迁移到新解决方案。为此，你必须搭建一支团队。突然之间，十x工程师需要从研究人员和开发人员转变为领导者。这可不仅是一般的领导者，得是超级领导者。在工程组织可能会参与到的所有类型的项目里，这是最复杂、风险最高的项目类型了。要更换产品核心引擎？是的。引入新范式（ML）？是的。对公司多个团队（研发、支持、服务）的日常工作有影响吗？是的。

怎么才能完成这种切换并建设这样一支团队呢？我认为不存在什么秘诀，而且找到能够做到这一点的人真的很少。在我们这里行之有效的一件事是，让负责旧解决方案团队的人员进入开发新解决方案的新团队。这之所以行得通，是因为这些人都是领域专家，并且他们了解新解决方案的巨大价值。他们也最清楚从旧解决方案迁移到新解决方案都需要些什么。最后，对于他们个人而言，这是跟能力很强的工程师合作并学习新技术的机会。归根结底，这一切都与人和领导力有关。只有在他们设法组建起一支能够确保新解决方案支撑规模生产环境的强大团队时，做项目的工程师才会成为10x工程师。

在我们这里，这种组织机制工作得非常好，现在我们有一支由30名工程师组成的团队在做DeepUI。现在这个解决方案已投入生产，我们正在努力利用它的潜力去开发其他用例。

“在研究人工智能之前，为什么不对天然愚蠢做点什么？” （Uny Splash ）

对人10倍的影响：

尽管这两种类型的10x工程师出色之处很不一样，但他们有一个共同点：两种类型的10x工程师对团队的其他人都具有巨大影响。他们是这么做的：

1. 榜样：其他工程师都希望像他们一样。当然，首先是希望能拿到一样的薪酬待遇，然后进一步发展到对技术决策的影响。10x工程师的存在证明了作为一名优秀工程师，你不需要成为经理也可以有另外一条晋升之路。

2. 标准：由于其他工程师也希望像他们一样，所以会努力去复制10x工程师的专业知识并遵循他们设定的技术标准。你会发现大家其实是在跟随他们的领导，阅读他们的代码，采用跟他们一样的设计模式，用相同的方式去写测试，像他们一样记录和展示自己的工作，等等。

3. 指导：只有同类最理解彼此。10x工程师非常善于发现有成长潜力以及能够成为专家的初级工程师。只需轻轻在后面推他们一把，每一位10x工程师都可以成为至少一为有才华的初级开发人员的出色导师。

“对我来说，在罗马拿到一个联赛冠军比在尤文图斯或者皇家马德里拿到10个冠军都要值得”（弗朗西斯科·托蒂 ）

结论：

10x工程师在现实当中确实存在。 作为经理 ，找到对你的团队有十倍影响力的工程师需要时间和精力，但这是值得的投资。一个超级有才的工程师可以让整个团队变好10倍，这就像一位超级天才的中场组织者就能带领一支水平一般的球队拿到联赛冠军一样（编者注：想想马拉多纳跟那不勒斯队）。

作为一位工程师，成为10x工程师是有可能的。你可以走“泛而浅”的路径，也可以走“专且深”的路径。不管你走哪一条路，这都是一段漫长的历程，所以，务必要选择你真正喜欢的领域。最后但并非最不重要的一点是，始终都要记住，这不仅关乎你拥有多少知识，或者作为开发者的执行技能如何。成为10x工程师还意味着领导其他工程师的能力，能让他们变得更好的能力。

译者：boxi。