工程师们迫切希望产品经理理解的事 | Camille Fournier（《The Manager's Path》）

Camille Fournier 2024-09-15

工程师们迫切希望产品经理理解的事 | Camille Fournier（《The Manager’s Path》）

产品经理最令工程师反感的行为

Lenny Rachitsky： 我很好奇，产品经理做的哪些事最让工程师反感。

Camille Fournier： 独占功劳。产品经理往往是项目对外沟通的窗口。工程师有时觉得自己得不到应有的认可，因为产品经理揽下了项目的所有荣耀和功劳，而工程师明明为此付出了大量心血。

Lenny Rachitsky： 我发现最优秀的产品经理往往是说话最少、鼓励其他人去做展示的那些——

Camille Fournier： 工程师对产品经理第二反感的事，就是对方根本不了解细节，还表现得好像细节无关紧要。这体现出对工程师工作的严重缺乏同理心，我觉得这真的会让人非常反感。

工程师的内在驱动力

Lenny Rachitsky： 你能不能谈谈人们对工程师的动机可能存在哪些误解？什么才能真正激发他们的热情？

Camille Fournier： 很多人以为工程师只是写代码的。不要低估你的工程师想要理解业务问题、理解客户问题的意愿。我认为那些做得最好的产品经理，不会因为别人有好想法而感到威胁。

嘉宾介绍

Lenny Rachitsky： 今天的嘉宾是 Camille Fournier。Camille 是科技行业最受尊敬的技术高管之一，也是《The Manager’s Path》的作者，这本书被许多人视为职业发展和走向管理岗位的权威指南。在她的职业生涯中，她曾担任 Rent The Runway 的 CTO、Goldman Sachs 的技术副总裁、JP Morgan Chase 的全球工程与架构主管，以及 Two Sigma 的平台工程负责人。她今年晚些时候还会出版一本新书，名为《Platform Engineering: A Guide for Technical Product and People Leaders》，目前已经可以预购，我们会在对话的后半部分深入讨论这个话题。

我们还会深入探讨产品经理做的哪些事最让工程师反感，以及如何避免；为什么大规模重写往往是一个陷阱；为什么你可能应该减少一对一会议的频率；成为管理者后最让人意外的是什么；以及在转向管理之前应该做多久独立贡献者（IC）的一些非常实用的经验法则，还有更多内容。这期节目涵盖面很广，会帮助你以全新的方式思考管理、平台团队、团队文化以及产品经理与工程师的关系。如果你喜欢这档播客，别忘了在你常用的播客应用或 YouTube 上订阅关注。这是避免错过未来节目的最佳方式，对播客也有极大的帮助。话不多说，有请 Camille Fournier。Camille，非常感谢你的到来，欢迎来到播客。

Camille Fournier： 非常感谢邀请我来。

如何做一个不那么令人反感的产品经理

Lenny Rachitsky： 这是我的荣幸。我想先问你一个很多产品经理都在想的问题：如何做一个不那么令人反感的产品经理。我知道你多年来和很多工程师共事过。我很好奇，产品经理做的哪些事最让工程师反感？产品经理又该如何避免？

Camille Fournier： 我觉得产品经理做的让工程师反感的事情有好几件。先说明一下，我确定工程师同样也令产品经理很头疼，所以这是一条双向车道。有些问题很好解决，有些可能稍微难一些。好解决的问题首先是独占功劳。有时候产品经理因为是项目对外沟通的窗口——跟客户谈、跟高管团队汇报等等——工程师有时觉得自己得不到应有的认可，因为产品经理揽下了项目的所有荣耀和功劳，而工程师明明为此付出了大量心血，对吧？所以要尽一切努力分享功劳，把工程团队纳入进来，在适当的时候给他们机会讲述自己的贡献。我觉得这些都是产品经理可以做的事，来避免那种——我认为相当容易解决的烦恼，就是不要独揽功劳，这不只是你一个人的事，有很多人为此付出了努力。

这也就自然引出了工程师对产品经理反感的第二件事：不了解细节，还表现得好像细节无关紧要。我认为这其实是一种文化差异。即便是普通管理者，像我这样需要跨很大范围管理、不得不更多关注全局的人，也会忘记工程要做得好，真正的关键恰恰在于细节。你不一定需要理解所有这些细节，但当你表现得好像它们无关紧要、你不在乎，只是说”我不关心，告诉我什么时候能做完”或者”为什么需要这么久？天哪，这看起来就是件小事”——这就体现出对工程师工作的严重缺乏同理心，我觉得这真的会非常令人反感。不过我也完全同意，有时候你确实会遇到一些并不真正重要的细节，那种情况下只需要稍微耐心一些就好。

“传话筒”与创意压抑

Camille Fournier： 第三件事是当”传话筒”。任何管理角色都可能犯这个毛病，但我觉得产品经理尤其容易让人反感。比如有人问你问题，你答不上来，要么是你确实不知道，要么是涉及到的技术细节只有工程师才掌握，而你把自己置于一个中间人的位置——别人问你问题，你转过去问工程师，拿到他们的回答，尤其是你并不真正理解那些回答的时候——这种情况确实时有发生，对吧？然后你再回去回复最初提问的人，就变成了一个传话中间人的角色。

我觉得这非常令人反感，坦白说，对所有人来说都是浪费时间。各种类型的管理者都会做这件事，但产品经理绝对也这么做，而且特别让工程师抓狂，尤其是项目中的资深工程师。最后一件我想列入清单的是，有时候产品经理似乎想把所有想法都据为己有，对吧？他们想成为每一个产品创意、每一个细节的提出者。在这些情况下，我看到的是工程师开始过度工程化，因为工程师会觉得：好吧，那我需要掌控点什么。

我需要一些发挥创造力的出口，所以我就会用我的工程技能作为创造力的发挥途径，花大量时间去纠结该用哪个框架、这个那个的。这些东西对产品交付可能其实没那么重要，但当你把项目团队的人完全排除在创意环节之外，他们就会在别的地方找到创造力的出口，而这实际上对产品是有害的。

Lenny Rachitsky： 最后一点很有意思。你的意思是，如果你不让工程师在构建什么和优先级排序上有发言权，那就会促使工程师去想”重新构建这个东西吧”、“用个新框架吧”、“重写这个系统吧”。

Camille Fournier： 是的，我的意思是……即使你不这样做，这种情况有时候也会发生。

Lenny Rachitsky： 对。

Camille Fournier： 我确实认为……当我看到最严重的情况时——而且我基本上总能预判到会看到什么——就是大量那种工程师去建造东西、寻找创意出口、去建一些也许不该建的东西。我往往会在那些他们的创造力被极度压抑的地方看到这种现象——对于他们正在构建的实际业务或产品，他们的声音被严重忽视，以至于在那个领域完全没有任何发挥空间，所以他们就会利用自己确实有话语权的领域，也就是自己有一定控制权的地方，而这通常是技术选择和相关的细节。

优秀产品经理的做法

Lenny Rachitsky： 太有意思了。我其实想深入聊聊关于重写的话题，你对此有一个很有意思的观点，不过在此之前，我们先多花点时间讨论刚才这些。这些都很棒。围绕不把工程师纳入创意构思和决定实际构建内容这个主题，从非常实操的角度来看，你有没有见过产品经理做得特别好的做法？

Camille Fournier： 我觉得做得最好的产品经理，他们不会因为别人有想法而感到威胁。他们不会因为工程团队里全是聪明人而觉得受到了威胁，因为他们意识到，没错，有些工程师可能确实有好想法，但他们仍然不知道怎么做产品经理的工作。根据我的经验，有很多工程师其实觉得自己能当产品经理，但他们并不真正理解做好产品经理这份工作需要具备的所有要素。而当产品经理花时间去建立那些关系，确保人们既觉得自己可以分享想法，也开始理解这位产品人员的工作到底是什么。

以及他们真正带来的是什么——比如我们到底怎么衡量这些投入？我们怎么真正理解客户？我们怎么从业务或客户的角度真正想清楚什么能让这件事成功？我认为这确实能创造一个更好的互动模式，然后工程师就可以安心地分享想法，同时理解其中很多想法不会最终落地，但至少有人在认真倾听并愿意花心思关注它们。

Lenny Rachitsky： 回到你说的那些让工程师对产品经理反感的事情，这个当中间传话人的问题，听起来解决方案很明确——直接把工程师和另一个工程师对接，或者把你的工程师和那个正在试图搞清楚问题的产品经理直接连起来，对吧？

