把别人的活儿也一起干了
文章摘要
Yossi Kreinin（yosefk）这篇短文的核心论点是：能干得了别人的活儿非常有用——它让你了解对方怎么工作、需要什么；而当你需要对方把活干完、对方却不肯干时，这种能力的价值就更大了。
他举了几个具体场景。第一，你做了个新东西，目标用户懒得开始用它，那就干脆自己去把它集成进对方的系统里。这招英特尔当年就用过：他们推出第一款 32 位 CPU 时，派自己的人去给微软的编译器加了这款 CPU 的支持——作者说他见过当年那个英特尔团队的人。他随即反问：英特尔这么做是在扶贫救济可怜的微软，还是为了从微软的成功中获益？第二，如果某个经理其实什么也不管，只要你能绕过去直接把他手下的人组织起来（当然不叫「管理」，也不抢功劳），事情照样能推进。他挖苦说，很多下属早就悟出自己真正的职责是「执行自上而下的指令、别的什么都不干，哪怕周围全着了火」，但总有些人一直没悟，而多数经理又懒得惩罚这些「学得慢的」，于是这些人就成了你可以合作的对象。第三，如果你需要某个依赖库加个功能，说服对方接受你的补丁，往往比让这项工作挤进对方那套「高速运转的规模化敏捷规划流程」要容易得多——他用一整段括号模仿了那套官腔：本季度和下季度的计划当然都已经定稿了，这正是我们交付速度的保障，不过再过几周我们可以讨论一下这件事相对于下下季度其他需求的优先级。他顺带补了一句时代注脚：现在合并变更可能更难了，因为你精心设计的补丁乍一看和随机 LLM 输出没什么两样，不过只要对方认识你就不成问题。
作者知道很多人觉得这种做法很扭曲、凭什么要这么干。他的信念是：不仅是 20% 的人干了 80% 的活，更关键的是所有这些工作之所以最终能达成目标，靠的是那不到 5% 的人——他们去做那些本该由别人做、但别人就是不做的事，而别人不做的理由在组织自身的现实观里全都完全正当，尽管这些正当理由累加起来的结果是整个地方必死无疑。他也相信，在组织糟糕到需要这种人（大多数组织都是）但又健康到最终能欣赏这种人的情况下（如果连这都做不到，那它已经在咽气了），你会得到丰厚回报；此外还有间接收益——你会成为少数真正理解这地方如何运转、怎样才能把事情办成的人。他坦承自己真正后悔的恰恰是反面：那些年他明明有能力涉足、却因为「离我的本职太远、而且很无聊」而拒绝进入的领域。事后看来「蠢得可以」——当你因为想当然地以为别人的活「总会有人干」而淹没在本可避免的问题里时，那些领域就不无聊了，只是可能已经太晚。
文章后半段是一个重要的限定，标题叫「但不是这样」。作者指出有两件表面相似、资深人士也很爱（因为能扩编制）、实则可能反噬的事：这两种情况下你不是在替别人把活干完，而是在与他们并行或取而代之地做同一件事。第一种是自己造而不是买，或者不用现成的免费方案。有些地方买得太多、明明供应商产品很烂也要买，理由是「标准是好东西」或者单纯因为花钱比招人容易；另一些地方则自造过度，因为在那里任何开支都批不下来，但扩编制相对容易。如果你关心的是改善预期结果而不是在特定环境里挑最省事的路，那么「买还是造」是一个高度个案化的艰难决策，你得学一堆细节，诚实地权衡自己的短板与潜在供应商的短板以及市场的结构性问题。第二种是每个部门各自为政，而不是把某项服务集中化。部门经理喜欢这样，因为少了一个不向自己汇报却要依赖的对象（没什么比「需要不归自己管的人做事」更让经理害怕）；更上层的管理者也喜欢，因为这样就不用处理「中央服务部门据说不行」的投诉，不必去判断这到底是真的、该怎么修，还是其他部门为自己失职找的借口。同样，如果你在意的是结果而非高层的省事程度，全公司标准化与各自造轮子之间的取舍也是个难题。
文末致谢里，Dan Luu 留下了一段有意思的评论：他从开头以为这篇要讲的是「创始人如果会做被招者的活儿就能招得更好，所以从零开始把公司做大很有价值」那套说法。他引用一位二次创业成功的朋友的判断——自己干过那份工作，招人确实容易得多；理论上你也可以靠「找到干过这活的可信的人」得到同样的价值，但经验上人们看走眼的概率高于看准。作者回应说这有道理，但他自己还没把公司做到那个规模所以无法确认；他觉得带团队时确实如此（前提是你懂得怎么管理那些做得比你好的人），但等团队长到几百人，里面一定会有你干不了其活儿的人，独立公司尤其会更快到达这一步。所以他认为真正的瓶颈会变成那项互补能力——管理那些你根本干不了其工作的人，而这并不容易。
HN 评论精华
210 分、109 条评论，讨论的走向和文章本身有相当大的张力。
排名最高的回复是一句冷嘲。 proc0 只写了一句：「就是拿同样的钱多干很多活。好主意。」rvz 接「为了全人类的福祉」，TeMPOraL 补上那句经典梗「为了我们所有人的福祉（除了已经死掉的那些）」。distortionfield 说基本上所有「生活黑客」类建议归根结底都是这个。这条线下面也出现了反驳：perelin 说前提是你不额外白干、到点就下班；dtdynasty 认为关键技能是判断这些额外工作未来能否转化为收入，有了这个判断它就从「纯多干」变成了一场下注；RugnirViking 从大公司开发者的角度说，在不重要的时候摸鱼、在关键时刻发力，总工作量其实差不多甚至更少，而且如果你知道该找哪个团队聊，可以省下自己几个月的工作量。
exmadscientist 提供了最有说服力的正面论证：这是杠杆。 有人要帮忙，你多半交付得了；出事了，你多半知道下一步做什么、或者至少知道该找谁，无论今天着火的是什么；有人在某件事上寸步不让，你手里的撬棍未必比别人长，但你清楚该把支点放在哪、施力之后会发生什么。他还举了个具体例子：正因为你能顺手把东西送到 FedEx、而且知道这个截止日期和包裹内容的所有门道不需要人解释，你可以按每小时 300 美元向客户收费做这件事——即便这通常不是资深顾问的活。
但「说不」的困难被反复提及。 Brajeshwar 说他的老板们曾劝他学会「更粗鲁一点」，别因为自己能做就什么都做；他学到的最重要的一课就是大写的 NO。jampekka 指出这里有个诡异的动力学：如果你明明会做却拒绝，会被视为无礼；但如果你说（哪怕是撒谎）「我不会」，通常就被接受了。而且帮忙会引发需求升级——一开始只是帮个对你很轻松的小忙，很快你就「拥有」了越来越多的任务，这和开源项目 issue 区里那些理所当然的伸手党没什么两样。yxhuvud 补充了「小写的 no」：表示你很乐意做，但这事得走正规流程、进 roadmap。fabianholzer 贡献了这条线的金句：「在大公司里，好人好事从无善终。」hdjrudni 说真有人对他说过这话——他一碰或修好某个东西，就永远成了那东西的主人。
centralization 那一段收到了实质性的反驳。 RevEng 说自己正在为一家超大企业做中央 AI 平台，各分支早就有各自还算满意的平台，总部觉得这是浪费所以要整合。他认为集中化的问题和任何单一来源一样：你被对方提供的东西和对方的时间表锁死，而且这东西要同时服务十万人，所以要么被做成尽可能通用、要么塞满与你无关的功能，两种结果对你都更糟。他也讲过自己基于免费库改写甚至完全替换的经历——免费方案不满足需求、还带着用不上的复杂度。作者 yosefk 亲自下场回复：「你到底在反对原文的哪一点？我同意你说的，我只是认为存在反论点，这需要逐案判断。」RevEng 澄清说他读到的原文论点是「集中化是更好的结果，只是对领导层不够有吸引力」，而他的反论点是集中化本身也有必须考虑的代价，它并不天然更优。
跑题最远也最有意思的一支，是关于「轮岗」。 ChrisMarshallNY 说他在一家日本企业工作过，HR 政策的核心就是让员工在公司内部流动，通常一到两年一站（因为员工会在同一家公司干一辈子，所以做得到），最终才进入更长的专精阶段；配套的是统一的编码与文档规范、统一工具和常态化培训。好处是能快速调动有经验的人手，也让员工理解自己的工作在整个系统里如何被使用（「戴着眼罩干活」是敬业员工的典型问题）；代价是高度依赖那种特定文化，引入了可观的开销与僵化，而且培养专家要很久。这引出一串跨国比较：tomaskafka 说捷克医生就是这样，要在医院各科室轮转约两年半；groestl 说奥地利叫 Turnus；tristor 说美国的住院医师制度也类似，但 tacticalturtle 纠正说住院医只在单一专科内部轮转，更像医学院三四年级的临床轮转。elmo-shrugged 给出了美国企业版的现实：公司嘴上支持这种灵活覆盖，可一旦你在本部门真的有用了，你老板就绝不肯放人，因为上层根本没在编制里留出足够冗余来替换你。SenHeng 补充了日本「総合職」的细节：三年一动，理论上防止形成小山头、同时扩展人脉；这套逻辑还延伸到超市店长、公立学校教师等岗位——如果你是小学老师，很可能看不到自己的学生毕业。
还有一条实用主义的小贴士来自 harry8：去公司另一头拜访别的团队时，手里永远拿个文件夹，打印点代码或几页规格书都行，总之别空着手晃悠。JR1427 则给出了更直白的版本：直接给对方团队的人发消息说你想多了解他们在做什么，约杯咖啡。