一个工程师请假，整个季度差点黄了

周一早上，一名工程师休了年假。午饭前，三条业务线全部卡死。Slack里堆满"请教个问题"的消息，没人接得住。站会变成了一场 scavenger hunt（寻宝游戏）——大家到处翻找缺失的上下文。到周三，团队终于意识到：问题不是产出不够，而是关键知识全锁在一个人脑子里。

这种场景，你的团队可能正在经历，只是还没爆发。

被误读的"优秀员工"

多数领导看到这种情况，不会警觉。他们会说这是"卓越表现"：

「她是我们最强的工程师」

「他对平台的理解没人比得上」

「出事了找他准没错」

原文作者承认自己职业生涯中说过所有这些话，"而且每次都付出了代价"。

真正拖慢团队的并非编码能力，而是缺失的"地图数据"——某些决策为什么存在、隐藏依赖藏在哪里、哪些改动看起来安全却会在下游引爆。团队有才华，系统却很脆弱。

如果你读过《凤凰项目》，会认出这是经典的 Brent 效应。一个不可或缺的人被绑到每条关键路径上，领导把"英雄式救火"误认为系统健康，一切看起来正常，直到这个人 unavailable（无法响应）。

作者打了个比方：不同年代，同一部电影，只是仪表盘更漂亮了。

这不是人的问题，是设计选择

核心洞察在这里：Brent 效应不是性格缺陷，是运营模式的选择。

你为"局部效率"做设计，醒来却发现"全局脆弱"。

危险之处在于形成过程中的"正常感"。起初什么都没坏——工单还在流转，发布还在进行，领导看到的仪表盘还是绿的。唯一的早期信号是行为层面的：风险出现时，所有人都知道该@谁，却没人追问这个模式为什么反复出现。

多数团队追踪周期时间、部署频率、事故数量。很好，继续追踪。但如果不追踪技能和上下文的分布情况，你就漏掉了能让前三项全部失效的风险。

作者现在用一个简单的评分机制应对关键领域——不是因为分数本身多性感，而是因为"我们应该多做交叉培训"这种模糊对话，从来熬不过季末压力。

五维评分：找到你的"单一神经系统"

选一个关键服务或工作流，从0到2分，五个维度打分。目标不是完美，是暴露你的路线图依赖了多少个"单一神经系统"。

1）覆盖度（Coverage）

多少工程师能在不找常规负责人的情况下安全修改这个区域？

2）恢复力（Recovery）

值班人员能否在不升级给同一个人的情况下恢复核心流程？

3）决策可追溯性（Decision Traceability）

工程师能找到决策背后的原因吗？

4）上手转移速度（Onboarding Transfer Speed）

新工程师能在30天内交付有意义的改动吗？

5）所有权轮换健康度（Ownership Rotation Health）

过去两个季度，所有权轮换过吗？

总分10分。

关键提醒：按领域评分，不是按团队。团队整体看起来健康，但某个支付流程、某个集成面、某个部署路径可能仍然命悬一线。目标不是拿到漂亮的平均分，是找出那些隐藏的单一故障点。

为什么这件事值得现在做

这个评分机制的价值不在于分数本身，而在于它强制把"隐性知识风险"变成可讨论、可优先排序的事项。季度规划时，你可以指着某个5分的领域说：这里需要投入，否则下次有人休假或离职，我们就在赌运气。

对25-40岁的科技从业者来说，这可能是你向上管理的最硬通货——不是抱怨"我太累了/太重要了"，而是拿出一个可量化的框架，让领导理解：某些"高效"的表象，其实是债务。