Camille Fournier： 这件事并不总是那么容易，因为再说一次，你面临这样一个矛盾：任何管理角色的大量工作就是参加会议、过滤信息，好让那些处于独立贡献者（IC）状态的人能够专注做事，而不是把一半的周末时间花在开会上。你需要非常谨慎地判断自己什么时候越过了那条线，以及是不是越过了太多次。如果你经常不得不说”我回头确认一下，我回头确认一下，我不知道，我回头确认一下”，也许跟你对话的那个人向你提出了错误层级的问题。

也许你需要直接把他们和工程师对接起来，但你要意识到这不应该是一种默认行为。偶尔会发生，但不应该频繁发生，因为如果频繁发生，那很可能是你在遗漏什么，很可能是你在这个传话游戏中丢失了信息，而随着时间推移这会导致问题。

Lenny Rachitsky： 说得好。所以基本上，如果你发现自己当中间传话人太多了，那可能就是时候直接把人对接起来了。我知道产品经理往往害怕这样做的原因是，工程师可能会同意一些他们认为对团队不好的事情，或者可能不理解对产品的所有影响，或者显然就是会把时间花在开会上而不是构建东西。

Camille Fournier： 是的，是的，有时候你是在一个群组会议中做这件事。我觉得 Slack 和其他聊天类工具实际上让这件事变得容易多了——可以在一个群组里让对的人看到，但再说一次，这也会分散注意力。所以这个问题没有一个简单的解决方案，我只是认为意识到这个问题很重要。

Lenny Rachitsky： 这是一个很好的观点。那么关于独占功劳这件事，你有没有见过产品经理在这方面有什么特别好的实操做法？就是每次发布产品的时候说”嘿，这些工程师参与了这个项目”之类的？

Camille Fournier： 不仅仅是感谢这些人，而是有时候要主动退后一步，让其他人来发言，尤其是当这是一个技术上非常有挑战性的项目时。我觉得这个问题没有特别简单的解决办法。我认为就是要真正意识到，当工程师觉得”这是我的工作成果，我得不到任何认可，而这个人把所有功劳都揽到自己身上”的时候，这确实会是一个非常痛的点。

Lenny Rachitsky： 我很喜欢这个观点。是的，我发现最优秀的产品经理往往是那些说得最少、鼓励其他人去做展示和发布的人。所以，我觉得这是一个很好的提醒——让你的工程师去做这些事。好的，太棒了。我们之前稍微聊到了”重写”这个话题——工程师有时候就是想重写整个系统，我觉得很多产品经理其实也一样。很多时候你正在构建的功能是建立在一些甚至已经不在公司的人五年、十年前写的东西之上，总会有一种感觉：“好吧，也许我们干脆重写这个东西，一切都会快得多。” 你有一个非常有意思的观点，我觉得很多产品经理会很想听到，就是重写往往是一个大陷阱，结果往往不是你想象的那样。你能谈谈你在这方面的经验和看法吗？

Camille Fournier： 好的，我个人亲自督导过不少重写——或者说不完全是重写，而是重新架构和重大系统演进。所以我绝对认为有时候这确实需要做，但我也见过太多这样的情况：工程师们说服自己，他们所遇到的那些系统问题的唯一解决方案——系统难以维护，难以修改，没人愿意在上面工作，因为用的是老旧过时的技术——就是到旁边去，构建一个新的东西来替换旧系统，这样就能把他们从痛苦中解放出来。我认为，如果你承认确实需要做一次升级，但制定了一个非常审慎的分阶段计划，并且真正想清楚——好的，我们不需要碰所有的东西，但推荐系统确实需要升级，而且它的 API 边界比较清晰，所以我们可以在不更换整个 Web 框架的情况下开始修复它——我认为系统的演进是有方法可循的，但人们真的会低估。他们低估了从旧系统迁移到新系统所需的时间，这是一个非常、非常大的问题。特别是当你讨论的系统有外部用户在使用时，无论是 Web 界面还是 API。你会想：“哦，我们大概知道怎么回事，所以不会是什么大问题。” 工程师们严重地、严重地、严重地低估了旧系统到新系统的迁移时间，这出了名了。而这会造成很多问题。顺便说一句，你在开发新系统的同时，仍然需要维护旧系统。所以我怀疑在座的很多产品经理听到”我们需要闭关六个月、一年、两年来构建这个新东西，在此期间我们基本上没法给系统加任何新功能”的时候，心情会好。那确实很令人恼火，坦率地说，这也是个问题，而且在很多情况下我认为这不应该是可以接受的答案。偶尔可能确实存在不得不这样做的情况，但我认为大多数时候，你不能真的承受得起说”我们要离开一段时间，很长时间不去碰这个系统，然后在这里构建一个新东西”。这种做法有太多说不通的地方。这也就是你提到的那篇博客文章里的一部分内容。如果你有一个系统，它并不真正需要功能增强或开发，因为它基本上还行，用户也在正常使用，它只是让工程师觉得烦，那你到底为什么要投入那么多钱去写一个新版本呢？有时候会出现一种认知失调——如果你确实需要做新功能，而旧系统确实……确实没办法做你需要的新东西，你需要找到一条通往可持续系统的路径，让你能够继续添加和演进。你应该投入，所以确实需要投资，但你必须问自己：如果我可以撒手不管这个东西，长时间不对它做任何操作，而且不会对我的业务造成真正损害，那改动它到底值不值得？这有没有意义？这里是有一些疑问的。我还认为，当人们尝试做重写时——特别是如果你想做的只是比如迁移到一种新语言，或者以某种方式进行现代化改造——很多时候人们严重低估了旧系统到底做了什么，以及他们对旧系统的了解程度。遗留系统里埋藏了大量的业务逻辑，而且往往是未被文档化的，往往是诡异的。你没有想清楚所有的业务规则，没有想清楚数据格式。我认为同样地，把旧系统中所有重要的东西复制到新系统中，比人们预期的要困难得多。还有更多的原因，但我确实认为有时候你需要演进系统。我的建议是，当你为制定演进计划而苦苦挣扎时，可以把旧系统的部分模块拿出来，对它们进行升级，使它们更具可扩展性，更容易操作，清理技术债务。但如果你想说的是”我们直接走开，我们要重写，我们要构建一个全新的东西，它会解决我们所有的问题”——这种做法很少能成功。

Lenny Rachitsky： 我觉得很多产品经理会说：“是的，非常感谢你说这些。“因为我觉得这也是工程团队和产品经理团队之间一直很大的一个矛盾点。那么总结一下，我觉得很多人在考虑”让我们重写这个东西”时容易忽略的——也就是你所说的很多人容易忽略的——就是迁移到新系统、迁移客户、用户、数据到新系统上所花的时间会比预期长得多。你低估了对旧系统实际功能的了解程度，你会遗漏功能，还会引入新的 bug。这其实和重新设计整个产品流程非常相似。总有一种感觉说”让我们从零开始重新思考这个新手引导流程”或者”让我们重建产品的这个部分”，但每次最终实验结果都是负面的。结果总是变得更差，然后你得花大量时间慢慢恢复到之前的水平，而且你还会忘记那些已有的功能——“哦，糟糕，我忘了那个功能，我忘了那个功能。“所以很有意思，产品端也存在非常类似的情况。好的，太棒了。我要换一个稍微不同的话题，是关于工程领导力的。

工程领导力的技术与管理平衡

我知道你在工程领导力方面写了很多东西，也花了很多时间和工程领导者交流，所以我有几个问题。其中一个是我知道最困扰工程领导者的事情之一，就是如何在保持技术能力和技术专长与领导力专长之间找到平衡，基本上就是找到正确的”高度”——在组织中应该处于什么位置，应该深入到什么程度的细节，同时还要保持足够的技术能力以保持相关性。在你自己的经验中，关于找到这种平衡你学到了什么？你会如何建议那些为此挣扎的工程领导者？

Camille Fournier： 我给大家的一个建议是，在真正觉得技术已经深入骨髓之前，不要停止亲自动手做技术。就是那种你觉得自己已经达到了一种精通的程度——就像如果你流利地掌握了一门第二语言，或者非常认真地练习过一种乐器很长时间，或者非常认真地练过一项运动很长时间，你会有这种体会：虽然我很久没做了，但如果重新拾起来，会有些生疏，但很快就能恢复到状态，对吧？也许体力上不如从前，但你会找到感觉的。写代码也是一样的。

