我，技术不过硬，但是团队里的重要“胶水”

从事辅导、编码和咨询工作已有三十多年的 Daniel Terhorst-North 曾赞扬 Tim Mackinnon 是他见过的“最好的程序员”，但几年后又称他为“最差的开发者”。为什么同一个程序员可以同时获得“最佳”和“最差”两个极端评论呢？

零绩效的“最差开发者”

千万别想在一套复杂的自适应系统中确切描绘独立个体的贡献度，因为这个问题在前提上就站不住脚。

用生产力指标来衡量开发者，好处就是能快速揪出那帮差劲的程序员。当时，Daniel 和 Tim 在一家大银行做软件咨询工作，当时公司打算引入个人绩效指标来“评估和规划个人发展”。

与之前考核代码行数或者 Bug 发现量这种“程序员总能找到一万种方法把绩效垒得高高的”方式不同，这次团队决定衡量大家“交付的故事”、或者叫“故事点”，借此反映真实商业价值。

“之前我们曾经引入过 Jira 等新技术，就有员工在绩效报告里列出一长串技术名称，轻松得到看似漂亮、其实并无意义的高评分。”Daniel 说道。相反，“Tim 这老兄的评分一直是零……没错，啥也没有。这不只是低或者下降的问题，而是‘无绩效’。一周又一周、一个项目又一个项目，Tim 始终‘没有存在价值’”。

看起来，Tim 应该马上被踢出公司。当时的经理也认这么认为，因此要求 Daniel 安排 Tim 离职，让那些真正能讲好技术故事的人顶替接管。但 Daniel 断然拒绝了，“这对我来说根本不算什么艰难的决定。因为我知道，Tim 非常优秀。”

Daniel 解释道，Tim 的生产力得分之所以是零，就是因为他从来不关注任何故事。相反，他会花一整天时间跟不同的同事对接。对于经验不足的开发人员，他会陪伴他们完成任务，引导其找到解决方案。他既不过度施压、也不随时催促，而是给他们认真学习的时间，同时精心设计考察方案和检验节点。而这种测试往往采取“苏格拉底式”的启发问题：如果 xx，该怎么办。

对于资深技术人来说，这其实是种在讨论中协作的过程。大家各自用不同的观念来尝试解决问题，从而创造出超越自身局限性的成果。Tim 是位出色的程序员，跟他合作总能让我们学到新的东西。

换言之，Tim 交付的并不是软件，而是善于交付软件的团队。整个团队变得更高效、更有生产力、更协调、更从容也更有趣，而这一切的核心就是 Tim。

Daniel 向经理讲明了事情原委，并邀请他定期过来观察工作过程。这个经理突然现身时，总能看到 Tim 在跟不同的员工坐在一起，帮助他们完成“手头的活”。不用说，有 Tim 参与的工作总能做得更好，评估周期也会相应缩短。“Tim 就是这样，如同一种神奇的质量、速度和成本催化剂。”

最终，公司留下了 Tim，并悄悄撤掉了个人生产力指标，转而考核团队责任。Daniel 表示，也很庆幸能有这样一位“神人”，“帮助我们作为统一的高绩效单位为整个组织做出贡献。”

如果你的职位是“软件工程师”，但你似乎大部分时间都在开会，一旦你想抽出时间编码，那就意味着没有人来培训初级工程师、更新路线图、用户交流、注意被忽略的事项、对设计文件提出问题，并确保所有人大致朝着同一个方向前进了。如果停止做这些事情，团队将不会那么成功。

实际上，你可能在一个不那么技术性的角色中会更快乐。如果是这样，那么恭喜你，你就是团队的“胶水”。如果不是，那你团队中的谁在担任这个角色？

不被重视的“胶水工作”

编码毋庸置疑是软件工程团队中的一个重要技能，但我们还需要很多其他技能，这些技能可能是一个项目成功和一个项目失败之间的关键。

比如，注意到团队中其他人遇到了阻碍并帮助他们解决问题；或者审查设计文件并注意到哪些地方被忽略了或出现不统一；或者帮助新人入职，使他们更快地提高工作效率；或者改进流程以让客户满意。所有这些工作可以被称为“胶水工作”。

这是技术领导力的一部分，有时团队中会有一些不是资深工程师、但恰好擅长这些工作的人。这种工作让团队变得更好。我们以软件工程师 Bobby 为例来看看这些人如何做“胶水工作”的。

Bobby 已经大学毕业几年、拥有两份技术工作的经验，虽然对自己的技能不是特别自信，但他很喜欢这份工作。刚加入新团队时，新的代码库非常复杂，Bobby 第一次修改花了很长时间。这是正常的，但每个人都忙于自己的工作，没有人来安抚他。Bobby 觉得自己进展太慢，需要太多帮助。几周后，他担心自己过不了试用期。

