那个系统离不开的 Architect

上一篇文章讨论了 Organisation 如何参与书写 Architecture。

但 Organisation 并不是抽象实体。Decision 由人做，Knowledge 存在人脑中，而让一个结构严重 Erode 的系统继续稳定运行的能力，也可能逐渐集中到很少几个人身上。

于是会出现一个很微妙、甚至带有悖论的局面：

某个 Architect、Senior Developer 或 Domain Expert 对系统的价值巨大。他解决最难的 Incident，知道最危险的 Dependency，能够判断哪些 Change 真正可行，也经常是 Release 最后一道安全线。

与此同时，Organisation 对他的依赖越来越危险。

问题并不是“Expert 太强”。真正的问题是：系统是否把 Expertise 转化成了可共享、可验证、可持续的组织能力，还是把系统的可运行性绑定到了某个人。

Truck Factor 只是最明显的一层

Truck Factor 问的是：如果多少关键人物突然离开，Project 会陷入严重问题？

这是一个有用概念，因为它迫使团队去看 Knowledge Concentration，而不是只看 Headcount。

但 Big Ball of Mud 的 Key-Person Risk 并不只发生在“某个人突然被公交车撞了”或者离职之后。

更常见的情况是：这个人一直都在。

只是正常 Change、Release、Incident、Design Decision 和 Estimate 都越来越需要他的 Attention。

系统没有“失去 Expert”，却已经把日常 Throughput 建立在 Expert 是否有时间之上。

因此，真正值得观察的不只是：

如果他明天离开会怎样？

还要问：

如果他下周有五件事情同时需要处理，整个系统还能否独立推进？

一个人的存在可以掩盖结构风险。

自我强化的 Knowledge Loop

Knowledge Monopoly 很少从一个正式决定开始。

没人会在 Architecture Decision Record 里写：

从今天起，只有 Alex 能够理解这个 Subsystem。

它通常通过完全合理的工作分配逐步形成。

系统很难理解，因此大家先找最熟悉的人。Expert 能够最快解决问题，于是下一次更早找他。每次处理 Incident、Review 或 Sonderfall，他又获得更多历史 Context。别人因为“问他更快”，反而更少建立自己的 Mental Model。

于是形成一个自我强化循环：系统复杂 → Expert 被更多调用 → Expert 获得更多独家 Context → Organisation 更依赖 Expert → 其他人更少积累同等知识 → 下一个问题再次更自然地流向同一个 Expert。

这个循环不需要恶意。

它甚至可能完全由效率驱动。

短期来看，每一次“直接找 Expert”都是局部最便宜的选择。

长期来看，Organisation 却在持续增加对同一个人的依赖。

Key-Person Dependency 往往不是某个人主动夺取知识，而是组织一次又一次选择了当下最快的路径。

当救火比预防更可见

Production Rescue 很容易被看见。

Incident 发生，客户受影响，Expert 进入，两个小时后系统恢复。结果清晰、可归因、可庆祝。

Preventive Work 则完全不同。

把一个危险 Boundary 变得清楚、写 Documentation、Pairing、分散 Knowledge、删除 Global State、建立 Contract Test 或让另一位 Developer 学会一个 Critical Flow，都很难直接展示“避免了哪个具体 Incident”。

于是组织会自然产生 Visibility Bias：Rescue 的价值高度可见，Prevention 的价值往往是“什么都没有发生”。

如果 Performance Review、Status 和 Recognition 又更多奖励 Rescue，那么系统甚至会在无意间让 Key Person 的救火角色越来越强。

这不意味着 Expert 在“制造问题以便当 Hero”。

它只说明：Organisation 更容易奖励可以观察到的危机处理，而不是看不到的结构风险减少。

当其他 Developer 开始依赖

Dependency 不只存在于 Organisation 对 Expert 的方向。

Team Member 也会适应这种结构。

当大家知道“问 Alex 五分钟比自己读两天 Code 更快”，独立探索的短期经济激励就会下降。

于是问题从：

Architecture Rule 是什么？

慢慢变成：

Alex 说这里能不能改？

从：

哪个 Test 能证明这个假设？

变成：

Alex 记不记得这个 Sonderfall？

这不一定是 Developer 缺乏主动性。对一个 Deadline 下的 Team 来说，这种做法可能非常理性。

但长期结果是 Team 的 Mental Model 变薄，Expert 的 Model 继续变厚。

Knowledge Sharing 也可能变成单向咨询：很多人从 Expert 获取答案，但很少有人获得足够时间和 Ownership，真正建立可以替代 Expert 的理解。

