超越编码：高级工程师如何扩大影响力和推动变革

[InfoQ 首页](https://www.infoq.com/ "InfoQ 首页")[演讲](https://www.infoq.com/presentations "演讲")超越编码：资深 IC 如何扩大影响力并推动变革

观看演讲

速度：

下载

45:39

/presentations/lessons-building-engineering-team/en/slides/Kas-1778590544400.jpg)

摘要

Netflix 的 Kasia Trapszo 讨论了从编写代码到扩展组织的转变。她分享了通过技术清晰度建立信任、使团队对齐以解决“正确”的问题以及通过有意的文档化来扩展判断力的经验教训。了解如何超越个人产出，创建一个持久的架构遗产，从而赋予他人做出更好决策的能力。

个人简介

Kasia Trapszo 是 Netflix 的 IC 领导者，负责公司商业平台的架构。她的背景多样，涵盖了初创公司的工程角色、银行业的实际工作以及从零开始组建团队。曾在东西海岸工作过的 Kasia 带来了对科技行业挑战和机遇的广泛视角。

关于会议

软件正在改变世界。QCon 旧金山通过促进开发者社区中的知识和创新传播来增强软件开发。作为一个由实践者驱动的会议，QCon 专为技术团队负责人、架构师、工程总监和项目经理设计，这些人在其团队中影响着创新。

演讲稿

Kasia Trapszo：当我是一名初级工程师时，我被分配了一个安全的任务，这个任务旨在教会你责任感，而不会让你有机会破坏任何太重要的东西。当时我在一家初创公司工作，我们的团队使用了一个古老的缺陷跟踪工具。可能是 Bugzilla。重点是，那个工具并不特别可配置。你要么收到通知，要么收不到通知。如果你配置了通知，你就会收到通知。你碰了一个缺陷，你会收到一封邮件。别人碰了一个缺陷，他们也会收到一封邮件。另一个人碰了一个缺陷，你会收到十封邮件。明白了吧。团队决定，这不可行。我们需要一个简洁的每日报告，显示我们当天的缺陷情况。对于初级工程师来说，这是一个完美的任务。我构建了它。编写了 cron 作业，因为那时你用的是调度。在本地测试了一切，看起来很棒。然后我将其推送到生产环境。但是，我有一个拼写错误。你们知道接下来会发生什么。故事出了点问题。我的 cron 表达式中有一个拼写错误。结果，它不是每天发送一次简洁的报告，而是每分钟向整个工程组织发送一次简洁的报告，包括我们的 CTO。那天我学到了几个教训。一是测试你的 cron 表达式。看看那东西。二是自动化带来的谦逊是免费的。还要记住团队是如何处理这件事的。没有人吼叫。没有人让我觉得自己很蠢。我的直接经理在整个过程中疯狂地给我发消息，就像，只要让它停下来就行。随便怎么都行。让我们停下来。我们都笑了。我们修复了它。我们继续前进。那一刻一直留在我的记忆中，因为我意识到从那次错误中学习是多么安全。这是我第一次理解，伟大的团队不仅仅由他们的技术技能定义，还在于他们如何沟通以及如何帮助彼此变得更好。这个想法伴随了我大部分的职业生涯。

背景

我是 Kasia Trapszo。我在 Netflix 负责商业领域的工程。过去十年左右的时间里，我一直从事这方面的工作。像你们中的许多人一样，我职业生涯的大部分时间都在思考系统，如何使它们更可靠、更可扩展。也许在凌晨两点时，尤其是在你值班的时候，让它们少一点令人意外。随着时间的推移，我确实意识到，作为工程师，我们面临的最困难的问题并不是关于系统的问题，而是关于人的问题。

沟通、假设、对齐以及如何扩展我们自己的判断力，以便在我们不再编写代码时，良好的决策仍然能够持续发生。我们将讨论这一方面的工程。真正意味着如何扩大你的影响力，当你的杠杆作用不再是代码行数，而是清晰度、信任和影响力。我将通过几个故事，一些成功的故事，一些不太成功的，来讲述清晰度如何建立信任。对齐如何创造影响力。自我扩展如何将这一切变成持久的东西。希望在这次演讲结束时，你们能带走一些可以实施的想法，因为所有这些都是理论性的。这些是区分优秀工程师和那些悄然改变整个组织运作方式的人的关键因素。

