故事

出版第一本书后没多久，我就意识到自己并不是那种喜欢看别人评价自己作品的人。最好的情况下，我会自我感觉良好那么一会儿，但更多时候只觉得难过。还在看书评的那段时间里，我看到一条评论，说那本书太以硅谷为中心，对大多数人没什么帮助。

在我开始构思后来成为这本书的想法时，这句话一直留在我脑海里，我不想只围绕自己的经历来写，把其他人的经历排除在外。更重要的是，我很清楚，我的职业生涯建立在一套特定的视角、运气和特权之上，我希望这本书能对那些在行业中有着不同体验的人也有用。

所以我想说，这本书里最好的部分，很大程度上得益于行业从业者坦诚而深刻的访谈，很感激能把这些访谈收录在这最后的一章里。即使前面的内容对你帮助不大，我也希望你能从这些职业故事中找到属于自己的独特收获。

Michelle Bu - Payments Products Tech Lead at Stripe

April, 2020 blog, twitter, linkedin

简单介绍一下你在 Stripe 目前的角色：你的头衔是什么，你和你的团队大致做什么工作？

我是 Stripe 的 Payments Products Tech Lead，直接向首席产品官汇报。我支持关键项目，并在全公司范围内处理紧急问题的缓解。我通常把 80% 的时间花在一两个大型的跨组织设计项目上，剩下 20% 的时间用来评审和支持全公司的技术与产品设计（特别是 API 设计）。

我常年维护的一份“最重要的三件事”文档示例：

我管理两名工程师，他们嵌入到高优先级的领域中。这既能放大我的影响力，也让这些工程师有机会接触 Stripe 的许多领域。目前，一名在做核心支付 API，另一名专注于改善集成体验。我仍然按 IC 职级序列考核——计划是最多同时带几个人，不会再多。

在你们公司，“常规”的 Staff-plus 工程师是做什么的？你的角色是这样，还是有所不同？

在 Stripe，大多数 Staff-plus 角色的工程师都在具体的团队中工作。有一些 Staff-plus 工程师同时有 Tech Lead 的头衔，负责某个产品领域或技术方向上更广泛的项目。

Stripe 的 Staff-plus 工程师有两种：纵深型的和宽广型的。

宽广型的工程师通过做模糊的、跨组织的项目来创造影响。他们往往在许多不同领域积累大量上下文，在全公司众多项目中扮演支持者的角色。这种形态的 Staff-plus 工程师在我们的产品工程团队中最常见。

纵深型的工程师往往是某个特定领域的专家。他们领导雄心勃勃的多年期项目。这种形态的 Staff-plus 工程师一般出现在产品基础设施和系统团队中。

作为 Staff-plus 工程师，你在哪些方面觉得自己最有影响力？

这一点随着我进入现在的 Payment Products Tech Lead 角色而发生了变化。（补充一点背景：Payments Products 由 20 多个团队组成，我们负责大部分面向用户的 API 和界面库。）

我开始更喜欢用“有干劲”这个词，而不是“有影响力”。“有影响力”是以公司为中心的，虽然这很重要，但“有干劲”更多是向内看的。正是找到让自己有干劲的工作，让我在 Stripe 待了这么久，一直去追求有影响力的工作。

当我直接在一线团队工作时，让我最有干劲的是能直接和用户互动，不管是在 #stripe IRC 频道上帮用户解决问题，还是设计并发布一个用户可以无缝集成的 API。

在现在的角色里，当我支持过的人宣布他们的工作上线了，或者当我看到自己帮助某个工程团队改变了对某个重要话题的理解模型时，我会感到有干劲。真正日复一日做那些艰苦的搭建和维护工作的，是这些团队，而不是我。我用他们的进展来衡量自己的影响，更重要的是，看这种进展的方向性，以及他们的工作和公司目标是否对齐。

最近记忆中一个具体的例子是，我和另一位 Staff-plus 工程师一起，把我们常见的 API 形态做了分类：有些标为流程（flow），有些标为引擎（engine），有些标为配置（config），等等。这项工作的目的是建立一套共享的心智模型和词汇，用来归类已有的 API，也用来讨论和设计新的 API。大家看过一次之后，就开始自发地使用这些分类！正是在这些时刻，我觉得自己通过传播有用的心智模型和想法，创造了杠杆，放大了自己的影响。

我会在 API Review 之类的评审论坛上花一些时间，但这类论坛往往更像代码评审。它们发生在设计流程的后期，更擅长防止坏结果，而不是陪伴团队一起走向好结果。当我能给产品团队的工程师提供设计出优秀 API 的工具时，我觉得自己更有影响力。

作为 Staff-plus 工程师，有没有什么是你做到这个级别之后才能做、或者说之前不会去做的事？

我在 Stripe 待了很久（从 2013 年就来了！）。因为资历老，我一直有一定话语权，但 Payment Products Tech Lead 这个角色（以及我直接向 CPO 汇报这件事）确实改变了人们和我打交道的方式。现在我在工作中明显感到更孤独了（也在积极适应这种新常态）。

有一件事需要时间适应：现在大家默认我对讨论的任何话题都应该有观点！当我是直接在一线团队的 Staff 级工程师时，这种情况没那么多。我记得换角色后不久开过一次会，我因为有点累，比平时安静一些。后来听说，汇报的人担心我不喜欢他们的方案，因为我一句话没说。那是我第一次意识到，人们在_等着我_表态、等着我支持他们的想法！从那以后，我在开会时一直注意保持投入、给出反馈，哪怕只是明确说我还没形成看法。

有些人比以前更重视我的意见、对我更客气，这让我有点不适应。以前也有人不配合，或者直接无视我的意见。我觉得经历过那些是好事。我当时足够自信（组织也足够信任我），会直接给他们关于协作的强硬反馈，确保这样的事不会发生在和我一样的人身上。而现在我担心的是，我正在失去看到这些互动发生的视野。

当你花越来越少的时间写代码时，如何对其他工程师的成长体验保持同理心？

我在新角色上只待了一年，所以还没觉得脱节太远。也许这一点会随时间改变。之前我是一个更小领域的 Tech Lead，那时我会写少量代码，也会参加团队的“值班轮换”，处理收到的请求、分诊并修复紧急 bug。

为了在新角色里保持上下文，我花很多时间和管理一线执行的工程师和 PM 一对一沟通。光是这一周，我就开了 12 个 30 分钟的 1-1。我还会跟进 Stripe 上报的每一个事故。（我们有一个 Slack 群组，加入后每个事故的 Slack 房间都会自动邀请你！）事故的“背景噪音”特别值得去听。通过细读每个事故的详情，我能估算出我们系统的现实和我每天思考的理想架构／理想产品之间有多大距离。我想知道工程师们在踩什么样的坑，他们掉进了什么样的失败陷阱，开发环境有没有帮他们爬出来。我把自己看作工程师群体在管理层面前的代言人，所以深入理解当下的现实对我很重要。

你会花时间推动技术、流程或架构变革吗？

到现在，我花在鼓吹某项_具体_技术或项目上的时间变少了，更多时间花在赋能别人，让他们去为自己认为重要的技术和项目发声。我也努力成为一个知识和支持的来源，大家在做跨领域的产品决策、向全公司陈述想法时，可以来找我要反馈。

我也会做一些明确思考理想架构和接口的项目。但说到底，迁移到任何理想状态都要靠各个团队自己完成，所以他们_必须_有主人翁感和被赋能的感觉。我花大量时间直接和每天做决策的工程师和 PM 交谈。理想的结果是，我们在方向上对齐，然后他们能在各自团队里为我们的北极星代言，并做出好的局部决策。

我现在做的项目在这方面难得多，因为它要为非常多、非常多的团队定义理想架构和接口——基本上就是所有做支付的团队！我还没找到可扩展的办法把所有人带上。连写文档（分发信息最具扩展性的方式！）都很难，因为不同团队（顾名思义）是从不同角度看接口的，对问题和解决方案的表述方式能打动每个团队的点完全不同。我们目前的做法是把文档评审当成用户测试：看着各团队的人读文档，看他们的光标停在哪里，他们对什么有反应，等等。目前看效果还不错！

之前我做过的 Payment Intents API 也是类似的跨领域项目，它重新思考了我们深受喜爱的 Charges API，以适应不断变化的支付领域。这个愿景花了两年才在全公司真正落地。即使有了组织的认同，我们至今也没完全实现最初理想设计的全部潜力。但这不是 bug！我们专注于给用户交付增量价值，同时验证设计。我预计，任何足够有雄心的设计项目，在我离开团队后都会继续下去。当时让这件事成立的一个重要做法是，把_一切_都写下来。

我们建了一份标准文档，定义理想中的抽象。直到今天，那个团队的人还在用这些抽象做北极星：

如果两个人问了同一个问题，我们马上把它加进一直维护的 FAQ。我们非常认真地对待每个人的反馈和问题，把举证责任放在自己身上。最后，我们努力让工作完全透明，甚至建了决策日志，全公司任何人都能用它跟进我们的进展。决策日志里的每一条都简洁地描述一个产品或技术决策，记录参与决策的人，并链接到详细的技术设计文档，文档里一般有完整的问题陈述和备选方案评估。

总的来说，对于有雄心的设计项目，我发现极度透明、同时明确说明自己是否准备好接受反馈，效果很好，关心这个话题的人都接受。这里是我领导过的一些项目的（公开）笔记文档顶部的措辞：

指导（sponsor）其他工程师是你工作的重要部分吗？

是的，而且是我最喜欢的部分之一！我在乎一起共事的人——他们是我每天有干劲来上班的主要原因。

对我来说，指导别人的一大块工作是为 IC 创造空间，让他们去做自己在乎的有影响力的工作。幸运的是，在现在的角色里，我不需要花时间主动证明自己能干，所以可以花相当多时间在项目的支持型角色上，帮别人发光。我很少觉得需要“抢功劳”，或者自己的名字一定要出现在帮过的项目的署名里（虽然被提到时总是开心的）。对于更开放的项目，有时借出我的名字是有用的。比如我最近发起了一个产品质量导师计划，我更多扮演组织者的角色，挑选学员、为他们配导师、偶尔看看他们的工作。和导师们比起来，我做的_远_没有他们多，但这个全公司范围的项目能启动起来，是因为我为它背书了。

日常工作中，我发现自己可以做个有用的“橡皮鸭”，给那些想知道如何推进复杂项目、如何解决技术分歧的人出主意。这种帮别人取得进展、自己不直接下场的工作，特别让我有成就感。

最后，我心里一直有一份名单，记着那些在自己的领域特别出色的人，一旦出现和他们兴趣匹配的_可见_机会，我就为他们争取。不过这里有个平衡。我学到的是，有时别人很难拒绝我。最近我请合作团队的一位工程师发封邮件，讲讲她做出的成绩。她发完后告诉我，她本来不想发，但又不想拒绝我。后来她给我看了她的“拒绝日志”里的相关条目：

Stripe 是你全职工作过的第一家公司，而且你一直待在 Stripe。你的 Staff 之路是怎样的？

我大学一毕业就加入了 Stripe。刚来时我的成长曲线其实比同批的工程师慢。前四年，我的发展速度比其他有野心的新毕业生慢。我想一方面是因为我写代码的时间不长（2011 年才上第一门编程课，2013 年就加入了 Stripe），另一方面是因为我在 Stripe 的第一个大项目是一个做了 1.5 年最后被取消的重写项目。

Stripe 刚引入职级时，我已经来了两年半，被定为 L2，而我们期望应届毕业生在 6 到 18 个月内达到 L2。说实话我挺失落的，因为同龄人已经到“高级工程师”级别了。那时我明明已经做了很多有影响力的工作，带起了大多数新来的产品工程师，事故时也总是冲上去帮忙。我那么拼，做了那么多有影响力的事，甚至是主项目之外的事！他们还想要我做什么？难道_不_帮别人吗？

回头看，L2 完全公允。我拼命、加班，是因为经验少，写出好代码的速度天然比别人慢一些。我的软件开发基础还不够扎实，说白了就是练得还不够！我做的有影响力的工作有价值，但也不是非我不可。当时的我，就是一个表现很好的 L2。

早期，我花在了解产品、了解支付领域上的时间，比写代码多得多。我花很多时间在 IRC 上帮用户（开发者）做集成。做了很多小任务（修 bug、小功能、给小痛点打补丁），技术上没挑战，但对用户很重要。这类工作不总能直接对应工程师的成长（不过我的调试能力倒是练出来了——我现在是个很厉害的调试高手）。我还在 Slack 和工单里过度热心地帮人，帮各团队为用户找到最好的方案，和其他团队、其他工程师建立了关系。头两年，大多数新来的产品工程师都是我帮忙带起来的。慢慢地，我有了“深爱用户、对产品了如指掌”的名声。（“用户第一”到现在还是我最喜欢的 Stripe 运营原则。）

后来我意识到，那段时间虽然在软件工程师的技术成长线上映射得不高效，但我其实学到了关键技能，让我后来从 Senior 到 Staff、再从 Staff 到现在的角色都走得非常快（加起来只用了 3 年！）。事实上我确信，正是头几年建立的人际关系，让那个被取消的 1.5 年技术项目没有给我的职业生涯带来太大打击。

后来在做第一版 Stripe Radar 和 Stripe Elements 时，我踏踏实实补了技术基础。我坚信，只要我对自己的技术短板有清醒认识，在做的项目里去补这些短板，并且主动挑战自己、去做超出技术舒适区的项目，技术能力自然能积累和练出来。而那些软技能、全公司的连接、对用户的专注、对产品的深刻理解——这些要花更长时间学，恰恰是它们在我补上技术基础后，加速了我走向 Staff。

你有过“Staff 项目”吗？

Stripe 产品的几乎每个组件我都广泛做过。随着时间推移，我做过的项目一般都会独立成专门的团队，其中有两个特别是在我做 Senior 工程师时做的，可能算 Staff 项目：Stripe Radar 和 Stripe Elements。

做 Radar 时，我们从零建了一个全新产品，深思熟虑地权衡做什么、不做什么，以便尽快把东西交到用户手里，还能安全地砍范围。2016 年 10 月上线时，那是我们经历过的最顺的产品发布之一。后来它成了非常成功的产品。

做 Stripe Elements 时，我搭了基础设施，从零设计了最初的 Card Elements API，不到 3 个月就上线生产。这全靠大量 dogfooding。做 Elements 时，我用不同的设计框架和设计（质量参差不齐）搭了三个微型电商店铺，来测试定制 API 的极限。从那以后，几十名工程师在这个代码库里成功开发，它成了新版 Stripe Checkout 的家，最重要的是，最初的 API 设计几乎没让我们后悔过。随着 API 产品扩张、我们对开发者用法的理解加深，破坏性变更总是难免的。我们当时很好地验证了最初的 API 设计，在快速上线和避免破坏性变更之间取得了平衡。

为了让新工程师能上手这个有大量 IFRAME 技巧的复杂产品，我写了大量文档。我发现讲故事很适合教别人为什么事情必须是这样：

现在回头看，两个项目的产品架构到今天基本都立得住。当时除了实现这些产品，我还得在上线后等上一段时间，等产品选择在用户那里被验证，等技术选择在内部工程师上手后被验证。

我觉得这是产品方向 Staff-plus 工程师的一条重要标准：

不只是把东西做上线，而是让它平稳推出，并在之后持续成功、持续增长，尽可能少留让人后悔的选择。做新产品时，砍角落、砍功能总是难免的。Staff 产品工程师会有意识地做这些产品和技术选择，代入各种用户 persona 做出当时最好的选择，并把粗糙的边角认真记录下来，留给未来的工程师。

你需要准备晋升材料吗？

我晋升 Staff 时很幸运，经理非常上心地帮我推晋升。说实话，当时我根本不懂怎么写自评。我写的是反思式的个人发展计划，写明年想学什么，而不是记录自己工作的业务影响和范围。其实是我的经理做了大部分工作，在他的评审里写清楚了我的影响。

还有两件事帮了我。第一，那段时间我的经理基本没换过。如果换经理，经理就丢了上下文， continuity 的工作就得你自己来做。第二，我的经理带的团队比较小，能花很多时间跟踪和理解我在做的细节。如果我当时是向一个带 10 个以上工程师的经理汇报，晋升材料的大量工作就得我自己做了。

对你晋升到 Staff 级别最重要的两三个因素是什么？

回想起来，一个可能让人意外的关键因素是（现在也是）我的冒名顶替综合征。它让我极度愿意接受反馈，愿意学习和成长，愿意为任何和自己工作沾边的事负责。从 PR 评论是否中肯，到某次会议是怎么开的，我都会主动找反馈。不管是技术还是组织上的问题，只要有东西坏了，我就坐立不安，内心深处特别想去搞懂它、修好它。Stripe 的产品没有哪块是“不关我的事”。这慢慢长成了两个超能力，对 Staff-plus 工程师来说，可能比技术超能力还重要：

1. 真正倾听他人、共情他人。

2. 对解决各种问题发自内心的在乎。

当然，冒名顶替综合征是双刃剑。它常常让我害怕、让我自我意识过剩——早期我总觉得自己因为不够快、不够高效会被开除。我是慢慢才对自己的长处有了安全感，说实话，这花了_很长_时间，以及经理和公司领导的大量正向反馈。

在产品工程方向到 Staff-plus，会比在基础设施工程方向更难吗？

我觉得是的。在 Stripe 会好一点，因为核心产品本身就是基础设施。这意味着产品工程里有很多机会去做需要考虑规模、健壮性、迁移路径和良好接口设计的项目。

如果你在主要做 UI 的团队，到 Staff 确实可能比较曲折，因为 UI 产品天然更短命，允许更多迭代和试错。要在 UI 团队做出 Staff 级别的影响，你得能创造杠杆。比如做设计良好的组件库、实验框架，等等。

产品工程师创造杠杆的另一个方面，是建立流程和系统来管理“产品债”。大家常说“技术债”，但支持老版本产品带来的“产品债”同样重要，规模化产品工程的很多难点，都和长期管理产品债、产品漂移（需要互操作的产品往不同方向走）有关。我相信公司积累到一定规模后，产品债本身就会在产品工程里催生 Staff 复杂度的工作。

关于晋升 Staff，有没有哪条建议对你特别有帮助？

_通用_的建议我没收到过什么特别有用的。一路上有不少针对具体情况的好建议，但那些建议总是和当时的情境绑定的。

对我最有用的通用体会，是学会和不确定性相处。在高级角色上持续成功，取决于你能不能随着组织需求的变化去适应和成长。

给想成为 Staff-plus 工程师的人什么建议？

先说几点前提：

• 我觉得自己的经理运特别好。

• 我的兴趣一直和对公司最重要的事对齐。（现在我也说不清，是我的个人兴趣（比如开发者产品、导师制）本来就对齐，还是我慢慢把自己调成了对齐。我_感觉_是前者，但不管哪种，我觉得自己一直对工作很有热情。）

我是公司里最显眼的产品工程师之一，所以有时工程师会看我在做什么，照着学，想复制成 Staff-plus。这感觉很好，我也很幸运能成为和我一样的人的榜样。

但我的第一条建议是，别为了模仿而去做自己不喜欢的工作。我做的事让我深感有干劲：和团队合作，解决抽象的建模和设计问题。这需要一定的韧性，能一轮一轮接住反馈再试，说实话，并不适合所有人。如果你盯着 Staff 头衔，而不是让自己去做有干劲的工作，很容易最后卡在一个自己不喜欢的角色里。做 Staff-plus 工程师，特别是宽广型的 Staff-plus，和做 Senior 工程师是很不一样的工作。

相反，去做让你有干劲的工作，哪怕纸面上看它带不来 Staff-plus。做好 Staff-plus 工程师的一大块能力，是发现和定义全新的高影响力工作，并让别人相信它的价值和影响。如果工作本身让你有干劲，做到这点反而更容易，因为你会更愿意深入思考自己的工作！

对于刚成为 Staff-plus 工程师的人，有什么建议？

Staff-plus 的工作是和你的团队、你的组织绑定的，别照搬不适合你情况的建议。比如我进现在这个角色时，很多其他 Staff-plus 工程师都在写个人 charter，描述未来 1 到 2 年想完成什么。这对纵深型工程师可能很有效，但对我这种需要快速响应组织变化和产品战略转向的宽广型工程师，帮助就没那么大。

你考虑过转工程管理吗？

我现在确实管两个人。但话说回来，我做的很多事和传统经理不一样。我不像招聘经理那样参与招聘，也不会遇到其他经理那种绩效管理的场景，因为能进我团队的工程师本来就是高绩效的。

我非常在乎 Stripe：看到不对劲的地方我就坐不住，想去修好。在有些组织里，这可能会把我推向工程管理，而不是现在的角色，我很感激管理不是唯一的路。我的长处和兴趣在产品工程、API 设计和执行上，而现在的角色让我每天都能用上这些长处。

你从哪些资源（书、博客、人等）中学到最多？

我爱读小说，从优秀文学里学到很多关于世界的认知。我不太爱读非虚构的商业或技术书。说到和工作直接相关的学习，我最珍视的是同伴关系。同伴给我及时的反馈，帮我把本来就在脑子里、没捋清的答案拽出来。

Stripe 有个叫“Leadership In Practice”的项目，所有经理和一些高级工程师都会参加。其中有一门关于适应性领导力的课，对我特别有帮助。后来我把学到的框架用在了很多场景里。

我从来不是那种找一个导师要答案的人。我一直用的是我以前叫“弗兰肯斯坦”式的、自己拼导师的办法，类似 Lara Hogan 在讲搭建 manager voltron 那篇帖子里写的。那些给我配一个导师的项目，总让我觉得别扭。我一般会先明确自己想成长的具体话题或领域，然后去找在那方面强的人，哪怕他们不是我的“官方”导师。

我大部分时间都在啃难而具体的问题，没有现成的通用答案。要找到对的办法，需要大量情境上下文，局外人是给不了多少洞见的。

最近读过、觉得不错的非虚构作品：

• Draft No. 4，John McPhee：我在工作中大部分时间都在写，经常卡文。但卡住了也要写下去，因为好的书面沟通是广播想法、放大自己的最有效手段。

• Creativity Inc.，Ed Catmull：这本书的语气确实让我挑眉，但关于如何在规模化下营造创造性工作环境，有太多可学的。这是我在产品组织和产品工程职能扩张过程中经常思考的事。

• Impro，Keith Johnstone：我觉得自己的超能力（尤其在公司变大后）是学得快、适应得快，所以我爱读讲不同学习和教学方式的书。这本讲学表演／即兴，挑战了关于教育的常规隐喻和叙事。

Ras Kasa Williams - Staff Engineer at Mailchimp

July, 2020 linkedin

简单介绍一下你目前的角色：在哪里工作，头衔是什么，你和你的团队大致做什么工作。

我是 Mailchimp 的 Staff Engineer，在 Data Services 工程组。Data Services 可以看作公司内数据工程的大本营。我们组建的系统主要支持数据科学和分析师团队（比如产品分析师、财务分析师、市场分析师等等）。

