从高级到资深：Pinterest 工程师的晋升密码不是写更多代码

来源：Jordan Cutler (Pinterest Staff Engineer) 真实晋升案例
原文：https://newsletter.eng-leadership.com/p/how-to-grow-from-senior-to-staff
核心命题：Senior→Staff 的跃迁，不是技术深度的比拼，而是思维模式的质变

导语：为什么很多高级工程师卡在"高级"

代码写得越来越快，系统架构越来越复杂，技术深度越来越深——但职级就是上不去。

Pinterest Web 平台 Staff Engineer Jordan Cutler 的观察是：卡在 Senior 的人，都在同一个维度上不断精进。而真正晋升到 Staff 的人，早就切换到了另一个维度。

Senior 工程师关注"我怎么能写得更好"。Staff 工程师关注"我怎么能让 10 个人写得更好"。

前者是个人产出，后者是乘数效应（Multiplier Mindset）。

本文拆解 Jordan 在 Pinterest 的真实晋升路径，从三个反直觉的维度，还原 Staff Engineering 的底层逻辑。

01｜维度一：扩大影响面——不要等指派，主动造场

反直觉：公司没要求你做的事，往往才是突破口

Pinterest 没有要求 Jordan 做"AI 工具推广"。他的正经工作是 Web Platform 团队的开发体验优化。

但他在日常工作中注意到一个行业级趋势：AI 正在重塑开发流程。而 Pinterest 内部没有人牵头做这件事。

于是他做了三件事：

1. 自己先实验：测试不同 AI 编码工具，优化自己的工作流
2. 拉一个小组：先私下问一个同样关注 AI 的朋友，"建个频道让大家分享 AI 用法，你觉得怎么样？"
3. 获取背书：把小组扩展到几个经理和 Staff+ 工程师，得到支持后直接开干

他创建了 #how-i-ai Slack 频道，第一句话是："Hey everyone，分享你是怎么用 AI 的，这里有巨大的互相学习机会。"

结果：

• 第一天：200+ 人加入
• 几个月后：1200+ 成员
• 多次在全员大会被点名表扬
• 被纳入公司级工具规划

这个频道带来的连锁反应：

• 因为他在 AI 领域的可见度，被高管邀请做月度 demo
• 因为 demo 表现出色，被首席架构师邀请加入"AI Coding Pathfinders"组
• 因为这个身份，领导公司级标准制定

关键洞察：这些机会不是"分配"来的，是他自己创造空间、播种价值、让复利发生的结果。

Jordan 后来还推出了 Claude 调度工具、文档生成器、幻灯片生成器、MCP 等 AI 工具。但这一切的起点，不是"接到任务"，而是"看到了空白，主动填补"。

02｜维度二：跨团队影响——说"你的页面慢"没人理，说这句就有人听

反直觉：指出问题不会赢得尊重，降低行动门槛才会

Jordan 入职 Pinterest 的第一个项目：审计 Search 页面性能，找出慢的原因，估算改进空间。

他第一次的做法：做了一份详细审计报告，列出所有问题，交给负责团队。

结果：对方没有 prioritize。

为什么？因为报告太复杂，团队看不出"为什么现在就要修这个"，也看不出"修了能带来什么"。

Jordan 复盘后的改变：

不说："JSON payload 有 500KB，太大了。"
说："Search 响应是 500KB，远超用户体验所需。修复后用户能看到搜索结果快 100ms。方案是减少查询参数中的条目数，并标准化响应格式。"

三要素齐全：

1. 问题是什么（500KB 响应）
2. 成本是多少（用户慢 100ms）
3. 修复长什么样（具体方案，不复杂）

这个版本被采纳了。

但这只是开始。他意识到，如果能在 Search 上做到，就能在其他核心页面上复制。

他主动找到 Home Feed 和 Pin Page（Closeup）的经理——这两个页面占 Pinterest 80% 流量——说："我正在审计 Search，要不要也快速看看你们的页面？"

** easy yes。** 谁不想知道自己页面的优化空间？

他跨页面分析用户流程，发现了一个典型场景：用户在 Home Feed 看到中等分辨率图片，点击 Pin 进入 Closeup，此时页面先显示背景色，等高清图加载。

Jordan 的优化建议：直接复用 Home Feed 的中等分辨率图作为 Closeup 的初始显示，高清图后台加载。

结果：三个核心页面的性能提升 30%+。

而这一切发生时，他还不是 Staff Engineer，只是 Senior。

关键洞察：跨团队影响不是靠 title，而是靠你让别人行动起来的成本足够低。"你有问题"被无视。"你有问题，这是数据，这是方案，我帮你修"才能驱动行动。