清晰度建立信任

我们将从一个关于清晰度的故事开始。你知道它是清晰的，因为有闪光点。不久前，我正在帮助我们的支付团队在一个项目中支持巴西的一种新的支付方式。这种支付方式对巴西人来说并不新鲜，它无处不在。然而，直到现在，它仅用于实时支付。Netflix 成为第一个决定将其用于订阅支付的大商家。从那时起，事情变得有趣多了。因为订阅计费与实时支付不同。你有重试、宽限期、续订。所有这些维持关系的无形复杂性，而不仅仅是简单的一次性交易。自然而然地，这个项目看起来相当复杂。文档很长，需求严格。团队非常确信我们需要重构我们的一些账单系统。没有人愿意碰账单系统，相信我。我们开始绘制新的状态、重试时间表、条件逻辑。这是一个一开始看起来相当简单的项目，但还没完成时，它最终触及了大部分代码库和三个相邻的服务。然而，在查看需求时，我开始觉得有些熟悉。规则写得不同，但模式是我以前见过的。这让我想起了我们在欧洲处理直接借记支付的方式。我们在欧洲已经做了十多年的直接借记支付，所以对此非常熟悉。这并不是因为我聪明或有经验，而是因为我见过足够多的支付方式，能够识别出底层模式，即使我们使用了不同的术语。这就是资深工程师的工作方式。不是知道所有的答案，而是有足够的经验可以识别出过去解决过的问题。果然，不同的名称，相同的逻辑，有限的重试窗口，延迟结算，一些特定的错误条件。一旦剥离了术语，它真的是相同的行为。当我向团队解释这一比较时，你可以感受到集体的松了一口气。我们不需要新的账单流程，也不需要新的状态。只是几项配置更改。这一认识节省了几周的工程努力，并使我们最关键的一个系统没有变得更加复杂。更重要的是，它建立了信任。这是因为团队看到我不是简单地拒绝更复杂的工作，而是说有一个更简单的方法。这才是真正的清晰。它通过帮助其他人看清楚问题来赢得影响力。当人们意识到你的清晰度使他们的工作变得更轻松时，他们开始更早地来找你一起思考问题。这就是资深工程师如何领导的。不是通过权威，而是通过赢得信任的推理。

对齐创造影响力

当然，即使你自己的思路很清晰，这种清晰度也不总能在多个团队之间的交接中幸存下来。我在另一个项目中学到了这一点。一切看起来都很对齐，直到两个系统开始互相通信。不久前，我参与了一个系统迁移项目。一个是旧系统，正在迁移到新版本，另一个是依赖于该旧系统的生产系统。两个团队都做了一切正确的事情。审查了 API，同意了模式，讨论了迁移计划。一切都看起来很扎实。测试通过了。迁移计划完美无缺。文档无可挑剔。你可以把它装裱起来。然后我们开始进行端到端测试。你们都经历过这种情况。你开始进行端到端测试，开始发现问题。我们开始看到不匹配的情况。应该对齐的交易没有对齐。虽然没有崩溃，但数据就是不匹配。我们深入调查，找到了罪魁祸首。有一个关键标识符，两个系统都依赖于它，但它格式稍有不同。这不是拼写错误，也不是缺少字段。两个团队都完全按照他们认为的规格实现了它。他们只是对同一规格做出了两种非常合理但截然不同的假设。相同的模式，相同的字段名，相同的文档，但却是两个非常合理且不同的假设。这是一个大问题，我觉得我们应该能早点发现它。这并不是代码有问题，也不是流程有问题。这是两个团队在各自上下文中进行了坚实的工程工作，每个团队在其上下文中都非常清晰。问题就在这里。我们有清晰度，但我们没有相同的清晰度。从那以后，我在团队、项目和系统之间多次看到这种模式。每个人在技术上都是正确的，但系统仍然彼此不一致。有多少人见过这种情况？每个人在技术上都是正确的，但系统仍然不一致。这是最糟糕的那种正确。这也是典型的分布式系统问题，太多的局部真理，缺乏一致性。