如果你坚持足够长的时间，你同样可以在技术技能上建立一种基础性的精通——你不会像一直在做的人那么快，而且做技术的一大挑战其实是各种工具及其不断演进，但你不会完全摸不着头脑。而且我认为，你在达到那种对某个技术领域的深度精通过程中所学到的一切都会伴随你，帮助你维持对自己技术能力的信心，并保持对”做一个好工程师意味着什么”的共情。

而且我觉得，这也会让你在放手不亲自写代码时少很多焦虑。不过我认为，每个经历这种转变的人，尤其如果你真的不得不完全放手，或者根本没有时间写代码，那么在一两年的时间里，不管怎样你都会感到焦虑。从这个阶段开始，你需要思考的是，“懂技术”其实也包括了解正在发生的事情，保持关注，并能提出好问题——根据我的经验，工程师们关心的是，技术领导者看起来是不是真的理解你在做什么，能不能提出好问题，能不能引导你做出更好的决策，而不是那种”哦不，你应该用这个库而不是那个库”的人。

实际上，如果一个很久不亲自动手的非常资深的人试图告诉你”别用这个库，用那个库”，这还挺烦人的。因为不知道你怎么想，反正如果一个人已经很久不亲自动手了，却试图在我目前擅长的领域指挥我做什么，我是不太信的。但我确实很感激这样的指导——“你考虑过这个吗？""跟我说说你打算怎么处理那个情况？""实现这个的主要技术挑战是什么？“——并且能够真正花时间倾听，然后在此基础上提出有见地的问题。

最后我想说的是，尽可能多地让自己身边围绕着聪明的技术人员，并且愿意倾听他们，和他们聊技术，向他们提问。我觉得这也是我能在下属面前保持技术敏锐度和可信度的部分原因——不是因为我在写代码，我确实没在写。但我确实在听很多非常聪明的人谈论技术，细到”我在调试这个数据库问题，到底是怎么回事”这种程度。而且我始终保持对这些故事的好奇心，从中学到东西，了解那些非常聪明的工程师在想什么、担心什么。

你能越多地建立起这样的、仍在亲自动手的人脉网络并与之保持联系，我觉得帮助就越大。

Lenny Rachitsky： 顺着最后这一点，你实际上是怎么做的呢？是去参加技术会议、和朋友交流，还是别的方式？

Camille Fournier： 对，是的。对我来说，一开始是去参加各种会议，认识人。现在我在很多不同的聊天群里，大家会经常交流，和以前的同事保持联系。我得承认我是个比较社交化的人，人脉比较广，所以这可能说起来容易做起来难。但我确实觉得，加入对的群聊很有帮助。另外，我也觉得——阅读各种技术新闻、技术评论和讨论版，当然这确实是良莠不齐的——但里面确实有聪明人。你找到那些聪明人，关注他们在说什么，这也是保持这种视角的一个好方法。

Lenny Rachitsky： 我在想，如果你对这些都不感兴趣了，是不是一个信号，说明也许你应该去做点别的事情了。就是如果你不再关注技术层面的东西的话。

Camille Fournier： 这很难说，因为我本身就是一个极客。我是真的很喜欢技术。我之所以在这个行业，就是因为我确实对技术的某些领域——不是每个领域，而是某些领域——有着发自内心的兴趣。我想了解数据库和基础设施领域最新在发生什么，我觉得这些都非常有意思。我觉得这些技术问题本身很有趣。所以我觉得这让我很成功，因为我天然就有那种好奇心和热情。但我不确定这是不是一个完全必要的前提条件。

Lenny Rachitsky： 是的，不过你说的这些让我想起推特上的一个叫 LevelsIO 的人。你听说过这个人吗？他最近刚上了 Lex Fridman 的播客。你听过那期吗？

Camille Fournier： 我好像看过一个片段，但没完整听过。

Lenny Rachitsky： 他可以说是最成功的独立工程师之一，完全自己做自己的东西，从不融资，就做自己能赚钱的产品。有趣的是，他的所有技术栈都是 PHP 和 jQuery。他就说，这些就够了。我一直说要学 Node.js、学 Python，但我在忙着做东西的时候没空学这些新东西，而他已经取得了极大的成功。这也印证了有时候也许你不需要一直把所有东西都重写成最新的框架。

Camille Fournier： 是的，我的意思是，实际上我认识很多聪明的工程师都属于这种情况。他们会说，我们用 PHP 和相对简单的 SQL 就构建了了不起的东西，而技术领域有太多的过度工程化了，我并不完全不同意这种看法。但挑战当然在于，适合一个人的方式，不一定适合有规模的团队——不管是好是坏，情况就是不同的。你得衡量让一个人高效的东西，是否也能让一百人、一千人、甚至十个人高效？这总是很难判断的。这也是为什么我确实认为你应该跟上你所在的技术领域正在发生的变化和趋势，但不要执着于追逐每一个潮流。

我认为要了解，但不一定要追逐。特别是，如果你在团队、大型公司甚至中型公司工作，你需要在”让一个人跑得快的技术”和”让十个人或一百个人跑得快的技术”之间取得平衡，而这并不总是同一件事。

值得关注的技术平台与框架

Lenny Rachitsky： 顺着这个话题再深入一下，也算是对你做一个”技术诱导”——现在有没有什么平台、语言或框架让你特别兴奋，觉得确实在帮助人们更快地做出更好的工作？或者反过来，大家都很兴奋但你觉得并不好的东西？

Camille Fournier： 我想说一个我其实写在自己笔记里准备聊的例子——GraphQL。我现在不会告诉一个团队该用还是不该用 GraphQL，因为这已经超出了我的专业领域和我的管理层面，而且这本来也不是我的工作。但它确实是一个既流行又被我认识的大部分资深人士评价不太高的东西。所以我想说的是，如果你在认真考虑用它，而你又不是 Facebook，那你真的要弄清楚自己到底想解决什么问题。因为从我听到的各种讨论来看，GraphQL 给前端工程师的承诺似乎是——你不用真的跟后端工程师协作，自己随便搭就行了，一切都会好好的。但实际上，任何真正在实践层面用过它的人，似乎都没得到过特别好的结果。当然，它显然是可以运作得很好的，因为 Facebook 就用得很好，我确信也有其他公司在用。但这个东西不算新了，却仍然是那种看起来很有趣的风潮，可能正在让很多人踩坑。

Lenny Rachitsky： 太好了，感谢你分享这个。我不知道这算不算一个完全对应的例子，但顺着这个话题，之前那个 podcast levels 的嘉宾，我忘了他全名，好像叫 Peter，他分享过一个观点：当一个框架背后有一家 VC 资助的创业公司时，这不是一个好信号，因为他们的工作变成了说服工程师去使用它然后付费，而这未必意味着它是最好的产品。

Camille Fournier： 这话说得对。不过我也要说，一些最浪费时间的框架也恰恰是从大公司里出来的。那个大公司的环境可能让那个框架在内部极其有用，但放到创业公司、小公司，甚至是没有其余配套环境的大公司里，就不一样了。但我也不觉得他说错了，大公司在这件事上同样难辞其咎。

Lenny Rachitsky： 看来我们都应该回归 PHP 和 jQuery，简单就好。

Camille Fournier： 也许吧。

转向管理之前先达到技术精通

Lenny Rachitsky： 好，那我们来收尾关于工程领导者找到正确平衡这个话题。总结一下你的建议——首先是在转向工程管理之前先达到精通，对吗？

Camille Fournier： 是工程管理。我想特别补充一点，如果你恰好是女性或者在科技行业中属于代表性不足的群体，这一点尤其重要，因为很遗憾，人们往往会一开始就低估你的技术能力。我认为在做出这种让所有人都害怕的跳跃之前，先建立对自己能力的内在信心也非常重要。如果你在跳之前已经具备了那种精通，那就更好。我希望更多人能这样做，因为说实话，我认为有很多人从未真正达到过精通就转了管理，之后也就丧失了技术能力。他们中有些人仍然是很好的管理者，当然，也有一些好的管理者从一开始就不是技术出身。我不想说这不可能。我只是认为，如果你在意自己的技术能力，如果你现在是技术型的人并且想保持这种技术素养，不要在有人第一次提出让你做管理时就接受。确保你真的花了足够多的时间在写代码上。

Lenny Rachitsky： 你有没有一个年数上的经验法则，或者某种方式来判断自己可能已经到了那个阶段？