从 Knowledge 变成 Expert Power

French 与 Raven 的 Social Power 模型把 Expert Power 描述为一种影响力：别人相信某个人拥有重要、稀缺且可信的专业知识，因此愿意接受他的判断。

这在 Software System 里完全正常。

复杂系统当然需要 Expertise。经验最丰富的人在关键决定上拥有更大影响力，通常也是合理的。

问题不在 Expert Power 的存在。

问题在于：系统是否仍然能够独立验证这个判断。

如果一个 Architect 说：“这个 Service 不能拆，因为 Billing 会坏”，成熟系统应该能够继续追问：哪个 Dependency？哪个 Contract？哪些 Test？哪条 Data Flow？哪个 Incident History？

如果最终答案只能是：

因为他最懂，所以相信他。

那么 Expert Power 已经不只是在帮助 Decision。

它开始替代 Architecture Evidence。

三个依赖阶段

Key-Person Dependency 可以粗略分成三个阶段。它们不是严格科学模型，而是一个实用诊断框架。

1. Knowledge Concentration

某个人知道得明显更多。

这很常见，也不自动危险。每个 Team 都会有 Expertise Distribution：有人更懂 Security，有人更懂 Domain，有人更熟悉 Deployment。

只要其他人仍然能通过 Code、Test、Documentation、Design Record 和 Peer Review 独立建立理解，Knowledge Concentration 只是 Expertise 的自然结果。

2. Operational Dependency

第二阶段，正常工作已经经常必须等待这个人。

Release 需要他 Review，Estimate 需要他确认，Incident 必须让他参与，复杂 Feature 不能在他休假时完成。

这时 Risk 已经不是“如果他离职”，而是 Throughput Bottleneck。

Organisation 的 Capacity 看起来可能有十名 Developer，但真正能够安全推进关键工作的人数远小于 Headcount。

3. Epistemic Dependency

第三阶段更危险。

Organisation 不只需要这个人执行任务，还需要他定义“什么是真的”。

其他人无法独立判断一个 Boundary 为什么存在，无法验证某个历史假设是否仍然有效，也无法区分真实业务规则和十年前的 Workaround。

此时 Expert 的解释本身变得难以被验证。

Operational Dependency 意味着“没有他做不动”；Epistemic Dependency 意味着“没有他甚至不知道应该相信什么”。

当解释本身无法被验证

Epistemic Dependency 的核心问题不是 Knowledge 量大。

而是 Knowledge 缺乏外部 Check。

Architecture 应该帮助 Organisation 把重要约束表达在可共享形式里：Boundary、Contract、Test、Type、Invariant、Data Ownership、Monitoring、ADR。

这些东西不需要消灭 Expert Judgment，但它们应该让 Expert Judgment 可以被讨论、验证和逐步传递。

如果一个系统的 Critical Truth 只能以口头形式存在，就会出现一种非常脆弱的状态：

• 新 Developer 很难区分事实与历史习惯；
• Review 变成对 Person 的 Trust，而不是对 Evidence 的 Review；
• Modernization 方案无法独立评估，因为任何反例都可能以“还有一个你不知道的 Sonderfall”结束；
• Organisation 无法准确判断自己究竟依赖哪些隐式规则。

这也是为什么单纯多写 Documentation 并不一定解决问题。

如果系统本身仍然高度 Entangled，Documentation 可能只是把复杂度复制到第二个地方。

真正有价值的是让结构本身更可验证。

Expertise 与 Transformation Competence 不是同一件事

这是整个主题中最重要、也最容易冒犯人的区分之一：

最懂现有系统的人，不一定自动是最适合设计未来系统的人。

维护 Big Ball of Mud 所需要的能力，与 Reconstruction 所需要的能力并不完全相同。

现状 Expertise 可能包括：历史 Dependency、故障模式、客户 Sonderfall、隐式 Data Contract、Release Ritual、旧 Technology 的深度知识。

Transformation Competence 则还需要：Boundary Design、Migration Strategy、Incremental Change、Requirements Reconstruction、Knowledge Distribution、Organizational Alignment，以及有意识地让某些旧知识逐步变得“不再需要”。

两类能力当然可以存在于同一个人身上。

但不能因为某个人“最懂 Legacy”，就自动把未来架构的全部 Decision Right 交给他。

同样也不能反过来：一个外部 Architect 只因为熟悉现代 Pattern，就忽视长期 Expert 对真实行为的深度知识。

Reconstruction 需要两类知识合作，而不是互相取代。

技术改变也会改变个人资源

Architecture Transformation 不只是移动 Code。

