Shopify 如何打造高强度文化 | Farhan Thawar（工程副总裁兼工程负责人）

Farhan Thawar 2024-12-19

Shopify 如何打造高强度文化 | Farhan Thawar（工程副总裁兼工程负责人）

文字记录

精选片段

Farhan Thawar： 如果你走了艰难的路却没有成功，实际上你依然赢了——因为你完成了一件难事，很可能和聪明人共事过，在这个过程中学到了有价值的东西。我见过很多求职者，我会问，你们在怎么找工作？每天投十份简历，你真的能学到什么吗？为什么不看看 API 文档，自己动手做点东西？即使你没能在 Shopify 找到工作，你也学到了东西。

Lenny Rachitsky： 首先，我想聊聊另一个主题——在组织中打造高强度文化。

Farhan Thawar： 每个人都说”哦，年轻时多努力、多加班什么的”。我的想法是，如果你每分钟能做更多事呢？

Lenny Rachitsky： 我越深入挖掘 Shopify 的工作方式，就越发现一些出乎意料的有趣做法。比如他们一直在推动删除代码、简化系统。

Farhan Thawar： 我们有一个删除代码俱乐部（Delete Code Club），几乎总能找到超过一百万行代码可以删除，这太疯狂了。

Lenny Rachitsky： 我发现你有一句很精彩的话——“不是每个人都能一次又一次地在公开场合显得愚蠢，但我相信这是我的超能力。”

Farhan Thawar： 我在很多场合面对过很多厉害的人，他们曾对我说，那是我听过最蠢的该死问题。我的目的不是要惹恼对方，而是想理解内容本身。

Lenny Rachitsky： 我看了你的 LinkedIn 和职业履历，发现你人生中每个十年都在为不同的亿万富翁工作。

Farhan Thawar： 他们大多是不同的人，但有一点是相似的，那就是他们都没有……

嘉宾介绍

Lenny Rachitsky： 今天的嘉宾是 Farhan Thawar。Farhan 是 Shopify 的工程副总裁兼工程负责人。Shopify 是一家非常有趣的公司——他们拥有超过一万名员工，全部远程办公；尽管公司成立将近二十年，依然保持着紧迫感和高速度，并以非常第一性原理的方式思考问题。这体现为他们创纪录的使用量、最近在财报电话会上远超预期的表现，以及打造了一款深受用户喜爱的产品。这在很大程度上归功于 Farhan，他在我们的对话中非常具体地分享了他在工程团队中维持强度和紧迫感的一系列做法，包括会议节奏、结对编程的反直觉力量、他们如何运作会议、如何不断取消会议，以及更多内容。他还分享了在面对多个选项时倾向于选择更难选项的经验，以及为什么这最终会让生活变得更轻松。他还分享了很多出色的招聘建议和令人惊叹的招聘故事，还谈到了他们的工程实习生项目——仅2025年的实习生项目就计划招聘超过一千名工程师。我在这档播客上邀请过很多来自 Shopify 的人，这是有充分理由的——因为这家公司及其领导者在如何经营出色业务、打造出色产品方面有很多值得我们学习的东西。如果你喜欢这档播客，别忘了在你最喜欢的播客应用或 YouTube 上订阅关注，这是避免错过未来节目的最佳方式，也对播客帮助极大。接下来，有请 Farhan Thawar。Farhan，非常感谢你的到来，欢迎来到播客。

Farhan Thawar： 谢谢邀请。

三大主题：招聘、高强度与艰难之路

Lenny Rachitsky： 在准备这次对话的过程中，我和你过去多年共事过的很多人聊过，基本上有三个主题反复出现——招聘、在组织中打造高强度文化，以及选择艰难之路。首先，这准确吗？其次，我们就围绕这三个主题来聊，你觉得怎么样？

Farhan Thawar： 是的，我对这三个主题各自的来源都有一些想法。我觉得如果你回顾我的职业生涯，我在每一方面都留下了印记，但我不认为我从一开始就知道自己在做什么。不过回过头来看，那确实是我最终走过的路。

Lenny Rachitsky： 完美，这就是乔布斯说的——回头看时一切都能串联起来。

Farhan Thawar： 是的。

选择艰难之路

Lenny Rachitsky： 好，让我们从选择艰难之路开始聊起。

Farhan Thawar： 好。

Lenny Rachitsky： 我经常听你给人们一个建议：当他们面对多个选项难以抉择时，选择更难的那条路，因为这会让后面的路变得更轻松。请分享一下这个建议，为什么它如此重要，你是从哪里学到的，又是怎么确立这套理念的。

Farhan Thawar： 简单来说就是——如果你面临一个选择，选了容易的事而且成功了，那很好；选了难的事而且成功了，也很好，只是你付出了更多努力。但如果你选了容易的事却没成功，你实际上什么也没学到，因为你选的是……你没有做太多工作，你大概率也没有和最聪明的人一起工作，因为聪明人通常不在容易的路上。结果你经历了整个过程，现在却觉得：我好像亏了，我输了那个选择，或者我想做某件事但没成。但如果你走了艰难的路却没有成功，实际上你依然赢了——因为你完成了一件难事，你可能和聪明人共事过，你在过程中学到了有价值的东西。我可以给你举个简短的例子。

求职中的难路原则

Farhan Thawar： 我接触过很多求职者，我问他们：“你在用什么方式找工作？“他们说：“我每天投十份简历。“我心想，好吧，这听起来挺容易的，而且你每天投十份简历真的能学到什么吗？我反而会对他们说：你感兴趣的那么多公司里，Shopify 可能是其中之一，你为什么不看看 API 文档，动手做点东西——做一个 Shopify 应用，做一个 admin extension，在 Shopify 之上构建点什么东西。即使你没有拿到 Shopify 的工作——这可能本来是你的目标——你也学到了东西，做出了成果，你的 GitHub 仓库里有了可以展示给别人看的内容。你还在了解产品，这些知识可能转化为你未来在其他地方的工作机会。所以我觉得，虽然这条路更难——当然，你不可能每天都在不同平台上做一个应用——也许你一天能做一个，但走在难的路上你确实能学到东西。

我选课也是同样的情况。我选了难的课，成绩会差一些，但我在那些课上遇到了更聪明的人，因为他们和我一样，是冲着课程内容的难度去的。这一点我在生活中逐渐意识到：如果我选择做难的事——而且我天生就倾向于这么做——我最终会获益。我去了滑铁卢大学，在计算机科学之外辅修了电气工程；读 MBA 的时候，又辅修了金融工程，因为更聪明的人走的就是那条路，而他们至今仍然是我的朋友。

难路不等于蛮干

Lenny Rachitsky： 顺着你刚才最后那个观点往下说，人们听到这里可能会想：只要更难，那就是正确的路。但有时候更难的事情仍然是个糟糕的主意，比如加入一家极其糟糕、令人非常痛苦的公司，或者用一种非常蠢的方式盖房子——虽然确实很难。除了”更难”之外，你觉得还有什么条件也应该同时成立？

Farhan Thawar： 对，一个很重要的因素当然是人。因为我发现我一路走来，始终聚焦于选择最好的学习旅程——哪里能让我学到最多。每个人的情况不同，有些人可能从书本或自己所处的领域中学习效果更好，但对我来说，我从人身上学到的东西很多，所以我有意把自己放进那些更难的房间里。举个例子，我读 MBA 时在学金融工程——顺便说一句，我是搞技术的，现在也还是搞技术的——身边的同学都在往金融岗位走。有一次有人直接问我：“你上这门课干嘛？“因为他们知道我是来”玩”的，但我的回答是：因为这是一段学习旅程。所以对我来说，很大一部分原因在于——没错，你即使输了也还能赢，因为就算进展不顺，你依然能从中获得技能；而且如果你真的走了艰难的路，你会和聪明人建立起深度的工作关系，这些关系会在你之后的人生中持续延续。

这也迫使你一直处于一种不适的状态——走进那些房间，承认”我什么都不懂”，这确实更难。我同意你的说法，你不想做蠢事，比如”我们用一种蠢的方式来干这件事”——这不是我的意思。我的意思是，让我们尝试去做那些我们能从中学习的难事。而且顺便说，这些事本身就在路径上，只是可能需要更多手工工作，或者不是大多数人的做法，但我们认为从那条路能学到更多。

甘愿当众出丑的超能力

Lenny Rachitsky： 说到这个，我找到了你说过的一句很棒的话：“不是每个人都能一次又一次在公众面前显得很蠢，但我相信这是我的超能力，而且我试图让我的整个团队也把这变成他们的超能力。”

Farhan Thawar： 没错，听起来有点好笑，但我确实是那个总在尝试蠢事的人。有时候管用了，甚至连我太太都受不了我在家里试这些。举个例子，可能是买了台新洗衣机，我就拿些衣服试一个奇怪的洗衣模式，然后衣服毁了。好吧，但至少我知道这个模式不能用了。不过也有可能我发现了一个 20 分钟的快速洗涤功能，从此每次洗衣服都能省下 40 分钟。为了发现这个，我可能毁了不少衣服。工作中也是一样，我们会尝试各种事情，有时可能导致灾难——希望不会——你可以想象有人说”让我试试 GCP 的新配置，也许会有好处”，但也许会把 Shopify 搞宕机，我们不想那样。所以你需要设置某种护栏。但尝试蠢事、说蠢话这件事本身是有价值的。顺便说，有一半的时候当我说了一些蠢话，别人会说”我也有同样的问题”，他们只是不敢说出来。

Lenny Rachitsky： 对那些想要培养这种能力的人来说——因为我觉得这项技能真的很难获得，但又极其重要——能接受失败、能接受自己看起来很蠢，你有没有什么话可以帮助他们建立这种心态？而不是仅仅说”我天生就擅长这个”。在你成为高管、大家觉得”他没问题，他知道自己在做什么”之前，是什么帮助你变得能坦然面对错误和失败的？

Farhan Thawar： 我不确定。我小时候在零售店打工，客人走进来，你按提成拿工资，他们不一定买东西，如果不买你就赚不到钱。也许就是这种经历——主动上前和人搭话，试着促成交易，你也许花了一个小时陪一个客户，结果他什么也没买，但你经历了一连串的否定反应。你要做的就是接受它，然后走向下一位客户。你不能一直纠结，觉得”天哪，我这一天全毁了”。相反，你要从中学习：“好，让我试试这种方式，让我试试那种方式。“这并不容易，但确实是一种建立信心的方式。有人说做电话推销，或者做很多事情都能让你遭受大量拒绝。陌生拜访（cold calling）也是其中之一，它可以帮你建立抗打击能力。我不知道我是不是天生就比别人更擅长应对。我只是觉得我真的不在乎自己看起来蠢不蠢。我一直都在说蠢话。我不是为了被拒绝而故意去做事——顺便说，有些销售训练中确实有”去拿到十个’不‘“的方法——我没做过那个。但我确实在很多场合，和很多精明的人、成功的商人共处过，他们转过头来对我说：“这是我听过最蠢的他妈的问题。“这确实发生在我身上。我的反应就是：“好吧，我们进入下一个问题。”

Lenny Rachitsky： 我喜欢这种态度，我觉得这就是关键所在——弹回去，不要崩溃。我觉得让像你这样做得这么好的人来说出这些，对很多人是一种鼓舞——有人会对你说”这是我听过最蠢的问题”——

Farhan Thawar： 哦是的，现在还有。

Lenny Rachitsky： 现在还有。好的。

Farhan Thawar： 那这样呢？我听过”这是最他妈蠢的问题”。然后最近我又听到”我已经给你解释了三遍”，因为我一直在问，但我就是不理解，然后我确实收到了这条消息，“我已经给你解释了三遍。“我心想，“好吧，我还是没懂。“我这么做的目的不是要烦对方，而是要理解内容。顺便说一下，我说的这些都是消息，我把它们存了下来。我直接截了图，因为我想，记住这个时刻？没关系，我在学习。

为不同的亿万富翁工作

Lenny Rachitsky： 顺着这个话题再问一个问题。我看了你的 LinkedIn 和职业经历，发现你人生中每个十年都在为不同的亿万富翁工作。二十多岁时是一个叫 Joe Lemond 的人，三十多岁时是 Chamath，这个十年是 Toby，也许下个十年就是你自己了，如果一切顺利的话。除了你已经分享过的——或者也许就是你分享过的这些——这三位你共事过的、非常成功的人之间，是否有一条贯穿的线索，是你从他们身上学到的？也许是他们共通的，或者甚至只是各自独有的？

Farhan Thawar： 挺有意思的，因为再说了，这是事后回看，你会觉得，等等，我当初可没这么计划的。你不可能这样计划——“我每个十年去给一个不同的亿万富翁打工”，这不是计划得来的，对吧？但他们有相似之处。他们其实是截然不同的人，但在一点上是相似的：他们对未来十年左右世界应该是什么样子，有一种非理性的看法。他们是极度长期的思考者，同时在这方面又非常理性——他们会审视并说，“嘿，10年、15年、20年、25年之后，世界会变成这个样子。“我并不擅长看到那种愿景，但我擅长朝着那个愿景每周推进1%。所以这两者的融合——我知道自己擅长什么，我擅长把球往前推。如果他们擅长长期愿景，我们就可以对齐说，“你擅长这个，我擅长这个，我们为什么不联手？”