我是组里的 tech lead 之一，专注于搭建可扩展的数据处理流水线，支撑内部分析平台，推动关键商业智能项目。我也承担了团队很大一部分 Eng Manager 的职责（虽然名义上我不是 Eng Manager）。在这个角色上待了快 2 年后，我正在把它交接给另一位工程师。

在你们公司，“常规”的 Staff-plus 工程师是做什么的？你的角色是这样，还是有所不同？

在 Mailchimp，一旦成为 Staff Engineer，就是“Engineering Leadership”的一员。因为正式的工程职级体系是几年前才落地的，“成为 Staff Engineer 意味着什么？”或者“成为 Engineering Leadership 一员意味着什么？”的答案很可能因人而异。

在我看来，关键是全局思考。就是和其他成员合作，理解全公司范围的业务／产品战略，并把它提炼成全工程范围的技术战略，去支撑产品、市场和其他职能同事的执行。就是合作改进招聘、入职、跨团队沟通、线上运维这些流程。就是合作提升整个部门的技术能力和协作能力。

也是把全局思考用到局部。就是让自己团队的（技术）规划／路线图和全工程的技术战略对齐，并且清楚什么时候为了服务团队直接利益相关方而偏离这条路是有意的；就是和团队的管理者合作，从别的团队引入招聘、入职、线上运维的好做法，也把自己团队的好做法分享出去；就是把全公司业务／产品战略的上下文，翻译成对团队手头项目的影响；就是有意识地给团队的 IC 创造机会，让他们提升技能、获得曝光、接触到全公司的其他人。

当然，我也不是每次都做对。但这个工作模式对我挺有效的。

你每天的时间是怎么分配的？

前面提到过，我一直是 Data Services 的 tech lead 之一（还承担了很多 Eng Manager 的职责）。

作为 tech lead，我负责定义团队的技术战略和方法，并对执行负责。我努力把这个战略锚定在它对内部客户（或业务）的价值上，必要时在全公司讲清楚。一年里我会做几次复盘，看取得了什么进展，业务上有什么变化需要调整战略。我仍然固定写代码——肯定比团队其他工程师写得少，但保持“手放在键盘上”很重要，这样我的技术战略（和其他宏观决策）才有团队一线体验做依据。我的一个重点是，因为我定了技术方向，要让团队其他工程师随之成长。更具体地说：我帮队友（通过指导或教练）理解怎么做技术决策，理解技术决策要锚定在它解决的客户／业务问题和带来的价值上；帮他们理解怎么把工程项目从问题陈述一路做到上线发布／长期运维；帮他们理解面对不同听众（工程师同行、工程管理层、非技术利益相关方等等）该怎么沟通。总之，是帮他们成长到能自给自足，能按我的技术战略、方向和方法独立运转、独立沟通，不需要我在场、不用我参与对话。

我们组没有产品经理。但理解内部客户需求、管理利益相关方这些活还是存在的。团队新来的 Eng Manager 对这些负责，但很多责任是我们分担的。我做了不少和内部客户聊天、回一次性小问题、理解新需求（比如新数据集）、推荐推进路径、定预期（什么时候能做新的需求）之类的工作。

我们组也没有项目经理。但同样，这些活还是存在的。我主张每个成员自己拥有分到的项目的项目管理职责（比如给利益相关方同步进展，等等）。我在项目管理技巧上做了不少教练，比如主动沟通风险／阻塞点好让我帮他们扫清，怎么持续交付增量价值来保持 momentum。

我花了不少时间被动积累内部客户和业务上下文。我会偶尔看看自己不维护的仓库合入的 PR，看看公开发的技术方案和提案，偶尔参加数据科学和分析师团队的内部分享，听他们讲做完的项目或正在探索的想法。这些都是小动作，但帮我保持了对局势的感知，也是团队季度规划的重要输入之一。

作为 tech lead，我是 Eng Tech Lead Cohort 的一员。这是一个正式组织，包含工程部所有 tech lead，用来同步上下文、讨论想法、推进全工程的技术路线图。组里时不时会有一些自发的讨论和工作。还有一个固定会议，参加的是所有 Staff、Senior Staff 和 Principal Engineer，用来抛出和讨论问题，必要时定负责人和行动项，也用来和彼此建立连接。我们和 Google 有紧密合作，他们是我们的云厂商。偶尔我会花时间和对接的团队聊遇到的挑战、我们的计划、合适的解法、需要什么正式培训，等等。

随着我交出 tech lead 的角色，每天的时间分配肯定会变。但说实话，我也不知道会变成什么样。

作为 Staff-plus 工程师，你在哪些方面觉得自己最有影响力？

如果一天结束时觉得帮同伴扫清了障碍、保住了 momentum，总让我很有成就感。

可能是帮 Data Services 的队友想清楚复杂技术问题的选项，权衡是先给即时价值还是做长期可持续。或者帮他们想清楚怎么深入调研一项新技术，判断它能不能解决我们的 top 3 问题之一。

可能是帮别的团队的同伴复盘过去一个季度的交付，这些交付有没有带来真实的业务／客户价值，怎么围绕这种影响组织叙事，为晋升争取理由。

可能是看到某个短期的“组织工作”卡住了，因为没达成共识，就鼓励参与的同伴站出来做决定（充分听取相关方的反馈），并把它推到完成。

这种感觉贯穿了我的整个职业生涯，我享受同伴的成功，和享受自己的成功一样多。但接了 tech lead 角色后，这件事的分量肯定变重了。它从“我喜欢做的事”，变成了“我喜欢、而且对我负责的团队的健康也很重要”的事。

作为 Staff-plus 工程师，有没有什么是你做到这个级别之后才能做、或者说之前不会去做的事？

前面提到过，在 Mailchimp 一旦成为 Staff Engineer，就是 Eng Leadership 的一员。

能明显感到，Staff 以上的工程师对时间有更多自主权和 ownership。他们为本职工作之外的事情腾时间时，遇到的阻力更小。这肯定也是我的亲身体会。

我也有了更多自然的机会去教练、指导、支持团队之外的同伴。晋升 Staff 之前我肯定也在做，但晋升之后明显变多了。这是每天工作中很有回报的部分，我很欢迎。

同行经常说头衔不重要。但我 100% 不同意，我在待过的公司里的亲身经历和观察告诉我，事实恰恰相反。

有一种流行观点认为，成为 Staff Engineer 需要完成一个“Staff 项目”。你有过 Staff 项目吗？如果有，是什么？

某种意义上说，算有吧。

我以 Senior Engineer 身份加入 Mailchimp，马上被放进一个项目组（包括一位 Engineering Director 和两位 Principal Engineer），做 Mailchimp 第一个内部自助分析平台。

这个项目的一个关键是高效、高水平地执行。好也罢坏也罢，有另外两位 Principal Engineer 在，大家对我的期望可能没那么高。但我能马上上手，几乎不用他们扶，就开始给核心工作做贡献，到最后成了团队的关键贡献者之一。后来这个项目被吸纳进我现在的工程组 Data Services，我也被正式任命为 tech lead，继续护航这些工作。

这个项目的另一个关键是在全公司高度可见。项目组的工作被定为公司级项目。这意味着大量高管层的曝光，当然也有随之而来的压力。但整个项目组一直保持了不错的 momentum，最终成功建出了分析平台的第一个版本。而且我的经理和组里的 Principal Engineer 有意给我创造机会，让我去讲项目组的工作，我最后在 Engineering All Hands、全公司 All Hands 都讲过，还在一次工程招聘活动上联合做过技术分享。因为项目可见度高，加上 Mailchimp 的文化，我在入职很短时间内就能和全公司各个级别的工程师合作，和其他部门的分析师打交道——一般人要花一年左右才有这种机会。

所以，是好工作加上在更资深的工程师身边依然高效的组合；也是那些资深工程师（和其他人）有意给我可见度和接触面的组合，虽然他们才是项目上的技术负责人。重要的一点是：晋升是直到我在 tech lead 位置上干了有意义的一段时间、交付了大量价值之后才来的。但这个项目绝对是导火索。

关于晋升 Staff，有没有哪条建议对你特别有帮助？

第一条来自我的经理 Marc Hedlund。他让我用第三人称写绩效自评。思路是，给别人写评审时，你更愿意夸对方、更少苛责。很简单，但对我超级有用。说来奇怪，它还帮我学会了怎么围绕自己的工作和它给业务带来的价值组织叙事。

第二条来自“Staff 项目”里的资深工程师之一 Dan McKinely。我请他直接给我优缺点的反馈。他说我在全公司建关系的能力是长处，因为工程里人和社交的部分不会消失，事实上它们是成事的关键。

第三条来自“Staff 项目”里的另一位资深工程师 Coda Hale。他讲的是放大影响。具体说：

第一，给其他工程师定技术方向是有效的；第二，作为你为他们结构化工作的结果，去指导他们、培养他们的能力。

这条建议是我理解 tech lead 角色的核心，就是真的有意识地给团队创造机会，让大家拉伸、练技能、学到很多。

对于刚成为 Staff 工程师的人，有什么建议？

别想着把工程部_所有_问题都解决掉，据我观察，那样很快会精疲力尽、变得愤世嫉俗。慢慢来。按理说你晋升是因为你已经在按 Staff 的标准工作，所以不用做什么大刀阔斧的改变。继续做那些带你到这个头衔的好工作。等安顿下来，再往外扩。

沟通和组织叙事是关键。一定要写……多写。想问题、想想法时，写下来（哪怕不打算分享）。一般我发现，如果一个问题陈述或想法写不成连贯简洁的一段，说明我还要再调研，不然很难说服别人值得投入。文字还能帮你扩展想法及其讨论，比起约每个可能的人开会安利，效率高得多。

让经理的工作轻松一点。别只带问题来，也带（最好多个）对解法的推荐／建议来，请他们给反馈。这样经理不用替你把解题的活全干了（他们手头的事多半已经够多了），还能用他们的经验帮你排除／确认选项。说来好笑，让人评价你的方案为什么不行，可比让人从零想个完整方案容易多了。

开始有意识地给直接合作的工程师创造机会，让他们练技能、拿到曝光、接触到平时接触不到的公司里的人。

早点建关系。当你需要花社交／政治资本表明立场时，关系能帮上忙。如果第一次和某人打交道，就是比如说，在招聘问题上各执一词，那你一开始就欠账了。说清楚，我不是让你“讨好人”。但如果你事先建好了工作关系，以后和这个人高效协作、一起成事会容易得多。

说实话，这些全做到可不少，这也只是一家之言。就当饭馆菜单，合口味的拿去试试。然后把你的经验分享给下一个想往 Staff 走的人，把人情传下去。

你考虑过工程管理吗？如果考虑过，你是如何决定走 Staff 工程师这条路的？

经常有人问我。

我的确有个当 CTO 的目标，但更多是给自己定个方向，防止在职业发展上躺平。在 Mailchimp 的语境里，升到 Principal Engineer 就算实现这个目标了。我在现在的级别上能交付真实可见的业务价值，所以我觉得沿着 IC 轨道走下去、继续有产出，也会很有成就感。

而且我已经承担了团队 Eng Manager 的很多职责（虽然名义上不是 Eng Manager）。所以如果转管理才开始做的那些事，我已经在实践了，也拿到了经验。这股痒暂时算止住了。

你从哪些资源（书、博客、人等）中学到最多？你在行业中的榜样是谁？

和各种技术和非技术听众做关于技术的口头沟通，是一项技能。我每天都在刻意练。Kelsey Hightower 就是我观察学习的对象，看他怎么做才是对的。还有我大学软件工程课的一位教授。他很少来上课，但他来的那几次，我学到的软件开发，比其他任何课堂都多。他们都擅长讲清楚，还会按听众调整。

有两篇博客帮我打磨了做技术方案和战略的方法。第一篇是 Pete Hodgson 的“Delivering on an architecture strategy”，讲在功能交付和基础架构工作之间取得可持续平衡的框架。第二篇是 James Cowling 的“Stepping Stones not Milestones”，讲大的架构项目如何交付真实价值。

Keavy McMinn - Senior Principal Engineer at Fastly

March, 2020 blog, twitter, linkedin

简单介绍一下你目前的角色：你的头衔、所在的公司，以及你的团队大致做什么工作？

我是 Fastly 的 senior principal engineer。Fastly 是一个边缘云平台，提供 CDN 这类服务。我在 OCTO，也就是 CTO 办公室，由十来位直接向 CTO 汇报的 principal 或 distinguished 工程师组成。OCTO 每个成员都有自己的 focus，我是 API Lead。

在你们公司，Staff-plus 工程师是做什么的？你平时的时间是怎么花的？

OCTO 里 principal 和 distinguished 工程师的类型差别很大。在工程团队一线、而不是在 OCTO 里的 principal 工程师也有。在 OCTO 组里，有人做互联网标准或学术研究，有人做深度的技术研究和原型，有人帮完全创新的团队孵化新东西。我做 API Lead，和大工程组织走得很近。

我们做的事各不相同，但有个共同目标：全局、长期、系统性地看问题。也去找工程里可能被忽略、掉在缝里的事，帮一把。我们的 CTO 支持我们的工作，但具体做什么项目他不定，那是我们自己定的。

我从没按百分比想过自己的时间。我的工作有阶段性，这周这个多一点，下周那个多一点。大量时间花在写东西、做研究和找人聊上。我会和做 API 的团队、经理们固定开会。我会花时间把长期战略拆成小块，做研究，写提案。然后在公司里到处安利这个提案。最近写代码少了，但在别的阶段我会搭 demo 或工具来支撑大工作。写代码的部分还是很好玩。

作为 Staff-plus 工程师，你在哪些方面觉得最有影响力？作为 Staff-plus 工程师，有什么是你职业生涯早期不会去做的？

做普通工程师时，很难挤出时间。你更多要在固定项目的约束和节奏里工作。做 principal，有信任、有时间和空间去试点东西。

有了头衔，就不用花那么多精力先摆资历。它帮别人设定了上下文。一上来大家就更尊重你，这点非常明显。你还能接触到高管，信息拿得早，也有 seat 在桌边去影响事情。

你会花时间推动技术、实践、流程或架构变革吗？

我被招进来就是为 API 定战略方向的。一部分是把握技术方向和技术选择。我把它当协作来做。你看，苦活累活我来干，做研究，把所有信息分析一遍，摆出权衡，给出推荐。我会把组织和工程组的上下文都收进来。

我摆出我认为对我们最好的方案，大家可以不同意。你知道吧，他们也确实经常不同意。我更多是引导和影响，而不是说“我有权直接告诉你怎么做”。我从没见过那种风格奏效。

有争议的决策，我会和不同相关组的代表碰。约一组工程师，告诉他们我打算推荐什么，问“你们怎么看？我漏了什么？”也会约管理、产品那边，可能还有法务、文档、安全，看项目需要约不同的人。我也反着干过：先把东西摆出来，再约会收反馈，而不是等着人在文档里评论。

你推动过什么事情？

在我现在的工作里，我一直在力推的是 API 变更要写设计文档。就是在写任何代码之前，在改动成本还很低的时候，把用户 workflow 和能支撑这些 workflow 的接口长什么样写下来。有时看似简单的事其实很难，特别是团队还不习惯用这些肌肉的时候。

我推动的方法是，提醒大家当初让我们想改变的痛点是什么。我们不是为了理论完美、代码漂亮或高大上的 concern 而追求完美。我会拉回来：“这些是大家都说痛的点，而这个办法你们知道最终能缓解那些痛。”

我让更多人开始在乎同样的事，比如我会开始和更多工程师结对做 API 评审。评审时，我尽量教别人我在看什么，并在过程和对话里多鼓励。

你怎么指导（sponsor）其他工程师？指导其他工程师是你工作的重要部分吗？

这在我现在的角色里不是重点。在 GitHub 时我很清楚自己有资历和 tenure 带来的特权，指导过一位工程师。我会给他越来越有挑战的事做，鼓励他对我工作中不清楚或好奇的任何事提问，为他争取更多责任和认可。

你是如何建立组织信任的？

在 Fastly，我一进来就被给了信任。我是被招进来做具体事情的。我记得当时问“有时间要求吗？”问他们对战略的想法，被明确告知他们要_我_去想清楚、告诉_他们_。信任和责任都很大。

自己攒信任和被招进来就带着信任，各有利弊。攒信任的同时也在攒上下文，我在 GitHub 就是这样。不过在我现在的工作里，我发现不带上下文进来、当一双新鲜眼睛其实很有用。看到大家觉得“哦，我们一直就这么做的”时，很容易追问。不被过去绑住，有时很解放。

有一种流行观点认为，成为 Staff Engineer 需要完成一个“Staff 项目”。你有过“Staff 项目”吗？如果有，是什么？

我没听过这个名字，但我懂这个意思。我确实几次领导并设计过这类项目——解决棘手的工程问题、给公司带来大影响——但很可惜，它们没让我晋升。不过它们推动了我的职业发展。这些项目给了我经验、知识和自信，让我能换个姿势定位自己。甚至能上公开 conference 讲，或者知道“我做过 X，还能再做 X”。

公开演讲或公开曝光对你到现在的级别重要吗？

重要，我觉得对我的整体职业发展影响巨大。我不觉得它是必需的，但觉得它确实能帮上忙，帮过我。我的第一次 conference 演讲是被邀请去的——组织者觉得我艺术背景出身，视角有意思。吓死人了，一开始我想拒绝。但我妈劝我接下来。所以公开演讲一开始更像意外，而不是刻意策略。

主要是，我喜欢在会上遇到的人。后来演讲者人脉给我带来了工作机会。

你最初是如何获得 Staff 或 Principal 头衔的？哪些因素对你拿到这个头衔帮助最大？

我是被 Fastly 直接以 Principal Engineer 招进来的。所以说实话，对我最大的因素是换公司。做的活没大变，但换公司这件事最终让我拿到了头衔。

当时有人力挺招我，我确信这帮了忙。那人之前没和我直接共事过，但熟悉我的工作。

远程工作对你的职业发展有影响吗？

据我所知没有。我一直远程，也确信它影响了随缘聊天，但我做太久了。你会有意识地去聊天、建关系。而且我的公司基本都是分布式的。如果远程是少数、公司又不真正接受分布式，我能想象问题会大一些。

关于晋升 Staff，有没有哪条建议对你特别有帮助？

没有，倒是收到过坏建议。老套话，“很好。现在再证明一次。”有些建议把人往英雄方向推，比如说你得搞出不寻常或神奇的东西才配。路明明有很多条。工程职级体系经常助长这些观念。

对于刚成为 Staff 工程师的人，有什么建议？

想到的是找同伴或支持网络。和做管理一样，越往上越孤独，要找到还愿意挑战你、能和你一起 brainstorm 的同伴。他们是不是和你一个领域、是不是一家公司，都不重要。

你考虑过工程管理吗？如果考虑过，你是如何决定走 Staff 工程师这条路的？

试过一次，体验不好。意识到那不是我的热情所在。我对工程管理太尊重了，不会为了不对的理由去做。对的理由只能是支持别人。

你从哪些资源（书、博客、人等）中学到最多？你在行业中的榜样是谁？

Conference 对我是资源，还有机会和成熟、低 ego、特别棒的工程领导和工程师共事。Chad Fowler 和他的书 The Passionate Programmer 排第一。Dave Thomas 也是，我刚学 Ruby 时常去听他的 workshop，他的书 The Pragmatic Programmer 也是好书。

Bert Fan - Senior Staff Engineer at Slack

May, 2020 blog, twitter, linkedin

先简单介绍一下你目前的角色：在哪里工作、职位是什么，你和你的团队平时都做些什么工作。

我是 Slack 平台团队的一名 Senior Staff Engineer。我很幸运，在 Slack App Directory 上线后不久就加入了 Slack，所以有机会参与把 Slack Platform 演进成今天的样子。

我做的工作很难一概而论，但目标始终如一：让开发者能够基于 Slack 做开发，让我们客户的工作生活更简单、更愉快、更高效。具体比如开发新的平台功能、提升 API 性能、写文档，以及与合作伙伴、内部集成方和第三方开发者合作，确保他们能构建出有影响力的软件。

在你们公司，“常规”的 Staff-plus 工程师都做些什么？你的角色是这样吗，有什么不同？

在 Slack，Staff-plus 工程师的工作差异极大，取决于你在公司的哪个部门、团队的人员构成和规模，以及业务需要你做什么。Staff-plus 工程师通常是项目的技术负责人（tech lead），也就是说，他们要写技术方案，向各方利益相关者征求反馈，与设计和产品密切合作决定做什么，并主导项目的技术实现。他们还会指导其他工程师，改进面试流程和工程师文化，完善工程流程和工具，为重构和技术债提供技术方向。Staff-plus 的核心是让别人能做出更好的工作——成为一个放大器（force multiplier）。

我的角色包括上面提到的所有事情，但我更少聚焦于具体的技术本身，而更关注技术所释放的可能性。所以我可能会花时间做一些几乎肯定会被扔掉的概念原型，或者收集某个用户流程的使用数据，以便更好地理解如何改进系统。我经常会在 Slack Platform 之上亲自构建应用，诚实地检验开发者体验到底如何，还会主动去其他人的平台上做开发，看看什么好用、什么不好用。我写进生产环境的代码比公司其他工程师少得多，对此我完全接受。

作为一名 Staff-plus 工程师，你做过哪些在拿到这个职级之前做不了、或者不会去做的事？

过去一年里我做了很多产品创意的试验，其中一些后来演变成了我们 Platform 真正的功能。我能得到这样的机会，一部分原因是我之前成功交付过一些项目，建立了信任，但 Staff-plus 的头衔似乎确实给了我在选题上多一点自由度。

好坏参半的是，我现在还参加很多以前从没参加过的战略和规划会议。如果你想知道从领导层视角看“香肠是怎么做出来的”，最好先想清楚你是不是真的想知道香肠是怎么做出来的。

当你花在动手开发上的时间越来越少，你怎么跟上技术实际的运作情况？

我发现最有效的方法是和全公司各个工程师定期一对一，花大量时间倾听。如果你愿意花时间建立起信任关系，让工程师觉得可以对你说真话，你就能了解到工程现状的很多真实情况。作为 Staff-plus 工程师，你对别人的薪水和下一次晋升没有任何实质影响力，所以只要你平易近人，工程师们会更愿意对你坦诚。

哪两三个因素对你晋升到 Staff 最重要？你的公司、所在地或教育背景对你的路径有什么影响？

我的出身背景相当优越——大学读了计算机科学专业毕业，没有负债，也没有学生贷款，这给了我换工作时的自由，不用担心交不起房租，也不用担心找不到下一份工作。我把这种自由用在了对工作地点更挑剔、更有策略上。

我承认大多数人没有这种选择，但对我来说，在自己觉得有意义的事情上工作很重要——做我自己也在用、并且我认为对世界有正面影响的东西。我相信这些选择带来了回报，因为这样的公司会吸引志同道合的人，这些人以后会去到其他同样气质的公司。这不是一个纯粹看实力的世界（meritocracy），你的人脉很重要。我有过像其他人一样在公司官网上投简历拿到工作，也有多年没联系、但我尊重、也知道对方认可我这个工程师的 manager，我硬着头皮给人家发了封邮件拿到了工作。我们这个行业有太多花时间的方式，如果你足够幸运，拥有选择的时间和资本，却不定期审视自己在做什么，那就是亏待自己。

