与 Shawna Martell 和 Dan Fike 一起去中心化决策
- Aisha Washington
- 2小时前
- 讀畢需時 7 分鐘
工程组织常说，希望团队能够自主行动。但在实践中，决策仍会不断上移、在会议中停滞，或取决于当时哪位资深架构师恰好有空。Shawna Martell 和 Dan Fike 描述了 Cartek 开发的另一种模式：先建立明确的工程战略，再授权值得信赖的技术领导者——称为 Navigator——帮助团队应用这一战略。
他们的方法将去中心化视为不止是授权。人们需要共享原则、足够的本地背景信息、获得经验丰富顾问建议的渠道，以及一种挑战或改进战略的方式。当这些要素协同发挥作用时，个人贡献者便能做出影响重大的决策，而无需让每个问题都经过管理层或集中式架构职能。
为什么自主性需要工程战略
Martell 和 Fike 将 Navigator 项目追溯到一个反复出现的问题：工程师希望获得更清晰的指导。没有一个达成共识的框架，团队就无法可靠地评估相互竞争的技术方案，也不知道应以哪些组织优先事项为准。
结果未必是糟糕的工程实践，而是不一致的工程实践。面对类似权衡的两个团队，可能会得出彼此不兼容的结论，因为每个团队采用的标准都不同，而且大多是隐性的。同样的争论一次又一次地出现，消耗时间，却无法形成持久的组织知识。
由中心统一批准每一项选择，确实能通过制造瓶颈来解决不一致的问题。相反，Cartek 试图让良好决策的依据得到广泛共享。其工程战略成为一个共同的参考点——一份记录组织如何评估权衡，以及在特定情境下通常重视什么的文档。
关键在于，这项战略源自工程师对背景信息的需求。Martell 和 Fike 并未将它描述为高管孤立制定的命令。它的目的，是让贡献者有信心采取行动，同时使他们的选择与更广泛的方向保持关联。
从现实出发，而不是从愿景海报出发
Cartek 流程中一个值得注意的部分，是强调记录决策实际上已经如何做出。团队并非从描述一个理想的未来组织开始。它首先审视当前状态，包括那些看起来不一致或难以辩护的实践。
这种组织考古很重要，因为每个工程团队都已经有一套战略，即便没有人把它写下来。它存在于反复出现的选择中：团队是为即时性能还是未来规模进行优化，是否接受运营复杂性以提高灵活性，或者是扩展现有系统而非创建新服务。
过去的设计文档和架构决策记录可以揭示这些模式。一份有用的记录会包含所考虑的备选方案、每种方案的收益和成本，以及某个选项最终胜出的原因。将多份记录放在一起看，就能显现这些选择背后的价值观。
Martell 和 Fike 将这些价值观与决策本身区分开来。决策说明某个具体案例中发生了什么。原则则提供可迁移到另一案例的条件性指导——实际上就是：“当这些条件适用时，优先采用这种回应。”提炼这类原则，可能需要重新了解旧决策背后的人和情境，尤其是在文档记录了结果却遗漏了理由时。
如实开始也让改变变得可衡量。理想化的战略或许听起来鼓舞人心，却会掩盖政策与实践之间的距离。对真实系统的描述建立了一个基线，组织可以据此有意识地变得更好。
Navigator 帮助团队读懂地图
该项目的名称体现了一个重要的责任分工。工程战略如同地图；Navigator 则帮助人们在陌生地形中解读它。他们会为战略作出贡献，但其主要职责不是发布总体计划，也不是亲自决定每一个技术问题。
在所讨论的时期，大约十几名 Navigator 支持着一个约有 400 人的工程组织。他们来自多个技术学科，包括前端和后端工程、可靠性与安全。他们在正式层级中的位置各不相同：有些人在团队内部深度参与，另一些则更接近高级领导层。
遴选标准与其说取决于头衔，不如说取决于已经展现出的判断力、技术深度和影响力。Martell 和 Fike 描述了一个与管理架构图并行存在的非正式网络。当问题模糊不清时，某些工程师自然会成为同事寻求建议的对象。Navigator 模式识别并连接这些值得信赖的人物，而非假定权威只会沿汇报关系流动。
Navigator 需要对身边的产品和系统拥有充分的背景信息。他们应了解哪些决策正在进行，识别工作何时与战略冲突，并在团队需要帮助时介入。这并不意味着接管控制权。Navigator 可以指导团队完成权衡、识别相关原则，或将尚未解决的问题带入更广泛的 Navigator 群体。
他们也在双向传递信息。战略帮助团队做出本地选择，而团队遇到的困难则揭示战略何处不完整。因此，Navigator 既是解读者，也是其持续修订的重要贡献者。
没有架构瓶颈的建议机制
Cartek 有意避免让正式架构师成为技术决策的强制入口。资深工程师可以在需要时承担架构工作，但组织不希望设置一个将决策权永久集中于一处的角色。
相反，其模式类似于一种架构建议流程。工程师可以在咨询受影响的人、具备相关经验的同事、书面战略，以及必要时的 Navigator 后做出决策。权威仍然是分散的，但咨询是被期待的。
该战略是集体建议的来源。它让经验较少的工程师也拥有一个可以用来检验提案的标准。例如，它可以澄清组织如何权衡性能与可扩展性，或维护成本与交付速度。
并非每个问题都能被简化为普遍性的指导。Martell 和 Fike 提到了这样一些选择：某项能力是应归入现有单体系统，还是值得创建一项新服务。组织可能有一个总体方向，却没有一条足以精确应对每种情境的规则。在这种情况下，战略应承认这种模糊性，并引导工程师进行知情咨询。
这保留了判断力，而不是用官僚流程取而代之。目标不是为未来的每个答案编码，而是让常规选择更容易，暴露真正困难的问题，并为人们提供一种一致的方式来推理例外情况。
战略应逐步变得不那么错误
Martell 和 Fike 将战略视为不断演变的工具，而非一套完成的教条。最初的原则必然存在缺口。有些会过于宽泛，另一些可能会在作者未曾预见的条件下失效。
真实决策会提供改进所需的反馈。团队将某个选项与战略进行比较，发现指导在哪些地方有帮助或失效，并通过其 Navigator 报告这些证据。随着时间推移，个别决策和共享框架都可以变得不那么错误。
允许有限的模糊性是设计的一部分。团队仍需要空间来发展适合自身系统和约束条件的本地“微战略”。Navigator 帮助确保这些本地方法仍与组织更大的方向兼容，而不会强迫每个团队采用完全相同的实现方式。
Navigator 彼此之间的关系强化了这一反馈循环。他们不会共同拥有每项决策，但当问题跨越领域时，可以咨询同行。他们兼具广泛的组织意识和深厚的专业知识，这对于涉及安全性、可靠性、平台架构和产品开发的跨领域问题尤其有用。
去中心化也是一种导师机制
只有当更多人学会如何行使权力时，分配权力才会奏效。因此，Navigator 角色包含一项隐含的教学责任：如何识别权衡、寻求恰当建议、记录推理过程，以及在信息不完整的情况下作出决策。
这对那些此前未被信任去做高影响力选择的工程师尤其重要。如果每一项重要提案后来都会被一个难以接触的资深小组推翻，仅仅告诉他们“主动负责”是不够的。Navigator 可以让推理过程变得可见，并在让决策贴近实际工作的位置的同时支持贡献者。
Martell 和 Fike 也将 Navigator 视角与管理视角区分开来。管理者必须在人、交付和团队执行之间取得平衡。Navigator 则提供深入的技术判断，并将本地工程选择与全组织战略联系起来。这两种视角应当相互补充，而不是合并为单一角色。
候选人会因其既有贡献而获得认可，并由高级领导者提名，而非通过传统流程申请。仅有技术公信力还不够。不愿培养他人或分享判断的人，将难以实现该计划的目标。
通过更好的决策衡量成功
去中心化的价值体现在具体的决策结果中。Martell 和 Fike 描述了这样一个团队：他们正在考虑为多个领域中都存在的问题构建一项新的共享平台服务。一个表面上看似合理的应对方式，可能是构建一个通用解决方案，然后着手开展一项漫长工作，以争取每位利益相关者的同意。
一位 Navigator 将该提案与组织战略进行了比较，并得出结论：一刀切的平台并非首选方向。由于该战略本身已经代表了一个达成共识的默认方案，Navigator 可以在无需从头重建整套论证的情况下解决这个问题。
这说明举证责任发生了有意义的转变。与其让倡导者反复说服他人某个方向是正确的，已记录的战略提供了起始立场。偏离仍然是可能的，但需要有令人信服的解释。
有用的进展指标包括：更快的决策、更少不必要的升级、更清晰地记录在设计文档中的推理，以及贡献者更强的信心。定性信号同样重要：工程师应当感到不再那么迷茫，而反复出现的争论应越来越多地产生可复用的原则，而非又一次临时妥协。
工程领导者如何开始
Martell 和 Fike 明确指出，在阐明战略之前任命 Navigator 不太可能奏效。没有一张共享地图，受信任的个人可能只是更高效地分发自己的个人偏好。
领导者可以从审查过去的架构决策和当前的设计文档开始。他们应识别反复出现的权衡，先写下争议最小的原则，并审视所声明的价值观与观察到的行为之间的差距。对这份记录感到不适是有用的证据：它指向了组织可能希望改变的实践。
一个实用的顺序是：
记录具有代表性的决策及其推理过程；
从反复出现的模式中提炼条件性原则；
识别当前实践与期望方向相冲突的领域；
找到已经在为他人提供建议、且受人尊敬的技术贡献者；
将这些人置于能够连接本地工作与组织战略的位置；
随着实际决策暴露遗漏或矛盾，修订该框架。
更深层的教训是，去中心化依赖于判断力基础设施。书面原则提供一致性，Navigator 提供背景与指导，而团队则贡献让系统保持扎根于现实的证据。共同作用之下，这些机制让权力能够更贴近实际工作，同时不让组织碎片化为彼此不兼容的技术方向。
