Stop Chasing 10x Rockstar Engineers — Build Systems That Work Even When They Leave / 别再追捧「10倍效率大神」了：搭建靠谱系统，比依赖个人能力更重要
There's a viral trope we've all seen online: a construction worker who can lay bricks twice as fast as everyone else, a barista who remembers every regular's order by heart, a senior engineer who can fix a production bug in 10 minutes that stumped the rest of the team for hours. We gush over these "heroes" as the ultimate asset to any team — but what happens when that hero quits, gets sick, or just takes a two-week vacation? This article we recently came across makes a sharp, practical argument that for enterprise teams, hero culture is not just unsustainable, it's actively harmful to long-term success.
企业软件开发的核心目标其实无非三个：减少bug、保证可扩展性、按时交付。但很多团队都掉入了同一个陷阱：把这些目标寄托在少数能力超强的核心成员身上，却忽略了搭建一套不依赖任何人也能稳定运行的系统。你以为用一份薪水雇到了能打三份工的大神是赚了，但等到大神离职那天你就会发现，整个项目的进度直接停摆，之前基于他的效率排的交付计划全成了空头支票。这不是员工的问题，是团队从一开始就把「个人能力」当成了系统的一部分。
The core logic of a system-first approach is actually really simple: humans are fallible. We get tired, we make careless mistakes, we forget things, we leave jobs for better opportunities. Instead of expecting everyone on the team to be perfectly disciplined and never slip up, build guardrails that catch mistakes before they cause problems. For example, instead of sending out a company-wide email reminding everyone not to push code directly to the master branch, just set up the repository to automatically reject direct pushes entirely. It doesn't matter if someone has a moment of distraction and tries to push by accident — the system will stop them before any damage is done, no scolding required.
其实这和我们写代码要加测试是一个道理：你修复了一个bug，不能只改完代码就完事，一定要加对应的测试用例，确保下次其他人改代码的时候不会再踩同一个坑。团队流程也是一样的，每次遇到问题，要做的不是指责「谁把事情搞砸了」，而是想「我们应该加个什么规则，能让以后不管谁来做，都不会再出这个问题」。好的系统甚至应该做到：就算整个团队的人全部换一遍，项目依然能稳定输出质量过关的成果。所有的工作产出都应该变成可留存的「资产」—— 不只是代码和数据，还有文档、决策记录、操作规范、流程准则，这些才是团队真正的护城河。
Of course, building this kind of system will almost always face pushback, especially from team members who benefit from being the irreplaceable "expert". The article shares a relatable anecdote: their team had consistent performance issues in a React app from unnecessary re-renders, so they proposed a simple rule to memoize all values returned from hooks to prevent the problem from happening again. One senior engineer pushed back hard, citing "premature optimization" and claiming it went against React documentation. The author's take? That engineer just liked being the go-to person who got to spend hours debugging re-render issues, making himself look indispensable to the team.
当然我们并不是说个人能力不重要，优秀的员工当然值得鼓励和奖励，但绝对不能把「所有人都有顶尖能力」当默认前提。真正高效的团队，不会指望每个人都是不犯错的大神，而是会用流程把普通人的能力发挥到最大，也把犯错的成本降到最低。下次你的团队再遇到问题的时候，先别急着找「厉害的人来搞定」，不如先想想：我们可以搭个什么样的系统，让下次再也不用为同样的问题头疼？
