对（亚马逊式）领导力的思考
亚马逊的领导力原则非常有名，不仅限于亚马逊内部，在整个科技界也是如此。虽然它们经常被嘲笑——包括被亚马逊员工自己——但它们通常也是运营公司的合理准则。我作为亚马逊客户已经超过25年，作为AWS客户将近20年，并且担任AWS Hero已有6年。尽管我从未为亚马逊工作过，但我觉得我对幕后情况了解得足够多，可以对其中一些原则发表一些评论。
客户痴迷
领导者从客户入手，逆向工作。他们积极努力地赢得并保持客户信任。虽然领导者关注竞争对手，但他们痴迷于客户。
客户痴迷是件好事，但我经常看到亚马逊员工将其理解得过于简单：“从客户入手”并不一定意味着“询问客户想要什么，然后给他们更快的马”。在AWS早期，我看到了很多我称之为“酷炫工程驱动”的产品：EC2推出时，人们并不清楚用它来做什么，但它非常酷，而且很明显它迟早会以某种形式成为一件大事。大约在2012年左右，AWS的文化似乎从“提供酷炫的构建模块”转变为“构建客户要求的东西”，在我看来，这是朝着错误方向迈出的一步（请注意，远不及大约2020年向“构建分析师在季度财报电话会议上要求的东西”的转变那么严重）。
客户要求什么与客户真正需要什么之间的这种张力，在弹性等领域体现得很明显。亚马逊的“完善架构框架”强烈劝告客户避免在单个可用区构建生产工作负载——但亚马逊的跨可用区带宽定价令人痛苦，而且亚马逊没有为构建耐用的多可用区应用程序提供有用的工具。大多数客户不会去实现Paxos，而极少数客户——尤其是那些远离实际开发流程的高管们——更不会向亚马逊要求Paxos即服务；但如果亚马逊员工坐下来问自己“客户需要什么才能很好地设计他们的应用程序”，他们很可能能想出亚马逊内部已经存在的几项服务。AWS应该回归本源，发布重要的构建模块——客户需要的东西，而不一定是他们正在要求的东西。
主人翁精神
领导者是主人。他们着眼长远，不会为了短期结果而牺牲长期价值。他们代表整个公司行事，而不仅仅是自己的团队。他们从不说“那不是我的工作”。
在我看来，这个原则既过于狭隘，也没有得到履行。仅仅代表整个公司行事是不够的：重要的是代表整个技术生态系统行事。一些亚马逊员工在这方面做得很好——我最近向FreeBSD的bhyve提交了补丁，因为一位亚马逊员工正在为大型虚拟机中的中断处理制定标准，尽管亚马逊并没有使用bhyve（至少，我认为没有！），但他理解让标准在整个虚拟化领域被广泛接受的重要性，而不是狭隘地局限于亚马逊所依赖的代码中。计算机安全领域有句谚语，让其中一个人更不安全，就会让我们所有人都不安全：攻击者会利用一个系统的漏洞来攻击另一个系统。虽然同样的情况并不直接适用于其他领域，但与他人合作，为每个人创造最佳结果，从长远来看，要比仅仅关注亚马逊当前的需求要好得多。
但总的来说，亚马逊甚至没有兑现其（狭隘的）承诺，即让领导者代表整个公司行事——它太过于各自为政了。亚马逊以保密著称，这在内部和外部都适用：当AWS推出两项类似的服务时，通常是因为两个团队不知道彼此正在做什么。如果没有人知道团队之外发生了什么，领导者如何能在整个公司范围内行事？他们不能；如果亚马逊希望让最优秀的人成为真正的主人翁，亚马逊就需要开始打破壁垒。
崇尚行动
速度在商业中至关重要。许多决策和行动是可逆的，不需要广泛研究。我们重视经过计算的风险承担。
亚马逊员工谈论“单向门”和“双向门”，确实许多决策是可以逆转的……但这并不总是意味着逆转决策没有代价。“崇尚行动”与另一个原则“坚持最高标准”之间存在明显且广为人知的张力；但在此与赢得并保持客户信任之间也存在张力。当AWS推出一项半生不熟的服务时，它会削弱客户对整个AWS的信任；即使该服务中的问题最终得到纠正（通过修复，或者在某些情况下，直接撤销掉一个本就不该存在的服务），失败的发布记忆仍将在客户心中留存多年。
在我担任FreeBSD安全官的七年任期内，人们都知道我是发布安全公告的人；但我做的最重要的事情不是发布安全公告——而是叫停火车并说“不，我们暂时不会发布这个”。我知道，尽管及时让人们拿到补丁很重要，但建立信任更为重要：如果我给了人们一个有问题的补丁，哪怕只有一次，他们将来安装安全更新的速度就会慢得多。我的团队对“说服我相信这是正确的”这句话很熟悉，我希望在亚马逊的高层看到更多这样的情况：首席工程师和杰出工程师需要带着“不作为的偏见”介入，并利用他们赢得的尊重，在那些不符合最高标准的项目损害信任之前将其叫停。亚马逊的招聘流程以包含可以否决招聘决定的“提升标准者”而闻名；他们也应该有可以否决服务发布的“服务标准提升者”。
Werner Vogels在他2024年的re:Invent主题演讲中说过一句名言：“倾听AWS英雄们的声音”。我想他指的是技术建议，也许主要是对AWS客户说的；但我愿意认为，亚马逊或许也能从我所表达的一些观点中获益。我们批评，是因为我们在乎。