我开始更加关注理解在哪里出现偏差。问题很少出在代码上。通常是在那些没有发生的对话中，因为我们大家都认为我们已经达成了一致。这才是真正的对齐所在。它不在文档中，而在于文档之下共享的理解。保持这种共享理解的活力，需要真正的工作。这不是你在任何路线图上能看到的那种工作。这个项目提醒我，每个团队清楚自己的职责是不够的。重要的是，当这些视角交汇时，它们仍然是一致的。清晰帮助人们做好工作，对齐则使这些工作能够协调一致。尤其是在涉及多个团队时，做到这一点，影响才会真正开始扩大。不久前，我们在解释一个机器学习模型的使用场景。这是一个用于路由支付交易的模型。这是一个非常可靠的模型，已经在生产环境中运行了相当长的时间。项目团队自然希望将其扩展到新的使用场景。从他们的角度来看，这是自然而然的下一步，模型运行良好，为什么不多加利用呢？然而，从工程的角度来看，情况有些不同。随着时间的推移，集成变得混乱。你知道系统会随着时间的推移而退化，就像它们自己一样。多个条件判断、旧的配置路径、历史遗留的问题，没有工程师愿意接近这些。在这种基础上增加更多功能，对工程团队来说，并不是进步。这感觉像是在增加技术债务，实际上是在自找麻烦。对话开始陷入循环。项目团队希望快速推进，当然，工程团队希望先稳定下来。产品团队嘛，你知道的，他们只想看到结果。每个人都有合理的观点，当然，每个人也都感到沮丧。原本的技术讨论变成了关于优先级的辩论。几轮下来，我意识到我们不知不觉地陷入了“我们”与“他们”的对立，工程团队与业务团队，谨慎与进步之间的对立。你们都经历过这样的会议。每个人都是对的，但不知为何事情却无法向前推进。这通常是我们在解决错误问题的一个很好的迹象。我尝试了不同的方法。我没有问是否应该增加这些新使用场景，而是问，六个月后，让每个人都对这个模型有信心需要什么？这个问题立刻改变了对话的基调。它将一场“我们”与“他们”的对话变成了“我们”与“问题”的对话。突然间，我们不再捍卫自己的立场，而是共同设计。一旦我们这样交流，我们意识到大家都在追求同一个目标。一个更简单的模型，更容易进化，边界更清晰，也许未来会有更少的意外。一旦这一点变得明显，对齐就容易多了。我们同意暂停扩展，同时清理集成层。团队定义了更清晰的输入边界，产品团队也看到了这不仅仅是一个延迟。我们正在投资未来的弹性。这就是真正的对齐。它不是强迫达成一致，而是帮助人们看到他们从两个不同的角度解决同一个问题。最终，模型得到了扩展，技术债务也得到了清理，虽然可能并不完全，因为技术债务永远不会完全消失。更重要的是，团队之间的合作更好了。人们停止争论所有权，开始关注系统接下来需要什么。对齐不是说服，而是连接。一旦成为“我们”与“问题”，事情就会更快、更轻松地推进。这段经历教会了我如何对齐团队。

还有一种对齐同样重要，而且实际上更难掌握。这种对齐是你必须在自己内心建立的，因为有时候最难说服自己属于某个场合的人就是你自己。当我第一次加入 Netflix 时，我是从一家初创公司作为高级工程师加入的。在那家初创公司，我是第一个工程师。我从零开始建立了那个工程团队。我对代码库了如指掌。回到 Netflix 后，我又回到了个人贡献者的角色。我真心兴奋能够再次做实际的工作。这正是我想要做的。然后我打开了代码库。那不是一碗拉面，那是意大利面代码。一开始，我以为这一定很出色，只是我不理解。我深入研究。我花了几天时间试图逆向工程这些复杂性。我真的相信，在这一切的背后，有一个超级优雅、美丽的架构设计，我只是没有资格看到。但越深入，就越觉得不合理。有一天，我和团队中的另一位工程师一起吃午饭，他说，没有人真正理解那部分代码。它就是一个黑盒子。就那样，迷雾散开了。问题不在我自己。那真的只是过度设计。那一刻改变了我对冒充者综合症的看法。很容易假设这种感觉意味着你不属于这里。有时，这可能是一个信号，表明你所看到的东西确实太复杂了。复杂性可以伪装成高深莫测。大多数时候，它其实只是缺乏清晰度，加上一些好的词汇，就像我的意大利面代码一样。一旦我意识到这一点，我就不再试图证明我理解一切。我开始问更简单的问题。这个抽象解决了什么问题？如果它没有解决问题，我们是否需要它？如果不必要，那就做我最喜欢的事情——删除它。如果这是一个非常简单的设计，会是什么样子？这些问题不仅让系统变得更好，也让我重新感到脚踏实地。我学到了一个一直铭记在心的道理：清晰不仅仅是为了别人创造的。每次进入新的领域，你都必须不断在内心重建这种清晰。因为冒充者综合症，坏消息是，它永远不会真正消失。它只是改变形态。解药几乎总是相同的：好奇心、谦逊，以及愿意成为房间里那个提出大家都想知道的问题的人。

