何为领导力

Kindle背后的故事

我有一本 Kindle Oasis，它是 2019 年发售的 Kindle 家族产品，有着不错的分辨率和翻页性能，拿在手里既不太轻也不太重。我经常随身带着，用它来读书，在高铁、地铁、出租车上、睡前等等。由于它是电子墨水屏，又自带了很多小的灯源，因此几乎能适应任何光线环境。Kindle 自带的字典功能，使得查阅生词不会太严重地影响阅读体验，因此很大程度上让我有勇气去更多地阅读一些英文书。当然，Kindle 最著名的功能是压泡面，可惜随着外卖的流行我也很少吃泡面了，这功能也就没怎么用上。

在今天我们看来，亚马逊 Kindle 业务的成功似乎是理所当然的，但是在我读了《Working Backwards -- Insights, Stories, and Secrets from Inside Amazon》（后面简称 《WB》）之后，才对 Kindle 成功背后的关键因素有了一些了解。

贝索斯是在 2004 年1月开始决定把数字媒体业务提升到战略高度的。据称是他受邀参加了乔布斯的一次会议，看到乔布斯竟然为了 Apple 的数字音乐业务，开发了 ITunes on Windows，深受触动。2004 年不像今天，那时候大多数人都是看实体书，听音乐买 CD，看电影买 DVD 或者去电影院，但是天才如乔布斯用 iPod 这一我现在想起来还禁不住激动的产品，给数字媒体点了一把火。

但贝索斯终究是贝索斯，他不像那些普通的 CEO，看到苹果成功了，就想着直接复制一个类似的产品去追赶。他的第一反应不是决定做什么，而是决定让谁做，以及怎么做。

亚马逊当时是有一个小团队做数字媒体业务的，但那个团队很小，产品经理距离贝索斯的汇报关系有六层。贝索斯的决定是把原来和他隔一层汇报的 Steve 拉出来专门负责数字媒体业务，并调整成直接向他汇报。他没有让 Steve 在负责原来业务的基础上，同时管理数字媒体，而是让 Steve 专心负责数字媒体业务，并且把这个业务的重要性提升到了直接汇报的高度，这就是亚马逊领导力原则 Single-Threaded Leadership（STL）的绝佳体现。

为什么亚马逊选择做了自己的硬件？要知道在此之前亚马逊可没有任何硬件经验。这背后实际上是有围绕用户体验做深入业务分析的。

在销售实体书的时代，亚马逊相比实体书店有两个核心竞争力，第一是选择的丰富性，在一个网站上可以找到几乎所有的书籍；第二是低价，由于不需要实体书店，以及亚马逊不断优化的库存效率，书籍有较大的价格优势。而亚马逊意识到，进入到电子书时代后，这两个优势将荡然无存。在电子书这个业务中，任何一个公司可以很快搭建平台，建设图书类目，由于不需要库存管理等因素，大家的价格竞争力也都没什么差别。而贝索斯认为，在这个新的业务中，价值的核心在两头，一头是内容，另外一头是阅读体验。而在当时，大家都在 PC 上读电子书（后来有了 iPad 等），阅读体验实在是不好。

因此，亚马逊为了给用户极佳的阅读体验，选择了做自己从未做过的硬件领域，想清楚了，并坚定地长期投入。在执行的过程中，大多数核心团队之外的人都不太能接受亚马逊做硬件，对此提出各种各样的疑问。这里还有一段有趣的对话：

在 2005 年的时候一次财务分析会上，大家在讨论 Kindle 这一业务持续增长的开销，在讨论的过程中，有人非常直接问 Jeff（贝索斯）：“你还愿意在 Kindle 上投多少钱？” Jeff 沉静地转向 CFO Tom，微笑着，耸耸肩，问了一个富有戏剧性的问题：“我们还有多少钱？”

“我们还有多少钱？”贝索斯的确是个有意思的领导者，当然，同样重要的是他对用户体验的执着，即亚马逊领导力原则中的 Customer Obsession，他对 Kindle 团队提的要求是“让读者感觉不到设备的存在”：

