聪慧的工程师在架构上会有分歧，这是健康的。技术领导的职责是将分歧转化为一个良好的决定和一个坚定的团队，而不是赢得争论。一旦大家就标准达成一致，大多数争议就会烟消云散。
解决问题的流程
text
1. AGREE on the criteria first — what are we optimizing for?
(scale, simplicity, time-to-ship, team familiarity)
2. Let each side make its STRONGEST case — steelman, don't strawman
3. Look for DATA — spike it, benchmark it, prototype it
4. If still tied — the TL decides, and explains why
5. DISAGREE AND COMMIT — once decided, everyone rows together
一个具体的例子
两位工程师在微服务 vs. 单体应用上争论。你重新定义问题："在接下来的一年里，我们要优化什么？" 答案是用小团队快速交付，这使单体应用成为明显的选择。这个争论实际上是围绕一些未声明的目标。
何时决策 vs. 何时推迟
对于可逆转的决定，快速选择一个并继续前进，做出错误决定的代价很小。对于单向决定，放慢速度并收集数据。将深思熟虑与可逆性相匹配可以避免无谓争论和鲁莽决策。
一个陷阱
不要用你的资深身份压制辩论，也不要让辩论无休止地进行。两者都会对团队造成伤害：前者会引发怨恨，后者会导致瘫痪。