所以这一点一直让我很有共鸣：怎么找到这些”非理性”的人——一切进步都取决于不讲道理的人。我怎样与这些人配对，因为我这个人太讲道理了，而我也没有办法变得不讲道理，所以我必须与这些人融合。所以这同样是我刻意去寻找的东西。甚至当2015年我自己创业的时候，我实际上坐下来，把我所知的多伦多所有不讲道理的人列了一份清单，然后挨个去见每一位创业者，搞清楚我们是否”API 兼容”，我能否与他们共事。最终我选了其中一位，一起创立了公司。

Lenny Rachitsky： 这个故事太精彩了。首先，我非常喜欢这个洞察——意识到”这不是我的超能力，我也不打算去培养它，我要找到一个可以融合的人，把彼此的 API 对接起来，做那个把东西建出来的人，而不是那个 envision 该建什么的人”。我觉得这很棒，因为很多人会想……我需要在所有这些方面都变强。我需要成为愿景、战略、执行、协作各方面的最强者，还有所有这些东西。所以我觉得这一点本身就很值得关注——认识到自己的优势和劣势，然后在优势上加倍投入。

选择工作的框架

Farhan Thawar： 对，听起来有点好笑，但我和你聊过，我写过一个框架，我也在推特上发过，我把它写下来这件事，永远改变了我选择工作的方式。因为在我第一份工作之后有一段空窗期，我当时在试图搞清楚为什么没有什么能像第一份工作那样让我兴奋。结果我发现，我需要坐下来认真想，我到底在乎什么？人们会被搞混。我自己也经常被那些不在框架里的东西搞混。比如说，一个很典型的例子——头衔、公司名、钱，这些东西都能让你迷失。因为可能有个猎头给你发消息说，“嘿，这里有个新职位，这是薪酬方案。“你就觉得，“天哪，好激动。“如果你没有一个写下来的框架，列出你真正在乎的东西，就很难不被干扰。应该说，很难不被带偏。你就会被那些东西带偏。所以相反，我会看框架然后问，这个和我的框架对齐吗？

实际上，说到这个地步——我有一次真的把我的框架发给了猎头，我说，“嘿，就是这个，“因为他们一直来来回回找我，我就说，“嘿，这个和我的框架不匹配。“这确实帮我省了很多不被干扰的时间，但它也促使我每年重新评估自己在做什么，看着框架问，“这是否忠于我的价值观？“现在我太太会说，我就像个机器人。当我意识到我的框架被违背了，我会立刻辞职，而且我确实这么做过。甚至在没有找好下家的情况下，我就是觉得，哦，我的框架被违背了，然后就辞了。就是这种感觉——我知道我享受做什么，那个框架帮我找到它。所以我鼓励所有人，任何在找工作的人我总说，“写下一个框架。你可以用我的作为参考，但搞清楚你在乎什么，确保你正在做的事情和那对齐。”

Lenny Rachitsky： 这个框架就是”关于去哪里工作需要问的问题”，是你的那个框架。好的，我们会附上链接让大家查看。你说框架不匹配就辞职的那个例子，你愿意分享吗？有没有什么可以学习的？

Farhan Thawar： 当然可以。这发生在我的上一家，也就是几家公司之前，我们当时在运营一家叫 Xtreme Labs 的移动公司。就是 Chamath 作为主要投资人那家，所以我们直接和他合作。然后我意识到……那家公司非常棒。我们做了很多年。那是一家移动应用开发公司。我们为世界上最大的品牌做移动应用——Facebook、Twitter、Instagram、Vine、NFL、NBA、Bloomberg、Slack，你能想到的我们都做过，那正是在 iPhone 和 Android 真正开始起飞的2009到2013年那段时期。后来我们被 Pivotal 收购了。随着时间的推移，我在 Pivotal、Pivotal 以及 Pivotal Labs 的角色发生了变化——从之前运营全球最大的办公室，运营全球最大的结对编程办公室。

我是结对编程（pair programming）的忠实拥趸，变成了一种真正试图把咨询业务与产品挂钩的角色。我最终成了 field CTO，说实话，了解那个世界确实很有意思，但这跟我之前做的事情不一样。所以如果我对照我的框架来看，它违背了所有我想做的事情。我不再和最聪明的人一起工作了。我成了一个 IC（个人贡献者）。我学到的没有我能学到的那么多。我的影响力也不大了。我就想，哦等等，这完全不对齐了。然后我就跟团队说，“嘿，我打算辞职。“顺便说一下，这件事后来带来了很好的结果——我成了从那里衍生出来的新公司的投资人，这是一段很棒的经历。我只是在当时的情况下说，“嘿，你其实没有专注于正确的事情。“

强度的重要性

Lenny Rachitsky： 我想回头再聊聊 Xtreme Labs，我知道那里还有其他有趣的故事，但首先我想谈谈另一个主题——当我向别人问起你的时候，很多人都会提到的一点。这个主题就是”强度”，具体来说就是在你的组织中创造强度，以及这样做的价值和力量。我看到你对这个概念的描述，我非常喜欢——如何在一小时内消耗更多的千焦，而不是在工作上投入更多小时。先聊聊为什么强度对一个组织如此重要。

Farhan Thawar： 嗯，我觉得有几点。第一，我有一个基本信念：一小时就是一小时。是同样的一小时。你花一小时和我花一小时，流逝的时间是一样的。而如果我在那一小时里消耗更多卡路里——假设我们都朝九晚五地工作——如果我能在这朝九晚五的时间内完成更多的事情，我们俩……时间流逝是一样的，但我就是完成了更多。这当然意味着我可以对孩子说”嘿，我送你去踢球”，做其他事情。我们仍然可以做同样多的工作之外的事情，但在工作期间，我只想在给定时间内尽可能多地完成，而不是拉长工作时间。我可以举个例子。我以前在一家公司工作时，每天工作12个小时，但中午还在打桌上足球。

然后我们去喝咖啡休息，做这些事情。时间当然就被拉长到了12个小时，而不是努力压缩到八小时的工作日里。结对编程（pair programming）就是一个很好的例子，因为这是一项非常高强度的活动。两个人在一台机器上，当两个人一起工作，不被互联网和各种干扰分心，只专注于为眼前的问题编写解决方案时，你能完成非常多的工作。而且它累人到这种程度：当人们刚开始结对编程时，头几个晚上每晚要睡10到12个小时，因为强度太大了。你工作得非常投入。但对我来说，这种强度实际上能带来非凡的成果，即使你并不需要投入更多时间。我觉得大多数人——你可能经常听到这种说法——每个人都说，“哦，年轻时努力工作，多干几个小时，诸如此类。”

我的想法是，如果你每分钟能做更多呢？快速推进事情。我觉得还有一个不太直观的事实是，真正厉害的人实际上可以快速地产出高质量的成果。拿一个”优秀”的人和一个”极其优秀”的人来比较——极其优秀的人可以在短时间内产出大量成果，而优秀的人可能需要更长时间。我觉得这里存在一个时间差异，是人们没有考虑到的。所以你可以在不太降低质量的前提下，把时间缩短2倍、3倍，对吧？这是帕金森定律（Parkinson’s Law）的反面——如果我给你一个小时做一件事，一个真正优秀的人可以在一小时内产出高质量的成果。

结对编程的力量

Lenny Rachitsky： 我想聊聊你怎么创建一个这样运作的组织，不过具体来说，你刚才提到了结对编程。我知道这是你最喜欢的工具之一。聊聊为什么它这么强大——作为一名外部观察者来看，两个工程师写同一份代码，为什么不会让速度减半？就聊聊你为什么是结对编程的忠实粉丝。

Farhan Thawar： 它是工程领域最被低估的管理工具，没有之一。它的使用率远远低于它应有的水平。结对编程，给不了解的人解释一下，就是两个人共用一台电脑。两个键盘、两个鼠标、两台显示器，但一台电脑，一起工作。如果是远程的话，你可以用像 Tuple 这样的工具——我们就是用它——你可以远程共享一台电脑。你说得完全对。关于结对编程有一条著名的推文：等等，两个工程师用一台电脑，岂不是只能写出一半的代码？答案是：不不不，他们写的甚至比一半还少——因为重点根本不在于代码行数。产出的瓶颈不是手在键盘上。不是我们两个坐在那里，瓶颈在于要把按键输入到屏幕上。

瓶颈在于：优雅的解决方案在哪里？我们如何思考问题，为眼前的问题构建正确的解决方案？Tobi 有个著名的做法，他搭建 Shopify 的很多功能都是通过结对编程完成的。他会设置一个计时器，他和 CTO Cody 一起结对编程一个小时。如果他们在一个小时内没有解决问题，他们会删掉所有代码，保留测试，重新开始。他们的想法是：如果我们不能在一个小时内把功能想清楚并写出代码，那说明我们的设计一定是错的。我们一定在构建错误的东西。所以他们删掉所有代码，保留测试，重新来写。有时候他只超了一分钟，他还是会删掉代码重新开始，因为他的理念是：正确的、优雅的解决方案应该能在一个小时内写完。

所以结对编程——那是一个极端版本——但即使是在 Pivotal Labs，如果你的搭档那天生病了，你写了一堆代码，比较硬核的做法是，你的搭档第二天来了之后会把你写的所有代码删掉，然后你们第二天重新写。而且话说回来，什么时候是重写代码最好的时机？就是你刚写完的时候，因为你现在已经了解了问题域。而且听起来像浪费时间——听起来就像我在删代码——但原因是代码会存活很长时间。代码是一种负债，而正确的解决方案——通常是更短、更优雅的解决方案——往往在你做了大量的路径探索之后才会浮现。而做这种路径探索的唯一方式就是开始，然后删除，然后再开始，然后发现，哦，不对。

现在我知道了。删除。而且这超级难做到，因为我们是人类，我们有沉没成本谬误（sunk cost fallacy），所以很难删除。但如果你能做到这一点，你实际上会得出一个好得多的解决方案。当然，结对编程的学习效率也非常高，因为你坐在别人旁边——不管用的是 Tuple 还是远程，还是面对面——你能学到按键操作，学到别人如何思考问题。你们来回讨论，是的，你写的代码可能会更少，但你在为客户交付价值的道路上前进得比独自工作时更快。而且有各种研究表明：幸福感更高、知识传递更好、信息孤岛更少、强度更高，所有这些好处。代价大约只是正常情况的20%左右。

我有个类比：篮球里的端尿盆式罚球（underhanded free throw），统计上已知命中率更高，但看起来很蠢，所以没人用。沙奎尔·奥尼尔——我不是什么篮球迷，但我读到过关于他的事——他是名人堂球员，有人问他：“你为什么不用端尿盆式罚球？“因为他出了名地不擅长罚球。他说：“看起来太蠢了。“即使他每年拿着几百万美元的薪水来做这件事。“看起来太蠢了，我不想那么做。”

Lenny Rachitsky： 我记得沙奎尔·奥尼尔那些年请了专门的罚球教练，我记得他们讨论过这件事，然后他说，“不，我永远不会那么做。“

Shopify 的结对编程实践

Farhan Thawar： “我永远不会那么做。“因为看起来太蠢了。顺便说一句，回到访谈开头我就说过，我不在乎什么看起来蠢或者显得傻，我们就是要做这件事。实际上，我运营过全世界最大的结对编程团队。

Lenny Rachitsky： 说到这个，Shopify 有多大比例的人这样做？你们都是这么工作的吗？

Farhan Thawar： 是的。Shopify，我之前提到过，Toby 和 Cody 在 Shopify 早期就是这么做的。结对编程很酷的一点是——在我之前所在的 XtremeLabs 也是如此——我们非常清楚要构建什么，因为我们做的移动应用几乎就像合同制造。我们会说，“我们有 iOS 版本了，能做一个 Android 版本吗？“所以我们能很快地说，“这是规格说明，赶紧做。“但 Shopify 完全不同。我们是一家探路型公司，我们在努力寻找正确的东西去构建。所以结对编程未必在所有时候都合适。像 Pivotal 和 Xtreme 那样，我们以前是每周结对编程四十个小时。

Shopify 的结对编程文化更接近每周四到八个小时，大家聚在一起面对某个问题，说，“嘿，我们结对半天吧，“或者”我们每个周三结对。“我们把这种方式当作工具箱里的一种工具，用来在一条路径上快速推进。但大量其他时间花在探路和弄清楚该构建什么上，以及试图说服各方：“嘿，我们要走这条路。哦，现在我完全清楚了。”

有时候，顺便说一句，十八个月后我们终于把所有事情都想明白了，那时就是我们应该删除一切、从头开始的时候。那也是我们会在那个节点去做的事情。所以，你不想连续结对编程十八个月。你想要的是寻路和探路。然后说，“我看清了全局。让我把一切删掉，重新构建。“因为你追求的是学习。我们已经获得了所有的学习成果，现在来写代码吧。

Lenny Rachitsky： 明白了。所以基本上是，当你对代码有相当把握、且是代码库中非常重要的部分时，就结对编程。

Farhan Thawar： 没错。另外在事故处理期间，我们也会大量采用结对的方式，一起搞清楚状况，和某个人合作，说，“嘿，我不太确定，我们上个通话或者开个 Tuple 一起看看吧。“然后说，“我们一起来搞清楚到底怎么回事。“

AI 对结对编程的影响

Lenny Rachitsky： 我忍不住想问 AI，它对这种工作方式有什么影响？