也许有一天你会成为这样的工程师：在 Twitter 上宣布换工作时，以前共事过的人会设一个四年后的日历提醒——等你股票完全归属（vest）了，第一时间来挖你。但在那之前，你得去写那些让你别扭的邮件，联系那些你想再共事的人。

关于晋升 Staff，有没有哪条建议对你特别有帮助？

我听过最好的建议是：晋升 Staff 往往是运气、时机和实力的组合。我观察到也亲身经历过这样一条路径：

1. 和你的 manager 建立互相信任的关系，对他们诚实、直接，说清楚你想要什么。而建立这种信任的前提，是把他们交代的事情一件件扎实交付。

2. 因为你的 manager 信任你，当听说有对公司影响重大的项目时，他们会为你争取，让你来带。或者，你得自己去找到甚至创造这样一个项目，再推动它立项。这要难得多，但依然可行。

3. 把这个项目成功交付。

4. 这个项目对公司产生了重大影响。

5. 因为你成功交付了一个有重大影响的项目，晋升 Staff 的提名就顺理成章，你的 manager 也乐意为你争取。

希望你能看出运气和时机会在哪里影响这个看似简单的计划——如果你和 manager 处不来怎么办？manager 离职或升职了怎么办？你在公司某个根本没有好项目的角落怎么办？项目注定失败怎么办？项目成功了但毫无影响怎么办？

这些都可能发生，除了下面这句，我给不出什么放之四海皆准的建议来破解它们：有时候你就是升不上去，你得对自己诚实，认清自己是不是正处在这种局面里。这时候，唯一的晋升办法可能是离开公司、换个地方。你以后也许还会“回旋镖”一样回到这家公司，而且职级比离开时更高，但就像一段失败的感情，回头草还吃吗？是重归于好，还是包袱太重、根本没法继续？

对刚成为 Staff Engineer 的人，有什么建议？

这在工程师圈子里算个老梗了：很多人入行就是因为不喜欢跟人打交道，但要把 Staff Engineer 干好，你很可能要花大量时间跟人打交道。职业生涯早期，靠把代码写得越来越好就能进步，但到某个阶段，你就该转向“更好地跟人协作”。信任别人，给别人做技术决策的自由（哪怕是你不同意的技术决策！），理解别人的动机，学会给难听的反馈，知道什么时候该坚持、什么时候该放手——这些都是有用的技能。

如果还没做到，试着成为那种别人想共事的工程师。每家公司都有那么几个工程师，如果你离职，你会想方设法规避竞业限制也要再跟他们共事。去成为别人眼中的那种工程师，它会为你的职业生涯打开很多扇门。

你考虑过走工程管理路线吗？如果考虑过，你是怎么决定走 staff engineer 这条路的？

职业生涯早期，我曾跟我的 manager 说，担心自己迟早得转管理，他说了些类似这样的话：“别担心！我们公司有双通道，管理通道和 IC（individual contributor，个人贡献者）通道，IC 通道里最高管理岗都有对等的职位，所以你永远不用为了升职而转管理。”严格来说没错，但现在回头看，里面有个明显的 omission：在很多公司，管理通道比工程师通道清晰得多。

在工程师阶梯上越往上走，能模仿的榜样越少，而且看起来一个比一个高不可攀。细究一下你会发现，有人是因为公司被收购时拿到的头衔，有人是因为写了一门编程语言或框架，有人是因为给公司带来了几千万美元的收入。

我的很多同事都转了管理，原因各异，我猜其中一个原因就是管理通道的晋升更明确、更可靠。但我坚定地认为，这不该是你做决定的主要动机。如果你们用开放的日历，去看看你 manager 的日程表，数数他们一周有多少个 1:1。那是你要的日程表吗？想不想写代码这事不是非黑即白的：有写代码的 tech lead manager，也有从不写一行生产代码、整天泡在 Google Docs 或 Dropbox Paper 里的 Staff-plus 工程师。但在我的职业生涯里，我从没裁过人、没卡过别人的晋升、没写过绩效 review——我知道硬币的哪一面更适合我。

Katie Sylor-Miller - Frontend Architect at Etsy

August, 2020 website, linkedin, twitter

先简单介绍一下你目前的角色：在哪里工作、职位是什么，你和你的团队平时都做些什么工作。

我在 Etsy 工作，它是全球领先的手工艺品在线集市。卖家把商品上架，卖给世界各地的人。我们专注于提供独特、特别或手工制作的商品，作为大卖场那种冷冰冰体验的替代品。

我目前在 Frontend Systems 团队，这是一个产品基础设施团队，负责我们的前端架构——包括我们的 PHP 视图渲染框架，不过我现在没有深度参与团队正在做的具体工作。过去几个月我一直在聚焦 Web 性能——以顾问的身份负责所有性能相关的事：改进监控和报表系统，找到需要改进的地方，随时给产品团队解答性能相关的问题。

Web 性能是很多公司要么忽视、要么不重视的东西。我加入 Etsy 时，多亏了 Lara Hogan 这些人，我们有很好的性能文化，但几年前组织调整之后，Web 性能团队没了，作为一个组织，我们躺在功劳簿上，把 Web 性能排到了后面。现在我们又把它放回了前台，因为行业里对“好”性能的定义和度量发生了很大变化，尤其是 SEO 方面。Google 在大力推动把 Web 性能作为搜索排名的标准之一。所以这确实是当下最受关注的领域之一，对零售商尤其如此。

在你们公司，“常规”的 Staff-plus 工程师都做些什么？你的角色是这样吗，有什么不同？

你的角色是这样吗，有什么不同？

关于 staff engineer 这个角色，有意思的是，我们把两种不同的“资深”放在了一个叫 staff engineer 的筐里，但其实这是两个不同的筐。

一种资深，是在某个领域成为专家，承担 tech lead 的角色，主导所在团队或组织的技术方向和路线图。另一种资深，是把工作范围和关注点拓宽，去思考跨团队的问题，推动建立跨多个团队的系统和实践。第二个筐就是我理解的 architect。你不是不懂业务，而是你的影响范围大于某个团队的 tech lead。

在 Etsy，资深级别有几档：Senior Engineer I 和 II，再往上是 Staff I 和 II，然后是 Senior Staff，对标 Director 级别。我的 title 是 Staff Engineer II，我也这么看自己，但我的具体角色是 frontend architect。这意味着我不只对自己团队在做什么负责，而是要看整个 Etsy 在前端领域做什么。未来是什么样子？我们要解决什么问题？怎么走到那里？我想的是这些，并在公司层面倡导能带我们走到那里的技术路线。

作为 architect，你花多少时间做软件开发？

好笑的是，我是 frontend architect，但我最近写得最多的居然是 SQL，因为我在做大量数据分析。我一直在看我们的性能指标，找改进空间，判断修哪些问题对性能和业务指标影响最大。我会零星写点 JS 或 PHP，但 mostly 是帮团队解阻塞、做小规模的性能试验，或者有重要的事但别人没时间，我就顺手做了。

我明显感觉自己变慢了，随着日历被会议填满，要找到整块写代码的专注时间越来越难。所以你们大概也不想让我写太多代码了！我现在更聚焦在发现机会，然后把这些工作“卖”出去，让我的团队或其他团队来做。

你每天的时间是怎么花的？

大概 50% 开会，剩下 50% 每天差别很大。有时候写文档，有时候泡在 SQL 里做数据分析，有时候泡在 Slack 里跟跨团队、跨角色的人聊。项目找上门的时候，开会会多一些，要去找其他团队了解他们在做什么，或者说服他们改动。差别真的很大。

我发现这个角色的人经常难以量化自己的工作，你找到过衡量影响力的好办法吗？

很高兴听到这话，因为这正是我非常非常挣扎的地方。我手头永远同时有一堆项目和讨论，我还有个坏毛病，容易被最新的事勾走，注意力发散，所以我必须很刻意、很清醒地组织工作和笔记。我永远在看所有可能做的事，挑出当天最有影响力、最重要的一件，这很难。

直到转成 architect，我才意识到自己以前多么依赖 sprint 和 JIRA 看板，依赖把 ticket 拖到“done”那一栏的仪式感，来确认自己完成了该完成的事。现在没有了团队上下文帮我组织一天，我只能靠自己的 to-do list，而且还在持续打磨这套系统。

一个确实有用的办法是：记下自己每天完成的所有事——开会、邮件、Slack 讨论等等。到季度跟 manager 做正式目标 review 时，我翻遍笔记，意识到：哇，我帮工程师修了六个不同试验的性能问题，我影响了某个团队，让他们的新功能走了更好的方向，我给了某个工程师反馈，帮到了他。这些事当时都觉得是小事，加在一起就是实实在在的影响。

作为 Staff-plus 工程师，你觉得自己在哪里最有影响力？

我最喜欢做的事是：发现一个没人碰过的新问题，想出一个疯狂的解法，然后我那些 brilliant 的同事接过这个想法，真正把它做成 awesome 的东西。起点是吸收大量来自一线工作的输入——看到这个团队在 x 上有问题，那个团队在 y 上有问题。把这些输入和你的经验、行业大势混在一起，在脑子里放一段时间，直到某天豁然开朗：原来背后更深的原因是 z，于是拿出一个解决它的方案——一个很难啃的方案。

转 architect 之前的一个例子：当时我的团队负责 Design System 组件。改动或修 shared 组件特别痛苦，因为组件的 markup 和模板没有单一可信来源（single source of truth）。全公司不是复用同一个模板文件，而是把 HTML 复制粘贴得到处都是。所以改一个组件时，根本找不全要更新的地方，组件的碎片散落在各处管理——有时在 JavaScript 里，有时在 Mustache 里，有时在 PHP 逻辑里。

于是我冒出个疯狂的想法：如果扩展我们自研的 PHP 框架，在 mustache 里支持可复用的模板块来表示所有组件，像 React 应用里那样自由组合，会怎么样？我做了个概念验证，写了提案，拿给团队。然后团队接过球就跑：建起了支撑这套组件系统的基础设施，做得比我自己动手好得多、健壮得多。

我最享受的部分就是发现问题、创造性地想解法，然后拿着提案到处“兜售”，让更多人参与进来、把活干成。

做前端的人，能像做开发者效率或基础设施的人那样为公司创造杠杆吗？

当然可以。我认识的专精前端的 staff engineer 屈指可数，我觉得前端这套技能在行业里没有得到应有的重视。我很幸运能在 Etsy 这样的地方入行，它倾向于招“全栈”工程师，而我有计算机科学 fundamentals 打底——大学读的就是 Computer Science，整个技术栈都干过、都懂。但我的热爱和 focus 一直是前端，因为它直面用户。我希望看到更多公司重视前端，因为我们带来的是有价值的技能和独特的思考方式。

至于成为 staff engineer，我觉得优秀 Staff Engineer 的素质跟你在哪个层（stack）没关系。说到底，staff engineer 得把工程决策看成一连串权衡（tradeoff），并把这些权衡讲清楚，这个能力在技术栈的任何一层都能练出来。

我还觉得 Staff Engineer 应该对自己专业相邻的所有领域都有广泛理解。做前端的我，花了很多时间去理解市场、业务目标、用户体验、视觉设计、服务端的视图层和业务逻辑层、代码怎么发布到浏览器、浏览器怎么把代码变成网页、用户又怎么跟它交互。在这些不同领域都有积累，做技术决策时更容易看到全局影响，也更懂权衡。

对用户有同理心，是所有工程师都该练的技能，我觉得在很多基础设施或开发者支持组织里被低估了——他们没意识到，对，自己也是有用户的！我在 Frontend Infrastructure 工作，我们努力把自己看成产品工程师，只不过我们做的产品是给其他工程师用的系统。所以我们有客户，有用户。我们设计系统 API 时，就是在为用户设计 API，要做好，就得理解我们的用户——也就是产品工程师。

所以我个人觉得，偏前端的人能成为很好的 Staff Engineer，因为他们习惯了时刻想着用户、想着用户会怎么跟自己做的东西交互。用户同理心是前端人带上桌的超能力。

当你自己写代码越来越少，你怎么保持对公司一线开发现实的同理心和感知？

Networking，networking，还是 networking，尤其是 1:1。我是全职远程。虽然现在大家都远程，但在不是完全分布式的团队里做远程，你得非常清醒地看自己在跟谁聊，确保在多个团队、多个群体都有连接，用得上这些关系网。

在 Etsy，我们很幸运有好几个员工资源组（Employee Resource Group），让人跨公司连接。我在代表科技行业边缘性别身份的 ERG（MAGIC）里相当活跃，好处是这个社区里有工程部每个部门的人。远程员工社区也一样。我会花时间指导 junior 同事、定期 1:1、参与 Slack 讨论，来维护和扩大这些连接，因为这对把握组织的整体脉搏帮助极大。我也会确保跟产品工程的工程师聊天，因为产品工程师是我们的客户群。

我正在努力改进的一点是多跟 manager 连接。长期以来我在 Individual Contributor 这条线人脉很强，过去几个月一直在拓宽关系网，把更多工程 manager 纳入进来。很多时候我的工作是“没有职权的影响力”（influence without authority）：决定不是我来做，而是去影响做决定的人，而很多时候拍板的就是 manager。

你是怎么 sponsor 其他工程师的？Sponsor 别人是你工作的重要部分吗？

我很幸运在 Etsy 跟 Lara Hogan 共事了几年，她讲了很多关于 sponsorship 的东西，作为科技行业的女性，我自己就受益于 sponsorship，也见过它的价值。我确实投入了很多时间和精力在这上面。

一年半以前，我的同事 Andy Yaco-Mink（另一位 Staff Engineer）和我注意到，产品团队之间没有好的渠道分享彼此在做什么，也没有渠道跟做产品基础设施的团队连接。为了解决它，我们提议并办起了一个月会，叫 Product Engineering Confab。这是个开放论坛，大家可以来提问、分享工作、庆祝胜利，我们做 infra 的也分享自己在做什么。

我们当时没完全料到的是，它还成了创造 sponsorship 机会的好地方。每个月我和 Andy 都要想：大家在做什么值得更广泛地分享？哪些试验跑出了有意思的结果？谁在做很酷的事，该被看见？然后我们就去找那些团队的工程师，说：“来 confab 讲讲你在做的事吧！”很轻松，五分钟，非常 informal，却是很好的公开演讲练习。

后来，有几位来讲过的人，后来去公司全员大会甚至本地 meetup 讲了。至少有一个人把分享扩展成了大 conference 上的演讲。还有人跟我们说，confab 上的演讲成了他们晋升材料里 leadership 的证据，那种感觉太棒了！你是在现在的公司第一次拿到 Staff Engineer 头衔的，晋升过程是怎样的？

我入职是 Senior Engineer，因为当时我们不直接招 Staff，这个政策后来才改。我加入 Etsy 之前已经在行业里干了快十年，但 mostly 是小公司、不知名的公司。来 Etsy 之前，我做前端 tech lead 已经五年多了。所以做 mentor、做 leader，我早就轻车熟路。跟管理、产品、设计紧密合作，定路线图、抓执行，这些我都烂熟于心。可以说 tech lead 这个角色我已经拿捏了。

但来到 Etsy，scope 比我以前见过的大得多。工程部比我待过的任何工程部都大好几个量级。我要学在真正的大规模下工作，这跟小公司完全不同。我学会了更看数据：为了搞懂试验框架，我去自学了基础统计。

不过从一开始，我就一直在四处找可以改进的地方。进来就说：“哎，这个事我们没做，应该做起来。”比如我注意到设计系统的 JS 组件大家写法随意，我就说“来定个框架和标准脚手架吧”。小到不起眼，但对我们的实践是很大的改进。我觉得晋升 Staff 的很多功夫就在这：发现问题，主动解决，而不是放任不管。

我在 Etsy 待了不到两年就升了 Staff。当时的 manager 是新来的，不了解我的过往，所以我们非常紧密地合作，一起准备晋升材料。我听说过 manager 主导和 IC 主导两种极端，我很庆幸自己深度参与了晋升过程。尤其是做远程，很多工作发生在 Slack、pull request 和文档里，不在 manager 活动的明面上，不主动，工作就被淹没了。你永远是自己最好的 advocate，做远程更是如此。你得花大力气让自己的成绩被看见、被知道。

哪两三个因素对你晋升到 Staff 最重要？你的公司、所在地或教育背景对你的路径有什么影响？

前面已经聊过一些：创造力、主动性、同理心等等。还有一个没说够的：沟通和透明。晋升 Staff 的很大一部分是让工作被看见，让大家知道你的名字、有好口碑。

很幸运，我在做前端基础设施的团队，自然要给全工程部写很多邮件讲我们的工作，所以曝光度很高。但做 infra 更大的一部分是客服——有人带着问题来你的 Slack 频道，你去帮人家解决。回学校读完计算机学位之前，我在服务业干了好几年，我一直拿那段客服经验要求自己跟同事的每一次互动：随时在，别摆架子，真正去听、去理解对方的需求。当你真心想帮同事，这藏不住。

你觉得有些公司特别擅长培养 Staff

工程师吗？

老实说，我只懂 Etsy 的 Staff engineering 怎么运作，所以完全是 biased！我觉得 Etsy 擅长培养 Staff Engineer，因为我们内部有重视技术卓越的文化，加上 blameless 的文化，还有想让世界变好一点的愿望。这吸引来又聪明又善良的人，而聪明加谦逊正是好 staff engineer 的料。这种环境会自我强化：好的榜样不断出现，想晋升的人就去学榜样的样子。所以整体上，在 Etsy 工作或工作过的这批人，给 Staff Engineer 立了很好的标杆。

但别忘了，很多小公司、不知名的公司里也有了不起的人在干 Staff engineering 的活，只是没叫 staff engineer，而是用其他方式认可技术线的 leader。很多公司里强的技术 leader 转了管理，甚至没听说过 Staff engineer 这种角色。在大厂很容易把 Staff 这个头衔当成终极目标，但记住，职业成长的路有很多条。

关于晋升 Staff，有没有哪条建议对你特别有帮助？

别人给过我、我也一定会传给其他 staff engineer 的最好建议是：有个误解，觉得成了 Staff Engineer 就能掌控自己的工作，大家都会听你的、按你说的做。事实完全相反！你为晋升这个实实在在的目标努力了那么久，一旦成了 Staff Engineer，一切突然变得模糊不清。你从解决相对明确的问题，变成负责找到对的问题，再想办法说服大家这个问题值得解。你的挑战方式跟职业生涯之前完全不同。

对正在追求 Staff 职级的人，有什么建议？

我被提名 Staff Engineer 前两次都没成，第三次才过。我觉得最后推我过线的，是我在 Director 那里有个好 sponsor。所以我的建议是：去发展你的人脉，开始跟你的 Director 或 VP 约时间，因为晋升与否是坐在屋子里的那拨人决定的。不是你的 peer，也不是你的 manager，是另一拨人，你得让他们知道你的名字和你的工作。到讨论晋升时，你要让他们想起：“哦，她发过全工程部的邮件讲这个项目。”或者“他在 Slack 里一直在回答大家的问题。”或者“她是不是在那个 conference 上讲过？”

找我问建议的人，特别是女性和 non-binary，我觉得他们本来指望我讲怎么成长为技术 leader，结果听到我说“你的技术大概已经够了，该去经营你在公司的 reputation”，都会很意外。不管喜欢不喜欢，没有好口碑到不了 Staff。大家都希望这是个 meritocracy，其实真不是。Staff 级别的角色受太多因素影响。

对越资深角色伴随的不确定性和模糊性，有什么应对建议？

要练出很强的自我认知，分清自己在追一件事，到底是因为自己想要，还是因为对组织有益。这很难。你得随时准备亲手毙掉自己的心头好，掉头，试新的。如果一条路走不通，别硬拗。

我特别喜欢 Dan Na 关于推着穿过 friction 的 talk，因为做技术 leader 天天都在经历这个。我经常想“没有职权的影响力”这个概念，因为 Staff Engineer 的工作就是：想清楚团队或组织该做什么，让组织对齐这个目标，再在没有人事权和拍板权的情况下，让事情发生。这需要极强的韧性，要调动一大堆所谓非技术技能才能往前推。

你从哪些资源（书、博客、人等）学到最多？你的 role model 是谁？

很多前面提过的人名，尤其是 Lara Hogan、Dan Na。Julia Evans 的东西我全都爱，还很幸运跟她合作过一个项目。Ryn Daniels 以前在 Etsy，写了很多职业成长的博客。Tanya Reilly 是我的大 inspiration——又一位厉害的职场妈妈，同时是受尊敬的技术 leader。前端领域，Nicole Sullivan、Jen Simmons、Ethan Marcotte 都是我的巨大 inspiration，只列几个。我很喜欢读 Camille Fournier 的 The Manager’s Path。我没走过管理线，那是个黑盒，任何帮你看懂管理世界的东西都有帮助，因为 Staff Engineer 某种程度上就像不管人的 manager。

Ritu Vincent - Staff Engineer at Dropbox

March, 2020 linkedin

先简单介绍一下你目前的角色：职位、在哪家公司，团队平时都做些什么工作？

我是 Dropbox 的 Staff Engineer。其实我之前就是 Dropbox 的 Staff Engineer，中途离开去了一家 startup，几个月前刚回来。回来是因为 Dropbox 里有个开内部孵化器的有意思的机会。我们在公司内部 fostering innovation。Dropbox 在文件同步领域已经是响当当的品牌，但竞争越来越多，我们要做更多，开拓新产品。孵化器直接跟 CEO 汇报，团队非常小。

我在 Dropbox 待得够久，跟很多人结下了很深的情谊，所以大家跟我聊这个角色时，听起来真好玩。我之前还做过几年 manager，有点手痒想写代码了。两件事加在一起，我回了 Dropbox。

孵化器有两部分。

第一部分是经典孵化器：全公司的工程师都可以来 pitch 想法，拿到 funding 加入项目，做出产品市场匹配度（product-market fit）或其他进展，每几个月继续拿 funding。目标是成功的项目毕业成独立业务线，不过我们还处在早期。

第二部分是常驻孵化器的工程师，一直在孵化器内部产生想法，高度自治地运作。我是常驻“侦察”小队里两名工程师之一，明年计划扩张。这跟我以前做过的任何事都不同，也是我想报名的原因。对我来说是巨大的范式转变。老实说，头几个月好玩和抓狂交织，因为当你的首要目标是快速试大量想法、其中多数都走不通时，impact 很难衡量。我得学着用更长的时间尺度看 impact——不是看我今天交付了什么，而是看未来我能影响公司交付什么。

在你们公司，Staff-plus 工程师都做些什么？

在 Dropbox，Staff Engineer 大概有两种画像。一种是 tech lead，做很多协调，给团队设计工作，花时间推项目。另一种更像 specialist（专家）。

