Stop relying on star programmers to save your project: the system-first approach that makes teams sustainable / 别再指望明星程序员救场了：让团队可持续发展的系统优先思维
Every tech team has that one "10x programmer" who knows the codebase inside out, fixes bugs in 10 minutes that stump everyone else, and seems to carry the entire project on their back. It feels like a win for the company, right? This person delivers way more value than their salary would suggest, and you can always count on them to pull the team out of a tight spot. But what happens when that person quits, gets sick, or even just takes a two-week vacation? Suddenly deadlines slip, bugs pile up, and the entire team is left scrambling to figure out how they did what they did. That’s the core problem a recent thought piece on team management pointed out: we spend too much time celebrating heroes, and not enough time building systems that don’t need heroes to function.
我们多少都见过团队里的「技术牛人」，闭着眼睛都能定位线上问题，随手写的代码效率比别人高好几倍，似乎整个项目的进度都绑在他们身上。但这种依赖个人能力的模式，本质上是把团队的抗风险能力降到了最低。一旦核心人员流失，之前交付效率有多高，后续停摆的速度就有多快。文章里举的例子很扎心：工地上有个工人能徒手把砖切得整整齐齐，比机械裁的还标准，大家都夸他厉害，但如果他离职了，后面的人根本没法复制他的手艺，工期直接就乱了。放在编程领域也是一样：你当然可以鼓励员工提升个人能力，但永远不能把团队的整体产出，赌在某几个人的「靠谱」上。
The author makes a really useful comparison between team processes and automated tests in programming. When you fix a bug, you don’t just patch the code and move on — you write a test to make sure that same bug never comes back, no matter who works on the code next. Processes work the exact same way: instead of yelling at people to be more careful when they accidentally push bad code to the master branch, you just set up branch protection rules that block direct pushes entirely, no human judgment required. It doesn’t matter if someone is tired, distracted, or new to the team; the system will catch the mistake before it causes damage. All the common practices we use in software teams — mandatory code reviews, strict linter rules, static type checking, required test coverage — aren’t there to make developers’ lives harder. They’re there to turn the team’s accumulated experience into guardrails that keep everyone from making avoidable mistakes, even if they don’t know all the context of the project.
这其实就是所谓「系统思维」的核心：承认所有人都有弱点，都会出错，然后用固定流程把出错的可能性降到最低。文章里提到的一个观点很有意思：好的系统应该是哪怕整个团队的人都换了一遍，项目依然能平稳运行。这就要求团队所有的工作产出都要变成可沉淀的「资产」：不仅仅是代码，还有文档、决策记录、规范手册，把之前踩过的坑、总结出来的最佳实践，都变成所有人必须遵守的规则，而不是藏在某几个老员工的脑子里。很多时候团队抗拒流程，不是流程没用，而是有些团队成员会觉得：一旦所有问题都有标准化的解决方案，自己作为「不可替代的专家」的价值就消失了。作者分享了自己团队的经历：他们的React项目频繁出现重复渲染的性能问题，最简单的解决方案是加一条规则，要求所有hooks返回值都做memoization，从根源上避免同类问题再发生，但就有程序员强烈反对，说这是「过早优化」，不符合React官方文档的推荐。其实本质上就是他不想失去靠解决这类重复问题来证明自己价值的机会。
None of this means that individual skill doesn’t matter, of course. Great developers will always make a team better, and we should absolutely reward and encourage high performance. But the goal of a well-run team shouldn’t be to collect as many star performers as possible. It should be to build a structure where average performers can deliver consistently great results, and where the loss of any single person won’t derail the entire project. When you start seeing process fixes as investments instead of inconveniences, you stop building teams that rely on heroes, and start building teams that are reliable all on their own.