Jeff 告诉团队他们有一个大胆的目标，就是改进一项已经经受 500 多年时间考验且没发生太大的变化的发明：书。在设计阶段首先要考虑的是，这款阅读器应该 “让人感觉不到存在”，让读者可以直接和内容建立联系。一旦这个人开始阅读，他们就不应该注意到自己在使用一个设备。

Kindle 在一定程度做到了，感谢亚马逊，让我可以更方便的阅读。

单线程领导力（Single-Threaded Leadership）

在 Kindle 背后的故事中我们了解到，当贝索斯决定把数字媒体提升到战略高度后，他首先做的是让 Steve 去领导这个业务，并且只领导这个业务，并直接向他汇报。原来 Steve 是汇报给 SVP Diego，Deigo 再汇报给贝索斯。贝索斯没有让 Steve 在处理实体书业务的同时，去发展数字媒体业务，因为那样做的话，相比当时的营收情况，数字媒体业务就永远排不上优先级。

这就是亚马逊单线程领导力原则，即：一个人，没有其他冲突的职责，对一件单独的事负责，可以独立领导一个单独的、很大程度上自治的团队，交付自身的目标。

这话说起来容易，做起来难，因为这背后凸显的是上层领导者的选择。如果你仔细琢磨，会发现这句话和我们公司文化中的一句土话 “既要，且要，还要” 是存在冲突的，后者对于上层领导来说很简单，但对于执行者来说，就往往意味着必须完成一堆目标，但每个目标的质量都（可能）被牺牲，而且执行者还得从各种角度去揣测和琢磨上层领导的判断，以免丢了领导心中真正重要的目标。

《WB》中描述了一个没能实现 的STL 场景，因为这个场景太典型了：

在一个 Jeff 参加的业务月度汇报会议上，某个新项目状态为红色（停滞），有人问是什么原因导致没有进展？

- 总监X：这个项目有很多部分，我们已经看到了5个没有解决的问题并且正在解决，这五个问题是……

- Jeff (打断)：在我们谈这些具体问题之前，谁能告诉我谁是这个事情的single threaded leader？

- 业务线VP：是我- Jeff：但是你是整个业务的负责人，我需要你专注整个业务整体结果而不是这个具体项目

- VP 1 (汇报给业务线VP)：那应该是我吧

- Jeff：这个项目是你和你的团队每天工作的全部内容吗？

- VP 1：不是的，我们目前只有一个产品经理是全职负责这个事情，但是我们其他兄弟都在帮他。

- Jeff (不耐烦)：这个产品经理是不是有足够的能力和权威，以及有团队资源来保证这个项目完成吗？

- VP 1：没有，所以我们打算招一个总监来带这个事情。

- Jeff：你打了多少个面试电话，做了多少现场面试来招聘这个新总监？

- VP 1: 我们还没有开放这个职位呢，我们正在准备JD，还没有开始招聘。

- Jeff: 开什么玩笑，这个新的 leader 不到位这个项目就不会有真正的进展，这才是导致项目停滞的真正原因（而不是那5个问题），让我们先解决招聘的问题。

- VP 1：好的，我们先招聘（开始准备招聘文档）

这个场景的前半段几乎每天都在我们的工作中发生。一件事情进展不如意，老板问谁在负责，员工 A 说是我，可老板一看他身上负责的事情已经有三四件了，然后员工 A 说我指派给我下属 B 了，可 B 的核心目标也不是这件事，然后这件事就继续这么没进展下去。当然，可能的解法有很多，一种方案是像案例中这样，去招聘；另外一种方案是，让 A 或者 B 放弃一些次要目标，把这件事情作为他的核心目标。

除了明确某个重要的事项有人把它作为最高优先级承担且这个人有足够的权力和资源之外，亚马逊发现要落实 STL 还有一个很大的障碍，那就是依赖（Dependency）。