它会重新分配 Knowledge、Decision Right、Visibility 和 Influence。

如果一个人的 Status、日常重要性甚至职业安全感，很大程度来自“只有我知道这里为什么这样”，那么成功 Simplification 会改变他的角色。

过去每个 Critical Incident 都找他；未来可能不再需要。过去某类 Change 必须经过他；未来 Boundary 和 Test 让其他 Team 也能独立完成。

这不是在暗示 Expert 一定会抵抗变化。

只是指出：技术变化也会改变社会资源。

忽视这一点，会让 Transformation Plan 假装自己只是在做技术工程，而现实中它同时改变组织中的地位与影响力。

Knowledge 也可以意味着安全感

对长期维护复杂系统的人来说，“我知道这里怎么工作”不仅是一项技能。

它也可能提供安全感。

在一个不确定的 Environment 里，深度 Domain 和 System Knowledge 能让人感到可控。别人需要自己，自己能够解决问题，自己的角色非常清晰。

如果系统突然被大幅简化，原本稀缺的知识可能不再稀缺。

这并不意味着人一定会因此反对改善。

但成熟 Transformation 应该意识到：人并不是无摩擦地从旧角色迁移到新角色。

Organisation 可以主动创造新的价值路径：让 Expert 成为 Teacher、Boundary Designer、Migration Lead、Reviewer、Mentor，而不是只把他的旧知识“自动折旧”。

用 Status 比“Ego”更精确

Architecture Discussion 很容易用一句话解释所有阻力：

他就是 Ego 太大。

这种解释通常很廉价。

Status、Expert Power、Psychological Ownership、Role Security 是更精确的概念。

它们描述的是正常组织动力，而不是人格缺陷。

Status 影响谁被听见；Expert Power 影响谁的判断更容易被接受；Psychological Ownership 描述人对某个知识领域、系统或成果产生“这是我的”感受。

这些机制可以影响 Change，但并不自动意味着恶意。

用更精确语言的价值在于：它让我们可以设计更好的 Intervention，而不是把复杂现象简化成“某个人性格有问题”。

并不是所有 Knowledge Monopoly 都是 Knowledge Hiding

Knowledge Hiding 在研究中通常指：面对他人的知识请求，有意隐瞒、模糊或保留相关知识。

这种行为真实存在，组织研究也有大量工作讨论其 Antecedent 和 Consequence。

但很多 Key-Person Situation 并不是 Knowledge Hiding。

Expert 可能非常乐于分享。

他可以做 Workshop、写 Wiki、Pairing、Review，甚至每天回答几十个问题。

系统仍然可能高度依赖他，因为真正需要传递的不是几页 Documentation，而是多年积累的 Context Network。

“Expert 很愿意解释”与“Organisation 已经拥有这个知识”是两件不同的事。

所以诊断 Key-Person Risk 时，不应从 Knowledge Concentration 直接推断个人动机。

当 Knowledge 被体验成“我的 Knowledge”

Psychological Ownership 研究提供了另一个有用视角。

人可以对知识、工作成果或专业领域形成很强的 Ownership 感。这种感受可能增加责任感，也可能在某些条件下影响 Sharing。

但同样需要谨慎。

外部观察者看到某个 Expert 对领域保护很强，并不能自动证明他故意隐藏 Knowledge。

更重要的问题仍然是组织结构：

• Critical Knowledge 是否只有一个 Source？
• 是否存在 Peer 能够 Check？
• Decision 是否留下 Reasoning？
• Test 与 Contract 是否保存了业务事实？
• 其他人是否有真实机会承担相同 Ownership？

当这些机制存在时，Psychological Ownership 可以成为责任感。

当这些机制不存在时，它可能与 Knowledge Monopoly 相互强化。

Power 不是骂人的词

Power 在这里不意味着操纵。

它只是影响 Decision 的资源。

Formal Role 是 Power。Budget 是 Power。Network 是 Power。Control over Information 是 Power。Expertise 同样是 Power。

因此，目标不是消灭 Expert Power。

事实上，Organisation 应该利用 Expert Power：复杂决策本来就需要最有经验的人产生影响。

好的 Governance 做的是另一件事：避免一个单一 Power Source 缺少任何 Counter-check。

当 Expert Opinion 可以被 Test、Second Expert、Architecture Rule、Data 和 Transparent Reasoning 支持时，Expert Power 是资产。

当它成为唯一验证机制时，它才变成结构风险。

无意识的 Stabilisation

Expert 每次救火，通常都在做正确的事。

Production 出问题时，他当然应该帮助。Release 有风险时，他当然应该 Review。Team 不知道历史 Sonderfall 时，他当然应该解释。