Farhan Thawar： AI 非常有趣。现在像 GitHub Copilot 这样的 AI 副驾驶，就是你的结对编程伙伴。你现在可以感觉自己实际上在结对，而不需要另一个人在场。你可以和 AI 结对。而且现在还出现了一种现象，人们使用 Whisper——他们对着 Cursor 说话——通过 Whisper 来说，“好的，我们来构建一个新的 React 组件，做这个功能。“他们说着话，代码就在生成。“哦不，我不是那个意思，我的意思是这样做。“所以你甚至不需要打字，只用语音就能和你的结对伙伴来回交流。

我觉得这很了不起。但我仍然主张，把那种体验再加上两个人类一起。也就是说，你有一个 AI 副驾驶，再加上人类，因为现在发生的事情是代码在生成。两个人类可以看着说，“哦，我知道它想做什么。“然后，要么因为有灵感而删除代码自己重写，要么直接采纳建议继续推进。但我非常喜欢当今 AI 副驾驶的世界，因为你再也不必独自编码了，对吧？你永远不必独自编码。你现在可以尝试一门新的编程语言，因为 API 和语法要容易上手得多。所有这些都对工程有利，对任何想要构建软件的人都有利。

Lenny Rachitsky： 很有道理。基本上，每个人都会成为结对编程者——

Farhan Thawar： 没错，正是如此。

Shopify 如何创造高强度工作节奏

Lenny Rachitsky： ——在未来。好的，我想回到你在 Shopify 还做了哪些事情来创造高强度这个话题。我觉得需要再次强调，高强度的意思是”如何在有限时间内完成更多，然后回家？“而不是每天从早到晚、周末也在干的那种高强度。

Farhan Thawar： 是的。我们有几样东西在支撑我们。第一，我们有一个叫 GSD 的工具，意思是 get shit done，你可能在和其他 Shopify 人聊天时听说过，就是每周向全公司汇报进展的概念。同样，这是帕金森定律的规模化应用。如果你每周都问人们进展，他们就会想每周都展示进步。这是我提到的一种方式，我也谈到了结对编程。

我们公司还做的另一件事是：以前我们的节奏是每年两次，黑色星期五、网络星期一，或者我们夏季有一次活动。现在，我们做六周评审。团队每六周要聚在一起，向直属领导以及 Toby 汇报路线图、资源配置和当前工作进展。

这件事很酷的地方在于——顺便说一句，这是巨大的时间投入——我们全都聚在一个房间里，明天就开始。周二、周三、周四，我们一群人会在办公室一起，逐个过公司里的每个项目，讨论项目本身、资源配置、进展如何，然后做出调整。这同样创造了高强度，因为你想展示做了什么、自上次六周评审以来学到了什么。我们发现六周是一个非常好的节奏，因为足够短，你还记得上下文；同时六周也足够长——尤其是如果你有一个十几人的工程团队，你能做很多事。不仅如此，你一天就能做很多事，但这算是一个检查点。

我注意到关于高强度的另一点是，比如说，我们在评审中收到了一些反馈，我们不会等到下一次六周评审才行动。第二天我们就开始构建、迭代、找人。然后到下周我们就说，“这是我们的进展轨迹。“说真的，我都想做一件马斯克那种 T 恤，上面写着”你这周做了什么？“因为帕金森定律是真实存在的。听起来好笑，但我一直反复提它——你分配给某件事多少时间，它就会花掉多少时间，对吧？

所以如果你在做一件大事——比如你在做一次组织架构调整——你可以慢慢来。“让我们坐下来，规划，再推行。“在大多数公司可能要六个月。在 Shopify，这是一两周的事。你坐下来，说，“嘿，这是基本框架。让我们再多找些人来想想。“但然后事情就会开始泄露，所以我们直接上线。我们对很多事情都是同样的做法。我们就是试图更快地行动，跳出那种……我们不做变更管理，我们直接落地，然后说，“嘿各位，这是一家多变的公司，现在的情况就是这样。但这就是我们快速把事情做成的方式。“然后继续我们的生活。

Lenny Rachitsky： 哇，这里面信息量太大了。我经历过那种六个月的组织架构调整。我觉得你刚才分享的那个背景——“我们身处一家多变的公司，我们在不断改变。事情不会很平稳，但我们认为此时做出改变比等待更好”——这就是 Shopify 的文化。听起来就是，“我们想保持快速推进，我们知道这不会是最平稳的过程，但我们清楚此刻做出改变比等待更好。“

混沌猴与韧性文化

Farhan Thawar： 这就是 Toby 提升公司韧性的方式。当年我们还有数据中心的时候，他会走过去直接拔掉机器的电源，对吧？

Lenny Rachitsky： 混沌猴。

Farhan Thawar： 对，混沌猴。你说得对。但这招确实有效，因为它传达的意思就是，“嘿，顺便说一句，东西会坏的。所以，让我们对此保持韧性。“这里也是同样的道理。“嘿，顺便说一句，有人会动了你的奶酪。没关系。我们的使命是让世界上出现更多企业家。我们不是来做六个月的变更管理路线图的。那样反而会拖慢我们为商家创造价值的速度。“

周更新与评审机制

Lenny Rachitsky： 那么在你分享的所有这些内容中，有一个是周更新。周更新是每个人分享自己这周在做什么，是这个意思吗？

Farhan Thawar： 每个项目。

Lenny Rachitsky： 每个项目。

Farhan Thawar： 每个项目都会有一个更新，可能包含一段视频，展示”这是用户体验”。显然还会有大量文字说明自上次以来有什么变化。我们有一个流程叫 OK1 和 OK2。OK1 通常在总监级别，他们会说，“好的，我认可这个方向。“或者，“我不认可。“然后他们可以做出调整。接下来到了 OK2，通常是该领域的 VP 级别，他会审视并说，“好的，你们在做的事情确实与整体架构是对齐的。但顺便问一下，你们看过这个背景信息吗？也许你们没注意到这个，这件事正在发生，或者行业的这个趋势。“你就是在那个层面进行对齐。然后，就像我之前提到的，每六周我们会和 Toby 过一遍，他本人也是个非常高强度的人。

很多时候就是这样的对话，“嘿，为什么这花了这么长时间？我们是不是想太多了？我们是不是因为被什么东西卡住了而没有推进？是不是缺少某块基础设施？“实际上我给你一个好例子。在上一次的评审中，我们当时在尝试用 LLM 解决一个有趣的 AI 问题，需要一个很大的输出上下文窗口。而现在大多数 LLM 的输出上下文窗口都很小。但在评审会上，我们和所有 LLM 团队都有共享的 Slack 频道，对吧？我在 OpenAI 频道发了消息，在 Gemini 频道发了消息等等。一个小时内，我们就把几个主要模型的上下文窗口调大了，然后我们就顺利推进了，仅仅因为我问了一句。

这就是一个例子。它不需要等到下一个六周评审，但它提高了紧迫感，因为团队当时说，“哦，我们被卡住了，因为我们以为必须把这些数据切片然后做这个那个，因为我们的输出上下文比较小，我们以为可以做一个大的输入上下文，但那就得做缓存。“反正就是一整套复杂的方案。我就问了一句，“我们有没有直接问他们能不能给更大的？“然后他们回复说，“哦，这个没有写在文档里，但我们现在就可以给 Shopify 开启。“这让整个团队一下子兴奋起来，“哦，我们现在可以立刻解除障碍了。“这就是快速行动的例子，再强调一次，就是问一个看起来很傻的问题。我当时想，“这可能不行吧，但是……”然后他们回来说，“哦，可以的，我们能做。“

频繁检查与速度

Lenny Rachitsky： 这个例子太好了。你在描述 Shopify 内部如何创造紧迫感和速度的时候，有意思的是，你列出来的东西其实是一系列会议和检查点。对大多数人来说，这感觉像是，“为什么我们需要这么多……”大家都在说”少开会”。我知道你们公司有一个著名的做法是取消所有会议，这个我们稍后可以聊。但有意思的是，更多的检查点和定期的检查反而让你行动更快。我猜部分原因是它确保你不会在做不必要、愚蠢、没人会用的事情，而是持续聚焦在真正最重要的东西上。

Farhan Thawar： 我觉得这就是”信任但要核实”的组合，对吧？别忘了，检查的目的不是让你说，“哈哈，抓到你没干活了。“不是那种呆伯特式的老板，“嘿，你那件事做了没？“即使我想到 Elon 发的那条短信，“嘿，你这周做了什么？“也不是为了抓 Parag 的把柄，“你什么都没做”或者”你做了一堆没用的事。“而是希望能够一起协作解决问题。意思是，当我问某人，“嘿，那个 LLM 项目推进了吗，因为我们现在有了更大的上下文窗口？“然后他们回复说，“哦，这是我们学到的东西。“我就能看着答案说，“哦，那你有没有想过这个？你有没有试过那个……”这是一种协作解决问题的方式。

我们都有这个词，大家都在谈论微观管理，而在 Shopify 我们其实不认为它是一个脏词。我们不认为它是脏词的原因是，它不是那种呆伯特式老板说”你那件事做了没”。而是，“嘿，我能和你一起解决这个问题吗？如果我跟你一起解决这个问题，我就得经常了解你的进展，然后给你建议，或者你跟我分享上下文，因为我不是每天都在一线做这些工作。“然后回过头来说，“哦，根据我所知道的和你所知道的，我们能不能把它往这个方向推？也许这样对商家更好。”

我不想过度使用”结对”这个比喻，但它确实很像，“我能和你结对吗？“这一点其实在我加入 Shopify 早期就学到了。Toby 会和我进行一对一会议，我当时觉得，“Toby，你不用浪费时间在我身上，你雇了我，我能搞定的。“结果他说，“哦，你误解了你来这里的原因。我们是一起来解决问题的。“我当时就想，“哦，我从没想过……”我以为他雇我是为了把问题从我这里拿走。他雇我是为了和我一起解决问题。这跟我之前的理解完全不同。

Lenny Rachitsky： 我喜欢这个说法。好的，你刚才提到了会议的事情。对于不了解你们对会议做了什么的人，我觉得值得简单分享一下，因为这很棒，很多公司都能从中学习。

会议末日

Farhan Thawar： 好的，当然。其实关于 meeting Armageddon 有个有趣的故事。在我加入 Shopify 之前，我就跟 Toby 聊过 meeting Armageddon 这件事。所以我觉得在他实施之前，我多少有点推动作用。我当时说，“嘿，你有没有看到……”好像是 Dropbox，“你有没有看到 Dropbox 在做的 Meetinggeddon？“他回复说，“这太有意思了。“那是我加入之前好几年的事了。所以我觉得有趣的是，它最终真的变成了现实。我们的具体做法是：每年在随机的时间点，我们会删除所有超过两人的周期性会议——一对一会议除外——而且仅限内部会议，面试或外部合作伙伴会议不在范围内。然后我们有两周的禁令期，期间不允许添加周期性会议。你可以开普通会议，但不能添加周期性会议。

其核心理念在于，周期性会议有很大的惯性。它总是在那里，你知道它即将到来，很难删掉，因为你会想，“哦对，我们每周都会讨论这件事。“所以我们的做法就是做一次会议重置。我觉得，对，它就叫混沌猴，管理员直接进去把所有周期性会议删掉。这个做法很棒的地方在于，它迫使你重新思考：“我们真的需要周期性会议吗？还是只需要开一次？或者需要不同的频率？“这是一方面。另一方面是，它释放了大量 crafter 的时间，对吧？

我在整个工程团队追踪的一个指标是：个人贡献者每周在会议中花多少小时？我们注意到，在我们做了……顺便说一下，我们做了两件事。第二件事我后面会讲，但第一件就是我们删除了会议。第二件事是我们把大量 Slack 上的内容迁移到了 Facebook Workplace，这个我一会儿再说。我们只做了这两件事，然后就看到 crafter 在会议上的时间大幅下降。接着，我们看到了各种各样的生产力提升，因为他们获得了那种心流时间，可以专注做事了。

所以现在 Shopify 的个人贡献者每周大约三个小时的会议时间，这非常了不起。每周三个小时，真的很棒。管理层也没那么糟。我记得我发过一条推文，大概是每周六到七个小时。为了保持对齐，这完全不算多。剩下的所有时间都是工作时间。

Lenny Rachitsky： 那 meeting Armageddon 和引入 Workplace 之前是多少个小时？

Farhan Thawar： 这个问题问得好。我得回去查一下。但大概下降了 50% 到 60% 左右。个人贡献者之前大概是每周五六个小时，降到了三个小时。管理层的话，大概是从 10 个小时降到了 6 个，差不多是这样。但差异确实非常大。而且就像我说的，我们只做了两件事：一是 meeting Armageddon，二是这个，我可以聊聊这个。这是一个——

Lenny Rachitsky： 好，我们来聊聊这个。

从 Slack 到 Workplace

Farhan Thawar： 好的。我想说，我很喜欢 Slack，它是即时通讯工具，大家都在用。但它确实容易造成分心。所以我们做的就是把所有公告类的信息迁移出去。也就是说，任何你发送状态更新或大范围公告的内容，我们全部迁移到了 Facebook Meta Workplace——基本上就是工作版的 Facebook，不过现在它正在被弃用，所以我们也得想想替代方案。但这确实把所有这类内容转移到了一个机器学习驱动的信息流上，你可以用不同于 Slack 的方式来消费它。因为 Slack 的模式是我给你发消息，你就会看到提醒，诸如此类。而 Workplace 更像是，“哦，我想去看看公司有什么新内容，获取更新，分享更新。“这也大大减少了干扰。所以我希望能找到下一个适合我们的工具，但它大概是那种信息河流的类型——我可以随时把脚伸进去蘸一下——而不是到处都是即时通讯和聊天。