我当初成为 Staff 时 definitely 是 tech lead 那种：带一个八人左右的团队，推了一个十八个月的项目。那个项目依赖多，硬骨头多。我要管住项目的沟通，还要把项目拆开分给团队，既把事做成，又帮大家成长。

Specialist 则是在某个领域深耕到底，比如 Python 之父 Guido van Rossum。Specialist 会接下极其复杂的项目独自攻坚，通常是别人接不了的项目。Specialist 比 tech lead 少。

Specialist 大多是外部招进来的吗？

有些 specialist 是从行业里招来的，比如 Guido，还有 ML 团队很多资深的人，但很多 specialist 是内部长出来的。这可能跟 Dropbox 比较晚才铺开 title 有关，大家有更长时间在我们的技术栈里长出深厚的上下文。

你每天的时间是怎么花的？

在孵化器的现在这个角色，我整天都在做原型。但以前做 tech lead 时，做的事杂得多。

我写代码，但写得不多，大概 20% 的时间。我是桌面客户端方向的 tech lead，花很多时间协调项目、给项目指方向。我还花很多时间跟招聘合作，这事是我感兴趣才做的，不是硬性要求。

比如，我设计过专项面试流程（speciality interview loop），主持过 debrief、筛过简历。我还在多元化倡议上做了很多。这也是我职业生涯里几度尝试工程管理的原因之一，我喜欢参与组织成长。

作为 Staff-plus 工程师，你觉得自己在哪里最有影响力？

我很自豪的一件事是参与了工程师级别体系的大改。2017 年，我是少数几个被选去做 engineer levels refresh 的 individual contributor，其他大多是 director 或 manager。我自豪是因为新的 ladder 影响了 Dropbox 每一位工程、产品和设计的人。

思考公司成长如何改变角色和职责，本身也很有意思。当时我们开始从很多不同背景招人，想用健康的方式激励每个人。这跟我的日常完全不同，把我推出舒适区一大截。

我也为我的 Staff Project 自豪，技术极其复杂。那个项目还让我帮团队很多人成长。几年后，还有离开公司的工程师给我发邮件，说因为那个项目他们更自信了、学到了很多。

也是在那个项目里，我的 manager 让我明白，我当 tech lead 的第一反应不 scale。一开始我想的是：“拆成二十块，分出去十八块，最难的两块留给自己”，我的 manager 推着我把难啃的骨头也分给团队，让他们被拉伸、被培养。

你会花时间倡导技术、实践、流程或架构的变革吗？

做 tech lead 时，我花很多时间倡导变革。我会跳进各种架构和技术讨论，哪怕不直接是我的领域，因为大家好像信任我的直觉。我认识太多技术直觉 amazing 但没有 Staff Engineer 头衔的工程师，但头衔确实把“有这种直觉”这件事 formalize 了。

我更希望拥有项目的团队来做最终决定。如果我心里有很明确的“正确答案”，我会试着把团队引向那个方向，而不是冲进去说“这就是正确答案”。

你是怎么 sponsor 其他工程师的？Sponsor 别人是你工作的重要部分吗？

我 definitely 把自己看成 sponsor。执行是我工作最有成就感的部分——我爱把东西做出来——但我一直爱帮人成长。看到我非正式带过、帮过的人后来做出很牛的事，我特别自豪。

作为 Staff Engineer，尤其是女性 Staff Engineer，我觉得很多人把我当榜样。管理那条路上榜样更多，所以我努力把做榜样当成职责的一部分，而不是只低头写代码。只低头写代码当然也很好，但我想帮别人，尤其是有 imposter syndrome 的人。

经常有人来问我：“我不知道下一步怎么走。”或者“我不知道怎么成为 staff engineer，那我去做 manager 吧。”我想帮他们找到自己的路。作为 Staff Engineer，让人看得见、找得到，能来问这些问题，我觉得是这个角色重要的一部分。

作为 Staff-plus 工程师，你做过哪些在职业生涯早期做不了、或者不会去做的事？

没有什么是没头衔就做不了的，但头衔给了我信心。除了头衔，另一个给我信心的是意识到：原来大家都在跟 imposter syndrome 搏斗。这是我跟一位工程师的关键谈话里学到的，我以为他是我见过最自信的工程师，跟他聊完他说：“我每件事都自我怀疑。回家就复盘白天说的话，想那是不是很蠢。”

正是这次谈话加上头衔，让我相信自己是个 Staff Engineer。它们给了我信心，去要更难的项目，或者让 manager 给我更多项目。

你在 Dropbox 晋升 Staff Engineer 的过程是怎样的？

我加入 Dropbox 一段时间后，公司才铺开外部 title。第一次有 title 的 review 季，只给了极少数工程师 Staff 头衔，当时还在校准。第二个 review 季我拿到了 Staff 头衔。

到第二季时，我做 Tech Lead 已经一段时间，我和 manager 都觉得我 clearly 在按 Staff 水准执行。Review 季之前我们对照新的级别定义找过 gap，整体很顺利。

哪两三个因素对你晋升到 Staff 最重要？ 对我来说，visibility definitely 是大因素之一，一部分来自做了很多正常工程职责之外的事。

比如，有年夏天我帮招聘跑 intern 项目。项目里我跟各团队的大量 intern mentor 合作，而 Dropbox 的 intern 班一向很大，结果我在全公司基本都混了个脸熟。招聘工作也有帮助。如果你每个月主持几十个 hiring debrief，推动 hiring 和 calibration 讨论，那你会跟工程部每个人都打上交道。我还帮过 onboarding，给入职新人讲核心工程的分享。

Sponsor 也 definitely 重要。我和 manager 的关系非常好，跟 skip-level manager 的关系也很好。我觉得这起了很大作用。

这些工作——有些公司叫“glue work”——是被直接认可的吗？

在 Dropbox，领导层高度认可这些工作。领导和很多资深工程师深度参与这些事，尤其是招聘，这不算 glue work。但话说回来，光靠这些到不了 Staff。关键是找到平衡：既有文化层面的 impact，又有拿得出手的技术硬货。

有个流行说法：成为 Staff Engineer 需要完成一个“Staff Project”。你有 Staff Project 吗，如果有，是什么？

你有 Staff Project 吗，如果有，是什么？

没有明文规定，也不是正式要求，但大家默认晋升要完成一个 Staff Project。我想不起哪个 Staff 晋升是没有硬项目的，通常是多人项目，晋升人做 Tech Lead。

我 definitely 有 Staff Project。当年 Dropbox 是消费级产品，下载安装在电脑上。Dropbox for Business 上线后，有个需求：个人账号和工作账号同时用，不用登出登入来回切。

第一版是在巨大的时间压力下写的，跑多个 Dropbox 进程：个人账号一个，工作账号一个。我的 Staff project 是让单个 Dropbox 进程支持多用户同时登录。难的是项目从内核一直贯穿到用户界面，Dropbox 系统的每一层我都得懂。

一开始以为六个月，结果干了十八个月。桌面客户端团队的大部分资源被它占了相当久。

关于晋升 Staff，有没有哪条建议对你特别有帮助？

职业生涯早期，我的本能是找那些我觉得能做好的项目，而不是更模糊、更逼我成长的项目。别人给我的建议是：逼自己走出舒适区，去要团队里难的项目。要到 Staff Engineer，你得懂、得会超出你现在会的东西。永远往前推一步，别怕要那些你觉得对自己太难的事。

这跟 imposter syndrome 连在一起：没十足把握能做好，就不想试。但你得习惯：搞砸了也没关系，试了再说。

对刚成为 Staff Engineer 的人，有什么建议？

经常有人来问我：“下一步做什么能到 Staff？”我常说的一条是：跟你的 manager 对你职业生涯想要什么，超级坦诚、超级开放。我早期 1:1 犯过的错，就是说我觉得 manager 想听的话，而不是我真正想的。

他们问我对一块工作感不感兴趣，我会琢磨他们为什么这么问，是不是 _想 _让我接？于是没兴趣也说感兴趣。他们问项目进展，哪怕烂透了，我也说挺好，怕让他们失望，而不是说我需要帮助。

后来我慢慢明白，你的 manager 真的是你队友。他们想让你成长、 productive、开心，成为最好的工程师。跟 manager 建立有效关系、让他们 sponsor 你，办法就是超级诚实、超级开放。

这在我自己做了 manager 后更明显，因为我 _想 _让团队每个人都成 Staff Engineer、都晋升。我想找理由提拔他们，跟他们一起努力。

你考虑过走工程管理路线吗，如果考虑过，你是怎么决定走 staff engineer 这条路的？

你是怎么决定走 staff engineer 这条路的？

我在两条路之间 pendulum 得挺厉害，因为两边都有太多我感兴趣的东西。我对带人感兴趣，喜欢跟招聘一起干，我就是那种真心喜欢面试的工程师，我喜欢琢磨团队怎么成长。但我也真爱写代码，管一段时间就想回去写代码、hack 点东西。

开始 mentor 和 manage 之后，我看职业成长的眼光 definitely 变了。两边摆帮我看到了很多视角。做 manager，headcount、绩效 review 这些职责非常明确。Staff engineer 的职责很模糊，不同公司差很多。Staff 角色的这种模糊，让很多人横向转了管理——其实他们做工程师会更开心。所以把 Staff 角色的信息多分享出来给大家看，很有价值。

你从哪些资源（书、博客、人等）学到最多？你的 role model 是谁？

我读书很多，但读的大多是 recreational。impact 最大的，是很多我当成 mentor 的人，通常是朋友、以前的 manager 和共事过的人。我有不少每月固定的午饭、咖啡和晚饭约会，跟以前共事、了解我、我信任的人。正是这些关于职业挑战和成长的谈话，带我走到了今天。

Rick Boone - Strategic Advisor to Uber’s VP of Infrastructure

April, 2020 linkedin

简单介绍一下你目前的角色：在哪里工作、职位是什么，你和你的团队大致做什么工作。

我是 Uber 基础设施副总裁的战略顾问（Strategic Advisor），也就是说，我是基础设施领导团队的一员，与工程总监们以及负责整个组织的项目经理们一起工作。Uber 的基础设施工程团队大约有 700 人，下设六个子组织，比如负责数据中心和服务器的 Metal、存储（Storage）、开发者平台（Developer Platform）等等。我与副总裁一起处理技术战略、文化战略以及专项事务。

战略顾问是一个覆盖面非常广的角色，例如我可能会做这些事：

• 评估我们未来两年的技术需求

• 帮助确定未来六个月路线图中创新的优先级

• 深入挖掘那些没有明确负责人、但又很重要的领域，帮助梳理相关的持续推进项目

• 在大的组织变动之前或之后，了解工程师们的真实感受

• 与两支需要达成一致、但分歧很大、看起来存在沟通问题的团队交流，想办法帮他们找到一条有效的前进道路

这真的是一份非常、非常宽泛的工作，混合了工程、文化、心理学、组织设计和战略。我常用流行文化中的两个形象来描述它。第一个是《权力的游戏》中的“国王之手”（Hand of the King），这是我能找到的最贴切的类比。第二个是《白宫风云》中的 Leo McGarry，他常说：“I serve at the pleasure of the President（我为总统服务，听凭总统差遣）。”在我的角色里，我会说，我为基础设施副总裁服务，听凭他差遣。

虽然现在这个角色只有我一个人，但之前担任基础设施副总裁战略顾问的有两个人，我们会按各自天然擅长的方向分工。她通常更关注与管理者和领导力相关的项目，而我更关注 IC 和工程方面的项目——不过两边的事情我们都做过。

战略顾问这个角色有点非正统；它是 Matthew Mengerink 在担任基础设施副总裁一段时间之后设立的。据我所知，我们这个组织和 CTO 办公室是仅有的设有这类角色的组织。Matthew 设立这个角色，是因为他看重来自工程团队内部、拥有完整上下文的反馈，他想建立这样一个反馈闭环，来为自己的决策提供依据。

在 Uber 基础设施组织里，这个角色特别有价值，因为这是一个非常、非常庞大的组织，而我所做的，就是提供一个综合了全局的视角。

这个角色和 TPM 角色相比有什么不同？

这是个有意思的问题，因为前几天我刚好在想参谋长（Chief of Staff）和我自己这个角色的区别。在基础设施领导团队里，有战略顾问和项目经理，过去还曾经有一个担任参谋长角色的人。

在我看来，项目经理是一个组织层面的运营角色。他们站在比较高的层面，确保基础设施内部的重大项目和重点领域按正常节奏推进、定期接受评估，把各种工作和举措运营起来，等等。而参谋长这个角色，是确保整个领导机器良好运转的——让参与运行和领导基础设施的所有人、各个小组、各种信息传递等等，都能有效地协同工作。

我的战略顾问角色，更多是利用广泛的领域知识，包括技术和文化两方面，深入到个人和组织层面的问题细节中，再融入工程方面的判断。从中提炼出一套建议或洞察，交付给组织负责人或整个领导团队。日常工作中，我绝大部分时间都是直接和组织的负责人以及项目经理们一起工作——把建议交付给组织的负责人，在得到他的输入和认可之后，再和项目经理们一起把它们变成现实。

你如何看待与你的赞助人（sponsor）保持一致的重要性？

有意思的是，这种一致是关键——几乎是这个角色得以成立的必要条件。Matthew 和我在原则、价值观、世界观、对情商的重视、对执行的态度和方法论上都非常一致。在太多事情上我们都是对齐的，以至于这几乎是一种共生关系。

与赞助人保持一致对于做好这份工作真的至关重要，但这不仅仅是战略顾问和副总裁之间那种不带感情的工作连接，也是 Rick 和 Matthew 作为两个人之间的连接，要确保这种契合是好的。

在我的角色里，我们经常连续几周都不在同一个房间里，但我仍然要像他的直接代理人一样行事。所以我走进一个房间时会想：“Matthew 在这里会怎么做？他会想问什么问题？针对这个问题他给过什么指导？”因为我不可能每次都跑回去找他确认，所以必须深入理解他的世界观并持续维护这种理解。这对我保留那种深度信任至关重要——作为他的代表，有效地执行他的战略和愿景。大家必须确信，如果 Matthew 本人在场，他会给出和我一样的答案。

这也意味着，我必须真正理解他的目标、意图、价值观和原则，确保自己愿意押上自己的声誉和信誉去推动它们。我的工作常常包括向工程师们宣传或转述他的愿景和落地方式，有时相关的补充背景并不为人所知。在这样做的时候，我必须确保自己不仅理解他这么做的逻辑和价值，而且自己也真的相信——否则，宣传就会变得困难，甚至显得虚伪。

刚进入这个角色时，这一点让我挣扎了很久。Matthew 总是跟我说：“你是我的代表，你尽管用我的名字和职位去推动事情、去做事。”这对我来说很难，因为我以前从没担任过这样的角色。以前我一直用的是自己的名字和声誉，现在却是在副总裁的名义和它所承载的一切之下行事。久而久之，我学会了慎重地使用这把“锤子”，因为你不想过度使用它。

我也学会了有时要让大家知道我现在戴的是哪顶帽子。我很喜欢指导别人，但有时大家分不清，面对他们的是为组织和公司利益服务的战略顾问，还是为这个人和他的职业生涯服务的导师；所以在具体的谈话里，我会尽量让对方知道我当前处在哪个角色中。如果我和我指导的人见面，他们可能想咨询换团队的事，甚至是离开这个组织或公司的事，他们想知道我是站在哪个立场给建议的。

在你们公司，“普通”的 Staff 及以上工程师是做什么的？你的角色是这样，还是有所不同？

我觉得最大的区别在于，其他高级别工程师主要做技术工作。他们是领导者，所以也会涉及情商、沟通、协作、冲突解决、布道等等方面，但他们每天仍有 80% 的精力是由技术问题驱动的。

而我呢，可能连续几周都在关注一个围绕群体心理或组织设计的项目。技术问题并不总是驱动我日常工作的纯粹焦点——尽管它们一直都在，哪怕只是在背景里。

现在你写代码少了，你如何保持对一线现实的感知？

当我是工程师的时候，我可以被动地做到这一点，因为你就在代码里，推提交、和服务的开通与运维中的各种摩擦打交道，等等。现在这套方法行不通了，因为我基本不碰代码了；所以现在，获取这些信息和感知需要一个主动的过程。

我做的一件事是继续坐在老团队旁边，这样能听到他们工作时的情况。也许他们会抱怨某个服务的稳定性，或者工具链上的某个缺口，能一直听到这些是很有帮助的。

我也不断问大家关于开发者体验的问题。我心里有一份名单，记着哪些人擅长发现问题、对方案给出反馈，我会经常找他们聊。有时这些交流更有组织一些，就是正式地发问卷征求输入，有时就只是一条快速的消息，问问近况。

我还会让大家把那些不在关键路径上、没有严格时间要求的活儿丢给我，我把这当作保持写代码手感的机会。但我得小心别进入实际产品的关键路径，因为我知道后续我不会有太多精力去维护那些代码。

你是如何赞助（sponsor）其他工程师的？赞助其他工程师是你工作的重要部分吗？

这个特定角色比较特殊的一点是，它本质上自带了与副总裁之间的指导关系。刚开始时，他问我：“五年后你想做什么？你的目标是什么？”当时，我对这些问题真的没有明确的答案。很长一段时间里，我的看法是，在我们这个时代，能写代码就已经让你处在人类历史上最好的位置之一了，工作有保障、发展路径也好，这对我来说似乎就够了。

花时间思考自己的目标之后，我真正意识到的是，我喜欢成为其他工程师看得见的榜样，特别是其他少数族裔工程师，帮助 Uber 这里的人或职业生涯更早阶段的人。我特别喜欢帮助那些刚入行、可能还有点怯生生的人。这是驱动我的很大一部分动力，而这个角色帮我认清并承认了这一点。以前我不觉得这算一个正当的人生目标，但我意识到，如果这是你热爱的东西，是你有激情的东西，那你就得去追求。

指导对我重要的另一个原因是，在我的人生和职业生涯中，我有六位堪称关键导师的人。他们每个人都在不同时期对我的人生产生了巨大的影响——没有他们过去和现在的指导，就没有今天的我。我对他们非常感激，也时常意识到他们指引了我多少。所以，我一直认可导师的力量，也想确保自己能把这份力量传递给别人。而且有时候，导师并不知道自己的某句话或某个举动如何改变了你，不知道那种涟漪效应会有多大，甚至多年以后还在延续。所以，我总是尽量让自己能被别人找到、做别人的导师，因为你永远不知道什么时候能对别人产生那种改变人生的影响，也不知道会以什么方式。也许只是在恰好的时机，给出一句恰好的话、一个恰好的视角、恰好的推一把。

我总跟大家说：“说真的，如果需要我，尽管来找我帮忙。”这是我工作中最让人兴奋的部分之一，我试着用几种不同的方式让自己触手可及。

一种方式是，我每个月都会给大部分工程新员工上一次 Engucation 课（engineering 和 education 拼成的一个词）。那门课叫“Lessons + Questions”，就是一个地方，他们可以问我任何关于 Uber 的问题——技术的、文化的，随便什么——我都尽量坦诚回答。最后，我会留下我的邮箱，告诉他们欢迎随时联系。之后确实有不少人联系我，我会给他们关于职业、在 Uber 工作等方面的建议。也有时候是有人在办公室里碰到我，顺便问点建议。

我想作为一名黑人工程师被大家看到，让别人知道我们在这里，这是可以做到的。一旦我意识到这是我的重要动力，我就知道自己必须练好公开演讲，因为这是扩大自己作为榜样影响力的关键方式。公开演讲曾经让我恐惧，我曾经特别讨厌公开演讲。但因为它是触达大量人群的关键方式，我告诉自己必须学会喜欢它，后来我学会了成为一个有效的演讲者，甚至真的爱上了它。现在它是让我最兴奋的事情之一——就像坐过山车，每次上台都会紧张，但那是一种刺激、有趣的紧张，上台时会有巨大的快感。

你会考虑打造自己的外部个人品牌吗？

我有几个朋友花时间打造外部个人品牌，其中一个现在正在重新捡起来。他意识到自己在 Uber 的工作太投入了，把外部的事情都搁置了。

我在这方面比较被动。如果我参与的事情被公开报道了，或者我做了一次公开演讲，我会在 LinkedIn 上贴个链接，但我自己完全不写东西。我想过要写，也有兴趣，但就是没写。我习惯用讲的方式来整理思路，所以这样写东西需要大量准备来组织想法，到目前为止我在外部基本没花时间做这件事。

你的战略顾问头衔是先在这家公司拿到的。你是被直接招进来做战略顾问的吗？如果不是，升到这个角色的过程是怎样的？

我的路径完全是非正统的。不是计划好的，也没有什么可复制的路径，更多的是一系列幸运的事件。之前 Rob Punkunus 担任过同样的角色，当他决定离开时，Matthew 请他推荐可能的接任者。他推荐了我和 Kate，最后我们俩都担任了战略顾问。

在此之前，Matthew 和我就已经有过几次积极的互动，我们开始发现彼此观点和价值观相近。比如，有一次我们的问答会上出现了大量匿名提交的刻薄评论，看到文化往那个方向走，我很困扰。我在一次问答会上站起来发言，请大家用更建设性的方式提出关切，我想那引起了 Matthew 的共鸣。

当他第一次建议我接这个角色时，我有很强的冒名顶替综合征。我甚至想让他收回邀请，觉得自己不合适，但最终我还是接受了，一直做到现在。

在你成为战略顾问的过程中，哪两三个因素最重要？你的公司选择、地理位置或教育背景对你的路径有什么影响？

除了 Rob 的推荐，最重要的因素是做了与 Matthew 价值观一致的、看得见的工作。我参与的一个项目是加入工作组，去理解和改善 SRE 的文化，那是 2017 年的事。这个工作组在 Susan Fowler 的博客文章发出之前就已经计划好了，而我们的第一次会议恰好在她发文三天之后。我真的觉得文化工作组做了很出色的工作，我自己和其他成员都为此非常自豪，用了十八个月，我们切实推动了一个百人组织的文化。

另外，我个人一直对文化和人类心理与行为领域的东西着迷。在我的职业生涯里，在我待过的公司，文化和群体心理常常是把组织从优秀带到卓越的隐藏变量。我本来就在用行为经济学、行为科学等方面的书和论文满足自己的好奇心，这种天然的兴趣把我推到了现在的位置。

关于如何做到 Staff，有哪条建议对你特别有帮助，还记得吗？

整个职业生涯中，人们总跟我说，我比自己意识到的更有影响力、更有潜力。我从来没听进去，对我来说是这样，对很多工程师来说也是这样，特别是少数族裔工程师，我们花大量时间自我怀疑。只看到不好的那部分太容易了。我们可能意识不到，当我们在会上充满激情地讲一件事时，大家真的在认真听。有这么多人一直告诉我，我没有意识到自己产生了多大的影响，我的观点不仅是成立的，而且真的在影响组织，这很有帮助。

另一个有帮助的是有导师。具体来说，我喜欢那种建设性地跟我“作对”的导师。我是说，他们会把我扔进那些让我害怕得要死、但他们确信我已经准备好的事情里。他们帮我把我推到了远超自己想象的地方。这些人通常是我合作过的管理者，我们能互相学习。