但每一次成功 Rescue 都有一个系统级副作用：Organisation 再次证明了“依靠 Expert 可以继续运行”。

这会降低立即改变结构的压力。

于是，Expert 可以在完全没有“维护现状”意图的情况下，成为现状稳定机制的一部分。

最优秀的补偿机制，有时恰恰会让根本问题更久不必被处理。

这与测试、Review、Release Ritual 对 Big Ball of Mud 的补偿机制类似。

它们解决真实风险，但也让结构性问题更少以灾难形式暴露。

有意识的 Stabilisation 也存在

反过来，也不能把所有情况浪漫化成“System made them do it”。

Agency 仍然存在。

有些人确实会利用 Knowledge Advantage 保持 Control，阻止他人获得 Context，把 Review 变成 Gatekeeping，或者故意维持只有自己能解决的问题。

Knowledge Hiding 研究说明，这类行为并非虚构。

No Blaming 不等于否认个人行为。

成熟分析必须同时容纳两件事：

1. 系统结构可以自然产生 Knowledge Concentration；
2. 个人仍然对自己如何使用这种 Position 负有责任。

如果我们只说“都是那个 Architect 的错”，会错过系统机制。

如果我们只说“都是系统的错”，又会消除 Agency。

Expert 不是 Organisation 的被动对象

Key Person 也有专业责任。

如果 Organisation 提供时间和空间，Expert 应该主动让重要 Decision 可理解：Documentation、Pairing、ADR、Test、Architecture Review、Teaching、Second Opinion。

他应该允许别人 Challenge 自己的判断，并尽量避免把“Trust me”当成 Architecture Contract。

这并不意味着他必须把十年知识在两周内“交接干净”。

很多 Context 无法简单传输。

但 Expert 可以帮助 Organisation 从“依赖我的答案”走向“依赖我们共同建立的结构”。

这是一种不同形式的 Seniority。

真正成熟的 Expert 不只是能够独自解决最难问题。

他还能够让越来越多问题不再必须由自己解决。

高能力不会让 Peer Review 变得多余

“他过去 50 次都判断对了”不是取消 Review 的理由。

恰恰相反，如果一个人的 Decision Radius 很大，那么透明 Evidence 更重要。

强 Expert 仍然可能错，尤其是在复杂环境里、信息不完整时，或者当历史 Knowledge 本身已经过时。

因此，大影响 Decision 应该尽可能留下可重复的 Reasoning：ADR、Experiment、Test、Measurement、Dependency Analysis、Migration Spike。

Review 不是对 Expertise 的不尊重。

它是把个人 Expertise 转化成组织 Knowledge 的机制之一。

一条挑衅性的 Consulting Rule

当我进入一个陌生、结构侵蚀严重的系统时，如果有人说：

“只有 X 真正懂这个系统。”

我的反应不是排除 X。

恰恰相反，我一定要和 X 工作。

他通常拥有极其重要、代码里没有的 Context。

但我也不会让 X 成为关于系统未来状态的唯一 Source of Truth。

这条规则背后的原因很简单：

最懂现状的人是理解问题不可替代的输入，但不能自动成为未来方案唯一不可质疑的验证者。

Transformation 需要 Legacy Expertise，也需要独立 Architecture Reasoning。

Key-person Paradox

于是出现整个主题最核心的悖论：

Organisation 越依赖 Expert 维持当前系统，就越不能在短期失去他。

而依赖越强，长期风险又越高。

Organisation 必须同时做两件表面矛盾的事：

1. 保护、尊重、充分使用 Expert；
2. 有计划地降低对他的独家依赖。

目标绝不是“让 Expert 变得不重要”。

真正理想的变化是价值形态发生改变。

从：

只有我能救这个系统。

变成：

我帮助系统、Team 和 Boundary 变得足够清楚，让更多人可以安全工作。

这种 Expert 往往对 Organisation 更有价值，而不是更少。

No Blaming 不等于没有 Responsibility

这一系列一直避免把 Big Ball of Mud 写成“坏人故事”。

在 Key-Person 主题上尤其需要保持同样原则。

理解 System 如何把人推入某种角色，并不意味着忽视个人 Decision。

成熟分析应该同时拒绝两个极端：

• “都是这个 Architect 的错”；
• “都是系统的错，所以个人行为完全不重要”。

现实通常处在中间。

System 产生 Incentive，Person 作出 Decision；Organisation 奖励某些行为，Expert 仍然决定如何回应；Complexity 让知识难以分散，但人仍然可以选择 Teaching 还是 Gatekeeping。