Lenny Rachitsky： 这太有意思了。所以具体来说，那些只是更新、不需要讨论的内容，你几乎想要 discourage 讨论。

Farhan Thawar： 对，Workplace 有评论功能，但它不是同一种工具。顺便说一下，Slack 非常棒，我们在用。只是对于这种场景，它对我们不太合适。所以我们想把这类内容放到别的地方。

创造更多强度的方法

Lenny Rachitsky： 我感觉，越是深入了解 Shopify 的工作方式，就越会发现一些我完全没想到的有趣做法。我很好奇还会出现什么。我们一直在聊你们，尤其是你个人，如何创造强度，尤其是在工程组织中。同时你也更广泛地分享了 Shopify 的整体做法。在这个清单上还有什么？你还发现什么其他有助于创造更多千焦每小时的做法？

Farhan Thawar： 好，再说一遍，我觉得还是要从头说起，没有什么比结对编程更有效的了，因为你真的只能坐在电脑前，别的事什么都干不了。所以结对编程是排第一的。我要说，周度节奏也很有帮助，这个你刚才提到过。它也是 GSD 的一部分，即分享进展更新，再加上六周评审，这些作用很大。另一方面，我们还有很多指标和告警，帮助我们观察系统中是否可能正在发生某些情况，让我们能够说，“嘿，等一下，这类事情出现得太频繁了。我们可能需要停下来重置一下，搞清楚到底怎么回事。“

Code Yellow 与基础设施投资

Farhan Thawar： 比如说，有一件事是，我们发现 Shopify 的工程师在 admin 上进行开发的耗时越来越长。所以我们发起了一个所谓的 code yellow，就是在 code red 之前的一个级别。Code yellow 的意思是，“嘿，我们要对 admin 发起 code yellow。“我们要确保 Shopify 内部的开发者体验真的很好。启动代码仓库应该很简单，做修改应该很容易，查看修改效果也应该很方便。这些事情同样能帮助我们创造强度，因为 code yellow 允许负责人去拍任何人的肩膀说，“停下你手头的事，来帮忙处理这个。“这其实是基础设施层面的事情。而建设基础设施能让你跑得更快。建设基础设施本身需要更长时间，但它能让你在此后永远跑得快，对吧？

我给你举一个具体的例子。2020、2021 年，疫情最疯狂的时期，显然又出现了一个加密货币之夏，crypto 疯狂暴涨。我们坐在一起讨论，“哇，我们很多商家现在都在要求 NFT 门控功能。“NFT 门控就是，“如果你持有这个 token，你就可以进入店铺查看我的商品，看到我的价格并完成结账，但前提是你必须持有这个 token。“我们从商家那里收到了大量需求，“我们想做这个。我们想卖 NFT，然后让持有 NFT 的买家获得这种优质体验。“我们的回应是，“我们同意，我们希望你们能做任何想做的事。所以我们也想为你们开发这个功能。“

平台思维：给油箱加满油

Farhan Thawar： 然后我们跟 Toby 坐在一起，他说，“你们想错了。“他问，“开发 NFT 门控需要多长时间？“我说，“我不知道，两三周吧。“他又问，“那如果开发一个平台层，暴露 API，让任何人都能在一小时内开发出 NFT 门控，需要多长时间？“我说，“我不知道，两三个月吧。“他说，“那就做这个。“他说，“因为你不知道他们会在平台之上构建什么。“NFT 门控只是一个用例，但如果你花时间去建设基础设施层——他称之为”给油箱加满油”——如果你把油加满，人们就可以用那些油跑很长很长的路。所以他说，“我一直希望你们这样思考……”而关键在于，“你能构建什么，让任何人都能在一小时内搭建出这个东西？“对吧？

Farhan Thawar： 他经常对我们做这样的事。他会说，“哦，这个应该只需要……”他说出来，但人们会理解错。他会说，“哦，这个你一天就能写完。“但他的意思是，“要怎样才能让你一天就能写完？你需要什么样的基础设施？“而且他自己确实是这样开发软件的。他会对着一个还不存在的 API 写代码，因为他觉得，“这里应该存在什么？这个 API。“他会把客户端代码写出来，来回反复打磨客户端和服务端，然后说，“好了，客户端代码是正确的。现在让我去实现服务端代码。”

这就是把东西当作基础设施来构建的思路，听起来今天会更慢，因为需要花费……两三个月而不是两三周。但之后，人们在上面构建的东西变得非常简单，涌现出了多得多的应用场景。这只是一种不同的软件思维方式。是一种不同层面的高强度投入——围绕构建基础设施层的高强度。我们当然也想快速交付，但在这种情况下需要两三个月，之后却能让所有人在我们的基础设施上以快得多的速度进行开发。当然，谁知道那之上会繁荣出什么来？

GitHub Copilot 与删除代码

Lenny Rachitsky： 这很有意思，也说得通——你们的思维方式如此侧重于构建最好的平台，而不是 necessarily 为某个人构建最好的点解决方案。这也解释了为什么你们花那么多时间精心打磨代码、做结对编程，因为说到底，这是一个让别人在上面构建东西的平台。我觉得这其中很多内容非常有价值，尤其是对平台型企业而言。

Farhan Thawar： 没错，确实如此。你这么一说让我想到一个数据。去年，可能有点跑题，我在推特上发了说 GitHub Copilot 已经为 Shopify 写了超过 100 万行代码。大家都惊了，“天哪。“这事被广泛传播，所有人都在讨论。然后我说，“我不知道大家为什么这么激动，因为我想看到的是 GitHub Copilot 删除 100 万行代码。“那才是你知道我们真正达到这个水平——接近一个真正的工程师的标志，对吧？所以我们今年著名地删除了数百万行代码，因为我们想要聚焦于沉没成本谬误，重新用优雅的方式构建，或者发现你已经不需要这个东西了然后重新构建。我甚至发了一条推文，有人说，“哦，Shopify 是全球前十的 Ruby 代码库之一。“我说，“我再也不想看到我们出现在这个榜单上。“我们不应该争夺第一名，我们应该争当第一百名，对吧？我们想从这个榜单上消失。让别人去拿那个王冠吧。

Lenny Rachitsky： 继续聊聊这个。你们一直在推动删除代码和简化。背后的原因是什么？到底是怎么回事？

代码库简化与删除代码俱乐部

Farhan Thawar： 有几个原因。第一，你能在脑海中装载的关于一个代码库的上下文越多越好。你永远不可能把整个 Shopify 装进脑子里，因为我们给商家提供的是一套庞大复杂的工具集。但你简化得越多，一切就变得越容易——弹性、性能、可靠性、可维护性，所有这些”ility”属性在代码库简洁时都会变得容易得多。你真正需要的是一个明确的 mandate：“好吧，让我们来看看这段代码。如果我今天从头开始，我真的还会构建这个东西吗？或者我现在是否已经有了足够的领域专业知识来说，‘不，这才是正确的解决方案’？所以我能不能删掉重来，用更简洁的方式重建？“一旦你这样做了，在它之上构建其他一切就变得容易了。

所以我们有一个常规做法——删除代码俱乐部，我们还有 hack day，一年两到三次，总会有一支团队专门负责删除代码。他们甚至有一本手册，“教你如何找到可以删除的东西。“这真的很棒。我们几乎每次都能找到超过 100 万行可以删除的代码，不知道这是好事还是坏事。但与此同时，我为团队勇于清理代码库中的冗余而鼓掌。一切都会变得更简单，对吧？代码加载更快，更容易理解。

这就是为什么当我在看 GitHub 统计数据时，你不应该只关注……Google 曾公布说，“哦，25% 的代码现在是由 AI 编写的。“我就想问，“删除呢？25% 的代码由 AI 删除在哪里？“对吧？这才是我们需要开始思考的方向。因为正确的代码从来不是以代码行数来衡量的。永远是别的东西。永远是优雅。这才是我们需要思考的。所以，作为我们长期基础设施思维的一部分，这确实是我们非常重视的事情。

实验、功能还是基础设施

Lenny Rachitsky： 我特别喜欢这一点，部分原因是它和我们在讨论的主题——速度、速率、高强度——是相通的。更小的代码库、更干净、更好的代码库能让你跑得更快。我以前其实也是工程师。不管是从工程师的角度还是从产品经理的角度，我都很喜欢干掉没用的东西、修复、让代码变得更干净、更好、更持久这种事。但在现实中，公司很难优先安排这件事。你有没有发现什么方法能帮助做到这一点？你提到了 hack day 和 hack week 是其中一部分。Toby 是工程师这一点可能也有帮助，他理解这些东西的价值。但对于想要做得更多的人，你有什么建议吗？

Farhan Thawar： 是的。实际上，我们在构建东西的时候，会把它归入三个桶之一。我们会问，“你是在做一个实验、一个功能，还是基础设施？“一旦你把东西分了类，你就可以说，“哦，这是一个实验。“你就知道，“好，这不是基础设施。这是我们为了学习在尝试一些东西。“顺便说一下，它之后可能会转化成实验或基础设施，但它最初是以实验开始的。如果你是在构建一个功能，功能基本上就是你利用已有的基础设施。我前面举的 token 门控就是例子。如果你现在能在一小时内把它构建出来，你大概会说，“哦，我们下面的基础设施是对的。”

但如果你像 Toby 那样做——他会说，“我希望存在这样的基础设施。这是功能。功能可能很快就能构建完，但现在我需要去构建基础设施。“你就进入了基础设施领域，这可能会花更长时间，但你同时为一大批用例赋能了。你不需要一次性全部想清楚，因为可能会有人以不同的方式使用你的 API。

Toby 的选择哲学

Farhan Thawar： 所以，我觉得你必须给自己归类。那么，人们怎么进入这种模式呢？这真的超级、超级难。而且我想说，Toby 是这里的秘诀，因为他几乎总是在推动我们把东西当作基础设施来思考。我的意思是，最让我头疼的事情之一大概就是——我总是去找他说，“嘿，我们可以做 A 或 B。“他看着我说，“你知道我要说什么，对吧？“我说，“你要说回去生成更多选项。“因为他不喜欢那些。“我不喜欢 A 或 B。等你拿出别的东西再回来。“对吧？实际上，也许我给你讲个小故事。他有一个说法，他说，“对于任何问题，错误的选项有无限多个。正确的选项大概有一万个，但每个人都在找到第一个正确选项时就停下来了。而你真正应该把所有时间花在上面的——因为那些行不通的选项你不会去花时间——正是这一万个正确选项里到底哪些是最好的。不要停在第一个就完事了。”

所以，当我去找他说”A 或 B”的时候，我是在一万个里面挑了两个。他就说，“那不是我……回去生成更多选项，因为那些不是最优的。“所以在这些事情上，他真是个哲学家。而且这确实改变了公司的运作方式，因为他会在这些事情上推动你。然后随着时间推移，我们学会了识别同样的模式。我也学会了推动我的团队去做基础设施、删除代码、让事情变简单，因为说到底，谁不想要免费的好处呢？对吧？免费的性能提升，免费的、易于导航的代码库，免费的可维护性，免费的弹性——因为我们去做了删除这件困难的工作。这确实很难。但这又回到开头了，对吧？选择困难的事。不要只是构建功能——去让功能变得容易构建。

结对编程与专注力

Lenny Rachitsky： 我觉得好东西越来越多。你还有什么对大家有帮助的想分享吗？有意思的是，我在读你发的那条推文，里面分享了很多建议——你简要提到了一点，我觉得在结对编程方面很重要：其中一个好处就是没有多任务处理。你不会在工作时刷 Twitter 或 Slack，因为你在被人看着。我能理解为什么这在本质上就更有生产力。

Farhan Thawar： 哦，那当然了。再说回来，端尿盆式罚球不仅看起来蠢，感觉也蠢。人们不……他们觉得坐在别人旁边是浪费时间，心想”我自己在电脑上可以做这件事。“但他们在一起是在构建一台机器。你读过《The Undoing Project》吗？那本书讲的是 Amos Tversky 和 Daniel Kahneman，那位著名的……

Lenny Rachitsky： 迈克尔·刘易斯写的，好像是。

Farhan Thawar： 行为经济学家。Michael Lewis。没错。他说过一句著名的话：“单独来看，我们还行；但合在一起，我们就是天才。“对吧？这就是结对编程者。两个人。你觉得，“嗯，我还行。但合在一起，我们就是天才。“这正是结对编程的意义所在。当然，希望我加上一个大语言模型也能成为天才，但这正是这种思维方式的源头。

Demo 文化

我想说另一个帮助我们创造高强度节奏的是 demo 文化。作为 GSD 更新的一部分，我们鼓励人们分享高保真的更新，不仅仅是图片，而是一个实际的 demo。仅用截图可能出问题的一点是，你无法获得完整的体验。你无法判断东西有多慢之类的，但有了 demo，你可以放一个链接。我们有这个工具叫 Spin，是一个内部开发环境，类似于云端开发环境，你可以说，“嘿，点这里在 Spin 上试试。“然后你就可以试用，看到它怎么运作。

