对（亚马逊式）领导力的思考
恶魔派遣
Colin Percival的随想
对（亚马逊式）领导力的思考
亚马逊的领导力原则不仅在公司内部，在整个科技界都享有盛名。虽然经常被嘲笑——包括亚马逊员工自己——但这些原则通常是运营公司的合理准则。我作为亚马逊客户超过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 Hero们的"。我认为他指的是技术建议，可能主要是对AWS客户说的；但我愿意认为亚马逊也可能从听取我在这里说的一些话中受益。我们批评是因为我们在乎。
发布於 2025-09-01 00:30 | 永久链接 | 评论