Newshot 文章标题：反驳“胶水工作被认为有害”
Sean Goedecke，《胶水工作被认为有害》（此处及以下引文中的强调均为原文所有）：
那么，既然胶水工作对项目交付如此关键，为什么它不能让你获得晋升？公司是傻吗？他们是故意把价值留在桌上不捡吗？不，我不这么认为。公司不奖励胶水工作，是因为他们不想让你把它排在优先位置。他们不想让你把它排在优先位置，是因为他们想让你交付功能。胶水工作很难。如果你有能力把胶水工作做好，他们希望你用这种能力去交付项目，而不是去提升整体效率。
这是一种得过且过的论调。如果你和大多数在大厂工作过的人一样，那么你显然能看出来，他们确实把价值留在了桌上。（这是否出于故意，取决于人们心里怎么想。）大厂雇主想要的东西在很大程度上是自相矛盾的。他们想让你交付功能。他们也知道总得有人做胶水工作来维持公司运转，但他们既难以描述、也难以捕捉它的价值。
在此处以及整篇文章中，Goedecke 相当准确地描述了big tech员工所面对的一些激励机制。我对这篇文章的不满在于，他让你把这些机制内化，而不是让你记住一个更好的世界是可能的。
核心问题在于，你在替公司决定它需要什么，而不是做好你的本职工作。让你的团队运转得更顺畅，难道不是你的本职工作吗？不是！你的本职工作是执行公司领导层的使命。
如果胶水工作对领导层的使命至关重要，那么忽视它又如何服务于这一使命？
以 60% 的效率执行这一使命，好过把全部时间花在提升整体效率上（更糟的是，以 100% 的效率去执行某个别的使命）。为什么？主要有两个原因：第一，你不可避免地会燃尽，这对所有人都不利；第二，最好让你的团队习惯于以公司的基线效率水平运转，而不是人为地在短期内消除摩擦。
这里混淆了两件非常不同的事：为真正的截止日期留一些油箱里的油，这是很好的建议；而不去努力让同事的生活变得更好，则是激励机制错位的真实案例。
况且，这个前提本身就是错的：有很多胶水工作，如果你给予它应有的尊重，是能永久消除摩擦的。我在这里显然有偏见，但我认为 cargo-nextest 项目就是一个很好的例子：胶水工作（跑测试！）做得如此之好，以至于问题基本消失了。更近一些，在 Oxide 我写了一个名为 flake-review 的 agent skill，背后是我花几个小时写的一份目录1。此后我用这个 skill 修复了将近十几个测试 flake，让整个团队的生活都变好了。
那么你应该永远不做胶水工作吗？不，你应该战术性地做胶水工作。也就是说，你应该为你所领导的项目——那些你要为其成功负责的项目——做这类额外工作，以确保它们成功。你不会因为胶水工作本身而获得奖励，但你会因为项目的成功而获得奖励。对于其他项目，你只管做好你的常规工作。
带着最强烈的情绪说：去他的。只要我是最适合做胶水工作的人，我就会去做胶水工作。那种仅仅因为某个中层管理者难以说清帮助同僚的价值、你就不该帮助同僚的想法，对任何严肃的专业人士来说都应该深感冒犯。
这是一种关于如何在办公室政治中取得成功的深度犬儒主义观点吗？我其实不这么认为。大型科技公司在任何时候都以大约 20-60% 的效率运转（随着规模变大，效率会变低）。
反对“胶水工作被认为有害”
人们职业生涯中的很大一部分时间，被浪费在那些本可解决、但其价值不被组织认可的问题上。面对这种不必要的浪费和痛苦，人怎么能不愤世嫉俗呢？这让我困惑不已。
那么，这里到底发生了什么？任何超过一定规模的组织都需要可辨识性才能运转。对可辨识性的要求会把许多人所反感的东西全都拉进来：绩效评估、OKRs、KPIs 以及诸如此类的东西2。
一些大型科技公司已经想出了办法，让其中一部分胶水工作变得更可辨识。例如，Meta 拥有规模相当大的内部工具和开发者基础设施团队，这些团队的目标围绕性能数据这类可衡量指标来设定。但总会有一部分胶水工作会抗拒一切衡量它的尝试；而公司越是不关心它，就越会因此受损。
那人们该怎么做呢？嗯，取消绩效评估肯定有帮助！在我于 Oxide 工作的最后几年里，胶水工作和特性工作之间的区别已经基本消失；我反复问同事和经理的问题是“我怎样才能帮上忙？”，而不是“什么会在我的绩效评估里显得好看？”但我接受，更大的组织将需要更高程度的可辨识性。我认为所有常见的答案都适用：不要过度招聘（当然也不要激励经理尽可能多地招人），不要要求所有工作都可辨识，其余的就信任你的员工。
- 我用自己的话写了这份目录，原因有两个：一是更深入地理解我们在代码库中见过的那些测试偶发失败模式，二是不让我的同事们承受 AI 生成的垃圾文字。 ↩︎
- 你知道 OKR 和 KPI 的含义略有不同吗？在写这篇文章之前，我并不知道！ ↩︎