后来，Bobby 取得了第一次胜利。一个客户提出请求：他们需要的数据应该由 API 提供，但团队尚未将此功能放在优先级列表中。Bobby 花了几天时间手动获取了客户需要的数据，客户感到非常高兴。他记录了如何获取这些数据，以及团队经常被问到的其他问题的答案，团队也不再频繁受到干扰。

过了一段时间，Bobby 开始与附近的团队成员交流。他们对一个问题的解决产生了分歧，Bobby 就与其所在团队的系统设计师开会，并提出了许多问题。事情开始变得不同：他们开始达成共识，构建出了更好的东西。他还将会议笔记发给大家，以确保每个人都对达成的共识有共同的理解。

后来，有新人加入团队。Bobby 记得自己刚刚加入时的艰难，因此撰写了大量的入职文件，同时建立了导师制度，以便所有新人都有人带。

有段时间，公司常常因为代码库中缺乏测试发生系统故障。Bobby 就召集了一群资深人员，不断推动他们就整个组织的编码标准达成一致。现在，所有代码都会经过测试，更易读、更加可靠。由于代码风格一致，代码审查变得更快。

诸如此类，大家都说 Bobby 是个出色的程序员。

实际上，组织中的每个人都应该看到那些让团队成功所需要的不那么“光彩”和不太容易晋升的工作。如果有意识地管理，“胶水工作”可以展示和建立强大的技术领导能力。如果不自知，它可能会限制职业发展，把人们推向不太技术性的角色，甚至使他们离开这个行业。

事实上，过早地从事胶水工作可能会限制职业发展。这是具有讽刺意味的：我们失去了优秀的工程师，因为他们恰好擅长我们需要的其他技能。

就像 Bobby 两年过去了，他一直发誓要尽快写更多的代码。但每一天都会有更重要的事情出现。团队开始将 Bobby 视为非正式领导。他对团队正在发生的一切了如指掌，但他的“硬技术”能力没有显著提升，“编码两小时然后去开会”让他感到非常痛苦。

不过他并不担心，因为每个人都说他的工作多么出色，他也总是得到出色的绩效评价。事实上，他觉得自己已经上升到了一个新的层次，他也想要得到晋升。

但是，这家公司似乎认为这种“胶水工作”不足以获得晋升，至少不在这个级别。尽管他们没有明确说出来，但他们确实希望看到代码或其他可量化的技术工作。而 Bobby 的经理从未告诉他，他做了太多的非晋升性工作。也许经理只是庆幸胶水工作得以完成，因为确实需要有人去做。

非晋升性工作是那种 “一个人的垃圾是另一个人的宝藏” 的事情。比如，如果一个工程师组织了一个团队活动，那么这就是他的非晋升性工作，但如果是一个行政人员这样做，那这可能就是他的核心工作。

“胶水”升职只能靠转岗吗？

对于 Bobby 的困境，有人建议他转向另一个可以将这些工作视为晋升的岗位。

“你能处理反馈吗？你喜欢指导吗？你喜欢与人打交道吗？如果是，那么你应该成为一个经理。你能站在客户的角度思考吗？如果是，那你应该做一个产品经理。”改变职业是常规解决方式，好像有能力做某事就意味着你必须去做它。

但实际上，如果你编写代码，你会变得更擅长编写代码。如果你管理人员，你会变得更擅长管理人员。所以，你想要变得更擅长什么？

Bobby 或许应该基于以下因素，有意识地选择：

• 希望在哪方面取得进步？
• 哪个工作会让他感到幸福和自豪？
• 哪些职业选择会让他感到舒适，即使难以重返之前的道路？
• 他在哪里会感到安全？

很多人不考虑他们想要的岗位，是因为他们觉得自己还没有掌握那份工作所需要的全部技能。比如很多计算机专业的大学生因为自己不是优秀的程序员就不申请编程工作，最终选择一个他们不想要的岗位。

这里，建议人们要有意识地选择。选择一个让你感到成功、幸福和自豪的工作，同时教会你想要学习的技能。通过实际做这份工作，你会逐渐变得擅长它。要知道，大多数情况下，我们不会在第一天就能做好一份工作，绝大部分的学习都发生在工作中。

然而，还有一个考虑因素，特别是当人们在大学或初入职场需要做决策时：离开更技术性的角色意味着会拒绝一些机会。

