Stop Chasing '10x Rockstars' for Your Team: The Case for Building Resilient Systems Instead / 别再迷信团队里的“10倍大牛”了：搭建抗风险系统才是长期发展的核心
I recently came across a thought-provoking piece that hits on a pain point so many tech teams know all too well: we often gush over that one standout engineer who can fix outages in 10 minutes or churn out features twice as fast as everyone else, framing them as the team’s biggest asset. But what happens when that person hands in their two weeks notice? Suddenly, the whole project grinds to a halt, bugs slip through the cracks, and deadlines get pushed back by months. The core argument of the piece is a simple but powerful one: if your team can only function well when a specific individual is around, you don’t have a good team—you have a bad system.
这篇文章的观点戳中了很多企业的管理误区：我们总把个体的高光表现当成团队的竞争力，却忽略了这种“英雄模式”的脆弱性。就像我们刷到过的工地“神级工人”视频，他们能靠娴熟的技巧把活儿干得又快又好，看起来老板赚翻了，但只要这个人一走，同样的工作进度立刻就会崩盘。短期来看，依靠顶尖个体确实能快速拿到结果，但一旦涉及到规模化扩张或者人员流动，这种模式的隐患就会全部爆发出来——毕竟人是最不可控的变量，会生病、会离职、会有状态不好的时候，只有系统才能对冲掉这些人为风险。
The author points out that a good system isn’t just a pile of rigid rules to micromanage people. It’s a set of guardrails designed to accommodate the fact that every human makes mistakes, no matter how skilled they are. For example, instead of trusting that all engineers will remember not to push broken code directly to the main branch, you can set up your repository to block direct pushes entirely, forcing every change to go through a pull request with automated checks. No matter how careful a developer is, they might accidentally commit a bug after a long day of coding, but a well-built system will catch that error before it causes production issues. It’s not about distrusting your team—it’s about setting them up to succeed even when they’re having an off day.
有意思的是，作者把流程和规则比作编程里的单元测试：你修复了一个bug之后，不能只改完代码就完事，最好补充一条对应的测试用例，这样下次任何人改代码触发了同样的问题，测试就能第一时间把问题拦下来。流程也是一样的作用：当你遇到一个共性问题，不要只靠口头提醒大家“下次注意”，要把解决方法固化成所有人都要遵守的流程。这样就算整个团队的人全部换了一遍，新人跟着流程走，也能输出稳定的质量，不会因为人员变动就让项目失控。他还举了很多研发团队里常见的系统设计，比如强制代码评审、要求所有改动都补充测试、用严格的静态检查工具拦截不规范代码，本质上都是把问题拦截在流程里，而不是靠工程师的个人自觉。
Of course, introducing these systems usually comes with pushback, and the author is honest about that. Some team members might resist new processes because being the only person who knows how to fix a certain type of problem gives them job security. He shares a story from his own team, where they tried to introduce a simple rule to memoize all hook return values in a React project to prevent recurring re-render performance issues. One engineer pushed back hard, citing “premature optimization” and the lack of official React recommendations for the practice. The author’s take? That engineer was resistant because fixing those re-render issues repeatedly made him feel like an indispensable expert, and a system that would eliminate that problem entirely threatened that status. This is a really important observation: building a system doesn’t just require tweaking processes—it also requires addressing the fear some people have of being replaceable.
说到底，推崇系统思维并不是要否定个体的价值，反而能让优秀的人发挥更大的作用。我们依然可以鼓励个体提升效率、拿出亮眼的成果，但不能把团队的生死存亡都押在某几个人身上。好的系统，是让普通人也能输出稳定的合格结果，让优秀的人不用花时间去填别人挖的坑，能把精力放在更有创造性的工作上。毕竟我们做团队、做项目，追求的从来都不是短暂的高光时刻，而是长期、稳定、可持续的发展，对吗？