对于刚成为 Staff Engineer 的人，你有什么建议？

这要回到我是如何走到今天的：除了技术，我对组织心理、文化、指导等等有广泛的兴趣。我从来不是那种 24 小时扎在代码里的纯工程师。我从来不是那种人，我必须与这一点和解。

对我来说，追随自己的热情很重要。最近是围绕指导，但也有过别的东西，比如机器学习，它一直是我的业余爱好。我喜欢机器生成洞察、模仿人类思考的方式——那是技术和心理学兴趣的完美结合。

我有这些热情，一直呵护着它们，然后当公司需求和热情对齐的机会出现时，我就抓住。比如，我之前在 Uber 的团队为容量规划做车队利用率洞察，那是一个把我对机器学习和站点可靠性的兴趣结合起来的好机会。

小公司给你做很多不同事情的机会，但到了一定规模的公司，也给你独特的、专注于热情的机会，这让我既保持了影响力，也保持了热情，尽管我从来不是那个坐在键盘前整天写代码的人。

你考虑过做工程管理吗？如果是，你是如何决定走 Staff 工程师这条路的？

这事我有时会想想，即使现在也在想。它在我可能性的清单上，整个职业生涯中人们都问过：“你考虑过转管理吗？”

我现在想专注的是成为一个高效的高层级、大局观领导者。将来某个时候，我也想培养人员管理能力，可能在中期左右。吸引我的是，人的行为让我着迷到不行，而人员管理是花时间研究它的好机会。

你从哪些资源（书、博客、人等等）学到过东西？你在这一行的榜样是谁？

说起来，职业生涯前三分之二的时间里，我喜欢读尽可能多的技术内容。整天泡在 YCombinator 或 RSS 订阅里，看分布式系统、可靠性等等。这些年我更爱读行为经济学、行为科学、人类心理学、组织战略等等。这方面的一些人我很喜欢，比如 Daniel Kahneman、Tim Harford、Dan Ariely。还有一些很棒的播客——Freakonomics、Choiceology、Hidden Brain。

还有，去年我开始整理一份关于人脑和行为的书单，分享给同样感兴趣的人。

技术方面我还在看 Reddit 上的 r/linux 和 r/programming，它们已经取代 RSS，成了我发现新东西读的主要渠道。

Nelson Elhage - Formerly Staff Engineer at Stripe

April, 2020 twitter, blog

简单介绍一下你目前的角色：职位是什么，在哪家公司，团队大致做什么工作？

我最近在 Stripe。他们做在线支付处理，是一家增长很快的创业公司，大约两千人。工程团队大约六百人。我离开时，严格来说没有头衔。如果我多待两个月，我会是 Staff Engineer，因为在经历了几年内部争论之后，他们终于开始推职级头衔了。

我最近所在的团队叫支付架构（Payment Architecture），是一个三四个比较资深的工程师组成的小团队。支付是 Stripe 产品的核心，我们负责支付代码库。我们特别关注代码库中金融基础设施那几层，建设支撑 Stripe 当前和未来产品线所需的数据模型和抽象。

我们研究代码结构如何适配组织结构，包括在一个快速增长的组织里如何组织代码——团队、产品、国家、支付方式都在不断增加。特别重要的是，我们的架构要能支持把所有权分散到多个办公室和多个时区。

我们推动了很多围绕代码质量和代码架构的举措，也做了一些实现和重写项目。对每个举措，我们会制定指标和目标，让各个团队认领这些目标，然后给他们提供工具，帮他们迁移到新标准上。

“支付架构”团队是一个常设团队，还是更像一个项目制团队？

两者都有点像。它不是一个战术性很强、授权范围很窄的团队。但它也不太可能作为一个团队永远存在。我们用实验性的方式演进架构，过程中不断修正和更新做法。我们希望这个团队最终把自己的工作干完、自然解散。

在你们公司，Staff 及以上工程师是做什么的？

这很难说得太肯定，因为 Stripe 刚开始引入头衔。谁是 Staff Engineer 并没有公开，但你能感觉到谁是资深工程师——就看谁在做那些最重要、最有影响力的事。

有一些清晰的 Staff Engineer 原型。一种是做深度的技术项目，可能去规划或搭建新的基础设施。在加入支付架构团队之前，我参与搭建了 Sorbet，也就是我们的 Ruby 静态类型检查器。我和另外两位资深工程师花了一年左右从零把它做出来，这是深度、高杠杆技术工作的典型例子。

还有一些 Staff Engineer 花时间去协调跨领域的项目，兼任架构师和项目经理，把组织不同部分拉到一起来解决一个大问题。通常这些问题和我们现有的架构或组织对得不齐，需要很多团队协作。

还有一些 Staff Engineer 和一支或几支团队一起工作，担任团队愿景的守护者。他们明确团队在往哪里走，一到五年后想达到什么状态。他们在整个组织里构建和传播这个愿景，然后推动落地。

你每天的时间是怎么花的？

这在支付架构和 Sorbet 两个角色里很不一样。Sorbet 更像是“低头写代码”的项目。在支付架构里，也还有一些编码，因为我们对自己主张的方案要亲自试一试、演示一下。

我也做了相当多的项目管理工作。比如照看任务跟踪器、主持每日站会、弄清楚谁需要帮助、谁被卡住了。我还花时间做公司和工程组织之间的沟通胶水，特别是和那些对我们做的工具和模式感兴趣的团队交流，给他们建议。

为此，我花时间开各种会讨论技术战略，每周也有相当一部分时间写设计文档，讲我们看到的问题，以及我们认为能解决问题的架构形态。最后，还要向领导层和其他团队解释和推销这些想法，以此定议程，推动他们投入和排优先级。

作为 Staff 及以上工程师，你觉得自己在哪里最有影响力？

最容易追溯影响的肯定是 Sorbet，一个三人团队用两年时间，把 Stripe 从动态类型代码库带到了基本静态类型的代码库，影响了全公司六百名工程师每天在编辑器和开发环境里的体验。

话虽如此，很难说那是否真的是最有影响力的项目。有一种更模糊的说法是，架构战略工作长期看影响会更大。

作为 Staff 及以上工程师，你做过什么在早期职位上做不了或不被允许做的事？

“被允许”这个问题很有意思，可能问法不太对，因为几乎没有什么正式规定说谁能做什么样的事，更多靠非正式的资历判断。

但话说回来，Sorbet 和支付架构团队都是相对雄心勃勃的项目。比如 Sorbet，需要把三位资深工程师从更具体的项目上抽出来。启动它们需要高度的组织尊重和信任，才能获准并得到支持，把团队从现有工作上抽离，转而花一年时间做这些项目。

你会花时间去推动技术、实践、流程或架构变革吗？

这有点随规划周期起伏。优先级最终意味着人员安排，而人员安排是在规划时决定的。

规划季是最紧迫的时期，但我在工程全局层面或多或少一直在想优先级的事。可能是注意到很多工程师都遇到的一个问题，或者看到什么东西在拖慢团队。这是一个持续、反复出现的主题，我一直在想，偶尔会变成紧迫的优先级，我会花时间为新建一个团队或解决一个问题去争取。

你是如何赞助其他工程师的？赞助其他工程师是你工作的重要部分吗？

那不是我花很多时间、用这些词去明确思考的角度，我也想不出明确的例子能说那就是我在做的事。相邻的一件事我做过几次，就是帮我不在其中的团队冷启动。比如，某个团队成立，接手原来属于我容量范围的某个系统，我会以紧密的顾问角色和他们一起工作，给他们背景和建议。

你在 Oracle 收购 Ksplice 之后拿到了 Architect 头衔。当时拿到 Architect 头衔的过程是怎样的？

我不记得 Ksplice 在被收购前有没有头衔。被收购后我在 Oracle 待了一年，头衔是 Architect，我想当时那是他们最高的个人贡献者级别。收购带来的头衔膨胀肯定是有的。如果不是通过收购进去，我不知道自己能不能拿到那个头衔。

Ksplice 被 Oracle 收购、你成为 Architect 之后，你每天做的工作和收购前相比有变化吗？

大体上是同一种风格的工作。变化的是，我花了多得多的时间和 Oracle 内部的 Oracle Linux 组织打交道。我的重点是弄清楚我们的产品如何和他们的集成，也让他们跟上我们的技术，以便他们能用起来。以前我也花时间培训新员工，但那速度慢得多，到了 Oracle 就变成：“我们把你丢进一个 400 人的组织，培训他们现在成了你工作的重要部分。”

在你做到 Staff 的过程中，哪两三个因素最重要？

我走的那条具体路径，很依赖于我进 Stripe 进得非常早。我大概是 30 号左右的员工。但我和别人不太一样的一点是，我努力在整个 Stripe 建立非常广的上下文和感知。当时只有 15 个工程师的时候，这还比较容易，没那么多东西。

但随着公司长大，我花了很多精力去跟上工程上发生的一切：团队之间的互动、扩展中的痛点。我努力保持一种异常全局的视角。这帮我知道哪些问题重要去做，特别是那些隔了一层的重要问题。如果我知道组织的目标是发布某个具体产品，我能看出来难在哪，是因为之前的架构决策，还是因为下游某个系统目前扛不住。

组织变得非常大之后，看清那些隔了一层依赖越来越难，而保持宽广视角和系统级视角对这件事有帮助。这也帮我把团队连接起来，让我成为信息的路由器、想法的路由器，也是提案的发起者。

很多团队容易只盯着自己的一亩三分地，对内部客户如何接入他们缺乏成型的认知。这是因为他们从没在自己支撑的内部客户团队待过。我帮各团队带来其他团队真实使用他们系统的上下文，把他们和组织里应该去收集观点的人连接起来。

组织变大之后，要保持这些上下文很难，但对一个没有从公司还小的时候就开始积累全局上下文的人来说更难。起步早的人，相对后来想反向推导出架构和组织依赖的人，有巨大的竞争优势。

我和 Keavy McMinn 聊的时候，她提到的一个有意思的观点是，有时不带完整历史包袱反而有助于看清事情。你有没有觉得自己的背景反而让前进变难了？

当然有。我会发现自己走进一个团队的谈话，准备给他们讲七年历史：每次有人尝试他们正在做的事都是怎么失败的、为什么没成。得刻意克制一下，问自己：“这些信息对他们到底有没有帮助、有哪里相关？”

有时这些信息确实没用。另一方面，如果有人试过、在暗礁上触礁了，那里可能真有还没解决的硬技术问题。指出暗礁可能有价值，但有胆量再试一次也很有价值，因为已经过去几年，我们已经是一个不一样的组织了。

有个流行说法是，成为 Staff Engineer 需要完成一个“Staff 项目”。你有 Staff 项目吗？如果有，是什么？

我本能地对“Staff 项目”这种说法有点警惕，部分原因是，我见过的 Staff Engineer 原型里，有一类人并不自己主导宏大项目或做大事，而是极其高效的 guru 和路由器，让整个工程组织运转得更好。

离 Staff 项目最近的，大概是我最后一次晋升是靠一个叫“Data Model Stripe Release Plan”的东西。我主导了这个为期六个月的计划，让一堆团队围绕几个项目协作，解决我们数据模型的弱点，推进数据模型，期望是带来变革性的提升。

从某些方面看，它不算一个很好的 Staff 项目例子。一是，我们做了不错的工作，但远没有当初希望的那么变革性，原因混杂，有些在我控制内，有些是问题本身太难，组织也没有资源在六个月里真正修好。

虽然那个项目本身不一定比我其他半年做的工作更好，但它是一个非常可见、高曝光的角色。它以重要的方式提高了我在公司的可见度和地位。

关于做 Staff Engineer，有哪条建议对你有帮助，能分享一下吗？

我学到的一课是专注和优先级的重要性。当你有前面说的那种宽广组织上下文时，这一点尤其重要。任何时刻你都能轻易找出三十件你想做的事。

偶尔你可以把这三十件事每件都往前推一点。这在一段时间内是有效率的，但要小心。如果这些事没人做、而你觉得应该做，你一次只挑一件、全力投入，效果会好得多，而不是同时在很多项目上各推一点。

一个很大的区别是，这些事是不是已经有团队在做了。如果已经有团队在做，只是方向不是你认为有效的，你去找这三十个团队、帮他们解堵，能撬动很大的杠杆。

最后你得说：“有这么多我想做的事，我不可能全做。今年我挑一两件来做，剩下的故意先不管，哪怕我觉得它们是大问题。”

对于刚成为 Staff Engineer 的人，你有什么建议？

一是我非常相信康威定律的首要地位，用它来指导组织的技术架构。

二是和工程领导层建立并经营关系：经理、总监、副总裁。我想这部分可能和组织结构有关，但在 Stripe 那些人通常有很大的隐性权力，因为他们是大家有问题会去问的人。他们对人员安排和优先级也有很大影响。

和他们搞好关系很重要，一来你能用自己的想法影响他们，二来你能理解他们看到的问题。你得知道他们的激励是什么，他们感知到、而你没感知到的问题是什么。和领导层对齐得更好，很多事会容易得多。

另一件对我很有价值的是估算。我发现养成习惯很有价值：看一个系统就能估出来，这东西每秒几个 GB，这个数据要占多少存储。不用估准，估到最接近的数量级通常就够用了。

你考虑过做工程管理吗？如果是，你是如何决定走 Staff 工程师这条路的？

考虑过，但没怎么认真考虑。我对自己比较了解，至少目前，我不会喜欢那份工作。我觉得那些互动会是一种不可持续的时间花法。我偶尔希望自己更感兴趣一点，因为我觉得那是获得很大权力的路，但好在我有足够的自知之明，相信自己不会喜欢、所以也做不好，我想这个判断是对的。

你从哪些资源（书、博客、人等等）学到过东西？

我经常被问这个问题，因为我的通用知识面广得不太寻常，但这些东西从哪来的，我没有好答案。我对计算、软件和架构有着旺盛的好奇心。读的东西很杂，花在软件工程 Twitter 上看链接的时间比健康水平要多。

对我很有价值的还有经营一个资深工程师的私人人脉。我和他们非正式地聊各自在做什么、在想什么。有了私人连接，你能看到大家遇到的问题和考虑的解法中非常不加修饰的一面。

我主要是靠职业上认识的人、乃至上学时认识的人的朋友的朋友关系网搭起来的，不是我事后刻意去找的。

我偶尔读技术论文，但不是主动去读。多数是被别人引用了，或在别的语境里碰到了。我肯定不会系统地跟踪或复习最新发表的东西。但我觉得，对所谓基础文献有个差不多的掌握，真的很有用。

Diana Pojar - Staff Data Engineer at Slack

April, 2020 blog, twitter, linkedin

简单介绍一下你目前的角色：职位是什么，在哪家公司，团队大致做什么工作？

我是 Slack 数据平台团队的 Staff Data Engineer 和技术负责人（Technical Lead）。我 2016 年 2 月加入 Slack，是数据工程团队最早的工程师之一。我深度参与建设了很多工具和基础设施，让数据可以长期用于分析。我加入时，团队刚决定用 Thrift 作为日志格式。如果有人想看数据洞察，得在生产 MySQL 数据库的只读副本上排 cron 任务。

Slack 数据工程团队的使命是让公司里的任何人（数据科学、工程师、产品经理等等）都能拿到数据，去算洞察、支撑业务决策或构建新功能。数据平台团队专注建设大规模可用的服务和框架，赋能所有需要在数据仓库里处理或使用数据的人。我们团队拥有的东西包括：暴露任务、表、列血缘和通用元数据的数据发现服务，事件日志结构，以及消费事件并在数据仓库里暴露成原始表的流水线。

在 Slack，Staff 及以上工程师是做什么的？你每天的时间是怎么花的？

Staff 及以上工程师的角色，很大程度上取决于团队需要什么，也取决于这个工程师本人的强项。就我的经验，Staff 及以上工程师的职责会随时间变化，但主要焦点通常是做对公司有战略价值的项目和工作，同时主导技术设计、拉高团队水平。

我见过的 Staff 及以上工程师分两大类：更偏深度（专家型）或更偏广度（通才型）。第一类更偏深度的人通常是某个领域的专家，大部分时间花在写代码或写技术设计文档上，在自己的专长领域找解法。公司会遇到独特挑战，需要领域专家来为这些极难的问题主导技术解法。比如在 Slack，随着公司长大、系统需要扩展和提性能，有一位 principal 工程师的主要焦点和热情就是发现和修复性能问题。

更偏广度的人通常和领导团队走得更近，影响组织或全公司技术愿景，改进流程和文化。因为广度大，他们更灵活，能按公司优先级和需要，在工程组织的不同领域工作。

我个人目前更喜欢广度，我的时间花法很大程度上取决于团队和组织需要什么。今年到目前为止，大概 50% 时间花在技术领导力上，和大家讨论应该重点投入的大技术方向，50% 花在指导、审代码、写代码、跟故障和修关键问题等等。这个比例每个季度都会变。

作为 Staff 及以上工程师，你觉得自己在哪里最有影响力？作为 Staff 及以上工程师，你做过什么在早期职位上不会去做的事？

我个人感觉很明显的一点是，晋升、头衔变了之后，没和我共事过的人给我的信任和尊重变多了。头衔和你影响组织、公司路线图和优先级的能力强相关——基本上你能进入“有事发生”的那个房间了。

我能参与建设直接决定公司成败的东西。为这样的项目争取立项、参与其中，在早期职位上是做不到的。

我也能拉高更初级的人，让他们的声音被听到。Staff+ 头衔带来别人没有的特权，我尽量用它来帮助周围的团队和同事成长。

你会花时间去推动技术、实践、流程或架构变革吗？你推动过什么？

其实我相当多的时间花在为技术方案、流程、架构或文化变革争取支持上——不只是写代码。我深度参与很多团队的技术设计评审，那些团队要建依赖数据工程工具和服务的系统。除了推动技术项目，我关注的一个领域是改进文化或流程。

一块我很在意、也相信自己在组织里起了重要作用的领域是故障管理和复盘。我参与过公司的韧性（resilience）团队，改进我们的故障复盘流程，但在我自己的数据工程组织里，我深度推动了整体 oncall 期望和结构，也落地了公司的故障响应体系。

你是如何赞助其他工程师的？赞助其他工程师是你工作的重要部分吗？

赞助对我来说其实是重要的一块，因为我专注和共事的很多人建立很好的关系，我坚信我们要互相托举。在打到 Staff Engineer 的路上，在和自己的冒名顶替综合征搏斗的过程中，我有幸遇到赞助过我、对我成长影响巨大的好人。几个共事过、长期做我导师和榜样的人是 Josh Wills、Stan Babourine、Bogdan Gaza 和 Travis Crawford。

指导和帮助周围人成长对我一直很重要，处在 Staff+ 位置，你有一种别人没有的特权和力量，我尽量用它来帮助和拉高周围的人。

你的 Staff Engineer 头衔是在 Slack 拿到的。你是被直接招进来做 Staff Engineer 的吗？如果不是，升到 Staff 的过程是怎样的？

我加入 Slack 时是中级工程师，一年后升到高级（Senior）。做高级工程师时，我有机会做多个组织级、公司级影响的项目，很多直接关系到公司业务指标怎么算，对公司准备上市至关重要。

在高级职位上做了两年后，我的经理告诉我，我已经在按下一级的水准工作，他认为晋升理由很充分，计划提名我。在 Slack，Staff+ 工程晋升要准备晋升材料包，用清晰细节和可衡量的信息说明这个人达到了某一级的水准。主要考察四个方面：技术质量、影响力、协作和执行。我和经理一起写、一起填晋升材料里的必要细节。做 IC 的话，如果可以，我强烈建议和经理一起写这份材料：它应该是团队合作的成果。材料准备好后，由专门的晋升委员会评审，到场的有全公司领导和 Staff+ 工程师。

在你做到 Staff 的过程中，哪两三个因素最重要？你的公司选择、地理位置或教育背景对你的路径有什么影响？

回头看，想想我做初级工程师时的想法和感受，到 Staff Engineer 的主要因素其实是真的相信你能做到，别让冒名顶替综合征赢。

一般来说，我对职业选择一直很有规划，通常每年会花些时间想自己在做什么、想重点成长的领域。我觉得这非常有价值，因为它让我退一步，评估现状，问自己在当前环境里还在不在成长，思考新机会。

所以 2015 年底，当我决定离开 Twitter，得知 Slack 开始组建数据工程团队时，能从零开始设计和建设系统、服务和框架，让我非常兴奋。加入 Slack 一支新成立的团队是一个独特机会，对我做到 Staff Engineer 肯定有帮助。它让我有机会做组织级或公司级影响的项目。比如我做的第一个大项目，把生产 MySQL 数据库约 25% 的负载迁到了数据仓库，给公司省了几百万美元。

另一个影响我到 Staff Engineer 的关键因素是周围的人，我很幸运，团队里有很棒的榜样和导师。我加入 Slack 时是团队第 4 个人，一个非常资深的团队（其他人都是 Senior Staff），这让我更想证明自己、证明我属于这里。在每个项目里积累指导、可见度和技术质量的记录，也帮我走到了 Staff，我没把工作只当工作，而是给每个项目、每个要解的问题都投入了很多热情。

有个流行说法是，成为 Staff Engineer 需要完成一个“Staff 项目”。你有 Staff 项目吗？如果有，是什么？

没有，我没有被分派过“Staff 项目”，Slack 的晋升流程里也没有这个东西。有个职业阶梯描述每一级的通用期望和影响范围，Staff+ 级别的影响范围从组织级开始向公司级扩大。

我总是尽量挑战自己，一直想在组织里推动变革和影响。我觉得对我到 Staff 路上最有影响力的项目，是参与思考并实现公司业务指标（比如 ARR）怎么算的技术设计，保证过程可靠、可扩展，最重要的是可复现。这是 Slack 完成上市准备流程中的关键举措。

关于如何做到 Staff，有哪条建议对你特别有帮助，还记得吗？回头看，有没有更容易到 Staff 的路可以走？

对我特别有帮助的一点是理解：Staff+ 工程师的工作和责任不只是写代码。基本上，把你带到高级的东西，带不到 Staff+。理解这个角色在你们公司、以及在整个行业里的期望很重要，不同公司之间是有差异的。

和经理或更资深的同事一起，找能挑战你、扩大你工作范围的项目。对我特别有帮助的是，我开始投入发展领导力和沟通能力。我也开始换一种方式框定和思考一些事，当我开始感到压力或怀疑自己能力时，那常常是我在成长的信号，说明我误打误撞进了一个成长空间很大的领域。

对于刚成为 Staff Engineer 的人，你有什么建议？

做到 Staff Engineer 带来很大责任，你要一直坚定地为同事发声。做 IC 的话，我觉得执行和动手永远是“容易”的事，难的其实是在组织里推动变革和影响。

我觉得在你做 Staff 工程师的不同阶段，关注点不一样是正常、也应该的。Staff 工程师该做什么，没有唯一干净利落的定义。

你考虑过做工程管理吗？如果是，你是如何决定走 Staff 工程师这条路的？