Camille Fournier： 这个”一万小时”精通的说法后来好像已经被推翻了，但当初确实有这个说法。对我来说，是本科、研究生加上四五年的全职工作。也许我算慢的，我没有像现在的人那样从初中就开始写很多代码。但我经历了几年非常高强度的本科和研究生阶段的手把手实践。所以我认为可能差不多在十年左右——这些年里你花大量时间写代码，真正理解如何成为一个技术专家。

Lenny Rachitsky： 明白了。所以基本上，如果你是一个工程师、正在考虑转向管理，你可能想等到写了大约十年代码再做这个决定。我觉得这比很多人想象的要长得多。而且我猜很多人并没有这样做，而没有这样做的话，后果可能是——

Camille Fournier： 如果你在高中就写了很多代码，又拿到了本科学位，那大概算六年——

Lenny Rachitsky： 我明白了。

Camille Fournier： 那你可能只需要四五年的工作经验，每周四十小时写代码。当然具体取决于公司。但我确实认为，当你看到一个 23 岁的人刚毕业不久——如果你是创始人那是完全不同的生活轨迹——但如果你在一家大公司，有人说”你沟通能力很好，要不要开始做管理？“，这往往实际上是在把你推向产品经理的方向，而在我看来，这恰恰是通往真正领导力最糟糕的路径。如果你觉得还没写够——同样，如果你就是觉得还没写够，如果你还在享受写代码的乐趣，不要急着去做管理。写代码是一件很棒的事，好好享受吧。

Lenny Rachitsky： 我完全理解你的意思。我以前也是工程师，实际上我做了十年工程师。不过我现在肯定算不上精通了。我从工程师转向了产品，我真的非常想念坐在那里写代码、构建东西的感觉，放弃那件事非常难。我想你应该也会想念吧。

Camille Fournier： 我想我可能到这时候已经忘了那种感觉了，但确实没有什么比得上那种满足感，因为你有那个快速的反馈循环，真的很美好。

从 IC 转管理的最大 surprises

Lenny Rachitsky： 说到转向管理这个话题，你写了一本可能是关于工程经理职业路径的最权威的书。那么当一个人从独立贡献者（IC）转向管理时，你觉得最让他们意外的是什么？他们最常不理解或感到惊讶的事情是什么？比如”天哪，我没料到这是我工作或生活的一部分。”

Camille Fournier： 我觉得有几件事。前提是他们确实想做好管理——确实有很多人转去做管理之后，根本不理解这份工作是什么，甚至缺乏足够的自知之明去意识到自己不理解——但对于那些真正想做、想做好的人来说，我觉得让他们比较意外的几点：第一，作为管理者，你真的不拥有自己的时间。你的团队、你的上级、公司拥有你的时间。而且你作为管理者越资深，这种情况越严重。我觉得独立贡献者（IC）常常以为，如果自己转去做管理，还能保留作为资深 IC 时的那种自由度。

但他们同时还觉得自己可以指挥别人做事、拥有各种权力。而现实是，管理更多是一种……我不太喜欢”仆从式领导”这个说法，但管理确实本质上是一份服务工作。你在为团队服务，为公司服务。你的职责是让事情变得更好，而这通常并不意味着你来做所有决定，也不意味着你一打响指别人就跳起来执行。因为如果你真这么干，尤其是在科技行业，大家会反抗的，不会听你的。这种文化在我们这个行业里行不通。

我也不认为那是一种好的文化。我不认为命令与控制——我告诉你做什么、你就做什么——能催生创造力。这跟产品经理试图包揽所有创意是一个道理。你手下有那么多聪明人，你作为管理者的职责不是在每种情况下都告诉他们该怎么做。偶尔确实需要，但更多时候，你是在试图说服他们接受你认为对的方向。某种意义上，你是在引导、鼓励、设定方向，为流程或行为设定护栏，但这绝不是那种”英明神武的领袖”的角色。

不是那种”我来做所有决定，所有人都仰望我，这份工作真爽”的感觉。它要艰辛得多，你基本上是在不断应对当下冒出来的各种事情。这确实是一份很难的工作。我认为，特别是当你认真想把管理做好——既有思考、有温度，同时又保持高效——这确实是一份非常难的工作。

Lenny Rachitsky： 我在想，工程领域是不是转管理后又回流到 IC 比例最高的地方。我见过不少这种情况，不知道工程师是不是最常见的。

Camille Fournier： 我不确定，但——

Lenny Rachitsky： 因为经历了你刚才说的那些之后，他们会想，“天哪，我干了什么——”

Camille Fournier： 你觉得产品经理不会这样吗？因为我觉得产品经理其实也会深受同样的问题困扰——

Lenny Rachitsky： 他们也会。

Camille Fournier： 也许有时候——

Lenny Rachitsky： 他们确实会。

Camille Fournier： 对。

Lenny Rachitsky： 不过有意思的是，我早年做过工程经理，我真的不太喜欢，在那个角色里很不开心。但做产品经理的管理者我就很开心，轻松得多。

Camille Fournier： 对，因为产品经理好管多了。产品经理太好了，太好管了。产品经理想……他们就是很愿意帮忙，沟通能力强。我很喜欢管产品经理。我得说，以我的经验来说，工程师真是太难管了。个个都是 prima donna（难伺候的人）。我自己就是工程师，但产品经理管起来确实更有趣。所以你说得有道理，你说得有道理。

Lenny Rachitsky： 不过我在想，因为我确实没见过太多产品经理管理者回流去做 IC 产品经理的。我觉得一旦你可以通过团队来打造产品，不用整天坐在 Excel 里、跟进各种截止日期，就很难放弃那种状态。你会享受在那个链条中更高的位置。

关于一对一沟通的反直觉观点

Lenny Rachitsky： 顺着这条线聊下去，你在一对一沟通（one-on-one）方面有一个很有意思的、比较反直觉的观点。大多数人的建议是：跟所有人都做一对一，定期做，这很重要。而你却认为也许应该少做一些一对一，尤其是作为工程经理，你能聊聊这个吗？

Camille Fournier： 好，先说清楚，你应该跟你的直属下属和你的上级做一对一，而且应该把这些当作不可侵犯的约定——我一般每周一次，或者隔周一次。所以我说的不是这套一对一。不是指你直接管理的人和你自己上级之间的那些一对一。但我观察到一种现象——不知道是远程办公兴起导致的，还是大公司的缘故，还是什么原因——我听到很多朋友在不同公司抱怨：每个人都在跟其他所有人做一对一。管理者跟自己的团队做一对一，同时还跟所有同级做一对一，跟所有利益相关方做一对一，跟产品和设计做一对一。我觉得这种方式根本不可扩展。它会随着你的人际关系数量线性增长。所以当公司规模扩大、你团队支撑的业务范围增长、团队本身也在增长时，你没法这样扩展。你不能指望在超过一定规模的团队或公司之后，还用一对一的方式来建立组织关系和维护信息感知。

另外我还觉得，人们把一对一当成了万能药。但现实是，你去跟那些其实并不想跟你做一对一的人做一对一——如果他们无心投资你们之间的关系，如果他们并不关心你在做什么，你约他们做一对一，他们可能还挺反感的。他们就是来走个过场，觉得”好吧，我应该做一个好的企业公民”，但心里想的是，“我们为什么要做这个？有什么意义？”

我还认为，一对一在用于利益相关方管理时尤其值得警惕。当你约见的不是你的团队成员，而是其他利益相关方时，如果你有非常多的利益相关方——我做过很多有大量内部利益相关方的岗位，因为建设内部平台是我过去很多年工作的重要组成部分。把跟这些利益相关方的沟通全都做成一对一，实际上可能是一种弱点。因为当你的利益相关方只是在一对一里告诉你他们对事情的满意或不满意时，你不满意的利益相关方听不到其他人的声音。比如你可能有一个非常不满意的利益相关方，五个非常满意的，而你对那个不满意的只能说”其他人都很满意”，但对方并没有亲眼看到。他们只能听你说”相信我，我跟其他所有人都做了一对一，他们都说没问题”。而这听起来就像在耍赖。

尊重自己的时间

Camille Fournier： 所以，当你面对大量利益相关方，试图仅靠一对一来管理他们，实际上在很多方面并不高效。总的来说，我觉得人们应该更尊重自己的时间。虽然我刚才说了管理者处在所有人的”支配”之下，这是事实，但你也要尊重自己的时间。不要仅仅因为你是管理者、这就是你的工作，就把自己的日程塞满会议。你真的有事情要跟那个人谈吗？你真的需要……当你约一个人做一对一的时候，你是在占用他们的时间。你不应该随意地、漫无目的地就约一个人一对一。