扩展自己等于持久影响

这引出了下一个教训。当你找到了自己的清晰，并开始帮助他人找到他们的清晰时，扩展自己真正开始了。因为每个高级工程师最终都会遇到一个瓶颈。这并不是因为工作变得更难了。而是因为工作量变得更多了。你有更多的设计评审、更多的会议、淹没在备忘录中、比任何人合理承受的更多的 Slack 对话。有一天，你意识到你的影响力依赖于一个人们记得而你甚至不记得参加过的会议。谁上周参加了那个会议？我参加了两次。不久之前，我也发现自己处于这种情况。我们进行了深思熟虑的讨论，做出了好的决策，进行了精彩的对话，然后几周后，我们又在同一主题上进行了深思熟虑的讨论，做出了好的决策，进行了精彩的对话。这是因为没有人把它们记录下来。这不是任何人的错。只是没有一种简单的方法来捕捉技术选择背后的“为什么”，那种无法整齐地放入 Jira 任务或设计文档中的理由。我尝试了一个实验。我开始使用生成式 AI 来总结会议记录，形成简短的架构决策记录。这是我的唯一一张与 AI 相关的幻灯片。几段文字，描述了决定的内容、原因以及我们做了哪些权衡。将其放入共享仓库，无需审批，无需仪式，只是一个非常简单的记录。我不确定是否有人会阅读它。几周内，发生了一些有趣的事情。其他工程师开始添加他们自己的笔记，链接图表，澄清权衡，甚至包括我没有参与的会议的笔记。系统开始自我维护。我参加了一个会议，有人会说，我们已经讨论过这个问题了，这里有链接。那时我意识到，这个过程已经超越了我。这就是扩展自己的真正含义。这不仅仅是做更多的事情。一天只有那么多小时。而是创造足够的清晰度，使其他人可以在没有你的情况下继续做出好的决策。这开始是因为我厌倦了重复自己，但有时懒惰只是等待正式化的效率。随着时间的推移，这个习惯改变了团队的工作方式。决策不再只存在于人们的头脑中，而是开始存在于仓库中。新工程师加入团队时，总是会疑惑某个东西为什么会这样工作。现在他们可以很容易地找到答案。在这个层面上的成长，不是关于速度。而是关于可重复性。是关于让你的推理可见，以便其他人可以重用、挑战并在此基础上构建。是的，冒充者综合症有时仍然会出现。因为当你不再亲自编写代码时，很容易怀疑自己是否仍在提供足够的价值。我也学会了以不同的方式看待这一点。这种怀疑通常意味着你正在进入一种新的贡献形式。一种放大他人的工作而不是你自己的贡献。这才是扩展自己的真正含义。创建即使你不再在场也能持续工作的清晰系统。