这不公平，但行业偏见设定得很明确，你在转向非工程角色之前真的需要有坚实的工程履历。因为一旦你放弃了工程师头衔，一旦你简历上的“最近工作”没有 “工程师” 这个词，行业中的一半人会假定你的技术技能“永远消失”，不可能再获得新技能。这是一种非常常见的潜在偏见。特别是如果你的职位名称包含 “项目经理” 等，许多人会立刻认为你不擅长技术。

谷歌云产品运营的传奇总监 Kripa Krishnan 曾经说过，尽管他因为性别和口音而在行业中经历了一些偏见，但与作为技术产品经理而经历的偏见相比，那些都不算什么。

“项目经理”和“技术产品经理”经常被“工程师”给比下去。很多人选择前面两个岗位后，会发现自己被推向了“非技术人”的角色，这是离开行业的第一步。有些人想再回到工程师岗位时，也无法以之前的作为开发者的水平被雇佣，因为人们不相信他们有能力胜任这份工作。

实际上，“不够技术”的印象非常笼统。你大可以具体说明需要他们掌握什么，比如：“我们的高级工程师都是系统设计师。请学习一些分布式系统课程，并对 CAP 定理有自己的见解。”否则只是在设置门槛，而不是提供有建设性的反馈。

给“胶水”相关人员的建议

经理们，如果你的职业晋升路径不要求你的高级员工具备 “胶水工作” 技能，那么请考虑一下你期望这项工作如何完成。 “胶水工作”的员工们，对于要求你做更多非晋升工作的请求表示拒绝，并将你的努力投入到你想要提高的某个领域。

胶水工作是项目成功与失败之间的关键因素。这就是为什么技术项目经理会产生如此大的影响：他们扮演着最重要的“胶水角色”：发现问题并加以解决。在没有项目经理的团队中，经理会承担这个角色。在其他团队中，这项工作会分散到愿意承担的人或被期望志愿承担这项工作的人身上。

如果你是“胶水”，你应该怎么做？如果你正在管理一个“胶水”人员，你又该怎么做？如何确保不浪费这个宝贵的技能组合？以 Bobby 为例，下面是一个四步计划：

第一步，这位工程师和他的经理进行一次长期拖延的职业对话。他需要直接提出问题，比如 “下一轮我会被提拔吗？”、“我需要做什么工作才能晋升？”、“这是否是高级工程师的工作？”基于他们对职业阶梯的理解，他的经理也需要诚实和直接。

这一步，他们需要达成一致的目标、制定计划，并在一段时间后进行检查，确保他们仍然在正确的轨道上。

第二步，职位头衔。如果他和他的经理希望他继续做大量的“胶水工作”，那么是否有一个能让他在技术上获得信誉的职位头衔？他可以成为技术负责人或其他什么职位吗？人们通常期望技术负责人承担大量的“胶水工作”。

可能有些人认为职位头衔无关紧要，但这并不意味着其他人不需要。职位头衔可以节省我们花在摆出自己资历上的时间和精力，还可以使人们在认为 “不够技术” 后继续做“胶水工作”。

第三步，Bobby 需要展示他的工作成果并介绍相关文档，“正因为他的工作和技术判断，这个事情才发生了。”

他的经理应该讲述同样的故事，一个胶水角色是某事成功的唯一原因，要公开表扬他们！Bobby 应该创建并保存相关设计提案、会议记录、团队邮件、推动事情发生的关键时刻等。

但是以上步骤可能仍然不奏效，也许六个月后，晋升决策者会再次说“不”。在这种情况下，有一个有点愤世嫉俗的解决方案：如果你因胶水工作而未被晋升……那么停止胶水工作，暂时完全按照职业晋升阶梯上的工作来做，即使这意味着放弃更重要的事情。这一决定的前提是你想要晋升。

Bobby 应该完成一些容易量化的技术工作，不要再担任非正式领导的角色。编写大量代码、编写一些任何人都可以编写的设计、学习如何性能调整数据库，做一些毫无争议的 “技术” 工作。

这意味着他必须停止做其他工作，编码无法融入胶水工作的满满日程中。关键是，不要托底那些即将失败的事情。

如果你希望拥有的技能是你整天工作的一部分，你将免费获得一定程度的学习。每次你查找 Stack Overflow，你都会学到一些东西。但对于没有重复做的任何事情，你必须主动去学习。即使是那些因胶水工作而受到认可并且想要继续从事的人，建议你们不断提高其他技能。

如果你只做胶水工作，你只会变得更擅长胶水工作。你让你的团队更有效率，但同时也伤害了你未来的自己。无论你最终要做什么，你都不太可能后悔在核心技术技能方面更加自信。