Colin 在书中介绍了两个依赖的例子，第一是为了完成手中的工作，需要协调很多团队去修改其他团队负责的代码；第二是对一个共享的数据库做一些修改，需要排队等着几个非常高 Level 的工程师审计。这种情况不是亚马逊所独有的，几乎所有达到一定规模的公司都会面临这个问题。在我们公司也有大量的相关讨论，我曾在一篇文章发表过一点评论，其中核心的观点是：

面对复杂的组织协作，大家都在讨论“如何更好地管理阻塞队列”，但是管理得再好，阻塞还是阻塞，而阻塞是依赖引起的，而且这是直接影响效率的“团队/部门间，人力资源投入的依赖“。我们需要一些“战役”，“勇气“，”拼搏“等偏价值观的东西，来引领大家更好的协作，但是协作效率需要科学的分析和诊断，跨部门、跨团队因为缺乏信任，沟通带宽低，目标不一致，协作效率必然会受影响，而不需要协作肯定是最有效率的。因此架构的设计，技术的演进，应该把”不需要人肉协作”作为一个重要的目标。

亚马逊的做法无疑也印证了我的观点，因为《WB》在“组织”这一章中有一节的小标题是“更好的协作是错误的答案”，亚马逊的领导层最终意识到了，所有跨团队的沟通工作需要的不是优化，而是消除。而 Jeff 的愿景是，组织内部的交互应该是松耦合的，应该通过良好定义的 API 来实现机器的交互，而不是通过人肉的电子邮件和会议。

Github 上有一篇非常有意思的文章印证了 Jeff 是如何执行这一愿景的，这篇文章的题目是《Stevey's Google Platforms Rant》，文章的作者在亚马逊和 Google 都工作过，文章内容有一些对 Google 的吐槽，但核心是一则 Jeff 在 2002 年左右发布的命令：

1. 从今往后所有团队必须通过服务接口暴露他们的数据和功能。 2. 团队直接的交互必须通过这些接口。

3. 任何其他形式的进程间通讯都是不允许的：禁止直接链接、禁止直接读取其他团队的数据存储、禁止共享内存模型、禁止任何形式的后门。唯一允许的通讯是经过网络的服务接口。

4. 用什么技术不重要。HTTP, Corba, Pubsub, 自定义协议 —— 不重要。贝索斯不关心。

5. 所有服务接口，没有任何例外，在最初设计的时候就需要考虑对外使用。意思是说，在团队计划和设计的时候，就要考虑这个接口是给外部世界的开发者使用的。没有例外。

6. 不这么做的员工会被开除。

7. 谢谢；祝好！

这几条指令非常有戏剧性，但如果我们深入思考一下，就会意识到这是多么天才的想法。首先，它在很大程度上解决了大规模组织协同的效率问题，这种解决方法不同于 Google 等公司对工程质量的严苛要求，但是有效；其次，它也在一定程度上催生了亚马逊今天最成功的业务：AWS。书中也有一章讲述 AWS 初创的故事，最早亚马逊做 Web Service 是面向开发者开放接口以带动电子商务的业务，但后来令他们感到巨大意外的是：这些面向外部开发者的服务的用户，竟然有一部分是亚马逊内部的工程师！想想这是多么有意思的情况。

六页纸和开会

《WB》书中有一章是讲“沟通”的，里面的核心是用六页纸的文档替代了传统的 PPT。hmm，我们公司的 PPT 文化也是非常厉害的，但是近期有着明显的转变，就我个人来说，我在这个财年写的 PPT 应该比上个财年少了许多，当然我写的以及 Review 的文档数量是增长了不少，通过内部工具的数据可以得到印证。

六页纸是如何实行的我就不再赘述了，大家可以阅读这本书深入了解，但是作为一个曾经做过很多演讲写过很多 PPT 的人，我还是想提醒一下大家 PPT 的问题：