或者他们会说，“在你自己的店铺里开一个 beta flag，然后试试。“这样就短路了很多误解，因为你会说”我要试试。“而且你不用等到最后，特别是有了 beta flag。你会说，“嘿，它在我的店铺里了。我刚进去发现这个页面要 20 秒才能加载完。这是你预期的吗？“对方说，“哦，我们没发现这个用例。“你会快得多地学到这些。

这又创造了反馈保真度上的高强度。因为我们著名的做法是，我们的 PM 团队会创建摩擦日志（friction log）。他们会说，“我正在走一遍……”他们会录一个屏幕共享，创建一个视频，然后说，“我正在走一遍流程。我开启了 beta flag，我正在走这个体验。这是我对体验的反馈。“然后你就得到了这种高保真的反馈回流，你会说，“好的，下周的迭代里修掉这些东西，然后再分享一个 beta flag，说，‘好了，现在试试。现在试试。现在试试。‘“所以你们不是在讨论状态报告，而是在讨论实际体验。

Shopify 的运转节奏

Lenny Rachitsky： 所以我在尝试从宏观上把你分享的所有东西联系起来，看看它们是如何组合在一起让你们跑得这么快的。我刚查了几个数据，让大家感受一下公司目前的规模和取得的成功程度。你们大概有 11,000 名员工，Google 上查的大概是这个数。而且你们基本上正在达到——不一定是市值的历史最高点，因为 COVID 那段时间给了你们很大的提振，但你们基本上正在回到 COVID 期间那种疯狂的估值水平。所以在一家一万多人的公司里，基本上处于历史最高点附近，跑得飞快，持续交付。用户喜欢这个产品。感觉你描述的一个关键点就是这套运营节奏——它创造了这些检查点，让人们持续前进，聚焦在正确的工具上，并在他们走向错误方向时快速获得反馈。

Farhan Thawar： 而且让领导者和那些人结对去解决那些问题——不仅仅是检查进度，而是实际和他们一起面对他们遇到的问题。这样你就同时有了在做这些事的匠人，和可能拥有更广泛上下文的领导者，大家一起协作来疏通阻塞。

Lenny Rachitsky： 而且很有意思的是——人们经常说，“我们不需要会议。干掉所有会议。“你们确实也这么做了，但同时，战略性会议和检查点也很有力量。另一个类别就是工程环境，工程师和工程师一起工作，结对编程之类的。你提到过一个结对编程的工具，Tuple，好像是。

匠人天堂

Farhan Thawar： Tuple。是的。有趣的是我们只用它，但我们内部其实有一句话，我们叫——Shopify 应该是一个匠人天堂。它应该是匠人们来磨练手艺、提升手艺的地方。显然，这对很多工程匠人来说很有共鸣，但不仅仅是工程，还有 UX、PM 和 ML，所有你希望那些人真正拥有良好体验的地方。我们希望他们来到 Shopify，因为我们相信这是最适合他们的地方。

Lenny Rachitsky： 我很喜欢。我刚记下了一条笔记，关于你如何为团队的成功创造条件——就是避免干扰。所以我觉得结对编程有帮助，从 Slack 转移到工作场所也有帮助。我觉得你对工作时间也很严格，你基本上不允许……

Farhan Thawar： 不是的。

Lenny Rachitsky： 不是。好吧。

Farhan Thawar： 不是的，确实不是。从这个角度来看，我们对工作时间并没有特别严格的要求，但我们确实有很多在东海岸时区的人，很多事情都在那个时段发生，不过我们确实也有遍布世界各地的人。但我之前提到过，我们有定期的签到和六周评审。所以六周的周期确实会带给你一种”你完成了什么，你有没有被卡住”的心态。你可以预期在几次签到时会说，“嘿，我们在解除阻塞方面没做多少。“这会促使你改变方法，去想，“好吧，我不想再参加一次没取得什么进展的评审。“那么我这次要怎么做才能确保我们释放出大量进展？而签到可以给你这样的动力，“这次我们就这样做。”

Lenny Rachitsky： 而且你们公司也是远程优先的。

Farhan Thawar： 是的。

远程优先的理念

Lenny Rachitsky： 我觉得这尤其酷。现在很多公司都在回归非远程模式。你们则坚持远程。你们为什么决定这样做？你们看到最大的好处是什么？

Farhan Thawar： 是的，我们有这个远程模式——我喜欢称之为 90% 远程或 95% 远程，因为我们有这些精心安排的线下体验。每年夏天，我们去年刚开始——抱歉，是今年——我们在做一件叫 Shopify Summit 的事情，把整个公司聚集在一起，是一种结合演讲加 hack day 的形式，还有聚餐、派对和乐队表演的聚会体验。这是一种超级有趣的方式，可以重新充电，随着时间重建你的信任电池。然后我们还有一个叫 bursts 的东西，就是”嘿，你想解决某个问题？你需要做原型，你需要做 hack。“人们可以直接说，“嘿，我要发起一个 burst。我们五个人一起去渥太华或多伦多或蒙特利尔或其他地方，讨论这个问题，聚在一起。”

所以这两者的组合意味着，一整年中你都可以充电。我们有信任电池的概念，就是人与人之间能有多少信任，如果你是远程的，它会随时间消耗。所以我们也有办公室，就像——想来就来。比如我之前提到，我每周来一次，现在 Toby 搬到多伦多了，所以我每周来三天。但就是想来就来，你不是必须来，对吧？今天我在家工作，但明天我会去办公室。这又让你有那些随机互动的机会，让你感觉到——是的，我们是 90% 以上远程的。但我认为主要原因是，我们想招聘世界上最优秀的人才，而这些人才可以在任何地方，只是碰巧不是所有人都住在办公室附近。

不过再说回来，关于 burst，这里有个好例子。黑色星期五和网络星期一的时候，我鼓励所有工程领导层来多伦多。我们都在办公室盯着图表。然后对于 hack day，我试着让大家去各个办公点，我们有四个——多伦多、蒙特利尔、渥太华和纽约——同样是想来就来，但能获得那种线下体验。所以这有点像一种组合。我不会称之为混合模式，因为你并没有”每个周五来或不来”这样的固定安排，更像是想来就来。

信任电池

Lenny Rachitsky： 有太多可以聊的了。顺便说一下，信任电池这个比喻太棒了。我也学会了使用它。简单来说就是——你对某个人的信任，把它想象成一块电池，可以消耗也可以增长，你应该尽量在可能的时候充电，然后随着时间慢慢使用这些电量。

Farhan Thawar： 而且它可以是有策略性的。我见过有人把它当作……我很确定 Toby 说他给每个人初始 50%，然后逐渐了解你。然后我也见过有人反过来用，说，“嘿，听着，这个团队很拼。我给你从一百开始，假设你已经拥有高信任，放手去做事情，只有当你做出偏离方向的事情时，你的信任电池才会消耗。“所以我见过人们把这个词当作一种快捷方式，用来搞清楚如何与某人协作。

Lenny Rachitsky： 我非常喜欢你们这种从第一性原理出发的做法，你们的很多运营方式都非常独特，而且显然效果很好。所以我觉得我们可以一直聊下去。我想谈谈招聘。我知道你在如何招聘优秀人才方面有一些非常独特的见解，而且还能快速招聘。但在聊这个之前，在强度、速度、快速推进方面，还有什么你觉得非常有价值想分享的吗？

领导团队的个性与适度混乱

Farhan Thawar： 我觉得领导团队的个性相当有强度。我们的高管团队有很多创始人，他们天然就是急躁、高强度的人。但即使是一些非创始人的高管，也是有成就的人，往往也相当——我们所有人都有这种急躁的态度，所以也许——我甚至不知道这是一种可以学习获得的技能，还是随着你的个性、基因自然而来的。但通常来说，即使在领导团队层面，比如，我们会尝试做——这是我每周发的帖子，列出所有正在进行的事情，这样我们不仅可以分享信息，还能展示各项事情的进展。然后有人可以跳出来说，“哦，你在做的这件事，和我在这里做的那个事有关联。“这创造了一种”随时都有很多事情在进行中”的感觉，我们想保持这种氛围，保持高能量。所以很多都是高能量、高强度的人。

Lenny Rachitsky： 这让我想起我在 Airbnb 的时候，感觉无论事情进展得多好，尤其是 Brian 总是油门踩到底。无论事情进展多好，都觉得还不够好。我们怎么才能更快？怎么才能做得更多？

Farhan Thawar： 我其实会走得更远。我认为如果你没有两三个大项目处于着火状态，你大概推进得还不够，因为你并没有真正尝试那些超出舒适区的事情。如果一切都很顺利，你是否真的在承担你需要承担的风险？所以我认为你必须稍微过度倾斜一些，应该随时有几件事在着火，不是说你应该去制造这些，而是它就应该自然发生，因为你在向新领域伸展，或者你推进得比你本该有的更快，或者你提前启用了一个新的负责人——所有这些事情应该创造一种”可能行得通”的局面。所以你希望在边缘有一点混乱。

Lenny Rachitsky： 我很喜欢这个观点。这可能听起来很有压力——为什么我想要那种到处是混乱和着火的状态？但实际上，如果你不这样做，你的企业不太可能取得巨大成功，而那才是更大的压力和痛苦。

Farhan Thawar： 没错。是的，就像反过来的，对吧？就是这个想法——人们觉得舒适给你带来稳定，但实际上不舒适才给你稳定，因为你在不断学习，这让你对可能遇到的事情更具韧性。

Lenny Rachitsky： 选择更难的路，有人可能会这样说。好的，我们来谈谈招聘。你对招聘有一些非常有趣的观点。我听说过的一个点是，你不太喜欢面试流程。你更倾向于不做面试，而是用别的方式替代。聊聊这个。

Farhan Thawar： 是的。所以在我整个职业生涯中，我注意到——我相信每个人都知道，这是一个公开的秘密，对吧？面试并不是衡量工作表现的好指标。我们都知道这一点。研究证明了这一点。每家公司里的人也都清楚——有人面试表现很好，工作中却不如预期；或者反过来，面试表现一般，进来之后却非常出色。我有一个亲身经历的例子，在我来 Shopify 之前的那家创业公司，我招了两个人做机器学习。一个是博士，在大学教过书，大家一看就觉得——天哪，毫无疑问的人选——而且还是员工推荐的。我们都觉得”这个人肯定很厉害”。另一个人是我在咖啡店遇到的一个小伙子，从来没有过软件方面的工作，但对机器学习特别感兴趣。结果第一个人，我们几周内就让他走了，因为他不适应我们的文化。

第二个人一直在我们创业公司，现在还在 Shopify，是一位非常出色的机器学习工程师。有一次我们的圣诞派对上，他说”这是我的第一份软件工作”。我们都惊了，“怎么可能？“真的是太可爱了。我们给了他们两个人同样的机会。关键是，我没有在任何一个方向上被简历带偏。我们让他们都进来了，说”这是工作环境。“我那家创业公司完全采用结对编程。所以他们就是结对编程。说句题外话，当我用自己的钱让员工结对编程时，我是真心相信这件事的。我付钱让两个人共用一台电脑。所以你知道我是认真的……

Lenny Rachitsky： 代码产出还不到一半。

Farhan Thawar： 对，没错。不到一半。但不管怎样，结对编程。几周之内情况就很明朗了——我一般给人员最多三个月的时间——第一个人明显不行，第二个人则表现很好。所以我很喜欢用赛车来打比方。如果我告诉你”嘿，我想招最好的赛车手”，你其实没什么问题可以问他们的，直接让他们上车就行。我们的情况也是一样的——当然，我们还是需要面试的——但我们确实会在入职后的 30、60、90 天里花时间确认，他们带来的东西是否真正与 Shopify 的需求匹配。同时你也应该对候选人坦诚，因为如果不合适，尽快发现这一点对他们和你都是好事，因为他们可能在别的地方非常出色。

我们之前提到过 Shopify 的环境是混乱的、节奏很快的，这确实不适合所有人，但没关系，对吧？我们并不想要……我们之前说过，我们想成为世界上最好的万人公司。我们不需要几百万人，只需要最优秀的一万人。所以如果不合适，尽快弄清楚对你有利，对我们也有利——你可以去一个你能大放异彩的地方，而我们则拥有在 Shopify 能大放异彩的人。所以工作试用，我是非常推崇的。这就引出了实习项目——多么好的面试流程——因为你可以拿到一个人四个月的真实工作产出。他们可以在四个月里体验在 Shopify 工作是什么感觉，我们也可以观察他们在 Shopify 四个月的表现，然后这可以转化为全职工作。

这才是真正好的面试流程，因为你真的什么都知道了。你不需要……我给你讲一个有趣的例子。我听说有一家公司，他们说”我们有实习项目，实习结束后，我们再面试他们转正。“我就想，“四个月的真实工作经历你都看过了，再花哪怕八个小时面试，你还能了解到什么新东西？“就是这种事情。你只需要看工作产出。所以我是工作试用的坚定拥护者。在之前的公司，就像你提到的那样，我几乎不做面试。我几乎就是直接说”进来干活吧。“这让我们……在前 90 天里，我们有大约 20% 的流失率，因为有些人确实不合适。但过了 90 天之后，流失率不到 1%，因为他们清楚自己要面对什么，我们也清楚他们如何融入。