还有一部分关于自我扩展的内容可能并不那么明显。在某个时刻，你的工作不再是做出伟大的技术决策，而是帮助其他人做出良好的技术决策。大约一年前，我们的一位资深工程师，我们叫她玛丽，来找我抱怨。她一直在处理一个非常棘手的数据迁移项目。技术工作很扎实，她的方法也很完美。但项目一直停滞不前，因为她无法在不同团队之间达成一致，每个团队都有自己的意见。她告诉我：“我觉得我在会议上花的时间比实际做工程的时间还要多，这难道就是资深工程师的工作吗？”我记得不久前我也问过自己同样的问题。有时候确实如此。我问她：“给我讲讲那次你觉得完全浪费时间的会议。”她描述了一次典型的架构评审会议，讨论只是在兜圈子。每个人都同意目标，但每个人都在争论在这个项目阶段根本没有任何意义的实现细节。我问她：“你有议程吗？”她说有点儿。她有设计文档。但会议中的每个人都知道会议结束时需要做出哪些决定吗？她没有这样做。这不是批评。我犯过这样的错误不下十次。你假设把一群聪明的人聚在一起，给他们足够的背景信息，共识就会自然而然地出现。但这不是现实。共识需要结构。我们讨论了如何设计一个用于决策的会议。首先明确要做的决定。人们需要知道他们应该决定什么。确定谁有输入权，谁是决策者或用 Netflix 的话说，谁是知情的船长。限定讨论时间。这一点最重要，因为工程师喜欢聊天。我也是其中之一。然后以记录下决定的内容和谁负责执行来结束会议。如果你从会议中出来后只有一份任务清单，而没有分配具体负责人，那这些任务很可能不会完成。这些都是基本的东西，但很少有人教过。你们还记得大学里有没有上过关于如何组织会议的课程吗？我肯定没有。第二周，她尝试了这种方法。那次会议用了 30 分钟而不是 60 分钟，而且她得到了明确的下一步行动。可能还是花了 60 分钟，但有了下一步行动。一段时间后，我看到她在为别人的项目主持设计评审。她在指导他们如何组织会议。自我扩展不仅仅是关于文档。它还在于认识到你通过试错学到的东西，并将其压缩成其他人可以立即使用的模式。当你帮助一位工程师跳过你三年前犯过的错误时，这就是杠杆作用。当这位工程师反过来再教给其他人时，这种影响就变得指数级增长。你所做的工作不再仅仅是直接影响到的系统，而是通过其他人影响到的系统。这并不是技术含量降低，而是一种不同的技术问题。如何传递判断力？如何扩展模式识别能力？如何将隐性知识显性化？这些都是工程问题。它们只是不会出现在 GitHub 上。

总结（清晰 - 信任 - 进展 - 扩展）

回顾这些故事，简化复杂性、对齐团队、扩展清晰度、帮助他人成长，它们都指向同一件事。资深工程师的真正工作，不是写更多的代码，而是建立能够超越你自身的清晰度。清晰度赢得信任，对齐将这种信任转化为前进的动力。自我扩展使这种动力得以持续。你的影响力不仅体现在你个人做了多少事情，还体现在你在参与他们的过程后，其他人如何思考、决策和沟通。这才是持久的影响。职业生涯早期，你开始证明你能做什么，你的技术技能有多强。然后你转向塑造做事的方式。你构建系统、架构。最终你意识到，你最大的贡献在于塑造他人的思维方式。这种工作没有提交历史。Git 提交。这种工作没有提交历史。这是让一切在代码改变后仍能继续前进的部分。如果从这次演讲中你只能记住一件事，那就记住这一点。你的代码可能会扩展系统，但你的经验和清晰度会扩展组织。这是一种持久的影响。我有一个挑战给你。选择本周你做出的一个决定，这个决定可能在六个月后其他人也需要了解。写三句话。为什么？你还考虑了什么？你做了哪些权衡？把它放在别人可以找到的地方。就是这样。这就是你开始所需的全部。这不是一个很好的策略，但只是一个小小的清晰行为。去扩展人，而不仅仅是系统，因为其中一方实际上会倾听。

问答

Kaye Mason：我参加了很多会议，人们只是谈论对齐，会议没完没了，然后我们需要第二次或第三次会议。当你谈到列出需要做出的决定时，你有什么建议来框架这个问题吗？这必须是一个是或否的决定，还是可以是“我们需要决定系统的架构”？

Kasia Trapszo：它可以是任何一种，但通常在进入这些设计讨论时，你心中有一些想要决定的事情。这可能是我们使用哪个数据库，或者我们是否继续进行这次迁移，是或否？关键是要确保我们知道我们在做哪些决定，这样我们就不会只是围绕实现细节兜圈子，因为工程师真的很喜欢这样做。

参与者 1：我认为你谈到了自我扩展的问题。回到我们的主题演讲，激励模型。很多时候，这可能只是人类心理学的问题，当你试图扩展自己时，你试图传递知识，教别人你的最佳实践。有一半的时间，做这件事的人并没有得到正确的激励。正如你所说，这并不是你的 Git 提交。那么，你怎么设计这个扩展系统，使你能够正确地受到激励？这可能只是一个领导力问题。有时候，当你把你的最佳实践和知识传授给其他人时，也会让你感到威胁，产生存在危机。从这个角度来看，我再次回到主题演讲的那个问题，即如何激励人们更频繁地这样做？

