在高级工程师关于管理技术质量的章节中，最后的建议之一是创建一个集中流程来策划技术变更：
使用架构审查、投资策略和采用新工具的结构化流程来策划技术变革。大多数不一致来自于缺乏背景，而这些是将背景注入决策的组织杠杆点。许多组织都是从这里开始的，但这是我建议打开的最后一个工具箱。如果没有明确的愿景，如何提供一致的架构审查？为什么要在人们设计完某些东西之后而不是在他们的入职过程中告诉他们你的策略呢？
正如引文中提到的，这是最后的建议，但并不是因为它是最终的选择。相反，这是因为我发现中心化的团队（通常称为架构团队或类似的东西）在实践中往往表现不佳。有时他们效率低下，有时他们做出错误的选择，有时他们根本没有做太多事情。 （我在扩展一致性中记录了这些架构团队面临的一些最常见的挑战。）
今年早些时候我加入 Carta 后，我们花了一段时间探索可以让工程师更轻松地完成高效工作的领域。出现的一个主题是工程中的技术决策：
- 许多工程师不同意组织其他部门做出的决策，特别是认为决策不一致
- 谁负责业务的任何特定部分的技术决策是可以解释的（人们大致同意，但如果你问四个负责制定重要事项决策的人，你通常会得到至少两个名字）
- 当两个团队在技术决策上存在分歧时，除了将问题上报给 CTO 之外，还不清楚如何解决该问题
这里的标准策略是首先记录最佳实践，希望这足够了，然后不情愿地建立一个架构团队来管理升级。在像 Carta 这样拥有约 400 名工程师的公司中，调整最佳实践确实是一项需要不断升级的工作。这是因为最佳实践依赖于环境，而在这种规模的组织中不存在通用的环境。最佳实践是全局优化和局部优化之间的平衡，对于某些团队来说，一些已决定的最佳实践在局部肯定会更糟糕。
这意味着我们要么需要建立工作组来决定每个最佳实践领域，要么决定一个架构团队作为我们想要编纂的全套实践的“常设工作组”。 Carta 拥有一大批非常有才华的工程师，所以我们当然可以建立一个架构团队。
然而，有一个小问题：我。我相当不喜欢架构团队。
这并不是说架构团队不能优秀，我曾与许多非常优秀的团队合作过，但即使是最好的团队也会因共识而放慢速度，并遭受共识驱动决策的缺点（特别是针对可接受的决策进行优化，而不是针对可接受的决策进行优化）。比最佳决策）。我还发现，即使有直接辅导，共识驱动的团队也很难改进，因为通常很难确定该辅导谁，而且责任也有点不稳定。
因此，我们采用了我已经尝试过几次的模式：导航器。 Navigator 的核心结构如下：
- 每个主要业务领域都有一名导航员（我们一开始大约有十名）。该 Navigator 是该领域内编写和操作的软件的积极贡献者
- 给定区域只有一个导航器；导航器不重叠
- 每个导航员对其领域内做出的技术决策完全负责。他们不仅仅是负责，还可以做出决定。这包括解释组织战略以在其背景下正确应用它
- 在实践中，大多数真正的问题都是技术、优先级和人员限制的交叉点。导航员负责在做出技术决策时与所在领域的领导层保持一致
- 每个导航员在决策和解释组织战略时完全向 CTO 负责
- 导航员是其区域内技术考虑的升级点，一对导航员是跨区域问题的升级点
- 如果一对导航员无法解决跨领域问题，或者导航员和人员经理无法解决技术-社会问题，那么 CTO 就是升级点
我们已经在这种模式下运行了大约六个月，我必须承认我认为它运行得很好。拥有一个责任明确且所有人都同意负责的政党是非常强大的。虽然发生了一些混乱的对话，但我们知道谁对什么负责，而且我们能够坐下来进行这些对话。之后，我们就能够改进，并在下一组对话中做得更好。 （我很少看到架构团队快速改进，但我看到导航员快速改进。）
导航器模式是如此明显，而且根据我的经验，它比其他模式要好得多，值得扪心自问为什么我们不经常看到它。我的简短回答是，我认为，如果我们为高级工程师提供必要的背景并让他们去做的话，这个行业就会不断低估他们所能做的事情。相信工程师能够做出真正重要的决定被认为是一种激进的行为，但事实并非如此。只要我们愿意让工程师承担重要角色，那么信任他们并不比信任组织中的其他任何人更激进：存在一些风险，但这是值得承担的风险。