Lenny Rachitsky： 所以在招聘流程方面，你现在还在 Shopify。你会面试候选人，他们也会做技术评估之类的。但听起来你们会非常明确地设定期望——“我们会录用你，但我们会在前 30、60、90 天里确认这是否真的合适，我们可能会让你走，而且这个可能性不小。“你们就是用这种方式来安排的吗？

Farhan Thawar： 对，我觉得可以这样理解——更重要的是，我们希望让面试流程尽可能接近真实工作本身。因为这样做，我们在面试中评估的技能就更接近实际工作中需要的。这是第一点。第二，我们有一个叫”人生故事”的面试环节，我们试图了解——你过往的所有经历是否能表明你是一个有好奇心、有广度的人？因为如果是的话，这样的人更有可能适合我们。有人说过一句让我印象很深的话——“你知道我为什么不喜欢简历吗？“我问”为什么？“他说，“简历告诉你做了什么，但不会告诉你为什么做那些事。”

这个洞察太有意思了。你的简历应该是一个”为什么”——你为什么从这家公司去了那家？那才是有趣的部分。而不是说你在微软做过 PM，在 Stripe 也做过 PM。关键是你为什么从 Stripe 跳到微软？这里面一定有有趣的故事。所以”人生故事”就是想把这一点挖掘出来——你为什么做了这些决定？你过去做了什么有趣的事？你是否充满好奇心？我一直觉得……我读了一本很棒的书，David Epstein 写的《Range》。那本书可能是我这辈子读过的最让我难受的书之一，因为每一页我都在想，“我不信。“我一直觉得自己是个专家型人才。我不停地翻页，心里想，“我不喜欢这些数据——它们一直说通才更厉害。“但到最后，我意识到自己其实是个通才。我花了那么久才意识到这一点，而我其实挺可笑的——我明明身为工程师，最后却重新设计了 Shopify 的薪酬体系。

所以我内心深处一直觉得自己就是个工程师，尽管我也在做招聘、人力资源等等其他事情。但我觉得这就是我们试图在面试中捕捉的东西。然后在入职初期，我们确实有一个通过 Slack 发送的调研，问”你对招进来的人满意吗？“这个调研应该配合与当事人的面对面沟通——你应该给他们反馈，帮助他们了解”嘿，有哪些地方需要调整才能更好地融入，确保期望一致？“同时也要和对方一起判断——“如果你觉得不太合适，让我们帮你在公司内找一个不同的角色，或者去别的地方，因为我们希望这里的人都有高影响力。“但那个人也应该在某个地方发挥高影响力——可能在 Shopify，可能是同一个角色，可能是不同的角色，也可能在别的公司。这对所有人都是好事。

Lenny Rachitsky： 那你们实际上会对新入职的工程师做工作试用吗？还是说这只是你们想做的事情？

Farhan Thawar： 对，我很想这么做。但我们收到的简历量太大了，很难全面推行。不过在实习生项目中，我们确实在大规模地做这件事。比如 2025 年，我们计划招一千名实习生，这就等于给我一千次工作试用的机会，从中挑选最优秀的百分之几留下来成为 Shopify 全职员工。

Lenny Rachitsky： 展开说说这件事——你们一年内要招一千名实习生，这个数字很大。这个思路是这些人实际上能创造有用的价值，同时实习生项目本身也是一个面试流程？

Farhan Thawar： 对，我觉得有两个层面。有些人把实习生项目看作社区回馈——“让我们回馈社区，招一些早期人才。“我就想，“等等，你是说我一年可以招一千个人？“而且他们会带着 LLM 和一颗大脑来上班，因为他们成长在 AI 时代。他们对我们是有用的，因为他们来自不同的一代人，在我们的场景下就是商业领域，他们对购物、AI、机器人、聊天、语音这些东西有着不同的体验。他们会给我们带来价值。我们也会教他们一些东西。然后我们可以一起决定——他们可能最终去了别的地方，这样的话，他们身上带着 Shopify 的印记走向其他公司，我觉得这也是好事；或者他们可能留在 Shopify，在更长的时间里持续创造价值。

这看起来是三赢。还有一个很酷的事，我发了那条推文之后，一批其他公司的 CTO 私信我说，“嘿，我们要招一千零一个实习生，超过你们。“我说，“太好了。“就凭那一条推文，如果我能让早期人才生态在经历了过去几年艰难的裁员潮之后重新启动，这对所有人都是好事——因为现在他们也意识到这些人非常有价值，他们带来了一套完全不同的技能组合。顺便说一个结对编程里的秘密：实习生永远比全职员工更有强度。所以这也能帮助强度的飞轮转动起来。

实习生项目的灵感来源

Lenny Rachitsky： 一切又绕回来了。这个实习生项目是从加拿大学校的 co-op（带薪实习）体系中发展出来的吗？Waterloo 有一个很大的 co-op 项目？

Farhan Thawar： 对，我毕业于 Waterloo，所以，你懂的。我在 Waterloo 上学，做了 co-op，也参加了实习项目。体验非常棒。因为最终你离开 Waterloo 的时候，拿到的不仅是学位，还有两年的工作经验——我做了六个四个月的实习学期，总共二十四个月。我觉得其中一个很重要的部分就是面试技能，因为每四个月我要面试十几个职位，这样做了六次。所以你出来的时候，既有丰富的面试经验，也有实际工作经验。把这个思路再推进一步，Shopify 一直都有实习生。我觉得我们需要做的是重新启动生态中早期人才的概念。我们的实习生项目有一两个大的不同点。

一是我们要求他们每周来办公室三天，而不是完全远程。目前只在三个办公室推行：蒙特利尔、多伦多和渥太华。原因是，我们希望他们有一个同辈群体——因为早期人才和你我这样已经在行业里摸爬滚打多年的人不一样。我们既在办公室工作过，也远程工作过，我们更擅长处理跨公司合作谈判和与不同公司的人沟通。但这些年轻人没有这些经验，他们可能从来没有在任何地方工作过。

如果不给他们提供线下接触的机会，对他们是一种亏欠。所以我们专门在那些城市设立了实习点，而且很多人确实在搬家——搬到蒙特利尔去做实习，这很棒。如果你是实习生的导师或经理，你每个月至少要跟他们在线下见一次面。我们在刻意构建这些体验。当然，他们会有一批几十人的同辈群体，全程陪伴。我们觉得这会让他们的体验更好。当然，没有什么比拍拍一个人的肩膀说”你见过这种情况吗？“更有效的了——对于早期人才来说，线下更容易做到。然后当然，随着时间推移，如果他们转为全职，还是可以来办公室——想来就来，也可以完全远程。

Lenny Rachitsky： 太棒了。给不太了解 co-op 项目的人简单说一下——基本上就是在你上学期间、毕业之前，夏天去公司工作。

Farhan Thawar： 不对。

Lenny Rachitsky： 哦，是全年进行的。好吧。

Farhan Thawar： 对，是全年进行的。Waterloo 的模式是这样的——我当时先上了八个月的课，两个学期。我的第一个 co-op 学期是夏天，但之后就是工作、上学、工作、上学，在整个余下的时间里交替进行。

Lenny Rachitsky： 就像是学期交替。

Farhan Thawar： 没错。每四个月，我要么在学校上课，要么在工作。所以我有时候一月份在工作，有时候九月份在工作。这非常好，因为它也让我能够在学校里超级高强度地学四个月，然后再去高强度地工作四个月。这个模式……我这周刚去 Waterloo 做了一次演讲，所以我很喜欢 Waterloo 和雇主之间这种共生关系。顺便说一句，不只是 Waterloo，很多学校都有暑期项目，UFT 和其他学校，美国也有很多学校在做。

Lenny Rachitsky： 有个有趣的插曲——完全跑个题——我之前有过一家创业公司叫 Local Mine，在蒙特利尔创办的。我不是加拿大人，但因为各种原因搬到了那里。那段经历很棒。我们的第一个员工就是从 co-op 项目来的，我不确定是不是 Waterloo 的，他叫 Nick Adams。他看到了我们的招聘帖子投了简历，我们当时还想，“co-op 是什么？“然后他来工作了，之后回学校继续读书，后来我们正式雇了他，再后来我们公司被收购后他去了 Airbnb。

Farhan Thawar： 没错。对我来说，当我做自己的创业公司 Helpful 时，我有一两个工程师，然后我真的直接招了四个实习生——因为你是二月份招人、五月份到岗。而且因为我在做结对编程，我得确保到时候有四个全职工程师在。所以我提前招了实习生，等着全职到位。我记得我差了一周——有一个实习生有一周没有搭档，但之后到了五月，我有四个全职、四个实习生，然后他们就全程结对工作了。

XtremeLabs 与 120 个直属下属

Lenny Rachitsky： 真是一段奇妙的旅程。我想再聊一个话题，然后我们就收尾。是关于 XtremeLabs 的。这里面有很多故事。感觉就像是加拿大的一个科技黑手党，涌现了很多非常厉害的人，有很多可以聊的。我听说的一个事实是，你在那里的时候有一百个直属下属——直接向你汇报。

Farhan Thawar： 一百二十个。

Lenny Rachitsky： 一百二十个直属下属，对我来说简直是噩梦。跟我说说你为什么决定这么做，以及是否推荐其他人也这样做。

一百二十个直属下属

Farhan Thawar： 是的，事情是这样的。我们一开始很小，只有十个人。我加入 XtremeLabs 的时候不是创始人，但非常早期，我就让所有人都直接向我汇报。然后随着团队扩张，我就一直让这些人继续直接向我汇报。我在思考，我们之前聊过匠人和匠人天堂这个概念——人们其实并不那么……管理者是有用的，但我在想，能不能用其他方式解决他们需要管理者来解决的那些问题？比如说，我该做什么？我想，“好，我们有产品待办列表”；或者”我被卡住了”，“我需要对我正在做的产品获得反馈”，或者”我在这个技术问题上卡住了”。我试图找到一些办法，让管理者不再是这些问题的唯一答案。

应该有别的解决方式。所以结对编程确实能帮你快速解除阻塞，因为你有另一个人可以讨论技术想法。有产品待办列表就能告诉你该做什么。我们每周都有内部 demo，然后每周还跟客户做 demo，因为我们本质上是为移动端做合同制造的。这给了他们反馈，知道方向对不对。我们有固定的工作时间，这让办公室里的节奏非常紧张。再说一次，那是 2009 到 2013 年的事了。所以这些事情其实都不需要管理者。我意识到的是，解除阻塞这件事才真正需要管理者。“我被卡住了”。那我就说，好吧，如果……我手下有这些 director。我做了两件出了名的事：第一，我有很多直属下属；第二，我完全不做定期一对一，因为你有 120 个直属下属的话不可能做定期一对一，否则你除了做一对一之外什么都干不了。

所以我说，“我会经常在周围出现，因为我不怎么开一对一会议。所以我们可以做非定期的一对一。“这也就是说，如果你被卡住了——实际上有一张很出名的照片，我的工位是一个很奇怪的正方形，几乎是圆形的，在整个工程师办公区域的正中间。我总是在那里，因为我不怎么开会，被卡住的人就可以直接走过来找我。实际上，线下结对编程有一个很酷的地方，就是你往对面一看就知道这个结对是不是在正常运转。因为如果两个人都在电脑前全神贯注，你就知道在正常运转；如果一个人往后靠或者你觉得”不对劲”，你就可以直接走过去——

如果说有一个人往后靠或者你觉得不对劲，那就不在正常运转。你就可以直接走过去问，“怎么回事？“但他们会来问我问题，我可以帮他们解除阻塞。比如，嘿，我们被这个卡住了，我们没有这个 API，我们需要钱买这台机器，之类的。所以这些非定期的一对一最终对我来说成了一种非常清晰的沟通方式。因为我整个职业生涯都在做定期一对一，离开微软三年后我想，那些每周一次持续三年的一对一到底有什么用呢？一百五十次一对一。

而非定期的那些确实有用。我想，当我敲开我经理的门说”我有这个问题”的时候——那些时刻才是重要的。所以这就是我在 XtremeLabs 创造的模式。那 120 个下属，就是随着时间自然增长的。我就是觉得不需要中间层管理者。那我就换一种方式帮这些人解除阻塞。我们想出了其他系统来解除阻塞，不需要管理者。而且我记忆力也不错，我清楚每个人的技能和薪酬，这些我都装在脑子里，这也很有帮助。

Chamath 的关键一问

但我确实打破了一样东西。实际上是 Chamath，他进来成为了我们最大的投资人。他显然是个聪明人，但他说了一句很到位的话——他不是说”这不可能行得通”，因为那样我会进入防御模式，向他解释为什么行得通。他只是对我说，我不会跟你争论这个现在行不行得通，但在四百人的规模下还行得通吗？我说，可能不行。他说，好，那就改。

所以后来我们确实加了一些结构，但我让几个人做 director，要求每人带 40 个直属下属。我说，我们仍然保持相当扁平的结构。这个模式后来确实奏效了，因为它仍然让他们用系统来解除人们的阻塞，而不是非得每周做一对一，或者讨论那些系统就能解决的阻塞问题。所以我一直在想办法把事情系统化。