卡西亚·特拉普索：正如你所说，这确实回到了领导力上。如果领导层不相信这种工程师、IC 领导模式有效，那你必须向他们证明这一点。证明的方法之一是找到一种衡量方法。一种方法可能是，你的团队在有人帮助他们扩展并教导他们如何正确做事的情况下，是否更高效地交付代码？这基本上就是说服领导层接受这一点。如果领导层不买账，认为这种模式无效，那么要么悄悄地去做，因为你想要这么做，要么找另一个团队。

参与者 2：在过去的几天里，我们听到了一些关于心理安全的内容。你能谈谈应该多久关注一次这个问题，以及如何最好地进行这样的对话？

卡西亚·特拉普索：我认为心理安全应该是每个团队文化的一部分。当出现问题时，这一点尤为明显。比如我提到的整个工程组织被邮件淹没的故事，当这种情况发生时，很容易对人发火，这很令人沮丧。但这不是人们学习的方式，这对任何人都没有帮助。当发生事故或出错时，允许人们从中学习而不互相指责，使用无责回顾，因为每个人都可以从中学习，而不是让一个人感到痛苦，这样会更好。

参与者 3：当你的影响力不够时，你会怎么处理？当你似乎遇到了障碍，与你合作的人不听你的建议，也不接受你的影响时，你会怎么办？

卡西亚·特拉普索：我认为这可能是一个信任缺失的信号。这意味着他们不信任你给他们提供了好的建议，或者不信任你有提供建议的能力。我会从建立信任开始，这可以通过许多不同的方式实现。我认为我与团队建立信任的方式是展示我的技术能力。这并不是因为我是一个超级明星工程师，而是因为我愿意接手没有人愿意做的任务。我会去重构没有人愿意碰的代码。我会去修复那些否则会被搁置的 bug。人们看到我在这样做，并以身作则，开始信任我提供的建议是好的，因为整个团队前进得更快。

参与者 4：在过去几年中，我们采用了架构决策记录，这极大地帮助了知识的形成，但事后看来，这也导致了认知过载。有太多的决策在四处飘荡，有太多的文档在四处飘荡。当领域太大时，如何解决工程师因太多事情而感到负担过重的问题？

卡西亚·特拉普索：我完全理解，因为我以前也有同样的感受，架构决策记录是个好主意，但如果没有人阅读它们，那有什么意义呢？太多了，人们被信息淹没。我又要回到 AI 这个话题，因为我觉得随着这些技术的发展，情况正在变得更好。你可以使用生成式 AI 不仅创建这些记录，还可以维护它们，确保它们有意义且彼此一致。如果你在创建新的架构记录，可以随时让你最喜欢的生成式 AI 工具检查它与其他记录的一致性。是否有意义？是否需要更新其他内容？我们是否保持一致？我们是否在制造无稽之谈？我觉得我们正处于真正改变我们对文档思维方式的边缘，多亏了生成式 AI。

参与者 5：你提到了冒充者综合症，我认为这在软件工程师中非常普遍。你怎么判断自己是在经历冒充者综合症，而不是邓宁-克鲁格效应，后者会致命，因为你会高估自己的能力，从而限制同事，而这不应该是你做的事情。

卡西亚·特拉普索：冒充者综合症真的不会消失。我没有撒谎。你可能会在会议上发表演讲，想着，我是合适的人选吗？这些人甚至在听我说吗？我没有答案。

参与者 6：作为 IC，你如何建立自信，开始委派任务？

卡西亚·特拉普索：你怎么相信自己在做正确的事情？来自他人的反馈。看到他人对你工作的反应，对你的文档的反应，对你说的话的反应。如果团队来找你解决问题，这是一个信号。这表明你在某些方面做得很好。如果你的同事信任你，愿意快速审查一个 pull request，我觉得这是一个很好的信号，因为通常这些事情会拖延很久。我认为关键是从他人的反馈中获取信心。

参与者 7：作为一名技术负责人，你有什么建议可以教团队“钓鱼”，比如从领导那里学习和采用模式？我觉得有时候很难让一些初级工程师接受这一点。