这多少跟我的性格有关。我不是那种擅长在公司里社交的人。有些人特别擅长——一起喝杯咖啡，一起吃个午饭，随便聊聊，建立关系。说实话，这些人在很多方面比我成功，我确实有点羡慕这种能力。但如果我们一起共事过，那我就会表现得很好。如果我们一起做过某个项目，一般来说大家都会很尊重我，因为我非常投入，在各方面都是一个很好的合作者。但让我跟一个人在毫无目的的情况下做一对一、纯粹为了”认识你”，我就真的很不擅长。

这并不是说这种一对一总是不好的。但我确实认为，很多人……如果这种”认识你”式的、随意的、以建立关系为目的的一对一是你的舒适区，那你大概应该多做一点。而你大概应该少做一点，因为你应该始终推动自己走出舒适区，而且你真的从中得到了什么吗，还是只是在打勾——我今天开了八个会，所以我很有生产力。

用更少的时间做更重要的事

Lenny Rachitsky： 这个说法非常能引起共鸣。顺着你的工作方式这个话题——我听说你很有名的一点是，打造了一种大家工作很努力、但工作生活平衡也很好团队文化。我们之前聊的时候，你其实告诉我你并不太相信过度工作。能不能谈谈你这个理念——怎么建立一个人们不过度工作、但仍然能出成果、也不会倦怠的好文化？

Camille Fournier： 我想我们都明白，如果我们能搞清楚并真正专注于最重要的事情，一切都会变得更好。搞清楚什么最重要确实很难，但过度工作某种程度上让你回避了这个最根本的难题——去搞清楚什么才是重要的。我听过你的一期播客，你跟某人聊到：如果你从来没有开除过一个人之后又后悔，你就不知道该留谁、不该留谁的边界在哪里。我承认对这个说法我心情复杂，虽然我理解你想表达的意思。如果你不经常重新校准你对”什么该放过、什么不该放过”的预期，你怎么知道到底什么才是真正重要的？

我想说的是，这件事不像开除人那样——你做一两次、后悔了、很快就学会了，很不幸。我认为你实际上需要经常性地测试和挑战自己：我是不是真的在最大化自己的产出？我是不是真的在创造最大的价值，还是只是在安抚自己内心的愧疚感——“我需要每周工作六十个小时、我需要睡在办公室、我需要怎样怎样，来证明我是一个努力工作的人、我在乎”。所以我确实认为，人们应该挑战自己保持专注，把重要的事情做完，并且始终问自己：什么是重要的？

什么重要这件事本身是会随时间变化的。但如果你不定期审计自己的时间，把那些不重要的事情从清单上划掉，你很可能在大量不重要的事情上浪费时间。好吧，你不想减少工作时间，你就是喜欢大量工作，那没问题，但如果你能定期做这些审计，你大概能完成更多有价值的事情。我还觉得人们授权不够。如果你不授权，你就会被淹没，因为你的团队什么都做不了，因为你没有花时间去教他们。授权最初通常需要更多时间，你得教别人做你想让他们做的事。

不总是这样，有时候他们会给你惊喜，做得比你还好，但也可能不会。所以你得教他们，但最终……你把自己解放出来了，可以扩展自己的影响力。所以我确实是一个坚定 believer：以专注的方式、用更少的时间努力工作，我认为是更有生产力的工作方式。我的职业生涯就是这样过来的，也取得了成功，我也一直鼓励为我工作的人这样做，我也看到了很多通过这种方式取得的成功。但这不是一件可以不加思考的事，它是一个持续反思、不断追求专注的主动过程。

Lenny Rachitsky： 如果有人在听这个，心想”我想开始这样做”，你有没有什么具体的实践或策略，可以帮助做好这件事？

Camille Fournier： 我觉得可以有不同的方法。一种方法是，比如每个周五我到下午四点就停止工作，或者不让自己周末工作。强迫自己下线，强迫自己建立边界，然后回顾一下自己完成了什么——我觉得这会有帮助。这很可怕，人们不喜欢这样做，但我确实认为这是最好的方法之一——就是告诉自己，我要下线了。这周每天下午六点我就下线。因为你的大脑可能还会继续想。

你可能还是会有些紧张，还在想工作的事，还在担心，但”想”和”做”之间是有区别的。尤其是对那些职业生涯早期的朋友，我认为这其实是我能够达到精通的原因之一——因为我在工作的时候非常擅长保持专注。当我还在亲手写代码的时候，一天中的很多个小时我都在真正地写代码。那时候我还不是……那是在社交媒体大爆发之前，我受到的干扰少得多。我不知道在当今时代我还能不能这么容易做到。但那种高度集中的深度工作时间，是因为我心里想的是，“我不想周末加班，我不想每天待到晚上九点，我就想把事情做完。“这意味着我没有做那么多的闲聊。

我没有每天跟人出去吃饭聊天，但我非常高产，而且我学会了在短时间内完成大量工作。我确实认为，在职业生涯早期学会这些技能，然后在整个职业生涯中持续运用，这是另一条建议。

保持专注的仪式

Lenny Rachitsky： 在保持专注方面，有没有什么帮助你进入状态的？是耳机、一杯饮料？什么能让你进入状态？

Camille Fournier： 当然，我有很多仪式。我有我的咖啡因仪式。

Lenny Rachitsky： 展开讲讲。

Camille Fournier： 嗯，我的意思是，我已经不能喝咖啡了，因为某个阶段我的胃出了问题，但我早上会喝茶。我也喝含咖啡因的水。午餐时会喝一罐健怡可乐，所以我有这样一套咖啡因摄入的仪式来帮助自己。我必须待在一个安静的地方。我发现某些非歌曲类的音乐……比如我非常喜欢 Four Tet，非常适合用来集中注意力；还有 Andre 3000 新出的那张长笛专辑，也非常适合专注时听——它不太有可预测性，没有歌词，而且旋律不那么容易预测。对我来说，这对集中注意力非常有帮助。我不能在听任何有歌词的内容时集中精力，我的大脑就是无法忽略文字。所以这些是我用来帮助自己进入状态的一些方法。

Lenny Rachitsky： 太棒了，我有类似的咖啡因策略。录这些播客的时候我总是在喝茶，还有我这里的这个小东西。然后我太太不想让我喝健怡可乐，因为她觉得里面的糖分什么的对身体不好，但我有时还是会喝，效果很好。我后来换成了绿茶，这是我的做法。先喝红茶，然后切换到绿茶。

Camille Fournier： 很聪明。

关于授权的补充

Lenny Rachitsky： 天哪，你分享的东西太多了，我都想深入聊聊。我来分享几点。你提到的关于授权的观点我觉得非常重要，学会授权还有一个好处，就是团队成员会感到被赋能。你给了他们承担责任的机会，他们会觉得”我有了展示自己能做其他事情的机会”。

Camille Fournier： 是的，而且如果你不授权，你永远无法扩展自己的影响力。

Lenny Rachitsky： 没错，而且学会授权一开始很难，但一旦你做得好了，就会变得非常棒。我就喜欢什么都授权出去，而且大家也很乐意。他们会说：“太好了，你在给我机会。“你说的关于……如果你有时候不为你砍掉的东西感到后悔，或者你开掉了某个人却并不后悔，那说明你还做得不够。实际上 Elon Musk，Elon Musk 对此有一个很好的方法论。我不知道你有没有听过他关于优化的理念。他有一套五步流程来弄清楚如何优化某件事，其中一步就是尝试砍掉东西——我们到底需不需要这个东西？如果你不觉得你砍掉的东西中有 10% 是错误的，那说明你砍得还不够多。

Camille Fournier： 你得找到自己的衡量标准。但我确实认为，试探极限是很重要的，不过这很可怕。说实话，这样做总是令人害怕。它会唤起那种”我忘了完成作业”的学校噩梦，尤其是对于那些经常进入这类公司和岗位的优等生来说。还是那句话，你得做一些让你害怕的事情，否则你永远不会成长。

平台工程与平台团队

Lenny Rachitsky： 好，我换个完全不同的话题。你有一本关于平台工程和平台团队的新书即将出版。这是我收到很多问题的话题。很多人在考虑转到平台团队，或者在平台团队工作遇到困难，又或者与平台团队协作时遇到困难。所以我在这方面有一系列问题。第一个是，我问了一些和你共事过的人该问你什么，有一位和你共事过的人分享了这样一段话，表达了他对与平台团队合作的不满，他经常向你抱怨这件事，他是做面向客户产品的。他说，平台团队通常很慢。

