为什么你要替别人把工作做完
Doing Everyone Else's Job
我发现，能替别人把活儿干了非常有用。这不仅帮你理解他们的工作逻辑和需求，更能在他们不愿动手时确保事情落地。就像Intel当年为了让自己的32位CPU被采用，直接派人去修改Microsoft的编译器一样。很多人觉得帮别人干活是职场慈善，但真相是：组织里那<5%愿意做“别人该做却不做”之事的人，才是推动目标达成的关键。当流程僵化、计划永远排不到你的需求时，直接提交补丁往往比等待Scaled Agile排期更有效。虽然这听起来有些扭曲，但在组织尚存生机时，这种“越界”行为通常会带来丰厚的回报，让你成为少数真正懂如何成事的人。
我相信不仅是20%的人完成了80%的工作，而且所有这些工作之所以能达成最终目标，全靠那<5%的人做了别人本该做却因种种正当理由而拒绝去做的事情。
HN 评论区
111- ChrisMarshallNY
我在一家日本公司工作过，他们人事政策的一大块内容就是把员工在公司内部轮岗。通常是 1 到 2 年一轮（因为员工会把整个职业生涯都奉献给这家公司，所以能这么做）。最终，他们会进入更长期的岗位，开始专业化发展。
他们会配合标准化的代码和文档风格、通用工具等措施。所有员工都会定期接受这些标准的培训。
其理念是能够迅速调动有经验的员工。这也帮助员工理解他们的工作是如何在一个集成系统中应用的（对于专职员工来说，戴上“眼罩”只关注自己的一亩三分地是个相当典型的问题）。
这套做法总体上是行得通的，但它依赖于他们特定的企业文化，也给系统引入了相当可观的开销和僵化。这也意味着培养专家需要很长时间。
就我个人而言，我一直很享受学习新东西（现在依然如此）。我实际上很乐意接手那些我不知道怎么做的项目。我之前在这里写过关于这点的内容：https://littlegreenviper.com/miscellany/thats-not-what-ships...
- maerF0x0
> 而且大多数经理都未能惩罚他们手下至少一部分这些学习慢的人
错，他们的惩罚方式是不把这类工作算作工作。
粘合性工作、保持井井有条、处理那些其他人早就习惯忍受（并视而不见）的烦心事——所有这些在绩效评估时大约都值 0 分，因为你的时间是一个零和游戏，它被用来交换那些高可见度、具有政治意义或其他方面值得奖励的工作。
根据我的经验，在大型公司（我大致划线的标准是 1000 人以上），你通常必须在框架内行事。在非常小的公司（或作为自雇人士/创业者，大致在 200 人以下），你应该遵循你努力投入的 EROI（能量投资回报率）最高的路径，不管那是谁的工作。在两者之间的灰色地带，你得读懂文化和管理层。
- RevEng
我不同意集中化的想法。我正在为一个非常大的企业创建一个中心化的 AI 平台。可想而知，这样的大公司里已经有几个由不同部门构建的不同平台。每个部门都有自己相对满意的东西。但公司高层认为这种冗余是浪费，所以想将其整合到一个平台中。
单一平台的问题与任何单一来源的问题一样：你只能被动接受他们提供的东西，而且得按他们的时间表来。你和另外十万人共享这个平台，所以它不是为你量身定制的，要么做得尽可能通用，要么塞满了无关的功能。这两种情况对你来说都更糟糕。
我经常制作内部库，要么基于免费替代品，要么完全取代它们，因为免费的版本无法满足我们的需求，且带有我们不需要的一些额外复杂性。是的，这伴随着成本，但有时为了真正满足需求的东西，这是值得的。
强迫每个人都使用同一个通用平台，要么强迫他们去绕过平台与其需求之间的不匹配，要么强迫平台去满足所有人的需求。这两种情况都不高效，而且会损害其他所有用户。
如果你打算自己做，最好有一个充分的理由，但你不应该被强迫对所有事情都采用单一解决方案——这最终可能比制作几个特定方案更昂贵。
- dmurray
我目前工作中让我讨厌的一点是，根本不可能做到这一点。
所有东西都被多层权限锁住了。即使是针对我实际工作所需的权限，设置起来也要花几周时间（我每次看到有人在这里换岗，或者入职新员工时都会遇到这种情况）。想要获得权限去插手改进我不官方负责的系统其他部分——即使我客气地请求可能会被批准，因为没人知道谁实际上应该拥有什么权限——其摩擦成本远高于去找那个“对”的人。
- Aurornis
> 如果经理实际上什么都不管，只要你能够去找他的人并有效地管理他们，这就没问题
> 但你通常能在他的组织里找到愿意与你合作的人，基于他们应该这样做的理论。
在我遇到的 100% 的案例中，无论是作为经理还是作为天真的员工，有人试图对我这么做时，真正的原因是他们根本不在乎经理/员工本该做什么。他们在寻找容易下手的目标，以便利用他们来做自己团队的工作。大多数关于“经理什么都不管”的指控都来自其他团队，他们甚至没有试图去理解其他经理或团队在做什么。如果其他经理或团队没有以某种方式为它们积极工作，他们就认为该经理什么都没做。
> 确实，他们中的许多人早就明白，他们真的应该只遵循自上而下传达的命令，除此之外什么都不做，即使周围的一切都在燃烧。但有些人永远想不通这一点，而且大多数经理都未能惩罚他们手下至少一部分这些学习慢的人，所以这些人就成了你的劳动力。
最善意的解读是，这是在利用闲置员工为他们更大的利益服务，但我在真实公司中看到的绝大多数案例，都是一个傲慢的经理把他们的活分摊给任何足够天真、只要你开口就会照做的员工。
我曾与许多非常友善的人共事并雇佣过他们，他们总是想伸出援手……
- cik
我倾向于在自己身上应用这一原则，在组织内部（而不是那些喜欢泛泛地尝试所有事情的人——这也没问题）。我一直是“巡视组织”的巨大拥趸。无论我是作为开发者加入，还是作为高管，我都会特意花时间与产品、支持和市场部门打交道。这最终能给我一个独特的视角。我鼓励其他人也这样做，当我“掌控”入职流程时，会将其作为流程的一部分。
这字面上是让人快速掌握客户画像和产品的最快方式。他们可以在听支持电话（如果有的话）的同时亲自试用产品。他们可以了解到痛点以及那些作为开发者的我们并不总能遇到的“硬边缘”情况。
- exmadscientist
能够做别人工作的另一个有力之处在于，你个人会获得很多杠杆效应，而且是通过多种不同的方式。别人需要帮忙？你可能知道如何交付。有东西着火了？你可能知道下一步该怎么做，或者至少该给谁打电话，不管今天是什么着火了。有人在某件事上不肯让步？你可能没有比别人更大的杠杆，但你很可能确切知道该把杠杆放在哪里，以及当你施加一点力时它会产生什么效果。
这很有用。
然后还有这样的时刻：你可以向客户收取 300 美元/小时的费用，仅仅为了把东西送到 FedEx。因为你能做到，你就在这里，而且你会把它做好——不需要任何人解释这个特定截止日期或包裹内容的特殊性；你心里有数。
即使这通常不是高级顾问的工作。
- randusername
> 我相信不仅 20% 的人做了 80% 的工作，而且所有这些工作之所以能实现其最终目标，全靠那不到 5% 的人，他们做着别人本该做却不愿做的事，原因在组织的现实视角下完全正当，尽管这些正当原因的累积效应注定会导致整个地方的死亡。
我不知道我是否曾因为一篇 HN 帖子而感到如此被认可。
我绝对是那些多做别人不愿做的额外工作的傻瓜之一。这并非出于利他主义，我只是无法激励自己去完成愚蠢的任务。问题是，在任何足够大的组织中，许多任务都是愚蠢的，因为几乎没有人步调一致。