这其实是我每隔几年就问自己一次的问题。每次自省、思考这个问题的答案，目前的答案都是不想做经理。我太爱写代码了，我坚信要做成功的管理者就不该写代码，而要全身心投入到团队成长上。我太喜欢参与技术决策、琢磨技术方案了，不想放弃这种动手体验，哪怕越资深写代码的时间越少。

不当工程经理不代表你不能影响别人、帮别人成长。做 Staff+ 工程师需要很多核心管理技能，哪怕你不是经理，我发现读管理书非常有帮助。我其实觉得这两个角色虽然是分开的平行轨道，但比大家想的要接近得多。

未来某个时候，这个问题的答案可能变，那也没关系。

你从哪些资源（书、博客、人等等）学到过东西？你在这一行的榜样是谁？

我大量用 Twitter，但基本只看不发，关注了很多技术圈的人。一般关注在会上听过演讲的人，或共事过、觉得内容对我有用的人。举几个，不分先后：Camille Fournier、Lara Hogan、Josh Wills、Vicki Boykis、David Gasca、Julia Grace、Holden Karau、John Allspaw、Charity Majors、Theo Schlossnagle、Jessica Joy Kerr、Sarah Catanzaro、Orange Book。

我也爱看书（每年大概读 50 本），从去年开始，每读完一本都会在 Goodreads 上留个小短评，下面几本对我有用：

• Thanks for the Feedback

• Radical Candor

• The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change

• Leadership and Self-Deception: Getting Out of the Box

• The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever

• First, Break All the Rules: What the World’s Greatest Managers Do Differently

• The Courage To Be Disliked: How to free yourself, change your life and achieve real happiness

• Give and Take: A Revolutionary Approach to Success

• Mistakes Were Made (But Not by Me): Why We Justify Foolish Beliefs, Bad Decisions, and Hurtful Acts

Dan Na - Staff Engineer and Team Lead at Squarespace

March, 2020 blog, twitter, linkedin

请先简单介绍一下你目前的角色：你的头衔、所在的公司，以及你的团队大致做什么样的工作？

我是 Squarespace 的一名 Staff Engineer。Squarespace 是领先的一站式平台，用来打造漂亮的线上形象：网站、域名、网店、营销工具、预约安排等等。我同时担任国际化平台团队的 Team Lead，该团队负责构建和维护贯穿 Squarespace 各产品的国际化基础原语。工程师们用我们拥有和维护的工具与库来打造本地化的产品。

在 Squarespace，Staff 及以上级别的工程师都做什么？你平时的时间是怎么分配的？

我觉得实际上 Staff 及以上工程师的日常职责差别很大，既取决于你的具体角色，也取决于你的职责在组织中的映射方式。

作为 Team Lead，我对团队的产出负全责，既包括业务层面，也包括技术层面。在业务方面，我花大量时间与公司内不同团队和职能的人开会。这些利益相关方包括产品、战略、客户运营等等。我希望尽可能多地收集输入，以验证我们团队的路线图确实反映了公司最重要的优先级。

在技术方面，我经常为团队正在进行的工作评审技术文档，或者站在白板前界定工作范围。我的角色已经演变为少写代码，多问一些关于架构决策和部署策略的追问。颇为讽刺的是，作为 Staff Engineer，我写代码反而比非 Staff 时期少得多。这当然不是这个职级的普遍情况，但在我的团队语境下，关掉 vim、转到更偏战略和 oversight 的角色，是我时间杠杆最高的使用方式。幸运的是，我的团队本身就是一群非常出色的工程师，所以我个人的代码贡献对产出的重要性相对没那么大。

但在 Squarespace，很多 Staff 及以上工程师并不是 Team Lead，他们写大量代码。也有人专注于工程流程和文化。总的来说，我觉得 Staff 及以上工程师的职责高度依赖具体情境。

作为 Staff 及以上工程师，你觉得自己在哪些方面最有影响力？有没有哪件事是你成为 Staff 之后才能做、而在 earlier 职级做不了或不会去做的？

在高于单个项目和团队层面的高阶工程讨论中，我有了一席之地。我们有定期的 Staff 工程会议，讨论跨团队的问题，既有技术性的，也有非技术性的。举个假设的例子，在这种会上，我会很自然地指出我所看到的工程师 onboarding 流程的不足。像工程师 onboarding 这样的话题，很难归属到某个具体团队，但缺乏明确的归属并不意味着它不重要。我认为 Staff 及以上的一个关键职责，就是愿意拥有所有影响（或阻碍）工程产出的事情，包括技术战略和文化。

还有一个日常层面的变化：我的头衔在对话一开始就带来了很高的可信度。我并不是主张一种重头衔轻想法的文化，但如果说它没有帮我推动或解决那些以前更难推动的问题，那是不诚实的。

你会花时间推动技术、实践、流程或架构上的变革吗？能分享一个你影响组织的故事吗？

我不太按类别来想推动这件事。我只是希望我们的工程团队和产品能做到最好，并去解决那些凭经验判断我能帮上忙的问题。举几个例子：

• 我刚加入公司时，正值员工数量 explosive 增长，我注意到除非恰好一起做过项目，否则很难认识其他团队的人。于是我建了一个 Slack 频道——#connect-engineering，用机器人每两周随机把两名工程师配对去喝咖啡。这个频道已经这样配对了两年多。
• 凭个人经验，我知道工程领导角色会有孤独感，和同事聊天时也能听到类似的孤独情绪。于是我和几个同级一起发起了一个非官方的工程管理读书会，向 Team Lead 和 Engineering Manager 开放。现在已经有两个自组织的读书会，每个约 10 人，为新老领导者提供了一个互相支持的安全空间。大家对读书会的反馈非常积极。

公平地说，这两个例子都不需要 Staff 及以上的头衔。但我确实认为，成为一名高效的 Staff 及以上工程师的一部分，就是像关心技术短板一样关心并补上文化短板。

你的 Staff Engineer 头衔是在 Squarespace 拿到的。当时晋升到 Staff 的流程是怎样的？

我入职时的职级是 Senior Software Engineer II（比 Staff 低一级）。幸运的是，我加入了一个正在做高影响力项目的团队，能立刻做出贡献。项目中最难的部分恰好是我熟悉的问题域——横跨多个代码库的大范围改动——我提议、 fall 原型并最终交付了一套我认为更能让公司长期受益的替代架构，那就是我们的前端翻译系统，我还在工程博客上写过：Building a System for Frontend Translations。

我还承担了围绕新翻译系统的沟通和教育工作，在内部会议上介绍架构，并通过邮件同步项目进展。把这一技术贡献，加上一些有意义的文化倡议——其他内部分享、#connect-engineering 等等——我的经理就有了充分的晋升理由，并得到了 Engineering Director 们的认可。

对于刚成为 Staff Engineer 的人，你有什么建议？

我觉得沿着职级阶梯往上走，是一个不断叠加的过程，逼着你去关心越来越多以前不关心的事情。而关心更多事情是很难的。

举个简单的例子：实习生只关心自己三个月内能做出的某个功能的一小部分。团队里的正式工程师关心这个功能的完整生命周期。Team Lead／经理关心组成一个产品的一系列功能。总监关心自己组织所拥有的一系列产品。依此类推。

每往上走一级，就意味着你要在原有所有层级的基础上，再多关心一层抽象。

Staff 工程角色也类似：你正在离开某个具体技术领域的舒适区，进入一个更一般的问题域：工程本身。作为领导者，你正在离开潜在的技术舒适区，进入影响工程产出的那一整套系统性挑战。你要问：那些卡在团队归属缝隙里、拖住工程团队的最大问题是什么？那些从现在起就是你的问题了，外加你原来技术领域的所有问题。

所以 Staff 固然是一个令人向往的头衔，但它也意味着显著增加的责任。不管你想不想，你现在已经是领导者了。

你是如何 sponsor 其他工程师的？sponsor 他人是你工作的重要部分吗？

我认为 sponsorship 是任何资深角色的关键职责，对任何工程组织的成长都至关重要。“sponsorship”的定义可能因人而异，但对我来说，一个具体的方式是提供曝光机会。例如：

• 让资历较浅的同事有机会在更大的会议上拥有并展示自己的工作。
• 联系刚上线了一个很棒功能的团队，请他们为工程博客写一篇文章。
• 鼓励我在 #connect-engineering 咖啡聊天中遇到的、有独特经验或视角的人做一次内部分享。
• 确保会议不被少数爱发言的人主导，主动征求房间里每个人的意见。
• 在人数众多的大 Slack 频道里公开表扬某个做了很棒但不为人知的工作的人。

Lara Hogan 有一篇讲 sponsorship 实践的好文章：What does sponsorship look like?

你考虑过走工程管理路线吗？如果考虑过，你是怎么决定走 Staff 工程师这条路的？

考虑过，现在也还在认真考虑。我知道把两条发展通道想成互斥更省事，但我不这么看。

我既喜欢交付代码，也喜欢带团队，我认为能同时把这两件事做到高水平，对长期的工程成功至关重要。Charity Majors 有一篇关于这个话题的非常好的博文，推荐一读：“The Engineer/Manager Pendulum”。

Charity 认为“管理发展通道 vs 工程发展通道”是个伪二分法，在两种角色之间交替会让你在两边都做得更好。这和我自己的体验一致。我之所以是更好的经理，是因为我知道在一个规划糟糕的项目里做 IC 有多痛苦；我之所以是更好的 IC，是因为我知道何时以及如何在一个进展不顺的项目上拉响警报。

我觉得构建软件最重要的战略能力之一，就是收敛到务实决策的能力。我反复见过的一种失败模式是：产品经理带着业务需求来，工程师带着技术上的反对意见来，双方都不肯让步。只有设身处地理解两边的诉求、驾驭这种张力，才能把事情做成，而培养这种同理心的最好办法，就是两把椅子都坐过。

具体回答这个问题：加入 Squarespace 之前，我上一份工作是 Engineering Manager。我很喜欢做 Engineering Manager，但我想保持技术敏锐度，所以接受了一个 IC 角色。后来我被晋升为 Staff。

有哪些资源（书、博客、人等等）对你帮助很大？你在行业内的榜样是谁？

在工程领导力方面，有两本书特别突出。

我最喜欢的工程领导力书籍一直是 Andrew Grove 的 High Output Management。我每年都会从书架上拿起它，然后不知不觉重读一遍。书里很多想法深刻塑造了我对工作和领导力的看法：“经理的产出以其组织产出来衡量”、“授权不等于弃权”、工程／管理杠杆的概念，等等。就讲工程领导力的实操层面而言，我仍然认为 Grove 这本书是最好的。

在领导力中关于人的那一面，我非常喜欢 Lara Hogan 的书：Resilient Management。我运气好得离谱，2013 年在 Etsy 开始我的纽约科技生涯时，Lara 是我的第一任工程经理。Lara 特别擅长拆解和应对那些最难的部分：情绪和个性的处理、心理安全感的营造、对同事的 sponsor。而且我跟她直接共事了近四年，她完全表里如一，知行合一。

非书籍方面，我订阅并喜欢读 Will Larson 的“Irrational Exuberance”，他经常以非常务实和战略的视角写工程管理。我最近还开始读 Marty Cagan 的“Insights Blog”，主要是因为产品领导力是我不太熟悉、但很想多学的领域。

我的榜样是多年来和我密切共事过的一些出色同事。我在 Etsy 和 Daniel Espeset 做了四年邻居，从他身上学到了数不清的东西：如何把技术执行和文化影响结合起来。我亲眼看 Lara 为工程团队争取并实现薪酬公平，学到了很多。现在我看 Tanya Reilly 这样的同事，随着规模不断增长而建立并演进我们的工程流程，也学到很多。最激励我的，是那些我亲眼见证的人：他们有勇气让公司变得更好，不管一路上遇到多少阻力。

Joy Ebertz - Senior Staff Software Engineer at Split

March, 2020 blog, twitter, linkedin

请先简单介绍一下你目前的角色：你的头衔、所在的公司，以及你的团队大致做什么样的工作？

我是 Split.io 的一名 Senior Staff Software Engineer，在我们叫 COE 的团队做后端。Split 是一个功能开关和实验框架。我们专注于让客户在 CI/CD 中把部署和发布解耦，也支持 A/B 测试。我的团队负责 Web 应用的大部分核心业务逻辑，从数据存储到 API 都归我们。另有一个团队专注实验那一侧，包括其中涉及的所有精细统计，这样我们就能更专注于主平台。

在 Split，Staff 及以上级别的工程师都做什么？你平时的时间是怎么分配的？

我还比较新，所以还在定义自己的角色，这正是资深角色的美妙之处。现在我还在 ramp up，大概会花一半到四分之三的时间做我所在 scrum 团队的具体任务，和这里其他工程师一样。剩下的时间，我参与各种讨论，和其他工程师一起定义长期架构和战略，包括未来的 API 和平台战略、鉴权框架要怎么做、拆分和解耦构建等等。最近我还接手了后端 chapter 的负责人，和另一名工程师共同领导，我们正在一起梳理后端技术愿景、给技术项目排优先级、主导标准讨论。即便如此，我还在博客上持续写作，并去会议上演讲。

作为 Staff 及以上工程师，你觉得自己在哪些方面最有影响力？有没有哪件事是你成为 Staff 之后才能做、而在 earlier 职级做不了或不会去做的？

你在 earlier 职级做不了或不会去做？

当我能推动为某个领域确立技术愿景、并让大家朝着这个愿景前进时，我觉得自己最有影响力。我想大家都会同意，我们希望代码架构比现在更好，或者在某些方面有所改进。但我发现，人们常常只是模糊地觉得“想要更好”，却说不清到底想要什么。我喜欢帮大家就“到底要去哪里”达成共识（其实永远到不了也没关系），并拿出一个大致的路线图。有了这个，我们就都朝着同一个方向走了。清楚地知道想要什么，我们才能和产品一起把它排进优先级。即使最终整个愿景排不上，但知道了方向，我们就可以慢慢做改动，一步步靠近它。比如，我改某个文件时顺手做几处小调整，让它更接近愿景。如果没有这个愿景，这些小调整永远不会发生。光有愿景还不够，还要让每个人都理解并内化它。刚才说的小改动的力量之一就在于，如果每个人在日常写代码时都在做这些小改动，突然之间，所有人都在朝着共同目标努力。

我觉得和更 junior 时相比，最大的差别是 ownership 和责任感。我一直愿意直言反对、推动改进。但更 junior 时，我常常默认某些事是别人的问题。现在，全都是我的问题。我可能因为觉得某件事不如另一件重要而选择不做，也可能把某个问题委派或转交给别人，但我依然把它看作我的问题。我不再默认“会有人来管”。我依然坚信要挑值得打的仗，不可能什么都做——那太多了。但我也不会再假设别人会去做，所以如果一件事值得做，要么我来做，要么由我把它交到合适的人手上。

你会花时间推动技术、实践、流程或架构上的变革吗？你推动过什么？能分享一个你影响组织的故事吗？

会。这些我都推动。在现在的角色里，这是我工作的一大半。虽然作为工程师，我也在一个 scrum 团队里贡献代码，但我觉得我的很多工作是盯着那些我以前见过的坑，或者更大的系统性问题。我的工作是让整个工程团队更高效——无论通过技术、架构还是流程。但我绝不会为了改而改。多年来我推动过不少事，从重写邮件通知系统，到重新思考测试，再到重做几个鉴权框架。

有些事，比如邮件系统改造，我没做什么宏大的事，只是在产品每次想加一个通知时提醒他们：系统已经摇摇欲坠，修好之前真的加不动了。在我坚持 push back 的过程中，身边的工程师也意识到他们也可以 push back。起初产品 mostly 选择不再加通知，但最终他们决定修这个系统。在这个例子里，关键就是把系统风险讲清楚，并在保障系统稳定运行这条自认为正确的路线上坚持住。

另一些事，比如鉴权框架，我是被指派去找方案的。这种情况下，即使大家都想要一个新／更好的方案，你还是要让他们相信你选的是对的。在极其复杂的系统里，人们常常觉得他们发现了你漏掉的东西（也许真漏了），所以尽早且频繁地征求反馈、认真记录并沟通“选了什么、为什么选”，以及“还考虑过什么、为什么没选”，非常重要。人们需要感到被倾听，需要知道你充分考虑了他们的顾虑。他们也想理解你的思考过程，但更重要的是，他们想知道你做了充分调研，而不是随手抓了第一个冒出来的方案。事实上，当我评审别人的设计时，这也是我重点看的——还考虑过什么？

你是如何 sponsor 其他工程师的？sponsor 他人是你工作的重要部分吗？

是的。一旦到了任何资深角色，只要你愿意，这永远是你工作的一部分。因为我在 Split 还比较新，还没太多机会，但我相信很快会变。有时 sponsor 是大事——推荐某人领导项目或带团队，但很多 sponsor 是小事——鼓励一下不太自信的人、在他们平时接触不到的资深人士面前展示他们的成绩、把自己手头的工作分出去一些，让能从中成长的人得到锻炼机会。我觉得可以做一个不 sponsor 人的 senior staff engineer，但做不到一个伟大的 senior staff engineer 还不 sponsor 人。sponsor 是我们带身边人成长的最有力方式之一，而带人成长是我们工作最重要的方面之一。

你的 Staff Engineer 头衔是在 Box 拿到的。当时晋升到 Staff 的流程是怎样的？

在 Box，我们要提交一份晋升材料，对照工程职级标准说明自己已经在按下一级的水准工作。经理也会提交推荐意见，两份材料一起交给晋升委员会，委员会由经理和 IC 组成（至少比申请的级别高一级）。他们评审材料，把经理叫来回答问题，然后给出建议。VP 可以改任何决定（不过据我所知从没发生过）。如果没通过，会给出原因，你可以补充信息申诉，或者下次再申请。申诉有时会通过，所以如果你不同意反馈，值得一试。我喜欢这个流程，因为最了解你成绩的人亲自来写，而且即使经理不同意你也可以申请。但我不喜欢的一点是，它微妙地歧视了不太自信、不擅长自我推销的人，也让经理在启动晋升流程上更不主动（等工程师自己来说想要晋升，而不是主动提）。

你觉得对你晋升到 Staff 最重要的两三个因素是什么？你加入的公司、所在城市或教育背景对你的路径有什么影响？

我觉得 location 影响不大。教育背景在更 junior 找面试时帮助很大，但之后（至少直接层面）帮助小多了。对我来说最重要的三个因素是公司、曝光度和机会。

我觉得在很多公司都能晋升。但我发现，身处一家快速成长的创业公司对我帮助很大。我加入 Box 时工程团队约 30 人，8 年后我离开时已有几百人，但大部分增长发生在前一半。这让我先进入一个足够小的工程环境，能真正了解环境、人和代码。然后因为公司在长大，只要主动、愿意接，就有大量领导机会和技术挑战。机会和我一起长大。同时，身边又有足够的人可以学习（我之前在一家很小的创业公司，只有 2-4 人，根本没有这种条件）。

所谓曝光度，就是找到某种被大家知道的方式。我一直都去办公室上班，我觉得这让曝光稍微容易一点，但 remote 也可能，只是也许更难一点一点。如果你做了很出色的工作却没人知道，晋升时就会被跳过。而且越资深，指导和教别人、帮公司打造技术品牌就越是你工作的一部分——这些本质上都是曝光。曝光可以有很多形式，对我来说有几件事起了作用：我在 Slack 讨论区很活跃，尽可能回答别人的问题；我在内外部写了很多博客、做过一些演讲；我还积极参加女性技术小组，和工程部各处的人建立了联系。

最后是机会。机会的样子也千差万别。对我特别有帮助的是加入了 API 标准委员会。起初我有点犹豫，因为觉得自己不是 API 专家，但读了几本（很短的）REST 书，加上之前做过各种 API，基础已经相当扎实。这个小组的厉害之处在于它横跨工程部很多团队，让我有机会和很多不同的工程师共事（也带来了刚说的曝光度），也有了清晰的东西来证明我能影响他人、为质量据理力争。我们在那里的项目对整个工程部影响广泛，也让我能 holistic 地思考某样东西（这里就是我们的 API）。

有一种流行说法，认为成为 Staff Engineer 需要完成一个“Staff 项目”。你有过 Staff 项目吗？如果有，是什么？

你有过 Staff 项目吗？如果有，是什么？

其实我并没有真正的 Staff 项目。我被晋升时，刚从管理岗转回 IC 大约 6 个月，所以引用了一部分做管理时的领导经历。当时我在技术侧领导 Box 的一个很小的团队，做一个跨公司合作项目，要理解另一家公司开发团队的需求，用最小的构建量满足他们。我还是全工程范围 API 工作组的成员，负责制定和维护 API 标准，手头还有几个 side 项目。我觉得这些合在一起，分别支撑了晋升要求的不同方面，共同证明了我具备他们期望的各方面能力。

有没有哪条关于晋升 Staff 的建议对你特别有帮助？有没有哪条到 Staff 的更容易的路是你本可以走的？

我曾经得到的一条建议是：放大你的优势。我们都有长处和短板，总在谈“改进空间”。很容易觉得，晋升的最好办法是消灭所有短板。但如果真是弱项，可能要花大量时间和精力，收效却微乎其微。显然不能有真正糟糕的短板，但在那之上，更该聚焦放大优势。怎样把擅长的事变成你的超能力？怎样用擅长的事去补不擅长的事？比如，我是个重度内向的人，不喜欢和陌生人寒暄， networking 很差。但我擅长写作，也喜欢写。我用公开博客认识了 otherwise 认识不到的人，也获得了更广的曝光。事实上，博客带给我的远比参加无数 meetup 多得多。

另一条更实操的建议，和 Box 写晋升材料的流程直接相关。有人建议我：第一，在你觉得自己准备好之前很久就写晋升材料。这样能看出哪里有短板，拿到非常具体的改进方向（或者你会惊讶地发现，其实你早就 ready 了）。第二，清楚地知道短板在哪里。晋升委员会读到的材料全都很正面，申请晋升没人会写负面的。所以他们不会找负面的东西，而是找没说的东西：空白点在哪里？哪些地方被回避或一笔带过了？用这个视角看自己的材料——缺了什么？哪里在含糊其辞？把那些补上。最后，讲好你的故事。

我们的晋升材料有带具体问题的模板，但越到高阶，每个人越不一样，我们也不希望大家一样。不要只回答问题，先想清楚你的优势是什么，你的超能力是什么，你的故事是什么，再把故事套进那些问题里。这样整体材料会强得多。

如果我没在管理岗绕那一圈，可能更早到 Staff。但我不后悔，也学到了很多：人们怎么想、组织怎么运转、大项目怎么排优先级。这些在我回到 IC 轨道后一直帮我做到现在，大概也帮我后来升到了 Senior Staff。我觉得没走最直接的路确实可能拖慢了我到 Staff 的速度，但对下一级反而不确定——没有那段经历，我可能在 Staff 上待更久。这么说吧，虽然我走的不是最直的路，但学到的东西长期来看帮了我很多。

对于刚成为 Staff Engineer 的人，你有什么建议？