他们经常推动我们牺牲功能来采用他们的系统。他们往往能获得无限的资源，尽管他们不需要展示任何投资回报率。那么，从与平台团队合作的角度出发，假设你在做面向客户的产品，有没有什么有效与平台团队合作的技巧，以及如何建立良好的关系？

Camille Fournier： 我非常理解任何有这种感受的人，因为部分原因正是我写这本书的动机——我和一位朋友 Ian Nolan 合著了这本书——因为太多平台团队都犯了他在抱怨的那些问题：他们不倾听，交付效率低下，也没有向公司解释清楚自己的价值。当你面对这种情况时，确实令人沮丧。说实话，我非常理解。不过我想说的是，首先，你越是花时间去理解平台团队面临的问题，尝试与他们协作，清楚表达你真正需要什么，以及你愿意怎样与他们合作，效果就越好。

我认为如果你生气了，然后只是试图避开他们或者暗中破坏他们，那也许从长远来看能行，但短期内只会让一切变得更糟。所以我确实认为，如果你对一个平台团队感到不满，一些技巧是——去找出那个团队中做得好的部分，因为我相信一定有做得好的地方，对吧？也许数据库团队就很出色。确保你与那部分团队保持良好的关系，并且能够指出你在那部分团队上合作得非常好。给他们产品反馈。

这挺烦人的，但有时候必须这么做，因为很多公司……实际上我认为做产品需要具备产品思维，坦率地说，你需要有产品经理来打造好的平台——内部平台。很多公司就是不这么做。他们认为在内部团队上浪费 headcount 去配备产品经理是不值得的。所以最终你得到的是这样一个平台团队——有很多聪明的工程师，但他们并不真正知道该构建什么。他们只是在构建自己认为对的东西。所以有时候你的工作就是充当他们的产品经理，告诉他们：这些是我们遇到的问题，这是我们需要的东西。

你在这方面表达得越清晰，特别是当他们没有产品团队的时候，通常你就能以这种方式从侧面引导他们。所以我认为这是当你在那种情况下可以采取的另一种方法。找到团队中运作良好、与你们团队配合默契的部分，确保发展好那些关系，努力放下愤怒和沮丧，清楚地表达你的需求，帮助他们理解他们真正应该做什么和构建什么。

Lenny Rachitsky： 这是非常有趣的建议。特别是，你是说如果他们没有产品经理来帮助引导方向，你可以帮助他们……基本上就是帮助他们思考对他们有利的事情，同时也有助于推进你想完成的工作。

Camille Fournier： 对。

Lenny Rachitsky： 非常棒的建议。好，那么从领导层的角度来看，要想打造一个高效的平台团队，你有没有关于如何搭建这些团队、如何激励这些团队以帮助他们取得成功的建议？

Camille Fournier： 首先，我非常坚信平台工程必须包含软件工程。如果你的平台团队中没有任何软件工程师，只有偏运维的系统工程师、DevOps、SRE——我承认有些 SRE 确实是软件工程师，但他们通常不太愿意写大型软件——那我认为你就偏离了重点。平台工程不仅仅是维护云基础设施、写一些小脚本或蓝图，或为其他团队做一些赋能项目，因为这些并不能真正创建一个有凝聚力的、连贯的平台。它无法创造出产品，坦率地说，你需要意识到——平台归根结底就是产品。

Camille Fournier： 你应该思考的是，如何创建有凝聚力的服务产品，让这家公司更具生产力？所以你需要软件工程师。是的，你也需要运维系统、SRE 专家。当然，你还需要产品人员。我的平台团队都配了产品经理——我为所有平台团队都配备了产品经理。在我服务过的公司中，我真正建立起了这套实践，因为我就是认为，如果你把这一切完全交给工程师和工程管理层，你不会得到很好的结果。他们已经尽力了，你偶尔确实能在这个领域找到产品直觉非常出色的工程师，但实际的细节……

产品工作的重点和方向，你不可能一边写一堆代码和/或管理一个庞大的软件工程团队，一边同时做产品经理。我认为这实际上对人的要求太高了，至少很难长期做到出色。所以在团队结构方面，我认为要认识到，这不只是 SRE V2。它远不止于此。你需要软件工程师，你需要系统工程师，你需要产品人员。而你需要产品人员的原因之一是，你要以影响力为导向、以结果为导向来思考，而不是仅仅说，“嗯，我们做了这个东西看起来挺酷的，我们采用了那家公司的技术，因为网上所有人都在谈论这个。”

不管是 VC 投资的公司还是大公司。我们要真正思考的是，我公司的工程师面临的问题是什么？我们如何通过正在构建的任何东西来提升他们的生产力或为业务创造杠杆效应，对吧？我们是否在缩短工程任务的周期时间？我们是否在解决阻碍产品发布和扩展的问题？我们是否在产品或平台中实现了真正有意义的成本削减或效率提升？这些是一些可衡量贡献的例子，但我认为一个挑战是，人们创建了这些平台团队，却认为它们可以脱离影响力导向，理由是，“嗯，你只要把基础设施跑起来、确保它正常工作就行了。”

但实际上不行——如果你做 OKR 之类的东西或目标设定之类的，你仍然必须做……你必须借鉴产品的很多最佳实践。在内部产品领域情况略有不同，但如果你要做平台，这仍然非常重要。

平台团队中的产品经理

Lenny Rachitsky： 顺着平台团队里设产品经理这个话题，我合作过的一些最优秀的产品经理就是在平台团队中的。这让我觉得——不是说把产品经理放在那里就完事了——而是那里可能是杠杆效应最高的地方，因为平台团队让公司其他人都能跑得更快。

Camille Fournier： 对。

Lenny Rachitsky： 这方面有一个不同之处，不知道你是否同意，就是产品经理与工程师的比例可以更高一些。平台团队中每个产品经理可以对应更多的工程师。

Camille Fournier： 对，对，我觉得这说得对，因为我认为平台团队中大量的工作并不完全是产品工作。很多工作更像是扩展性问题，或者非常深入的技术挑战——比如我必须弄清楚如何实现某个技术目标，或者我必须做性能优化——这些并不总是需要产品规格文档，对吧？这通常是工程密集型的任务。所以是的，我觉得比例确实会有所不同。

什么是平台团队

Lenny Rachitsky： 我们已经深入讨论了这个话题。也许可以帮助大家理解一下，什么是平台团队，哪些团队可以算作平台团队，举些例子。

Camille Fournier： 我对平台工程的高层次定义是——如果你正在开发和运营平台，目的是管理整体系统复杂性并为业务创造杠杆效应。现在很多人谈论平台团队时，他们主要在谈论一些以前可能叫做 dev tools 的团队。比如公司的 CI/CD 工具链，大量的云基础设施配置和工具。如果你所在的公司面临特定的技术问题，你可能正在构建半定制化的存储系统，这也可以是平台团队的一部分。实际上我觉得还有——另外，Web 框架——Web/移动端框架及其支持。

这类工程也可以成为平台服务的一部分。我实际上还认为存在一些你可能会称之为集成平台的团队，或者说介于基础设施/开发者工具和产品之间的平台。比如计费平台——如果你公司所有不同产品共享一个统一的计费平台，这和那些更偏 dev tools、基础设施类平台团队面临的挑战有很多重叠，因为你要支持多个不同的产品线使用同一个系统，这个系统需要以一定的效率扩展。你仍然需要做产品发现。

你可能比纯内部工具团队有更多面向业务的产品关注点，但这就进入了融合区域。

何时开始创建平台团队

Lenny Rachitsky： 对于早期阶段的创始人或较小规模的公司，听到这些可能会想，“糟糕，我需要平台团队吗？“所以你在摇头——如果你没在看 YouTube 视频的话。有哪些信号表明是时候开始创建平台团队、为此分配资源了？

Camille Fournier： 首先，我认为大概是——当你有 50 名以上工程师的时候。我觉得这不是你在只有 10 名工程师时就应该开始做的事情，对吧？当你——所以现在你的工程团队之间可能有大量的临时协调，可能你有——你有一个 GitHub，有个人确保这些东西都能正常运行。你有几个云数据库，各个团队各有几个人，他们互相交流信息来搞清楚状况，诸如此类。好吧，这都没问题，但到了某个节点，你要么会碰到严重的效率问题，你会看到同样的人出现在一堆不同的团队里。