03｜维度三：构建可扩展系统——放弃救火，让指标替你说话

反直觉：最忙的人不是贡献最大的人，建立自动运转系统才是

Jordan 和经理的一次对话让他意识到："我们的开发体验到底怎么样？"——这个问题他们答不上来。

数据散落各处：

• Buildkite（CI 数据）
• GitHub（PR 统计）
• JIRA（项目速度）
• Honeycomb（可观测性）
• DX 调查（主观感受）

但没有统一视图。优先级靠"感觉"：Slack 有人抱怨构建慢，就修构建；有人提测试不稳定，就修测试。或者追最新热点，但不知道这和工作目标有什么关系。

Jordan 建了一个框架，连接三层：

关键设计：每个指标都有红/黄/绿阈值，定义"好"的标准。

• CI 流水线 < 12 分钟 = 绿
• 12-18 分钟 = 黄

• 18 分钟 = 红

阈值基于行业百分位数据和开发者反馈。

效果：

• "CI 慢"变成 "CI 流水线是红色，平均 19 分钟"
• 红色 dashboard 自动创造紧迫感
• 季度规划时，先看 spreadsheet，红色优先，黄色次之
• 从"打地鼠"变成"数据驱动决策"

但 Jordan 没有止步于"建了框架"。他让这套系统自我运转：

团队只需定义一个配置对象（指标名、分类、阈值），一个 pipeline 每周自动拉数据、计算变化、周一早上自动发格式化报告到 Slack。回归问题置顶，改进项关联最近上线的工作。

同样的数据同步到 Google Sheets，追踪长期趋势。

这套系统的可扩展性：

• API Platform 团队一天内定义了自己的配置文件，获得全部功能
• 移动端团队正在考虑采用
• Web Modernization 团队想加"未使用代码"月报，一个 PR 搞定
• Jordan 不需要再碰它

关键洞察：真正的 Staff-level 贡献不是"我修了多少问题"，而是我建立了一个系统，让问题自动浮现、让优先级自动排序、让团队自动运转。这个系统的价值，会随着团队规模扩大而指数增长。

04｜三个维度的底层统一：乘数思维

统一内核：从个人产出 → 团队产出 → 系统产出。

Jordan 的案例最打动人的地方是：他做这些事的时候，职级还是 Senior。他不是在"履行 Staff 的职责"，而是在"用 Staff 的方式工作"——然后职级自然跟上了。

这颠覆了"先升职再改变"的常见逻辑。正确的顺序是先改变，再升职。

05｜对国内工程师的映射

国内大厂的职级体系（如阿里 P6→P7→P8，字节 2-1→2-2→3-1）和 Pinterest 的 Senior→Staff 不完全对标，但核心逻辑相通：

国内工程师常踩的坑：

1. 只盯技术深度：P8 面试还讲算法优化，而不是讲"我怎么让三个团队共建了某平台"
2. 等老板分配跨团队项目：Staff 级机会不会主动出现，需要自己创造
3. 救火式工作：以"忙"为荣，但评委看到的是"没有系统性产出"

可立即执行的行动：

• 扩大影响面：在你负责的领域外，找一个没人管但有价值的事，主动建个频道/文档/工具
• 跨团队沟通：下次提问题时，强制自己加上"成本估算"和"修复方案"
• 建立指标：把你团队最模糊的问题（"构建慢""测试不稳定"）变成红/黄/绿 dashboard

结语：Senior 是终点，Staff 是起点

Jordan 的经历揭示了一个残酷真相：Senior 是大多数人能靠努力达到的天花板，但 Staff 及以上，努力的方向必须改变。

代码更快、架构更复杂、技术更深——这些在 Senior 阶段是加分项。在 Staff 阶段，它们是基本盘，不再是加分项。

真正的加分项是：

• 你能不能看到一个没人看到的空白？
• 你能不能让其他团队愿意听你的？
• 你能不能建立一个不需要你持续投入的自动系统？

乘数思维不是让 10 个人替你写代码。是让 10 个人因为你的工作，写得更快、更好、更开心。

从个人贡献到乘数效应，这条路没有捷径。但 Jordan 证明了一点：你可以从 Senior 阶段就开始练习，而不是等到 Staff 的 title 到手后才被迫改变。

参考来源

• Jordan Cutler, "How to Grow from Senior to Staff", eng-leadership.com, 2026
• Jordan Cutler, "The Multiplier Mindset" (O'Reilly 书籍早期发布)

#工程师晋升 #StaffEngineer #Pinterest #技术领导力 #职业发展 #MultiplierMindset #小凯