卡西亚·特拉普索：这非常难。告诉人们如何做正确的事情很难。我想说，以身作则是最好的方法，因为如果你自己都不实践你说的话，人们是不会听的。随着我在职业生涯中变得更加资深，我意识到影响人们的最好方式是愿意去做别人不愿意做的事情。我们之前讨论过的一个话题，虽然现在有了生成式 AI 已经不再相关，但成为那个自愿记录会议的人。通常这个任务会交给初级工程师，但如果你也加入进来，你就能与团队建立信任。他们会看到你愿意去做，他们也会更愿意去做。

参与者 8：我们谈了很多关于默默担任个人贡献者（IC），通过做好事和拥有扎实的工程技能在组织中获得影响力的话题。我们还谈到不要试图说服或劝说别人，而是寻找共识。你有什么见解可以分享，关于如何与产品部门或其他部门中那些非常大声且有说服力的人竞争？

卡西亚·特拉普索：即使房间里最响亮的人，他们也有自己的角度。每个人都有一个故事。他们想做某件事总有原因。我认为第一个关键是要找到那个原因。比如，为什么他们会对某个特定问题大声疾呼，或者试图以某种特定方式做事，并看看这是否能帮助你与他们一起解决问题。将这变成一个机会，建立更好的工作关系，从而建立信任。我认为关键是同理心，总是试着思考那个人为什么会说、做或要求某些事情。

凯伊·梅森：你非常强调能够犯错并从中学习的重要性。作为一名工程领导者，尤其是像你这样级别的领导者，当事情到达你的办公桌时，可能已经涉及数十亿美元的影响，人们都在惊慌失措。你如何建立一种文化，确保人们有空间从错误中学习？

卡西亚·特拉普索：这种文化必须来自领导层。它必须自上而下，纯粹是领导层传达的信息，即错误是我们从中学习的东西。事件是学习的机会。如果某件事已经让我们损失了数十亿美元，那钱已经花出去了，不如从中学习。我觉得个人贡献者（IC）在这方面文化的改变中影响力较小，所以这真的必须来自领导层。

凯伊·梅森：关于共识的问题，你谈了很多关于共同解决问题，这在横向合作中效果很好。但如果横向对齐了，但向上对齐却没有呢？

卡西亚·特拉普索：当领导层没有对齐，但工程师们已经对齐了怎么办？首先，你需要确保工程师们已经对齐。是的，如果工程师们已经对齐，而领导层没有对齐，这是一个非常困难的问题。你需要让领导层对齐。当我过去遇到这种情况时，你需要向上一级汇报。这是你必须做的。

参与者 9：假设我是一名相当资深的个人贡献者（IC），我的同事是一名工程经理，我们俩都向高级管理团队汇报。作为一名 IC，我如何证明我对公司的价值至少与那位工程经理一样，尽管工程经理有一个完整的团队来交付项目和贡献，而作为 IC，我只有自己，在绩效方面如何证明这一点？

你在问，作为一名单独的个人贡献者（IC），当你的同事是一名有整个团队支持的工程经理时，如何证明自己的价值？

卡西亚·特拉普索：我会假设，作为那名单独的个人贡献者（IC），你要么在做与那个 IC 团队不同层次的工作，要么这不是一个公平的比较，因为一个人与多个人相比。如果你在做那种不同的工作，即我们之前提到的一些领导工作，比如带来清晰度、创造共识、弥合差距，那么工程组织需要重视这项工作。如果他们不重视这项工作，你就需要找到一种衡量方法，向工程领导展示这项工作的增值性。它带来了有价值的东西，使团队工作更快，使产品更好。无论是什么，总有一种方法可以向他们证明这一点。

参与者 10：你认为“不同意但承诺”是一种有效的达成共识的方法，还是通常表明讨论中有什么问题，有些问题没有被解决？

卡西亚·特拉普索：在 Netflix 的文化中，“不同意但承诺”是其中的一部分。这通常只是表明人们对于如何解决同一个问题有不同的想法。所有条件相同的情况下，我们都经历过这种情况，同一个问题可以有多种解决方案，只是你在优化什么，以及你的权衡是什么。“不同意但承诺”基本上意味着你认为这是更好的解决方案，但由于另一个人是我们所说的知情船长，或该项目的决策者，你会为了公司、项目或组织的利益去做正确的事情，而不是试图确保你的做事方式获胜。这是一种完全有效的看待问题的方式，因为我们会有不同的方法来解决同一个问题。这只是工程师的一部分。

查看更多[带有讲稿的演讲](https://www.infoq.com/transcripts/presentations/)

录制于：

2026年5月12日