越资深，工作越不是关于代码。当然，和人 manager 不一样，你依然有很强的技术属性，即使到 principal，大概也还在写一些代码。但越往上，工作越是关于指导和带身边的人成长（以及更广范围的人）、通过打造公司的公开技术品牌来建设团队、发现可以改进或纠正的更大技术趋势、帮团队或公司确立技术愿景、为技术债项目争取资源。越来越是看到更全局的东西，并让别人上船。于是，沟通、领导力和说服力变得比以前更重要。

你考虑过走工程管理路线吗？如果考虑过，你是怎么决定走 Staff 工程师这条路的？

我在 Box 中期做过大约一年半的管理，发现自己很讨厌（更多可以看我博客里那篇）。不过我发现，在大多数公司，管理和 Staff 及以上角色其实重叠很多。两种角色都要指导他人、要领导、要说服人，都要想得更大、更关注长期——无论技术还是人。我不打算回管理岗，但那段管理经历让我学到很多，也确实帮我走到了 Staff 甚至更高。

有哪些资源（书、博客、人等等）对你帮助很大？

你的榜样是谁？

我一般不追随某个具体的人，而是从身边的几乎每个人身上学习、找灵感。我列几个，但说实话，我从无数不同的人身上学到东西，包括很多比我 junior 的人。

我有过一位经理，每次我带着问题找他，他都会把问题抛回来，问我觉得该怎么办。久到我还没找他，就已经能听见他在让我直接给对方反馈、让我自己想办法修好。他真正教会我：虽然作为经理他愿意支持我，但只有靠自己，我才能学到最多、成为最好的自己。他教会我为一切负责。

反过来，我共事过的一位 principal engineer 后来教会我，不必事事都自己扛。学会负责之后，我开始忘了我不是一个人。我当然听过大家谈 delegation，但听过、或者从 sprint 任务层面想过 delegation，和把“争取优先级”、“为团队定技术愿景”、“跟进某个 initiative”委派出去，是另一回事。

还有一位同事，她解决问题的方式和我太不一样，有时会把我逼疯。她会在我觉得显而易见的地方要澄清，在我觉得大家都一致的地方要详细解释。但她也是我共事过的最聪明的工程师之一，和她共事让我明白，不同风格同样可以一样好，而把两种冲突的风格放在一起，常常比我们各自单打独斗产出好得多。

她发现了我以为显而易见的东西里的漏洞，虽然她有时把我逼疯，但我们一起做成了很了不起的事，我也因此变得更好。

Damian Schenkelman - Principal Engineer at Auth0

August, 2020 blog, twitter, linkedin

请先简单介绍一下你目前的角色：你在哪里工作、头衔是什么，你和你的团队大致做什么样的工作。

我是 Auth0 的一名 Principal Engineer，Auth0 是一个 Identity as a Service 平台。我在系统架构组，该组目前有三名 Principal Engineer。我们和不同团队一起做战略项目，也塑造 Auth0 的技术战略、架构决策和规范。

写这篇访谈时，我正和几个身份与访问管理（IAM）团队一起，作为一个大型新产品特性的 tech lead，同时也在和其他团队一起推进可靠性和扩展性方面的 initiative。

在你们公司，“普通”的 Staff 及以上工程师都做什么？你的角色是这样，还是有所不同？

在工程内部，我们按领域组织（目前是身份与访问管理、开发者体验、服务管理和平台）。Auth0 的 Staff Engineer 是能在某个领域内技术领导团队的人。Staff Engineer 通常属于该领域内的单个团队，同时也能积极参与该领域范围内的 initiative。

Principal 是我们职级阶梯的下一级。Principal Engineer 可以在某个具体团队做深，也可以和多个团队合作、 scope 覆盖整个组织。今天我是“广度模式”：既做具体的 initiative，也定义技术战略、平台的技术选型，并领导设计与架构工作组（Design and Architecture，简称 DNA）。

DNA 有 6 名成员（3 名常任 Principal，3 名每 6 个月轮换的 Staff／Senior II）。工作组负责制定决策和规范，把 Auth0 的技术引向某个具体方向（比如避免语言泛滥，这样库只需写一次，大家换团队也容易），也和团队一起对大型项目做技术评审。

我的角色最大的不同在于，我在公司 6 年多了，其中 3 年多是 Director of Engineering，所以我的 scope 是“最广的”。我既和产品团队也和平台团队一起做 initiative，也经常和其他部门合作：和高潜力客户开会、和法务一起过合同措辞、和市场部合作。

你每天的时间是怎么花的？

差别很大：）。典型的一周会有很多会，所以我在试一个新办法：把会集中在周一、周三、周五。周四完全 block 掉，周二只处理紧急事项。因为我们是 remote，所有会都在 Zoom 上开。

开会的日子里，固定的会有：- 1:1：和我的经理（VP of Engineering）、某个团队的经理或 tech lead 同步。这些对话很适合了解近况、知道他们的挑战。如果脱离这些太远，我做事的效率会受影响。- 团队会议：工程领导层会议、设计与架构工作组会议。

也有很多不定期的会。比如：- 我 tech lead 的具体 initiative - 帮几个团队想办法把某件事启动起来 - 同步做设计评审

周四（以及周二能挤出的时间），我用来思考：- 当前的 initiative 进展如何 - 未来（下个季度、明年）我们该做／能做什么 - 写文档、规范、博客 - （不太多）做 POC 和／或写小工具

作为 Staff 及以上工程师，你觉得自己在哪些方面最有影响力？最好讲个具体的故事。

最大的影响来自“人的规模化”，尽可能多地正向影响内部更多人的工作。Scaling Up Excellence 这本书有个好懂的比喻：规模化是地面战，不是空袭一次就完。要花很多时间，要有耐心，要让全公司在目标和路径上对齐，才能走到终点。

作为 Principal Engineer，我会找那些我认为能长期给尽可能多人定方向的机会／缺口。让产品交付组织约 200 人在某个话题上对齐，价值远大于我自己写代码解决某个问题。前者影响更大，也更 scalable。

有没有哪件事是你成为 Staff 及以上工程师之后才能做、而在之前做不了或不会去做的？

成为 Principal 之前，我在 Auth0 是 Director of Engineering。最有意思的是，作为 Principal Engineer，大家对我的反馈没那么 defensive 了，1:1 里也更放得开。我猜部分原因是，作为 Principal Engineer，你不再“代表组织的一部分”。

在这方面，做 IC 感觉好多了。

你会花时间推动技术、实践、流程或架构上的变革吗？你推动过什么？能分享一个你影响组织的故事吗？

快速成长的公司有个常见病：某种“不清晰”。在我们这里，就是对未来 coming 什么非常困惑，导致技术决策又慢又低效。团队不确定该不该用某个技术，因为不知道未来会不会被支持；不确定该不该按某种方式构建某个产品，因为不知道这和长期技术战略是否一致，等等。自然就低效了。

我们相信需要一个长期方向，讲清楚今天遇到技术问题该怎么下手，以及怎么从现状弥合到未来愿景。更具体地说，我们需要一份成文的技术战略，写明长期要成功该做什么、不该做什么。

和很多人聊过之后，我发现大家都接触过不一致的信息和谣言，搞得不敢做决策，比如：“听说公司未来要搞 X”，或者“听说平台团队以后不支持技术 Y 了”。有个谣言特别混乱：说我们要支持某个客户需求及其技术含义。大家一直听说，却从没见过具体计划。我把这些问题写下来，把点连成线，目标是把信息变成知识。我意识到短期长期都要解。

短期： 要先填上更紧急、更短期事项的不确定性坑。团队要做技术决策，等不了一套完整的技术愿景和路线图。而且即使有了长期愿景和决策，具体例外还是要评审。我组建了“设计与架构”（DNA）小组，写了指南和建议，包括“批准可用”的技术选型，引导团队独立做不需要评审的决策，并建立了 RFC 评审流程。

长期： 我列了一组我认为公司必须决策的话题。针对两种受众做了两版材料——管理层和技术侧。给管理层的版本简洁，用非技术类比和解释，给出可执行的方案。给技术侧的版本细得多，有很多技术术语。我用了 nemawashi（一种非正式的铺垫过程：通过找相关人聊天、收集支持和反馈，为某个提议的变更或项目悄悄打基础，等等），先和 VP of Engineering、其他高管、同级和其他资深领导沟通，在正式决策前拿到 buy-in。具体来说，我找大家要想法和意见、拿到支持，这样等我们开会讨论决策时，就不是他们第一次见这些想法。最后我们开会、权衡 trade-off、定了一组决策。所有决策都记在决策日志里，并白纸黑字指定了负责人去推进。

随着亲手写代码的时间变少，你怎么跟上事情真正的运作方式？

有两方面：跟上通用技术，以及跟上 Auth0 内部的事和工程团队的现状。

跟 Auth0 内部的事，我做这些：- 对内：通过 Slack 和跟一些 tech lead、Engineering Manager 的 1:1，耳朵贴着地面。帮我第一手理解他们的挑战，也能发现模式、给出全局解而不是局部解。- 对外：和客户／潜在客户聊，看他们怎么用产品，读提到 Auth0 和身份领域的 tweet 和新闻，等等。

技术方面，我觉得跟得不如自己想的那么紧，但也在尽力：）。行业每个月都有太多重要的新东西，很难全跟上。接受“会多、亲手少，注定跟得不如意”是重要的一步。接受之后，才能去排真正有价值的优先级。

我读书，抽时间做 POC 或读特定主题的博客／论文，也会主动领导某些 initiative，哪怕不常写代码，也要跟上我们是怎么做开发的。

你是如何 sponsor 其他工程师的？sponsor 他人是你工作的重要部分吗？

是的，很多！我是工程领导团队的成员。我们每周开两次会，讨论组织层面的话题。再加上耳朵贴着地面，以及参与中期计划的会，让我能提前知道（有时还能提议）有哪些机会。

每当有机会出现，我通常会提我认为能从中受益的人名，解释为什么觉得他们合适，如果有 perceived 技能短板，还会主动提出 mentor 他们。

你的 Principal Engineer 头衔是在 Auth0 拿到的。你是直接以

Principal Engineer 入职的吗？如果不是，晋升到 Principal 的流程是怎样的？

我的故事比较特别。2014 年 5 月我加入 Auth0，是第五名工程师、大约第十名员工。当时没有头衔、没有职级阶梯，什么都没有。2015 年左右，我开始 mentor 新人、和几个人做 1:1。2015 年底，我一边做自己的 initiative，一边领导别人、帮着招人等等。2015 年末，Auth0 的 CTO 和联合创始人 Matias Woloski 想找人领导工程团队，问我愿不愿意做 Director of Engineering。

我做职业选择有个幸运的原则：最大化学习和啃硬骨头的机会。这是帮我做决定的主要原则。当他把这个机会给我——一个 25 岁、住在阿根廷的年轻人，去领导一家“硅谷”、remote-first、exponential 增长公司的工程组织——我自然说“好”。我从没想过“我要做管理”，只是因为想学、想解难题，就去了。

结果很好。我学到了很多关于建团队、建组织、带人的东西。因为我是早期工程师之一，很多系统是我建的，又喜欢技术讨论，所以在这个角色里我也做了大量技术领导工作，既和产品团队，也和平台／infra 团队。2019 年初，作为 Director of Platform，我开始觉得学得不如以前快，也想要比只做平台更广的 scope。和当时 Auth0 的 VP of Engineering Christian McCarrick 聊了很多次之后，我意识到下一个想挑战的是做 Auth0 的技术领导之一。2019 年 8 月，我转到了 Principal Engineer。

你觉得对你升到 Principal 最重要的两三个因素是什么？你加入的公司、所在城市或教育背景对你的路径有什么影响？

我很喜欢 Seneca 的一句话：“Luck is what happens when preparation meets opportunity.”。到 Principal，既要做对一些事，也要很多运气。我想说说到 Principal 的几个关键因素，以及运气在其中怎么起了作用。第一份工作

在阿根廷，大学期间就开始工作很常见。高中毕业时，我找到了一家很棒的公司 Southworks。那地方两点很关键：

• 公司做的项目用的都是前沿技术，给了我大量锻炼学习能力的机会。
• 公司主要是 remote 给美国的微软做 vendor，不只看重技术，也让我们练了沟通、预期管理和其他人际技能。

我高中一毕业就能做软件，是因为 11 岁时我开始跟妈妈说想“做游戏”，爸妈就找了一所教编程的高中供我上。

运气怎么起的作用： 我本来要去另一家公司，是高中同学跟我说她哥哥在 Southworks，他们在招 junior。他把公司推销得很好，我决定把另一个机会先放一放，看看能不能进 Southworks。

Auth0

我是 Auth0 的早期工程师之一，多年来产品和 infra 的很多部分都做过，所以帮人、给有价值的输入都容易。做过 Director of Engineering 也让我懂了很多业务，成了更高效的贡献者。

运气怎么起的作用： 任何创业公司的成功，在很多时间点都需要大量运气。如果 Auth0 没长成这样，我不会有那些学习机会，也走不到今天。

这点尤其重要，因为我住在阿根廷，那里的软件行业比美国小得多，大多数公司没有双通道。

团队运动

我小时候和青少年时期打篮球，很早就明白：得很少分但赢，比狂砍分但输，爽多了。这两点塑造了我的工作方式：- 经常帮队友，看我们怎么作为团队赢

• 去学、去做那些“补缺口”需要的事，练出了领导力和人际技能，对后来长大很有用

有一种流行说法，认为成为 Staff Engineer 需要完成一个“Staff 项目”。你有过 Staff 项目吗？如果有，是什么？

没有。因为我在 Auth0 的成长路径，我基本“跳过了那一段”。作为创业公司的 Director，我有机会技术领导很多又大又关键的 initiative，但没有某个明确的“staff／principal 项目”。

真要说，最接近“Staff 项目”的，是 2017 和 2018 年我领导的提升 Auth0 可靠性和扩展性的工作，带了一些项目，为一部分关键客户提供更高的 SLA。

对于刚成为 Staff Engineer 的人，你有什么建议？

Staff 在不同地方意思不同，所以第一条建议是：尽可能多和人聊，把期望对齐清楚。

接下来要说的是耐心。他们能走到今天，多半是因为技术强、出结果，但越往上，工作的结果要越久才显现。你可能同时做更多事，影响的时间 horizon 更长。你现在影响更多不同角色的人，有时他们要更久才能“看清”你一眼就看清的东西。耐心、逐步影响人、教别人，长期看是值得的。

最后：习惯写下来，并反复讲给别人听。把想法、计划、 reasoning 和标准写下来，是规模化自己的办法。写下来，任何人以后都能看到、能引用，比“只口头说说”好得多：更 scalable，也更不容易被误解。重复也必要，光发布文档没用，还要把想法分享给人。开 AMA、brown bag 和其他分享会，讲你的想法，很有价值。

你考虑过走工程管理路线吗？如果考虑过，你是怎么决定走 Staff 工程师这条路的？

没刻意计划，但 Director 的机会来了我就接了。不过我觉得有个钟摆，可以在两条路之间来回走。难易取决于公司，以及 Staff／Principal 的技能有多专，但我觉得可能。

现在我很想继续打磨技术能力和领导能力，因为我觉得那会带来最有价值的学习和挑战。

有哪些资源（书、博客、人等等）对你帮助很大？你的榜样是谁？

我会在 Twitter 上关注那些我觉得在做有意思的事、值得我学的人。有太多人在做有意思的事，有太多可学的！想到几个名字：- Aphyr 的 Jepsen 和分布式系统内容很棒。- Tanya Reilly 有些很好的内容，比如 Squarespace 的 RFC 流程和 Being Glue。- David Fowler 分享了很多 .NET Framework 和 ASP.NET 内部原理的内容，很有意思。还有这个他讲自己怎么成为 ASP.NET Architect 的视频。- 在 Auth0，我和 Jon Allie 共事，他是出色的工程师和人。追求简单，能把东西讲得很清楚，明明懂那么多却极其谦逊。

关于资深 IC 的书或类似内容，我没找到太多（也许值得写一本）。最近读的 Fundamentals of Software Architecture 把这个角色讲得相当好，也讲了其中的 nuance 和灰色地带。

一些管理书能帮你建立组织 awareness，也帮你做 mentoring、1:1、招聘，这些都是 Staff 及以上工程师常帮的忙。Andrew Grove 在 High Output Management 里把“know-how manager”定义为“可能不直接管任何人，但即使没有正式组织权力也能影响他人工作的人”，听起来很像 Staff 及以上工程师。强烈推荐 Managing Humans，故事好读有趣，也能帮你和经理共情，这对 Staff 及以上工程师很重要。The 7 habits of highly effective people 也有很多对 Staff 及以上工程师有用的课。

Accelerate 也很棒，它把公司成功和工程实践、产出连起来，对影响利益相关方很有用，尤其到高管层。

Dmitry Petrashko - Tech Advisor to the Head of Infra at Stripe

May, 2020 presentations, twitter, linkedin

简单介绍一下你目前的角色：你在哪里工作、职称是什么，你和你的团队大致做什么工作？ 我是一名 Staff Engineer，同时担任 Stripe 基础设施负责人（Head of Infrastructure）的技术顾问（Technical Advisor）。

我目前所在的团队就是整个 Stripe Infrastructure，负责 Stripe 基础的设施服务——计算、网络、存储、数据库、数据工程、性能与效率、可观测性服务以及开发者工具。我们的工作是让 Stripe 的工程师能够专注于产品。

我“成长”起来的团队是 Developer Productivity，负责构建 Stripe 产品开发过程中使用的流程、工具和核心库，包括测试框架、linter、类型检查器、构建工具、用于渐进式发布的库等等。我从这个团队（当时还是一个单一团队）的一名工程师做起，最终成为了这个方向的 Pillar Tech Lead。

在你们公司，“常规”的 Staff-plus Engineer 是做什么的？你的角色是这样吗，还是有所不同？

在 Stripe，Staff Engineer 并不是一个具体岗位，而是一个级别，对应着对影响力、沟通能力、人员领导力和项目领导力的期望。Staff Engineer 会担任不同的角色，我目前的角色是技术顾问（Technical Advisor，简称 TA）。在这个角色里，我与 Foundation 负责人 Rahul Patil 紧密合作，目标是提前研究关键议题、深入解决关键问题（设计、代码、分析）、头脑风暴技术层面的行动项、协助紧急的技术跟进、埋点收集数据，等等。这个角色的设计初衷是扩展 Rahul 的带宽和战略思考能力，但并不直接做技术决策。

作为通往这个角色的过渡，我之前还担任过 Pillar Tech Lead。随着 PTL 越来越多，这个角色的期望也定义得更清楚了：* PTL 帮助各自团队做出技术决策，让这些决策彼此之间、以及与其他 Stripe 团队的技术决策之间能够很好地协同。Stripe 的大多数技术决策由团队自己做，但一位经验丰富的 PTL 可以帮助微调这些决策，以获得更好的结果。PTL 还会在团队之间无法就技术问题达成一致时担任仲裁者。* PTL 引导 Stripe 的技术方向，参与判断哪些是最重要的问题，并设定解决这些问题的高层次技术路线。* PTL 通过在其他 Pillar Tech Lead 面前代表自己所在的组织、并把别处做出的技术决策带回自己合作的团队来促进对齐，从而帮助自己所在的组织。* PTL 为其他工程师创造承担高影响力项目的机会，并帮助他们取得成功。

在 PTL 这个角色上，我过去与 Developer Productivity 负责人以及该方向下各团队的经理紧密合作。我们交换上下文，朝着一个商定好的目标努力。

PTL 和 TA 这两个角色相似之处在于，都是与工程经理（EM）合作，把我们对用户需求和手头工具的洞察带进来，而 EM 则对 Stripe 范围内的非技术约束（比如资源约束）有更好的理解。

你每天的时间是怎么安排的？

在最理想的一周里，我会在周一、周三和周五开会或参加工作组：要么是 1:1，要么是团队会议，一起协作制定短期和长期的计划与战略。在我理想的一周里，周二和周四会独自写代码。而现实中，根据团队当时的需要，我可能会开更多的会，或者有更多写代码的时间。如果我要启动一个新项目，我通常会先安排一个会议较少的一周：专注于写项目简报、思考设计、可交付成果和里程碑，以及安全性和可靠性的影响；接下来的一周则是在公司内部分享这个提案，并处理收到的反馈。

虽然有时候看起来很难找到写代码的时间，但我认为写代码很重要，因为它让我与工程一线保持紧密连接，成为 PTL 所需要的、在业务需求与优先级和工程约束之间搭桥的人。

作为 Staff-plus Engineer，你觉得自己在哪里最有影响力？

Staff Engineer，尤其是 Pillar Tech Lead，经常会帮助为新项目定方向。当我能帮助改进一个出发点很好、解决的是真实需求，但起草团队要么缺乏经验、要么缺乏上下文、因而写不出好的计划来抓住机会的提案时，我觉得自己特别有影响力。在这种情况下，一份结构良好的计划可以大幅缩小范围，同时拿到大部分价值，从而更快地证明影响力。或者反过来，发现手头的提案其实能覆盖比团队最初设想的更多的用例，把项目重新聚焦到一个团队之前不知道、但能带来更大业务影响的用例上：在这两种情况下，我都是通过赋能其他工程师来产生影响力的。

你作为 Staff-plus Engineer 做过的事中，有没有什么是你在这个头衔之前做不到、或者不会去做的？

没有，Stripe 有意让 Staff 这个徽章不成为新机会的门槛，我认为我们在这方面做得很好。PTL 这个角色也是如此。我们挑选担任 PTL 的工程师，都是善于代表他人意见的人。甚至在我成为 PTL 之前，我就觉得当时的 PTL Paul Tarjan 总能确保我的观点被呈现出来。

你会花时间去推动技术、实践、流程或架构上的变革吗？你曾经推动过什么？能讲一个你在组织中施加影响的故事吗？

能分享一个你在组织中施加影响的故事吗？

我是被专门招进来把类型检查引入 Stripe 的 Ruby 中的。这包括和 Nelson、Paul 一起，架构并实现类型检查器 Sorbet，以及培育围绕它的使用文化。

在 Sorbet 早期，我们根据 Stripe 最需要的用例，非常谨慎地选择要加哪些特性。我认为我们在用类型系统覆盖 Stripe 大多数用例的同时，还保持了简单性：很容易滑向一个推崇复杂性和精英主义的类型系统和文化，我很高兴我们的努力避免了从无类型走向另一个极端。

今天，作为技术顾问，我推动的是那些能带来超额影响的变革，最常见的是在 Stripe 的可靠性、可扩展性、安全性和生产力方面。可能是改变数据的分片和存储方式，也可能是改变我们做变更管理的方式。不过与 Sorbet 时期最大的不同是，我不会在一个项目上待好几年，而是在组织接受之后、有了一份里程碑清晰、风险可控的计划之后，就会尽快找到并培养一个接手的人。之后我会与推动这些重要项目的人保持频繁的 check-in，目标是帮助降低风险、发现更快交付的机会，因此我的参与只在项目早期比较显眼。