1. PPT 表述非常依赖演讲者的技巧，语言，音量，吐词，表情等等，这些技巧对听众有着非常大的影响力，但是和内容的质量无关。
2. 不严谨的图是无法清晰地描述逻辑的，而我们看到的大量 PPT 中的图，基本上都是不严谨的。
3. 那种中间分两三层，放几个框；边上放两个框；自己部分画得最大的“麻将图”，基本都是无用的。

我在公司另外一个同事写的《一个中国工程师眼中的亚马逊》这篇文章的评论区中这么写道：

维特根斯坦在其著作《逻辑哲学论》中有这么一句话：「可以言说的东西都可以清楚地加以言说，而对于不可谈论的东西，人们必须以沉默待之。」维特根斯坦认为语言是混乱的东西，这种混乱带来了大量的问题，无谓的辩论误解等等，因此需要用逻辑哲学去明确，他构建了一整套给予严密逻辑的逻辑语言，每句话都是一个观点，观点上再构建观点，等等。所以整个体系没有一句不清楚的话，也没有一句废话。他的逻辑哲学和计算机的体系原理很接近，计算机是没法构建在不清晰的逻辑基础上的。

回到我们的开会、晋升答辩、沟通等各类事情上来。各种低效、混乱，根因就在于大家用语言和 PPT 描述事实的时候，含混不清，有些甚至故意制造混乱，意图用非逻辑的部分影响听众。我觉得这些就是应该“以沉默待之”的部分，语言应该表达观点，观点必须建构在逻辑之上，可以有假设，但需要尽量证明假设。

当然，以维特根斯坦的标准来要求写六页纸，未免过于严苛，也不现实。但是我的确在我的团队范围（包括我的 TL 谷朴在他的团队范围）实行了文档文化，稍微大一些的特性都要求先写方案设计，经过 Review 后才开始开发。方案设计清晰地记录了软件设计背后的意图和取舍，也会有相关的讨论，而这些信息，光看代码往往很难获得。

与之对照的例子是：近期我团队接手了很多遗留系统，大家在这些系统上修修补补，在上百万规模的代码中修 BUG，当大家问前一任接手这些代码的同学有没有相关文档的时候，得到的回答是：“四个字，口口相传”。

进一步的，我们也基于此方法提升了开周会的效率，现在我团队十多人一起开周会，都能在一小时内完成，具体开会的方法是：

1. 会前每个写好 update （200-300 字），重点更新进展风险和需要协作的内容
2. 开会前 15-20 分钟静默阅读，有问题的写 comments
3. 对于 comments 讨论 15-20 分钟
4. TL 做外部信息同步（例如招聘进展、和团队相关的项目进展、和我们相关的组织变动等等）

运行了一段时间，我发现这种形式比较以前有效率多了，但同时我也发现，很多人的写作水平是真的需要提高😖。其实技术写作远比很多人想象得难，因为一方面 Writing is Thinking，写作是一个思考的过程，如果思考不清晰，写出来的东西自然容易一团浆糊；另外，写作技巧是需要锻炼的，Google 的 《Technical Writing Courses for Engineers》是一个不错的学习材料，推荐给大家。

亚马逊的度量

全书的第六章，“度量，管理你的输入，而不是你的输出”，是整本书对我影响最大的部分，我读了不下三遍，并且基于书中的思路调整我团队的工作方法。没有买书的同学也可以阅读网上公开的《This is How Amazon Measures Itself》这篇文章，文章基本提炼了这一章核心的内容。

很多人说亚马逊可以做很大长期的投入和创新，是因为亚马逊不关心盈利。作者说了，不是这么回事，盈利对于亚马逊和其他公司一样重要，除了盈利指标外，还有周度的营收、总用户数、会员订阅数、股价、现金流等等。但是有一点大家得认识到，这些指标都是结果指标。结果指标很重要，但是你无法长期用一种持续的方法去操控它们。