每个团队都有同样类型的人在解决同样类型的问题。你就会觉得，为什么每个团队有三个人在处理这件事，而不是集中起来让它更高效一些。也有可能是你碰到了某个核心扩展性问题，确实需要一个专门的团队来解决。同样，这可能体现在开发者生产力上——每个开发团队都在各做各的，所有人都超级慢，因为代码就是发布不出去，一切都要跨团队协调，简直一团糟——这是怎么回事？我们需要解决这个问题。或者你确实有一个技术难度很高的领域，需要一个专注的团队来解决扩展性问题。

这些都是你可能需要开始考虑平台团队的信号，但说到底——一般来说，我不会太早投入。这是给那些已经成熟的公司准备的，值得投资让内部人员更高效，至少从成本和效率的角度集中某些职能。

Lenny Rachitsky： 假设你在平台团队上，你是一名工程师或者甚至是产品经理，对于如何在这种环境中取得成功、在平台团队中表现出色，你有什么建议吗？

平台团队的成功之道

Camille Fournier： 如果你想做平台方向，如果你是工程师，或者工程经理，你必须记住，这类工作有一半其实是运维质量和运维卓越性。平台工程不仅仅是写代码然后扔给别人就完事了。对运维挑战和系统扩展抱有兴趣和热情，我认为是相当重要的——如果你想从软件工程师的角度成为一名优秀的平台工程师的话。如果你更偏向产品经理的角色——你得真心在意……我认为你必须对与非常聪明的工程师合作感兴趣，他们在很多事情上比你懂得多得多。

而且你要几乎成为一个擅长——不一定是零到一，而是超过一个人的阶段，因为实际上公司里很多最好的平台型产品都是从单个应用团队起步的。某个应用团队遇到一个问题，自己把它解决了，结果发现那个解决方案其实是一个非常好的思路。所以一个好的平台团队经常会在各个团队中寻找这类方案，然后把它们吸纳过来，推广给越来越多的人。所以，我认为如果你想做那种从零到一、一直在构建全新东西的工作，在平台团队中可能不会那么开心。

但如果你对接管已有系统、使其稳定、扩展、提高效率、随着公司发展而演进这类事情更感兴趣，我想你在平台团队中会过得更开心。

Lenny Rachitsky： 太好了。在我们结束这部分、进入非常令人期待的快问快答环节之前，关于与平台团队合作、在平台团队工作、或者组建平台团队，你还有什么想补充的吗？

平台团队的三大难题

Camille Fournier： 我认为还有两三件我们没有谈到的事情，是关于平台团队真正困难的地方，而且我觉得这些方面不太被讨论。首先是，管理平台项目与管理敏捷项目有些不同。你可以借鉴很多从敏捷产品交付中学到的最佳实践，但你运行的是周期更长、规模更大、复杂度更高的构建工作，因为你在平台层面构建的很多东西本身就花费更长时间，也更复杂。所以你必须愿意投入进去，特别是如果你在平台领域担任管理岗位的话。

其次，你要处理大量的迁移工作。这点很烦人。迁移是不可避免的，即使你不主动推动它们，你的云服务提供商会说，哦，你得从 EKS v19 迁移到 v121 或者类似的版本，这可能需要修改代码，然后对所有应用团队来说都是一大麻烦。所以，如果你对如何平滑地处理这种底层变更对客户和公司的影响感兴趣，你在平台团队会过得很开心。如果你对这方面不感兴趣，你可能不会太享受这份工作。平台工作中有大量细节导向的工作。当然，最后一部分就是——利益相关者简直是一场噩梦。我那位写问题来抱怨平台合作伙伴快把他逼疯的朋友，我毫不怀疑他也在把对方逼疯。

因为你面对的是大量的利益相关者——你的技术条线的同级同事，可能还有产品经理，可能还有高管，他们会问：这个团队是干什么的？他们真的值这么多钱吗？我们为什么在这上面花这么多？我不明白他们在做什么。在某些情况下，我都能做得更好。所以，这份工作中实际上有很大一部分，特别是作为产品经理或工程领导层，是利益相关者管理，而且要真正学会做好这件事。这并不总是——我认为大家普遍公认这是这份工作中最没意思的部分。我觉得没人喜欢它，但这确实是一种技能，我很庆幸自己具备这个技能。所以，如果你在考虑组建这样的团队——

然后心想，我可以只做有趣的技术工作或者酷炫的产品，我对工程生产力充满热情，或者我对大规模状态存储系统充满热情，其他的我都不想管——从长远来看，你在领导岗位上可能不会真正感到快乐。作为独立贡献者（IC）可能还好，但对于领导者来说尤其如此，这份工作远不止有趣的技术问题、有趣的运维问题，甚至不止产品层面的事情。

Lenny Rachitsky： 你说有几件事我们没谈到，还有其他的吗？

Camille Fournier： 这已经是最快的了。感兴趣的听众，我的书将在接下来几个月由 O’Reilly 出版，会深入涵盖所有这些内容。

Lenny Rachitsky： 有具体的日期大家应该关注吗？

Camille Fournier： 我想现在应该已经在 Amazon 上可以预购了。书名叫 Platform Engineering，然后副标题是……大概是面向技术、产品和人才领导者的指南之类的。具体的发布日期——我不太确定 Kindle 版本什么时候出，我们还在做文稿编辑，但应该很快就能完成。

Lenny Rachitsky： 好的，太棒了。大家现在就可以预购。我当然会在节目备注和描述中放上链接，书名叫 Platform Engineering。在我们进入非常令人期待的快问快答环节之前，我想先带大家进入这个播客的一个固定环节，我叫它 AI Corner。AI 是很多人非常关注的话题，我也一直很好奇大家在工作或生活中是如何发现它的价值的。所以问题是——你在工作中有没有发现 AI 在哪些方面对你有帮助？有没有什么有趣的使用方式？

AI Corner

Camille Fournier： 我觉得它有帮助的场景是，比如我写了一个句子，我觉得这个句子内容不错，但措辞或格式我不太满意，需要编辑一下，但我又想不出怎么改。我经常会把它放到 ChatGPT 里，问它”能帮我重新表达一下吗？能帮我换个说法吗？“不总是效果很好，但有时候确实有用。它会说”对，如果我把这个调换一下或者换一个词，句子就更容易读了。“我觉得它——我认为它在这类小场景之前还是不错的。我认为对于大量文本，我的体验就没那么好了。我可能还算是一个 AI 新手。

我想说的是，AI 在引用方面真的很差——至少 ChatGPT 是这样。其他的模型我没有太多使用。我确实在 Twitter 或者某个社交媒体上看到有人说，Francis Ford Coppola 是不是用 ChatGPT 给那部新片——叫什么来着，Agopolus——写了假影评。

Lenny Rachitsky： 对。

Camille Fournier： Agopolus 可能是这么拼的。

Lenny Rachitsky： 对。

Camille Fournier： 我看到那个的时候就想，我其实也遇到过类似的情况——我当时在给书找引用，我想也许 ChatGPT 知道，就问它”你能给我一些关于……的好引用吗？“我忘了具体是什么主题了，就说是关于管理复杂性之类的吧。然后它给了我一些非常有意思的引用。我想太好了，但我最好核实一下。结果它们全都不是真的，没有一条是真实的。我就说这不是一个真实的引用。它会说是的，你说得对，这不是，然后给你换一个——换的那个也不是。

Camille Fournier： 我就说，那也不是真正的引用啊。所以别让它给你找引用，因为……或者如果你一定要用，确保那是真实的引用，而不只是措辞有趣的……我的意思是，它在某些方面对文本的概括还不错，只不过不是真正的引用。

Lenny Rachitsky： 这是一个很好的提醒，总的来说就是不要假定它告诉你的东西是真的。一般来说，它给你的不一定是真实的东西。它在编造内容，通常是对的，但也经常可能不对。这确实是个很好的提醒。关于你说的第一个技巧，你有没有什么好用的提示词，可以教大家怎么把内容喂给它？就是直接给一句话，让它帮你写一个更好的版本？

Camille Fournier： 没有，我完全没有搞明白提示词工程这件事。前几天我试着让它帮我总结一篇论文，它居然给了我另一篇论文的摘要。然后我去问朋友，朋友说”嗯，给你一个摘要。“我说”这个摘要看起来不错。“朋友说”是这样的，我先告诉 AI 它是这个领域的专家，需要仔细阅读，而且它非常聪明。“我就想说，我怎么还要管理机器？我已经要管理所有这些人类了，为什么现在还要我管理机器，拜托？

