# 20. 无权威的领导力

架构师如何在没有正式权力的情况下产生影响：principles、alignment、mentoring、decision making 和技术文化。

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** 约 25 分钟阅读
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/zh/learn/software-architect-20-leadership

---

## 1. 核心观点

技术领导力是提升团队决策的能力，不是亲自做出每一个决策。

### 原则比意见更能 scale

> 交通规则让成千上万的司机通过路口，而不必在每个路口都向调度员请示。

如果架构师手动回答每个问题，他就成了 bottleneck。如果他把 principles、quality gates 和 decision framework 表达清楚，团队就能自己行动。

举个 principle 的例子："Domain layer 不依赖 infrastructure"。这比在每个 PR 里争论能不能在 use case 里 import ORM 强得多。

### Influence 需要信任

> 导航能稳定地带你到目的地，人们才会一直听它。一次自信但错误的路线，会让信任掉很久。

信任来自准确、敢于承认 uncertainty、对 trade-offs 的诚实描述，以及对团队上下文的尊重。一个总是"知道得比你多"的架构师，会迅速失去影响力。

强有力的表态听起来不像绝对真理："我觉得这套数据模型风险很高，因为迁移会牵动 external API 和 billing。我们检验一下替代方案。"

## 2. 例子与反例

架构师离开时应该留下一个更强的团队，而不是一个对自己有依赖的团队。

### 例子：把 architecture review 当作教学

> 好教练不会替球队打比赛。他帮助球员看清整个场地。

review 里，架构师不下结论，而是提问：invariants 是什么、idempotency 放在哪、怎么迁移、partial failure 时会发生什么、哪些 metrics 能证明成功。团队自己锐化设计，并把结论写进 ADR。

下一次，团队会在没有架构师的房间里，自己问出其中的一部分问题。

### 反例：英雄架构师

> 如果一座桥只靠一个人每天手动拧螺丝才不塌，那就不是一座可靠的桥。

架构师亲自修所有难题、写最重要的几块代码、把所有决策装在自己脑子里、什么也不下放。外表看起来高效，内里却制造了 bus factor 和 learned helplessness。

真正的领导力，会降低对单个人的依赖。

#### 自检

- 哪些决策团队可以在没有我的情况下做出？
- 哪些 principle 替代了一再重复的争论？
- 最近一个月我把架构 reasoning 教给了谁？
- 我的参与在哪里变成了 bottleneck？

下一模块：[业务与产品](./software-architect-21-business-product)。