但是我们总得度量点什么，因为如果没有度量，何谈改进呢？彼得·德鲁克也有句名言：“You can't manage what you can't meature”，我们做需求总不能都是凭感觉，拍脑袋，又或者是哪个客户的嗓门大就听谁的。亚马逊的答案是：重点关注可控输入指标(controllable input metrics)，可控输入指标的例子有：选品、价格、或者便捷度，这些亚马逊是可以控制的，例如给类目添加商品，控制成本以降低价格，或者调整库存来提升发货的速度。

通过书中的案例和分析，我对度量这个事情也做了一点总结：

1. 不要过度关注结果指标，因为即便你关注了你发现也做不了什么，影响结果指标的因素太多了。
2. 度量的目标一定是为了改进，是为了改进，是为了改进，想清楚你想改进什么。如果度量的目的是为了考核，这个度量基本就会失去意义。
3. 找到合理的 Controllable Input Metrics 并不容易，需要持续去思考业务，不断改进。
4. 获取准确的度量数据，是需要很高的成本的。因此做这个投入前一定要先想明白要改进什么。

我是负责运维基础设施平台业务的，这个业务的一个核心模块就是发布。我们之前有过统计用户的满意度（典型的结果指标），但是这个指标数据其实没有办法清晰地指导我们如何做改进，因此我和团队一起讨论如何制定我们的 Controllabe Input Metrics，最终我们确定先用流畅发布率、发布关注时长、发布操作次数这几个我们相对可控制的指标来度量这个业务。以发布关注时长为例，我们要统计用户在发布页面、日志页面、web shell 页面停留的时间，这本身消耗的时间精力就比我们预期的长很多，然后再想办法通过优化出错的提示，提高系统的性能，来让用户更快地获取反馈，进而降低关注时长。我们认为这是一个可度量，也可以帮助我们改进的指标。

作为技术同学，其实我们早已经习惯度量各项技术指标了，典型的 QPS，RT，系统资源的利用率等等。但就我来说，这种技术的度量思维和《WB》中所阐述的度量还是有很大的差距，这里的核心就是：你的度量是不是面向用户体验设计的。

技术同学往往会迷醉于高性能，大规模，这本没有错，但是如果我们把视角转向用户，或者说把思维方式转向业务，那么对于度量的理解也会发生变化。我们可以这么问：这个技术指标提升了，对于用户来说意味着什么？又或者更好的问法是：现在用户最关心什么？他关心的这个点，可以用哪个度量指标来体现？这个度量指标的改善，可以进一步分解到哪个技术指标？而后者的问法才是 Working Backwards 的做法，从用户体验出发，推导我们的工作。同时我们也必然会发现，理解机器的行为是不够的，还必须理解用户的行为。

小结

《Working Backwards》是 2021 年对我影响最大的书之一（其余的几本有《逻辑哲学论》《Metaphors We Live By》《道德情操论》），作者 Colin 在 1998 年加入亚马逊，一直工作了 12 年，另一位作者 Bill 在 1999 年加入，在亚马逊工作了 15 年，他们在亚马逊都是很高层的 Leader，在 Jeff 身边参与或者见证了很多决策，并深入理解这些决策背后的思考。因此这本书显得非常生动，作者讲述的是真实的故事，没有一点说教的感觉，阅读的体验就非常好。

最后，我发现一个有意思的事情，Colin 离开亚马逊后去了新加坡，并做了 RedMart 的 COO，后来这家公司被我们公司阿里巴巴收购了。

延伸阅读

• 《Working Backwards: Insights, Stories, and Secrets from Inside Amazon》 https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets-ebook/dp/B08BYCQBZN
• 《Stevey's Google Platforms Rant》 https://gist.github.com/chitchcock/1281611
• 《This is How Amazon Measures Itself》https://www.holistics.io/blog/how-amazon-measures
• 《Technical Writing Courses for Engineers》 https://developers.google.com/tech-writing
• 《“Writing is Thinking”—an annotated twitter thread》 https://medium.learningbyshipping.com/writing-is-thinking-an-annotated-twitter-thread-2a75fe07fade