闪电问答环节

Lenny Rachitsky： 我还以为这东西能解决我们所有的问题呢。是啊，那个角色设定。工程学里有个缩写词来说明怎么使用它，总是要先给它一个角色——这是你要扮演的角色，你是一个出色的写手，这是我对你的要求。对。我也很不擅长这个。顺便说一下，Claude 在写作方面确实非常出色，这是它的超能力之一，所以如果你想尝试写作，值得试试。Claude，由 Anthropic 出品。

关于你说的假引用那个话题，对了，Francis Ford Coppola 要出一部电影……如你所说，那个预告片里全是人们据说对他其他电影比如《教父》之类的评价引用，全都是非常刻薄的引言，全是对他电影的恶评。

后来发现，嗯，它们全都不是真实的引用，而且他们实际上已经撤下了那个预告片，我刚读到的，因为他就是编造了那些著名评论家的话。

Camille Fournier： 那么，也许——

Lenny Rachitsky： 也许是 ChatGPT 干的。

Camille Fournier： 你是可能被骗的。我不知道是 ChatGPT 还是什么调皮的实习生之类的，但我们确实可能——

Lenny Rachitsky： 或者是精心策划的营销噱头。

Camille Fournier： 也有可能。

Lenny Rachitsky： 好了。那么，Camille，我们进入了非常令人兴奋的闪电问答环节。准备好了吗？

Camille Fournier： 准备好了。

Lenny Rachitsky： 太好了。第一个问题，你会推荐给他人的两三本书是什么？

Camille Fournier： 第一本是《What Got You Here Won’t Get You There》。我非常喜欢这本书。我觉得任何想要挑战自己、追求成长的人都应该读一读，非常棒。第二本叫《When Things Fall Apart》，作者是 Pema Chödrön。这本书是当你……至少对我来说，当我在周围的环境中挣扎的时候，我觉得它非常抚慰人心，提醒你生活本就艰难，最好的方式是……你只需要去呼吸，去感受，让这本书提醒你每个人的生活都不容易，并在过程中让你成为一个更善良的人。

Lenny Rachitsky： 最近有没有特别喜欢的一部电影或电视剧？

Camille Fournier： 我很喜欢《异形：夺命舰》（Alien Romulus）。非常好看。如果你喜欢恐怖的异形电影，太棒了。

Lenny Rachitsky： 我讨厌恐怖片，所以那是一部新的《异形》电影。好的。

Camille Fournier： 是的。

Lenny Rachitsky： 都不知道还有新的《异形》电影。

Camille Fournier： 我很喜欢。

Lenny Rachitsky： 有没有最近发现并特别喜欢的产品，可以是 app，也可以是实体产品？

Camille Fournier： 说到最近的话不太好说，但我是一个 Whoop 的超级粉丝。我在疫情期间入手的，它是我最……我就是它的迷妹。我不知道，我就是真的很喜欢它。我每天都用。也许它完全不准确，但看起来足够准，而且我就是觉得它是一个很有趣、很酷的产品。

Lenny Rachitsky： 我知道 Whoop 这个产品，听这个播客的人里也有人在用它，所以他们听到这个应该会很高兴。还有两个问题。你有没有一个经常回想起来的、会分享给朋友或家人的、在工作生活中觉得有用的人生座右铭？

Camille Fournier： 如果你不挑战自己，如果你不冒险，你就永远不会成长。这是一个很重要的座右铭。我觉得你必须……挑战自己、敢于冒险，这才是成长的途径。对我来说另一条是保持好奇心。你越能记住自己不知道的比知道的多，保持开放心态，愿意承认自己是错的，你就会越快乐，也一定会成为更好的领导者。

Camille 的健身日常

Lenny Rachitsky： 最后一个问题，关于健身的话题，录播客的时候你一直用头挡着它，当我们……你身后看起来是一个非常显眼的杠铃组还是哑铃组，我分不清哪个是哪个。聊聊你的锻炼计划，或者你是怎么健身的。

Camille Fournier： 我举铁的时间可能比你播客的一些听众的年龄还大，这更多是说明我的年纪。我现在有两个孩子了，所以举铁主要是维持状态，但我以前是一个非常……我硬拉能超过自己体重的两倍，是一个非常非常强壮的人。当然现在人人都开始举铁了，这让健身房变得很烦。所以我房间里有一套小器械，配一根婴儿尺寸的杠铃，就是……当我没法去健身房的时候，至少可以在家举一点。

Lenny Rachitsky： 你最喜欢的举铁动作是什么？

Camille Fournier： 我喜欢最基础的——硬拉、深蹲、过头推举，就是那种非常简单的、经典的举铁动作。

Lenny Rachitsky： 太棒了。Camille，这次访谈太精彩了。和我想象的一样好，我们聊了好多内容。最后两个问题。大家想联系你、关注你的动态、了解你的书的话，在网上哪里可以找到你？另外，听众们怎样才能帮到你？

Camille Fournier： 好的，鉴于现在社交媒体的奇怪状况，这个问题其实比以往更难回答了。我在 LinkedIn 上，你可以关注我的 LinkedIn，我可能……以前我不太在那里发东西，但我预计未来几个月会开始发更多内容。我写东西的时候也还在用 Medium，其实我挺喜欢 Medium 的，medium.com 上 scamille 是我的用户名。这两个是不错的方式。我有一个 Twitter/X 账号，目前是锁定的状态，我可能会也可能不会在某个时候解锁它，但正如我说的，社交媒体变得越来越奇怪了。所以我觉得 LinkedIn 可能是这类事情最方便的方式。

Lenny Rachitsky： 我记得在某个地方读到过，scamille 这个用户名源自你年轻时对 ska 音乐的热爱，对吗？

Camille Fournier： 没错，是的。那是高中时候的事了，我当时是一个超级 ska 乐迷。

Lenny Rachitsky： 有意思的是，我们的用户名就是从很小的时候留下来的，然后就永远成了我们在网上的身份。

Camille Fournier： 是啊。

Lenny Rachitsky： 太荒谬了。然后你还没回答我最后一个问题——听众们怎样能帮到你？

Camille Fournier： 我有一本新书即将出版，还有另一本已经写好的书。当然，我很希望大家买我的书，也很希望大家把我的书推荐给其他人。我的第一本书已经被翻译成了好多种语言，这非常令人兴奋。如果你读了之后觉得有收获，请告诉我，在社交媒体上 @ 我，我觉得那就太棒了，敬请期待。还有，如果你在找人去你们公司聊聊平台工程方面的话题，我可能会有兴趣。不过我总的来说很喜欢结识有趣的人，如果你在纽约，可以联系我，谁知道呢。Lenny，今天能和你聊天真的非常非常开心，非常感谢你邀请我来节目。

Lenny Rachitsky： 我也是。Camille，谢谢你答应来上节目，你太棒了。非常感谢你的到来。

Camille Fournier： 保重。

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

术语表

原文中文
Alien Romulus《异形：夺命舰》（2024年科幻恐怖电影）
AmazonAmazon
Andre 3000Andre 3000（音乐人）
Camille FournierCamille Fournier（嘉宾，曾任 Rent the Runway 首席技术官）
ChatGPTChatGPT
CI/CDCI/CD（持续集成/持续部署）
dev toolsdev tools（开发者工具）
DevOpsDevOps
Four TetFour Tet（音乐人/乐队）
Francis Ford CoppolaFrancis Ford Coppola（美国电影导演）
GraphQLGraphQL（一种 API 查询语言和运行时）
headcountheadcount（人员编制）
Ian NolanIan Nolan（Camille Fournier 的合著者）
IC (Individual Contributor)独立贡献者（IC）
jQueryjQuery
Lenny RachitskyLenny Rachitsky（播客主持人）
O’ReillyO’Reilly（技术图书出版商）
OKR (Objectives and Key Results)OKR（目标与关键结果）
Pema ChödrönPema Chödrön（藏传佛教尼师、作家）
PHPPHP
PM (Product Manager)产品经理
prompt engineering提示词工程
ROI (Return on Investment)ROI（投资回报率）
skaska（斯卡音乐，一种起源于牙买加的音乐流派）
SRE (Site Reliability Engineering)SRE
WhoopWhoop（智能健身追踪手环品牌）

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