当你花在动手开发上的时间越来越少，你如何跟上事情的真实运作方式？

当我是 PTL 的时候，我每周至少有几天在写代码。我和团队里的其他工程师紧密合作，我们不断互相学习。

作为技术顾问，我写代码的时间不如做 PTL 时那么多。我大多只在 code-yellow 的情况下写代码。但这个角色的成功依赖于有好的洞察和深厚的工程理解。为此，我会和我们的内部客户交流，紧跟我所支持的团队的系统设计，尤其是故障阈值和故障模式。

在这个角色里，理解客户需求非常重要。一个有用的资源是 Stripe 全公司的工程师调研，由 Developer Productivity 组织，我们想从中找到是什么在阻碍工程师的生产力：可能是某个工具自上次调研以来变慢了，也可能是某个用例的用户群变大了但没有得到很好的支持。虽然这个调研很少发现我们完全不知道的事情，但它是做相对优先级排序的好工具：我们可以比较有多少人在抱怨同一件事，并据此排优先级。

另外，在 Covid-19 封锁之前，我习惯在 Stripe 随机找桌子一起吃晚饭。我会问三个问题：

• 你在做什么？
• 什么让你觉得难？
• 基础设施团队能帮上什么？

这在两个方面成了很好的工具：1）让我连接到我的用户，发现他们的需求；2）帮助缓解那些暂时还没被支持到的团队的不满，展开类似这样的讨论：“是的，我同意我们可以通过做 X 来帮你，现在，让我们一起看看我们应该停掉什么来腾出地方”，这时对方经常会发现，虽然他们希望我们解决他们的痛点，但并不希望以牺牲我们当前项目的优先级为代价。

在我从 PTL 角色过渡出来的时候，我创建了一个现在叫 DevProd Assembly 的小组，把开发者生产力团队的负责人聚在一起。这个小组的每个成员都要与 2-3 个产品团队建立高度信任的关系，每月访谈他们，并与其他 Assembly 成员汇总反馈。

你是如何赞助（sponsor）其他工程师的？赞助他人是你工作的重要部分吗？

虽然赞助其他工程师并不是 Staff Engineer 的硬性要求，但我认为它有助于成为一名成功的 Staff Engineer，因为它能通过为他人创造机会并帮助他们成功，来放大你的影响力。

是的，有多个项目是我帮助界定了范围、启动并降低了风险，同时还培养了一个人，在我转去做下一件事时接手。

指导（mentorship）和赞助（sponsorship）是有区别的，我两者都做。指导是帮助他人成长并交付影响力。赞助是帮助一个人进入一个能展示自己交付更大影响力能力的位置上。在和团队合作时，我会尽量让大家去做一些超出舒适区一点的项目，这就是在赞助他们，然后我再去指导他们，帮助项目成功。

你是在现在的公司第一次拿到 Staff Engineer 头衔的。你是直接以 Staff Engineer 被招进来的吗？如果不是，晋升到 Staff 的过程是怎样的？

我不是以 Staff Engineer 被招进来的。在 Stripe，我经历了两次升级才到 Staff 级别。这两次升级很相似：都是在员工已经以更高一级的水平工作了相当长一段时间之后，Stripe 才做升级，调整期望，要求他们今后继续以那个级别的水准工作。

对你达到 Staff 最重要的两三个因素是什么？

按重要性从高到低排列：

1. 聚焦对业务和公司的影响。

2. 善于协作：加入会议和工作组时要帮助达成更好的结果。

3. 技术功底。

对我个人来说，在拿到 Staff Engineer 之前需要补上的是第二项。我当时已经在交付影响力，也被认为是寻求技术建议可以去找的人。我需要提高的是沟通和协作能力，这样才能建设性地帮助我团队之外的人，他们可能是第一次见到我，尽管他们的项目出发点很好，但计划未必是最好的交付路径。

对我有帮助的一个技巧是，在会议之后立刻在私聊里要反馈，尤其是在那些开得不太完美的会之后。这让我学到了自己做了什么可能让对方在会上感到不自在，而且在少数情况下，真诚地问“怎样才能做得更好”还帮助挽回了一个已经开砸了的会的成果。

你工作过的地方和你的教育背景如何影响了你的道路？

公司： 我很感激 Stripe 有这么多产生影响力的机会，这确实帮了我很多。

教育： 我碰巧读了一个非常实用的博士，研究如何构建快速且可维护的编译器，几乎完全转化成了适用于我工作的知识：帮助一家公司扩展工程规模。虽然它对我帮助很大，但我觉得这里面运气成分很大：我恰好在对的时间加入了对的实验室（当 Scala 3 诞生的条件成熟时，我在实验室已经待了足够久，不至于太“嫩”，但又还早到没有完全定死自己的研究方向）。我不确定是否会建议别人去读博：从实用的角度看，我的很多朋友在 Stripe、Google、Facebook 做 4 年以上系统，和读完一个博士学到的东西一样多。如果你想学数据库是怎么工作的——你不只可以在研究数据库的实验室学到，在那些对数据库需求最高、并且有团队在持续改进它们的公司里同样可以学到。不过话说回来，博士对我来说是一个改变所在地的好工具。

地点： 我为了加入 Stripe 从瑞士来到美国。为了加入欧洲最好的计算机科学博士项目之一，我从俄罗斯来到瑞士。为了进入前苏联最好的大学之一，我从乌克兰来到俄罗斯。每一次搬迁，我觉得我都是在做地理套利：从一个我是佼佼者的地方，逃到一个我只是平均水平的地方。其中几次，我觉得自己并不是最优候选人。通过加入那里的人、向他们学习，我成长了很多。美国和欧洲哪个对职业发展更好，我很难说，但从我的经验来看，换地方确实让我成长了很多。

有一种流行的说法，成为 Staff Engineer 需要完成一个“Staff 项目”。你有这样的 Staff 项目吗？如果有，是什么？

事后回想起来，这个问题对我来说很难回答。因为：据我所知，Sorbet 足够大，可以算我的 Staff 项目，但当时有 Nelson 和 Paul 在，我们三个人协作非常紧密、速度非常快，很难把项目的成功归功于某个人，而不是整个团队。

在进入这个项目后的第一次绩效评估前后，我们三个人都收到反馈，说我们应该更好地讲清楚哪些影响是哪个人带来的。我倒是很想说，下一次绩效评估时不再遇到同样的问题是因为我们有意采取了行动，但我觉得并不是：我觉得只是项目自然进入了一个大得多的阶段，我们不再需要“在同样的 10 个文件里快速迭代”，自然就有了更清晰、更大的 ownership 划分。

我成了“内部架构和子类型”的人，也是“和用户聊”的人，而 Paul 成了“改代码让类型检查器满意”的人。Nelson 对 Stripe 其他系统的运作明显更了解，因此帮助把这个工具和它们集成。这些都正好发挥了我们的长处：我之前有类型检查器的经验（我的博士就是研究这个的），Paul 非常擅长程序化的 codemod，Nelson 不仅对系统整体非常懂，而且在 Stripe 待得够久、加入得够早，几乎了解 Stripe 的每一个系统。到了项目的这个阶段（稳定和推广），这些都成了巨大的领域，因此让每个人成为一个领域的直接负责人（DRI）、其他人偶尔帮忙，就变得容易多了。

在 Sorbet 之后，我在很短的时间里（6 个月）又交付了几个有影响力的项目，我认为这些最终敲定了我拿到 Staff Engineer 级别，但如果只选一个，我还是会选 Sorbet，因为这个项目的范围足够大：技术和文化两方面都是。

关于如何达到 Staff，有没有哪条建议对你特别有帮助？

1. 在学术界与 Martin Odersky 和 Ondrej Lhotak 共事，帮助我理解了复杂系统是如何协同工作的，以及如何把这些讲清楚。

2. Brian Goetz 让我理解了，一个简单、又能经受住大规模采用考验的设计背后，有多少工作量。

3. Paul Tarjan 让我看到了调整沟通风格、让所有相关方都能建设性收场的重要性。

对于刚刚成为 Staff

Engineer 的人，你有什么建议？

至少在 Stripe，Staff Engineer 做的领域各不相同。一定要和你的汇报链对齐：你应该达成什么样的影响，以及在通往这个影响的路上，哪些事情是可以妥协的。清楚地沟通你在做什么妥协，以及为什么。

你考虑过走工程管理路线吗？如果是，你是如何决定走 Staff Engineer 这条路的？

过去每次考虑这个问题，我都是问自己和周围的人：“这会不会带来更大的影响”。到目前为止，每次的答案似乎都是“不会”。

不过，我发现向优秀的管理者学习一些管理技能，即使在 IC 角色里也有巨大的好处（对我来说是 James Iry、Scott MacVicar、Will Larson、Christian Anderson 和 Shane O’Sullivan）。

Stephen Wan - Staff Engineer at Samsara

September, 2020 github, twitter, linkedin

简单介绍一下你目前的角色：你在哪里工作、职称是什么，你和你的团队大致做什么工作。

我是 Samsara 的一名 Staff Engineer。

四年前我加入这家公司，当时公司成立一年左右，有五十多名员工。现在，公司已经有一千多人，工程团队分布在 Bay Area、Atlanta 和 London。

我刚加入时，还没有真正成型的团队，十来个工程师想到什么做什么。九个月后，人数翻倍，我们围绕当时几个核心产品组成了产品团队。我短暂地带过一个产品团队，之后转到刚刚起步的基础设施组，组建了前端基础设施团队。这些年里，我逐渐往技术栈下层走，也在后端和可观测性系统上待过一段时间。

今天，我在 Infrastructure & Platform（I&P）组，大部分时间和 Developer Experience 团队在一起，这个团队负责构建工具，让全栈开发工作流保持高效。

在你们公司，“常规”的 Staff-plus Engineer 是做什么的？你的角色是这样吗，还是有所不同？

我们的大多数 Staff+ Engineer 都在专门的领域，要么是 web 基础设施，要么是设备固件。这么算我属于多数派，但 Staff Engineer 们做的工作差别很大，所以很难说自己在这个角色里算“常规”。

从 IC 和管理双通道的对应关系看，Staff 被认为相当于总监级别。Staff Engineer 可以参与很多通常只对管理者开放的流程。我们会被邀请参加跨工程的总监会议，至少在 I&P，我们会参与路线图规划和管理同步会。最近，我们还让 Staff Engineer 参与了一些晋升校准会。

这种权限让你感觉一只脚踩在两边。这个角色和 Senior 级别很不一样，不再是纯粹的“个人”代码贡献角色，但和更偏重人的管理通道也很不一样。

对照 Will 的 Staff 原型，我觉得我的角色介于 Solver 和 Tech Lead 之间。对我来说，乐趣之一就是每 6-12 个月换一个角色，扎进系统的不同部分，和不同的人一起工作。

你每天的时间是怎么安排的？

每天差别挺大。现在，我尽量把周二和周四定为开会日，这样一周剩下的时间就有整块的专注时间。

开会日通常包括和紧密合作的人的 1:1，以及各种例会。我也会花一些时间和人结对，看代码、看设计评审，或者做更开放的设计讨论。

其他日子的专注时间花在调查研究上，既看当前的问题，也为未来的项目铺路。哪些系统需要投入？我们的团队执行得怎么样？我们的小组应该为哪些即将到来的变化做准备？这些时间花在更广义的 shaping 上。

回头看，这种专注和我到 Staff 之前很不一样。不再是在单个项目或团队里做个人执行，而是视角更广、周期更长。值得一提的是，我很难保证有连续超过一天的时间写代码。在排工程路线图人力时，我不算在内，不过我会尽量每周留出至少一天写点代码。

在更微观的层面，我维护着一份叫“Stephen 在做什么？”的文档，精确到小时来驱动我的工作。里面有一个主要的部分写本周的事，还有一些给未来几周的提醒。每周一，我重新开始——上周没做完的就删掉，很少留到下周。

这种默认删除的意图帮我保持专注，不会觉得自己被扯得太散。很长一段时间，我试过维护一个 back-burner 清单，但 mostly 只是让我更焦虑。大部分 back-burner 事项一个月后反正也是被删掉、做不完。

你会花时间去推动技术、实践、流程或架构上的变革吗？你曾经推动过什么？能分享一个你在组织中施加影响的故事吗？

会。具体推动的技术或方法每个季度都不一样，但 advocacy 最后成了我花时间的大头。往小了说，我帮忙写过文化文档，讲我们怎么做设计文档、怎么做代码评审、代码 ownership 规则是什么。往大了说，我花了几个季度帮产品团队落地 Service Level Objectives（SLOs）。

当时，我们已经有了一套比较成熟的功能和客户群，但对 uptime 的度量还很原始。出了故障，很难讲清楚对客户的影响，因为缺少区分和定义来沟通（“百分之多少的客户受影响？是读和写都受影响吗？这是故障还是已知 bug？”），尽管我们有 plenty 的指标和 dashboard 可以看。

图 5：Stephen 在做什么？

引入 SLO 肯定需要新的工程工作，但我猜我在这个项目上的大部分时间是花在写文档、找人聊、给团队做咨询式支持上。我们希望大家能端到端理解可靠性目标：如何定义目标、如何在故障中谈论它、如何在系统中度量它、如何长期跟踪它、不健康时如何响应。要深入到这个程度，需要大量的宣讲和打磨才能真正落地。

和我们大多数大的“迁移”一样，让很多团队用上 SLO 是迭代推进的。我们先找一个团队小范围试点、重度支持，再把面向全组织的宣讲铺开。我觉得我在其中一个关键作用是，既能和工程师在很具体的“这东西怎么用”的层面聊新工具，也能说服总监级别的人，让他们觉得花力气用 SLO 的语言说话是值得的。

这个模式在我做 Staff Engineer 的大多数项目里都成立。我的角色最后落在了在不同组之间牵线搭桥、把一个变革卖到全组织。

当你花在动手开发上的时间越来越少，你如何跟上事情的真实运作方式？

我每周会留一些时间写代码、做代码评审，哪怕只是提一个小的 bug fix。我会尽量参加其他 IC 日常都在参加的仪式——代码评审、翻文档、处理故障，等等。

当然，光这些不足以让我在脑子里保持高保真的模型——横跨太多团队、太多事情，根本跟不过来。剩下的就是有意去找反馈，听别人的一手经验。

我也试着帮组织把反馈环 baked 进去。我帮我们启动了半年度的开发团队调研，混合了技术系统和工程文化两类问题。这些调研的回复对从一线感知组织的情绪非常有帮助。

你是如何赞助（sponsor）其他工程师的？赞助他人是你工作的重要部分吗？

是的。我有意去交出自己的状态，往后退一步，让别人建立起专长。

在组织层面，我觉得有结构性赞助他人的办法，把其他工程师推到领域专家的位置上。举个例子，去年年底我参与引入了一套新的分布式追踪系统。我们的核心 web 应用由多个不同的后端系统支撑，多年下来，这些系统之间的数据流越来越难理解，页面性能也受到了影响。我们需要一个工具把自己挖出来。

我之前做过早期性能工具的迭代，相关知识基本都在我脑子里。在新项目里，我的一个明确目标是带更多人跟上来。只在系统设计里打好技术基础是不够的：项目上的队友必须在未来几年里真正拥有这个领域的专长。

具体来说，就是我把更多时间花在和未来的 tracing owner 讨论和结对上，而更少直接贡献代码或设计。当我们和一个产品团队做 beta 测试时，我会推另一个工程师去写销售 pitch、去想 demo、去帮那个团队 onboard。

今天，这套追踪系统被广泛使用，完全由 SRE 和 Observability 组维护。当时和我一起工作的那些人，现在成了性能问题的 go-to 团队。

在更个人的层面，总有一些小地方可以把别人往聚光灯下推一推。赞助机会可以很小。尤其当我和资历较浅的人合作时，我可能会建议他们去啃新系统设计里更未知的一块，或者起草一份新的文档，或者在组内大会上 demo 我们的成果。

这一小推可能就是某个人启动所需要的全部，有时它还会自然地延伸出指导和结对的机会。有些事（比如第一次搭 slide deck）做过几次之前会觉得无从下手，在那里，赞助和指导两边都很有影响力。

这里也有张力要拿捏好。我们想把人培养到能拥有更多、能做系统决策的位置，又想让这些决策的做事方式和努力方向是对齐的。这很花功夫——既不 gatekeep，又要拿到满意的结果，需要大量的注意力。

你是在现在的公司第一次拿到 Staff Engineer 头衔的。你是直接以 Staff Engineer 被招进来的吗？如果不是，晋升到 Staff 的过程是怎样的？

我加入公司时，我们还没有 IC 头衔。2019 年初引入级别体系时，我被定到了 Staff。

我觉得我占了一个很大的便宜：我是早期工程师。这段历史给了我大量关于过去决策的上下文——知道我们已经踩过哪些坑，帮助新项目落到一个好的位置。

在每个成长阶段，我们都会加更多的人和管理层级，组织运作方式都会经历一个“重新学习”期。慢慢地，团队的 scope 会收窄，只能看到拼图里更小的一块。而我脑子里装着大部分工程历史，不仅帮我连起这些分裂的部分，也让我和那些不再直接合作的组织部分保持了人脉起点。这种广度自然让我更容易看清什么对组织最有影响力。

对你达到 Staff 最重要的两三个因素是什么？你们公司、你的地点或教育背景如何影响了你的道路？

我的背景不太传统——我学的是电子工程而不是计算机，还没拿到学位就退学了。这个缺口逼着我在经验上更多自学，但也给我留下了很重的冒充者综合征。职业生涯早期，我因为没有对的学历挂掉过很多软件面试。早期那种冒充感让我特别想多学，生怕自己不知道的东西露怯。

退学前那个暑假，我在 Stripe 实习。我记得，可能是带着玫瑰色眼镜，觉得那里的工程文化特别让我兴奋：超级聚焦客户体验，并且对用技术实现它充满热情。那段经历对我想要的工作氛围影响很大。

后来离开学校，我全职加入了一家小 startup，其实我完全不知道自己在干什么。那家公司在我待的时候业务有点摇摆，但幸运的是我和几位 thoughtful 的资深工程师走得很近，他们很有指导人的热情。在那里我有很大的自由去学我想学的东西，这对我很好，对公司大概不太好。

再补充一点背景，高中时我在计算机夏令营打过两个暑假的工，教小学生基本的计算机素养。那种教学心态确实让我对人们如何理解和使用计算机系统更有同理心。

到我加入 Samsara 时，这些经历让我清楚地知道我想要的工作感觉是什么样的——作为早期员工，我有影响力去塑造它。

拼图的最后一块是我在 Samsara 的头三年。那段时间我非常幸运，能和那么多 thoughtful 的合作者一起工作。今天我的很多工作习惯、心智模型和举止，都能直接追溯到那些人。没有他们的影响，我不敢想象自己能走到今天这一步。

有一种流行的说法，成为 Staff Engineer 需要完成一个“Staff 项目”。你有这样的 Staff 项目吗？如果有，是什么？

没有，我没有被指定的 Staff 项目。回头看，这些年有些项目加起来也许相当于一个大的 Staff 项目，但在定级时我们没有明确谈过这个。

作为一个概念，我对这种单点聚焦的大项目持怀疑态度，担心它们会把人推向 hero 心态，而我们真正想奖励的是能建设组织、而不是扛着组织走的工程师。比起一次大的交付，我更想看到持续的迭代改进和稳定的执行：深思熟虑的工程的 track record。

我很高兴 Samsara 似乎也认同这一点。我们的职业发展文档谈的更多是持续稳定的执行，而不是单个大项目。

对于刚刚成为 Staff Engineer 的人，你有什么建议？

想到两点。

多说话，慢慢习惯。我觉得 Senior 到 Staff 最大的变化之一是对人的聚焦：调和互相竞争的优先级、澄清误会、让大家对齐到同一页。虽然 Staff Engineer 通常没有直接下属，但他们工作在技术和人组成的系统里：最大的影响力来自同时影响两者。

尽量别把自己耗干。刚转到 Staff 时，很容易滑进一种心态，觉得什么都是你的责任，要把注意力切成很多片去管一切。花了一段时间我才意识到，这个角色不是要我加倍努力去掺和每件事，而是要通过组织里的其他人去推动变化。信任大家，指出问题，然后相信他们能搞定。

你考虑过走工程管理路线吗？如果是，你是如何决定走 Staff Engineer 这条路的？

2016 年，我记得和经理第一次聊过走 IC 还是管理路线。当时，我觉得自己的职业生涯还早，想继续在核心技术经验上加码。

之后每年我都会重新评估一次，每次都得出同样的结论——我在技术上还没玩够，不想收手。那段时间，我做的大部分工作都是围绕给公司的人构建开发体验。这些努力最后把我推向了更多 Staff 式的工作，我也就自然地一路走了过来。

你从哪些资源（书、博客、人等等）学到最多？你在业内的榜样是谁？

我偏爱把复杂话题用人话讲清楚的文字，小说和非小说都算。

我记得读到过小说家村上春树写第一部小说时先用英文写，再翻回日文，以此塑造表达风格。他说：“我只能用简单的短英文句子写。这意味着，不管脑子里有多少复杂纷繁的想法，我都没法照原样写下来。语言必须简单，想法必须用好懂的方式表达。”

写软件是完全不同的领域，但这种感觉很对我的一个价值观：脑子里搞懂只是一半——能把理解表达出来，一样难，一样有价值。

我喜欢读深入技术领域的博客和论文。几年来反复回看的包括：Bob Nystrom 关于编程语言的博客、Vyacheslav Egorov 关于编译器和 V8 内部（Chrome 的 JS 引擎）的博客、Brandur 关于各类系统话题的博客、Nelson Elhage 的 Accidentally Quadratic、Vicki Pfau 关于开发 GameBoy Advance 模拟器的博客、fail0verflow 关于主机架构和漏洞的博客和演讲、Bungie 关于构建和制作初代 Halo 游戏的工程分享。

打个比方，职业生涯早期我对编程语言内部刚起兴趣，找了本编译器教材（“龙书”）来学。这本书很难啃。也许跟着教授和几个同学还能读下来，但对我来说，靠读书建立起可用的心智模型真的很难。后来，我找到了 Bob Nystrom 的 Crafting Interpreters，用的方法实用得多，简直像吹进一股新鲜空气。

我也很喜欢读代码库。职业生涯早期，我记得调一个棘手的 React 问题，某个回调的执行顺序和我想的不一样。看文档没用，打 log 也不够。当时的导师让我去读了一部分源码来搞懂发生了什么，那真的让我有点震撼。不仅修掉了 bug，对 React 是怎么工作的也有了强得多的理解。

那真的是个转折点。能快速扎进陌生代码、跳来跳去，真的像超能力，也给了我更大的模式匹配库，去理解不同的软件设计方法。最近喜欢的一个是读 esbuild 的设计和代码，一个超快的 JavaScript 打包器。

最后，过去几年我最喜欢的非虚构读物是关于 BART 历史、Xerox PARC 历史，以及现代日本文化概览的书。在每个细分领域，我都觉得历史和上下文特别迷人，看似独立的小事件和小决策，最后累积成了今天世界的样子。