Lenny Rachitsky： 我很喜欢这个故事。又是一个打破常规的例子，不是简单地”大家都是这么做的所以我也这么做”，而是亲自去实验。即使你心里清楚，也许长期来看这不是最终的运作方式。我想在 Shopify 你应该没有 120 个直属下属吧。

Farhan Thawar： 没有，大概十四个左右。我们确实有一些指导原则，在工程团队中我们说每个人应该带八到二十个下属。肯定有人多有人少。但我们确实尽量保持扁平，因为我们相信三个人向一个人汇报，那个人上面又只有三个人，这种深层级架构是没有意义的，只会制造一个非常深的层级结构。顺便说一下，我们确实能看到——离 Toby 越远，我们在调研结果中就能看到问题。对齐会出现偏差，所以你确实能看到你需要更近、需要一个更扁平的组织，而实现方式就是每一层有更多的直属下属。

Lenny Rachitsky： 有道理。好，最后一个问题，然后我们进入非常令人期待的快问快答环节。我们有一个固定环节叫”失败角”——一般来说，人们上播客节目都是分享自己的成功故事，这是我做过的所有事情，这些是我的重大胜利。然后大家会觉得，唉，要是我也能一直这么成功就好了。但实际上，每个上节目的人都失败过很多次。你能不能分享一个你职业生涯中的失败故事，让大家看到像你这样的人也会失败，以及你从中学到了什么？

失败角

Farhan Thawar： 我有几个。先说一件事，我觉得我在 Tim Ferriss 的书或者播客里看到过，他说，创建一份失败简历，把所有事情都写下来。我不建议大家这么做，因为我真的做了——我是一个精力充沛、开朗的人。我在手机上建了一个备忘录叫”失败简历”，把所有失败的经历都写了下来，真的很令人沮丧。所以我不建议大家这么做，但我很乐意分享几个案例。

一个是我实际上被裁员过两次。大家可能想不到——哦，我在做这些事，竟然被裁过两次。但我觉得那两次都是正确的决定，对公司正确，对我也正确。

我其实把那些经历当作重新审视自己的方式，最终形成了我现在如何分配时间的框架。不过那是另一个故事了。

Shopify 的失败案例

Farhan Thawar： 我讲一个在 Shopify 的例子吧。2019 年，我刚入职的第一周，我们在重建销售终端（POS）系统，这个系统现在的 GMB（商品交易总额）已达数十亿美元。但当时我们的想法是，用新的 UX 和新的技术平台来重建它。那是我入职第一周，我是移动端的人，来自 XtremeLabs。大家讨论的是，我们该用 React Native 来构建，还是在各移动平台上原生构建？于是我做了一番评估，花了很多时间，诸如此类，最后我给出了一个折中方案——现在想想挺蠢的。我说，iOS 用 Swift 做，Android 用 React Native 做。我的理由是，我想学习 React Native，而且我觉得 Android 是更难的平台，所以用 React Native 来构建，但 iOS 用 Swift，因为这样可以确保我们的产品能上市。当时我们市场上还没有任何 React Native 应用。一年后我们发布了 iOS 版本，大获成功。然后我们又花了六个月为 Android 和其他平台构建 React Native 版本。我们很快就意识到，React Native 才是面向未来的平台。我们心想，天哪，这让我们可以统一为一个平台，甚至可以在 Web 上运行，而且可以让 Web 的 React 工程师来参与开发。赢家非常明确。那时我们还发布了一个 Shop 应用，也是 React Native 的。

我们学到了很多。于是我回去跟大家说，各位，我犯了一个巨大的错误。我们花了一年时间构建这个东西，已经上线了，但我们不得不重写。我们得重新基于 iOS 版本来做。我想我凭加入 Shopify 第一周做的那个决定，实际烧掉了一百名工程师十八个月的时间。我去找 Toby，跟他说，嘿，我觉得我犯了这个错误，我们得这么做，这要再耗费一百名工程师、六个月什么的。他看着我说，你应该把这个故事告诉所有人。他只说了这句话。不是说”嘿，不好”或者”好”。他说，你学到什么了吗？对我来说那是一个顿悟时刻，但他的意思是，这是一个学习型组织。我彻底失败了，我告诉了所有人我失败了、我犯的错等等，但他说，直接告诉大家就行了。然后他说，你知道你犯了什么错吗？

我一开始说，我不觉得……什么错？他说，你没有冒险。他说，我永远会对不冒险的人严厉对待，而你在这种情况下没有冒险。但如果你冒了险但结果不好，你永远不会惹上麻烦，因为你冒了险，而且是正确的风险。但他说，但你没有冒险。

所以我本应该做的——顺便说一句，即使现在回想起来，这也非常难做到——Shopify 第一周嘛，就是去冒险选择一个我们还没有发布过生产应用的平台。但他是对的，我们本应该这么做，因为那样我们会省下大量时间。所以是的，彻底的失败，抱歉。不过现在产品非常成功，我们全部上了 React Native，连 Shop Green 应用也是 React Native 的。所有东西都是 React Native，我们还是核心贡献者。一切都很好。但我确实烧掉了一百名工程师大概十八个月的时间，作为我在公司的第一个决定。

Lenny Rachitsky： 这可能是我见过的最好的失败协调案例了。这是一个非常好的例子。两个其实都是，不过我在想，好吧，这对我来说感觉像是一个很不错的决定，而且——

Farhan Thawar： 听起来像，对吧？但那就不是他的决定了。

Lenny Rachitsky： 但很显然，你不能一味地冒险。冒险是有界限的，应该是知情的冒险。你当时有没有遗漏什么信息，本可以告诉你这是正确的路径？因为事后来看当然应该这么做，但回顾当时，你觉得除了”我们应该走那条风险更高的路”之外，你还应该做什么？

Farhan Thawar： 嗯，有一点关于我职业生涯的特质——我做事情从来不会只做一半。当我开始研究 React Native 时，绝不是随便看看文档、读一读、做个小东西就完了。我飞到 Meta，和 React 团队见面。我成了核心贡献者，负责运营 React Native 工作组，我们成了 React Native 的发布负责人（release captain）。我早就知道自己会做所有这些事情，所以我想——而且在 React Native 中你也可以下沉到原生层做那些不可能在框架层完成的事情——所以我认为我当时的折中是错误的。我知道自己会全力以赴做所有这些事，我本应该审视自己的思考过程，说，如果我把所有事情都做了，还能失败吗？但我没有考虑到这一点，因为我同时做了五六件事。

我真的把所有人召集到一起，运营那个工作组，当发布负责人，和 Meta 的 React 团队一起交流，做所有的事情。我们甚至比成为 React 核心贡献者更早地成为了 React Native 的核心贡献者，就因为我做的那些事。所以我觉得，既然知道自己会全力投入，我就应该说，你知道吗？这不会失败的。但我当时对那条路径没有信心，所以我折中了。折中是最糟糕的。我记得当时的 CTO 说过，我在想是不是应该直接要求你上 React Native。他原话就是这么说的。我说，如果你这么要求，我会照做，但那就是他的决定了。他没有这么做，他没有告诉我去做。

Lenny Rachitsky： 好吧，这就说得通多了。太有趣了，Facebook 在早期也犯过类似的错误——

Farhan Thawar： HTML5。

Lenny Rachitsky： 对，就是这个。不知道你有没有看过 Zuck 在 Chase Center 接受 Acquired 播客采访的那次，他谈到这件事时说，他们的市值跌了 80%，即将上市，他们推出了那个应用，没人认为他们能做移动广告。他说，那让我们倒退了一年半。但他说，基于后来经历的所有痛苦来看，那还不算太糟。

Farhan Thawar： 对，确实如此。也许大家不知道的是，我当时在 Facebook，在 XtremeLabs，参与了 Facebook 应用的开发，我们做了那个应用。那整周每天提交 iOS 应用的时候我都在办公室，因为它不断崩溃。我们显然有苹果那边的人的直接联系方式，但我们周一提交一个新应用——崩溃了，再提交一个应用……不只是我们，是我们和 Facebook 一起。所以我从内部亲历了那场 HTML5 的灾难。

Lenny Rachitsky： 我还以为你要说你也建议了 Facebook 选择 HTML5 应用，让他们倒退了一年呢。

Farhan Thawar： 我没有。我们恰好在那段时期和他们在一起。是的。

Lenny Rachitsky： 太搞笑了。太精彩了，谢谢分享。在我们进入非常精彩的快问快答环节之前，你还有什么想留给听众的吗？可以是你提到过的某个话题的补充，最后一条智慧 nugget，还是说我们直接进入快问快答？

一段题外话

Farhan Thawar： 嗯，我说一件可能让你有点尴尬的事吧。我一直在用你的绩效管理框架，就是你那篇第一轮评审文章里的，而且我当时并不知道那是你写的。我其实是先发现了它——你作为著名的 Lenny 播客主持人而被大家熟知，但在更早的日子里，也许是那个做 PM 的 Lenny。我很久以前就读到过那篇文章，然后直接复制了里面的内容，里面有一个 Google 文档链接，是一个绩效评审框架的模板，我已经用了好几年了。

Farhan Thawar： 我在 Shopify 做的每一次绩效评审，用的都是那个框架。最近我在给我的行政助理写一个帖子，讲怎么用 LLM 来帮我更轻松地写这些评审——当然，内容你都得自己读、自己过一遍——但我在想，能不能用 LLM 生成一部分？所以我想把原文发给她。于是我回去翻 First Round Review，找到了那篇文章，然后一看——天哪，是 Lenny，同一个人。

我觉得这个框架有趣的地方在于，我在这里用了六年了，而且我觉得不是我的功劳，是这个框架本身能挖掘出好的信息。在评审过程中，有多个人跟我反馈说，当我按照那个格式交付反馈时，他们会说，哇，我在这个行业干了这么久，这是我收到过最好的绩效评审。这是因为框架本身能挖掘出好的信息。所以要恭喜你。

但让我觉得好笑的是，我随机地要来上这个播客，两三周前才刚给行政助理写了那个文档，然后发现是同一个人。

Lenny Rachitsky： 哎呀，这可真是太巧了。我太喜欢这个故事了。我也要归功于这个播客的一位四期嘉宾 Vlad Loktev，他是我当时在 Airbnb 的经理，我就是受他启发才写了那篇关于绩效评审框架的文章。

Farhan Thawar： 太棒了。

Lenny Rachitsky： 所以功劳要追溯到他那。我也不知道他是从哪学来的，搞不好就是他自己发明的。所以也要感谢 Vlad。顺着这个话题再说一个有趣的事：我在 First Round Review 上还有另一篇关于 W 框架的帖子，那是一个做年度规划的框架。我慢慢发现很多很多公司都在用这个框架，但不知道它是从哪来的。他们就说，哦，我们有这个 W 框架。有人把它翻了个方向，叫 M 框架。但这是另一个渗透到科技公司生态中的东西，非常棒。

Farhan Thawar： 太棒了。

快问快答环节

Lenny Rachitsky： 好了，Farhan，我们已经到达了非常精彩的快问快答环节。准备好了吗？

Farhan Thawar： 准备好了。

Lenny Rachitsky： 开始吧。你有两三本最常推荐给别人的书吗？

Farhan Thawar： 有一本。Toby 有一个让人烦恼的超长书单，他推荐的书——不是全部，通常都很好，取决于我们是否在同一个频道上，比如小说方面就不是。但他推荐给我一本，我觉得现在每个人都应该读，叫《Manna》，M-A-N-N-A，作者是 Marshall Brain。这是一本关于 AI 的书。我觉得最有趣的地方在于，它描绘了一个 AI 告诉人类该做什么的未来。就是这样一个设想：想象一下未来你上班的时候，AI 会告诉你该关注哪些邮件，或者该看哪个仪表盘，因为出了什么异常。这本书把这个概念推到了一个有趣的层面。我推荐读一读，不长，挺有意思的。

另一本我经常推荐给人的书，说起来有点奇怪推荐这个，是 John Brooks 的《Business Adventures》。这本很有名，如果你问——我想是比尔·盖茨——他认为有史以来最好的书是哪本，就是这本。这本书最酷的地方在于，对任何有注意力问题的人来说都不容易消化。Paul Graham 写过一篇文章叫《How to Do Great Work》，超级长。那篇文章最棒的部分就在于你必须能通读全文。《Business Adventures》也是一样的道理。它一共 12 章，12 个故事，中间没有停顿。每一篇都超级长。但它会深入到一个问题中去，如果你能保持专注，读透每个问题的深度，你一定能学到东西，就像 Paul Graham 那篇文章一样。我很喜欢它那么长，因为我把它发给别人时会说，这里的考验是你能不能读完？能不能一直读到结尾？这不是贬义的意思——如果你能读到结尾，你就能从这篇文章中提取出精华，前提是你能全部读完。所以这两本——《Manna》正好相反，非常简单，轻松易读。

Lenny Rachitsky： 我很想读这两本。下一个问题。你最近有没有特别喜欢的电影或电视剧？

Farhan Thawar： 最近的一部是《Challengers》，那部关于网球的电影，Zendaya 主演的。我就是在家随手点开看了，最棒的是它的摄影和音乐。他们用了一种奇怪的艺术片风格，人物在说话的时候音乐会突然变得特别大声，非常奇怪，但非常非常好的电影。然后你刚才说的是电影和——

Lenny Rachitsky： 或者电视剧，对，什么都行。

Farhan Thawar： 对，我历来最喜欢的之一大概就是《Halt and Catch Fire》了。不知道你看过没有。