责任存在。

只是责任不等于把系统问题人格化。

研究说明了什么——又没有说明什么

关于 Truck Factor、Knowledge Hiding、Expert Power、Psychological Ownership 和 Knowledge Sharing 的研究，为我们理解 Knowledge Concentration 提供了真实机制。

这些研究支持一些一般性判断：知识可能集中；Expertise 会产生影响力；Knowledge Hiding 是现实行为；Psychological Ownership、Job Insecurity、Leadership 等因素可能与 Knowledge Sharing / Hiding 相关。

但它们不能让我们从外部观察直接推断某个具体 Expert 的动机。

看到“只有 Alex 知道”并不能证明 Alex 在故意隐藏。

看到一个 Architect 强烈反对 Migration，也不能只凭这一点判断是 Status Anxiety。

因此，实际诊断应该首先聚焦可观察结构：

• Decision 是否可验证？
• Knowledge 是否有冗余？
• 是否存在 Second Expert？
• 正常 Change 是否必须等某个人？
• Critical Rule 是否只存在于 Memory？
• Peer 是否能够独立 Challenge Reasoning？

这些问题比心理猜测更可靠。

Organisation 需要 Expert——但不需要“不可质疑”

一个健康系统不是没有 Expert。

恰恰相反，优秀 Organisation 通常拥有非常强的 Expert。

区别只在于 Expertise 被用来做什么。

在健康结构里，Expertise 用来建立 Boundary、Model、Test、Tool、Documentation 和其他人的能力。

在脆弱结构里，Expertise 本身成为运行机制：没有这个人，大家不知道该改什么，也不知道该相信什么。

真正需要减少的不是 Expertise。

需要减少的是“只有这个 Expert 才能让系统继续工作”的结构。

最好的结果不是 Expert 被“去价值化”。

而是他的价值从独家知识转向更高层次的组织能力：Teaching、Design、Decision Quality、Risk Reduction 和使系统更容易被其他人理解。

来源与延伸研究

• Avelino, G., Passos, L., Hora, A. & Valente, M. T. (2016): A Novel Approach for Estimating Truck Factors. 24th IEEE International Conference on Program Comprehension. DOI 10.1109/ICPC.2016.7503718.
• Connelly, C. E., Zweig, D., Webster, J. & Trougakos, J. P. (2012): Knowledge hiding in organizations. Journal of Organizational Behavior, 33(1), 64–88. DOI 10.1002/job.737.
• French, J. R. P. Jr. & Raven, B. H. (1959): The Bases of Social Power. In D. Cartwright (ed.), Studies in Social Power. 关于后续扩展，见 Raven (1993): DOI 10.1111/j.1540-4560.1993.tb01191.x.
• Issac, A. C., Bednall, T. C., Baral, R., Magliocca, P. & Dhir, A. (2022): The effects of expert power and referent power on knowledge sharing and knowledge hiding. Journal of Knowledge Management, 27(2), 383–403. DOI 10.1108/JKM-10-2021-0750.
• Moser, K. S. (2017): The Influence of Feedback and Expert Status in Knowledge Sharing Dilemmas. Applied Psychology, 66(4), 674–709. DOI 10.1111/apps.12105.
• Huo, W., Cai, Z., Luo, J., Men, C. & Jia, R. (2016): Antecedents and intervention mechanisms: a multi-level study of R&D team’s knowledge hiding behavior. Journal of Knowledge Management, 20(5), 880–897. DOI 10.1108/JKM-11-2015-0451.
• Tian, Y., Mao, L., Zhou, M. & Cao, Q. (2021): Knowledge-based psychological ownership and knowledge hiding: The roles of loss of knowledge power and emotional intelligence. Social Behavior and Personality, 49(8), e10530. DOI 10.2224/sbp.10530.
• Jeong, J., Kim, B.-J. & Lee, J. (2023): The effect of job insecurity on knowledge hiding behavior: The mediation of psychological safety and the moderation of servant leadership. Frontiers in Public Health, 11, 1108881. DOI 10.3389/fpubh.2023.1108881.
• Arain, G. A., Bhatti, Z. A., Hameed, I., Khan, A. K. & Rudolph, C. W. (2024): A meta-analysis of the nomological network of knowledge hiding in organizations. Personnel Psychology, 77(2), 651–682. DOI 10.1111/peps.12562.
• Schou, P. K. & Nesheim, T. (2024): What We Do in the Shadows: How expert workers reclaim control in digitalized and centralized organizations through ‘stealth work’. Organization Studies, 45(5), 719–744. DOI 10.1177/01708406241233175.