Lenny Rachitsky： 关于早期科技行业的那部。

Farhan Thawar： 早期科技行业。我记得 Andreessen 在一个播客里说过，这是最接近真实创业公司样子的一部作品。所以《Halt and Catch Fire》是我的终极推荐，每个人都应该看。

Lenny Rachitsky： 你最近有没有发现一个你特别喜欢的产品？

Farhan Thawar： 我不知道我现在想不想赶上潮流，但 Meta Ray-Ban 真的很棒。关于 Meta Ray-Ban 最大的事情是，我一直没有入手，看到身边的人在戴，直到有一天有人说，“我再也不带 AirPods 出门了。“我就想，哦，我可以把两个设备换成一个设备。我出门总会带墨镜和 AirPods，因为我会去散步或者听播客，现在只需要一个设备就行了。

有一次就是这样，夏天的时候，我在一个泳池派对上，有人给我打电话，我就直接用墨镜接了，旁边的人都搞不清楚我在哪接的这个电话。但它的科技含量刚刚好，不突兀，你看不出来，看起来不像任何科技产品。还有一次我在跟孩子们踢足球，我有三个孩子，我就把视频功能打开了，我当守门员，他们在射门，我在守门。他们完全不知道我在录像。这是一个非常棒的时刻，因为我在跟他们一起踢球，没有拿着手机，却拍到了一组我本来根本不可能拍到的视频。所以我真的很喜欢 Meta Ray-Ban。

Lenny Rachitsky： 我们请过 Boz 来做播客，他负责很多这方面的工作，他给我们演示了一下。我做采访的时候还专门戴上了 Ray-Ban，纯粹为了好玩。你可以看看我的设置。好的，还有两个问题。你有没有一个最喜欢的人生座右铭，在工作或生活中觉得特别有用的？

Farhan Thawar： 好的，我有。而且我的很多个人简介里都有这句话，就是：“你所知道的一切都是错的”（everything you know is wrong）。我喜欢这句话的原因——人们总问，你会把什么放在广告牌上？然后人们会回来跟我说，他们知道这是我的座右铭。

原因是它体现了一种理念：如果你所掌握的所有知识都是错误的，你能否从第一性原理出发，重新构建对世界的认知？我大致就是这样思考问题的——任何东西都可能是错误的，甚至那些你认为是正确的东西。这也是为什么，回到之前说的，我喜欢做实验，我喜欢看起来很傻，因为我总是在尝试各种东西，因为我在想，即便你说这是对的，我也不确定这到底行不行得通。

特斯拉趣事与人生信条

Farhan Thawar： 举个实际的例子——我妻子很讨厌我这样做——我有一辆特斯拉，我经常在车还没完全停稳的时候就换挡，普通车是做不到的，但我会挂在前进挡，减速准备倒车进车库，然后趁着车还在动就直接切到倒挡。

要不是亲自试过，你根本不会知道这操作是可行的。有时候车会发出嘀嘀声提示你速度太快了。我妻子特别讨厌我这样。但我就是喜欢尝试各种奇怪的东西，所以我说”你所知道的一切都是错的”。谁知道什么是可能的呢，试试就知道了。

Lenny Rachitsky： 我的特斯拉我也这么干。以前开非电动车的时候也这么干，我老婆总说，别这样，会搞坏的。

Farhan Thawar： 对，就是这样。

Lenny Rachitsky： 我特别喜欢电动车这一点——没有齿轮会被你弄坏，它就是软件。

Farhan Thawar： 没错。

Lenny Rachitsky： 你分享的那句”你所知道的一切都是错的”，让我想起 Airbnb 的创始人也经常说类似的话——你周围的一切都是某个人设计的，另一个和你一样的人。他们未必比你更聪明、更有洞察力。他们的做法不一定就是对的，别人也许能找到更好的方案……

Farhan Thawar： Steve Jobs 也说过类似的话，大意是你能设计任何东西，一切都是人设计的。这句话我也很喜欢。

招聘女服务员的故事

Lenny Rachitsky： 对。最后一个问题。你之前给我讲过一个故事，说你招了一个博士，然后又招了一个在咖啡店偶然遇到的人。我还读到过另一个类似的故事，说你招了一个女服务员。

Farhan Thawar： 是的。

Lenny Rachitsky： 这是真的吗？来，讲讲这个故事。

Farhan Thawar： 嗯，这又是我妻子对我头疼的事情清单上的一项。每次我们出门，我总在四处观察，总在扫描周围的人——看看有没有认识的人之类的。我喜欢观察人，而且我对面孔的记忆力很好。这次的情况是我们去了一家餐厅，我看到一个女服务员做得非常非常出色——她在不同的餐桌之间来回穿梭，面带微笑，记下所有人的订单，确认厨房那边的事情也在有条不紊地进行。她几乎是在掌控那家忙得不可开交的整个餐厅。于是我跟她聊起来，我说，你在这之外还做什么？你看起来特别厉害。她说，你什么意思？我就是个服务员啊。

我说，那你愿不愿意——当时是 XtremeLabs——我说，你愿不愿意来 XtremeLabs 工作？她说，那是什么？我就给她解释了一下，拿到了她的联系方式。她来到办公室，一开始做的是前台接待，从零售行业进入了办公室环境。然后我把她调来做我的行政助理，再后来她成了我的一名招聘人员。我教她怎么做招聘、怎么跟人沟通，她跟着我去参加宣讲会。后来我们实际上又从那家餐厅招了更多工作做得非常出色的人。令人惊讶的是，首先，她很有条理，但不是那种教条化的条理。我得教她用 Google Docs 和 G Suite 这些工具，但她非常聪明，只是从来没有得到过机会。

最酷的是，她最终接手了我们的一项 HR 职能。她之前有大专学历，凭借在我们这里积累的工作经验，她得以再读一年，拿到了大学学位。现在她是一家公司的 HR 总监。这简直太棒了——她从那种环境走到了这种环境。而且她之前从餐厅带出来的那些聪明又拼命的人，后来也都走上了非常棒的职业道路。只要我看到某个人工作做得好，我就会想，他们是做什么的？我能不能跟他们合作？这只是把人从那个环境中发掘出来的一个例子。我还有很多其他类似的经历——比如在旁边听到某个设计师或工程师的对话，然后我就试着把他们招进我的公司。

Lenny Rachitsky： 哇，这个故事太好了。我特别喜欢。也许餐厅是科技公司新的人才输送管道，之前还真没想到这一点。

Farhan Thawar： 嗯，我的意思是，每个人都在某方面是聪明的。我当时就是想弄清楚，她在这件事上做得这么好，那她在别的事情上一定也会非常出色。

Lenny Rachitsky： 太棒了。感觉还有很多故事可以讲，但我们得收尾了，让你走了，Farhan。最后两个问题：如果大家想联系你、了解更多信息，或者想申请去 Shopify 工作，在哪里可以找到你？另外，听众怎样才能帮到你？

Farhan Thawar： 好的，Twitter 大概是我最常出没的地方，就是 X 上的 @FNThawar，回头我放到节目备注里。至于听众嘛，我的意思是，我喜欢被挑战。肯定有人听了我说的话之后会觉得，哦，这也太蠢了，我们做法不一样，或者这里有研究表明那个方法是行不通的。我很愿意听到这些，因为说实话，我就是一直在学习的路上。如果我做了什么蠢事，我非常希望能学到更好的方法。所以我很希望大家留言评论，比如，嘿，这个想法很蠢，你应该试试那个，或者，这根本说不通。我很想多学一些。这就是我想说的。

Lenny Rachitsky： 好的，大家可以在 YouTube 或 Substack 帖子里留言，说说 Farhan 哪里说错了。

Farhan Thawar： 太好了。

Lenny Rachitsky： 非常感谢你的到来。

Farhan Thawar： 谢谢邀请我。大家再见。

结语

Lenny Rachitsky： 非常感谢大家的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你最喜欢的播客应用上订阅。也请考虑给我们评分或留下评价，这真的能帮助更多听众发现这个播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于节目的信息。下期再见。

术语表

原文中文
AcquiredAcquired（知名商业播客，不翻译）
Amos TverskyAmos Tversky（知名认知心理学家）
AndreessenAndreessen（指 Marc Andreessen，知名风险投资人、a16z 联合创始人）
API compatibleAPI 兼容
Bill Gates比尔·盖茨
Black Friday, Cyber Monday黑色星期五和网络星期一
BozBoz（Andrew Bosworth 的昵称，Meta 高管、CTO）
BrianBrian（指 Airbnb 联合创始人兼 CEO Brian Chesky）
burstburst（Shopify 内部的短期线下协作冲刺，不翻译）
Business Adventures《Business Adventures》（John Brooks 所著商业纪实书籍，不翻译）
Challengers《Challengers》（2024 年电影，不翻译）
ChamathChamath（指 Chamath Palihapitiya，知名风险投资人、Social Capital 创始人）
chaos monkey混沌猴
CodyCody（Shopify 早期联合开发者，不翻译）
cold calling陌生拜访（cold calling）
crafter匠人（Shopify 内部对工程师、设计师等技术人员的称呼）
cruft冗余代码（代码库中积累的无用、过时代码）
CursorCursor（AI 代码编辑器，不翻译）
Daniel Kahneman丹尼尔·卡尼曼（诺贝尔经济学奖得主、认知心理学家）
Delete Code Club删除代码俱乐部（Shopify 内部项目）
demo culturedemo 文化（以实际演示为核心的工作文化）
Dilbert boss呆伯特式老板
Fail Corner失败角
Failure Resume失败简历
field CTOfield CTO（区域首席技术官）
first principles第一性原理
First Round ReviewFirst Round Review（First Round Capital 旗下的出版物，不翻译）
friction log摩擦日志（friction log，记录产品体验中摩擦点的文档）
GCPGCP（Google Cloud Platform，不翻译）
get shit done (GSD)get shit done（GSD，Shopify 内部项目管理工具/理念）
GitHubGitHub（不翻译）
GMBGMB（Gross Merchandise Volume，商品交易总额）
hack dayhack day（黑客日，Shopify 内部的创新/实验日）
Halt and Catch Fire《Halt and Catch Fire》（AMC 出品电视剧，不翻译）
How to Do Great Work《How to Do Great Work》（Paul Graham 所著长文，不翻译）
ICIC（Individual Contributor，个人贡献者）
illities”ility” 属性（软件工程中非功能性需求统称，如 reliability、scalability、maintainability 等，均以 -ility 结尾）
John BrooksJohn Brooks（美国财经记者、作家）
life story人生故事（Shopify 面试环节之一，了解候选人经历与动机）
lightning round快问快答环节
M frameworkM 框架（W 框架的变体）
mandatemandate（明确的授权/指令）
Manna《Manna》（Marshall Brain 所著关于 AI 的中篇小说，不翻译）
Marshall BrainMarshall Brain（美国作家、HowStuffWorks 创始人）
meeting Armageddonmeeting Armageddon（会议末日，Shopify 每年一次清除周期性会议的实践）
Meta Ray-BansMeta Ray-Ban（Meta 与 Ray-Ban 合作推出的智能眼镜）
Michael Lewis迈克尔·刘易斯（知名非虚构作家）
moratorium禁令期
OK1 / OK2OK1 / OK2（Shopify 内部项目评审流程）
pair programming结对编程
ParagParag（指 Parag Agrawal，Twitter 前CEO）
Parkinson’s Law帕金森定律
pathfinding探路
Paul GrahamPaul Graham（Y Combinator 联合创始人、知名创业者）
performance review framework绩效评审框架
PivotalPivotal（知名软件开发咨询公司，不翻译）
PMPM（Product Manager，产品经理）
Range《Range》（David Epstein 所著关于通才与专才的著作，全名 Range: Why Generalists Triumph in a Specialized World）
release captain发布负责人（release captain，开源项目中负责版本发布的角色）
Shaquille O’Neal沙奎尔·奥尼尔
ShopifyShopify（知名电商平台，不翻译）
Shopify SummitShopify Summit（Shopify 全公司年度聚会，不翻译）
SpinSpin（Shopify 内部云端开发环境）
sunk cost fallacy沉没成本谬误
The Undoing Project《The Undoing Project》（Michael Lewis 关于行为经济学的著作）
Tim FerrissTim Ferriss（知名作家、播客主持人，著有《The 4-Hour Workweek》）
TobyToby（Shopify 创始人 Tobias Lütke 的昵称，不翻译）
token gatingtoken 门控（持有特定 token 才能访问的机制）
trust battery信任电池（trust battery，Shopify 内部用于描述人际关系中信任增减的比喻）
TupleTuple（结对编程远程协作工具，不翻译）
underhanded free throw端尿盆式罚球
unreasonable man不讲道理的人（引自萧伯纳名言）
Vlad LoktevVlad Loktev（Lenny 在 Airbnb 时的前经理）
VP and Head of Eng工程副总裁兼工程负责人
W frameworkW 框架（年度规划框架）
wayfinding寻路
WhisperWhisper（OpenAI 语音识别模型，不翻译）
XtremeLabsXtremeLabs（Farhan 之前所在的公司，不翻译）
ZendayaZendaya（美国演员，不翻译）
ZuckZuck（Mark Zuckerberg 的昵称，不翻译）

此文档由 AI 分片翻译（translate_long_document）