Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 写得更多就能晋升吗
公开的阶梯到底在衡量什么
四种原型 — 你正站在哪一个位置
影响力如何变成“证据”
胶水工作的陷阱 — Reilly 到底说了什么
写作就是杠杆
不靠政治，也能被看见
诚实的旁注 — 阶梯本身充满噪声
AI 时代的脚注
结语
参考资料

引言 — 写得更多就能晋升吗

晋升停滞的工程师最先抓住的药方，往往是“更多、更快”。关掉更多的工单，提交更多的 PR，周末也在写。可一年过去，级别还是原地不动。

原因很简单。在公开的工程师职级阶梯里，没有一份把产出量当作衡量的轴。 这不是猜测，而是打开文档就能核实的事实。本文以真实的阶梯原文、Will Larson 对 Staff 及以上工程师的研究，以及 Tanya Reilly 关于胶水工作的论述为依据，来梳理“到底什么才是真正被评估的”。

公开的阶梯到底在衡量什么

progression.fyi 上公开着 CircleCI、Dropbox、Monzo、Etsy、Spotify、Square、Rent the Runway 等数十家公司的职业发展框架。把它们并排放在一起读，会发现措辞各不相同，但衡量的那几个轴重合得惊人。

Rent the Runway 的阶梯属于最早公开的那一批，它立起的四根柱子后来被无数框架照搬 — "Technical Skill"、"Get Stuff Done"、"Impact"、"Communication & Leadership"。

Dropbox 的职业发展框架更直白。文档开篇就写道 "Dropbox measures the success of its engineers largely on business impact"，并用三个轴来定义各级别的期望 — Scope（范围）、Collaborative Reach（协作半径）、Levers for Impact（影响力杠杆）。 接着它把话说死：正是这些期望，构成了 "the what that determines the difference between an IC3 and IC4"。Staff（IC5）的范围是这样写的 — "I deliver multi-year, multi-team product or platform goals"，以及 "open-ended problems that require difficult prioritization, defining both the what and how"。协作半径则是 "I am increasingly influencing the roadmaps of other Dropbox teams"。

CircleCI 设了从 E1（Associate）到 E6（Principal）的六个层级，而真正区分层级的，是影响力所能触及的范围 — "from task to epic, team level, and onwards ... to across several teams and, ultimately, across the organization"。并且工作的性质本身也在变：职责会 "shifts over time from execution to include facilitating, guiding, and mentoring others, whether or not they are in a management role"。文档自己举的例子很清楚：初级工程师写测试，最高层级的人则引领多个团队的测试策略。同一个主题，不同的杠杆。

CircleCI E1 -> E6 : 影响力所及的范围在扩大
  task  ->  epic  ->  team  ->  several teams  ->  organization

Dropbox IC3 -> IC5 : 三个轴同时变大
  Scope              我的项目     ->  multi-year, multi-team goals
  Collaborative      我的团队     ->  影响其他团队的路线图
  Levers for Impact  直接执行     ->  战略、判断、榜样

任何阶梯上都没有的轴:
  “写了多少行代码”

这里有一点必须诚实。正如 Rent the Runway 里确实立着 "Get Stuff Done" 这根柱子，执行力当然会被评估。只不过它是 所有层级的默认前提。 它不是把你往上抬的轴，而是缺了就出局的轴。层级之间真正变化的，是范围与杠杆。Senior 迟迟到不了 Staff 的常见原因，不是执行力不够，而是执行永远只发生在别人替他划好的范围之内。

四种原型 — 你正站在哪一个位置

Will Larson 采访了多家公司的 Staff 及以上工程师，把他们归纳为四种原型。

Tech Lead — "guides the approach and execution of a particular team"。与经理搭档，引领一个团队的技术方向与执行落地。这是最常见的一种，按 Larson 的观察，他调研过的每一家公司都有这个角色。也是大多数人最先抵达的那种 Staff 形态。
Architect — "responsible for the direction, quality, and approach within a critical area"。像 API 设计或基础设施这类长期存续的核心领域，以数年为尺度来承担。通常要工程师规模过了 100 人，这个位置才会出现。
Solver — "digs deep into arbitrarily complex problems and finds an appropriate path forward"。一头扎进组织点名的难题，解决之后就转战下一处火场。与前两者不同，他并不持有长期的所有权。
Right Hand — "extends an executive's attention, borrowing their scope and authority"。借用高管的范围与权限来运转复杂的组织。四种里最稀有的一种，通常要到 1,000 名工程师的规模才会出现。

重要的是，Larson 把这些当作 观察，而不是处方 来呈现。他这样写道 — "Being a Staff-engineer is not just a role, rather it's the intersection of the role, your behaviors, your impact, and the organization's recognition."

所以现实的问题不是“我想成为哪一种原型”，而是 “此刻我们公司真正有席位的原型是哪一种”。 在一家 50 人的公司里硬要当 Architect，等于朝着一个并不存在的位置奔跑。反过来，如果组织里“团队”这个概念本就薄弱，那么通往 Solver 的路会宽阔得多。

影响力如何变成“证据”

这里正是人们误解最深的地方。创造影响力是一回事，让影响力 被读到 是另一回事。而晋升，恰恰取决于后者。

范围大的工作，本质上在记录里留下的痕迹很淡。假如你把两个团队争执了半年的接口之争摆平了，产出物是 30 行代码和一份共识，提交日志里几乎什么都不会留下。所以 Staff 级别的工作，必须刻意做成 能留下证据的形状。

设计文档与 RFC。 Staff 工作的一半，是定义“要造什么”（用 Dropbox 自己的说法，就是 "defining both the what and how"）。这份定义一旦以文档留存下来，它本身就是你在那个级别上做过判断的证据。
故障应对中的领导力。 担任 Incident Commander，写复盘（postmortem），把防止复发的每一条都追到关闭为止。组织最脆弱的那一刻是谁给出了方向，所有人都会记得。
指导与评审。 Dropbox 的 IC5 条目里明确写着 "I serve as a role model for other Dropbox engineers"。把别人的代码变好，不是业余爱好，而是阶梯上白纸黑字的一条。
跨团队解阻。 把你撼动过其他团队路线图的那些瞬间记录下来。那正是 Dropbox 所说的协作半径本身。

而这一切的顶点，是 StaffEng 所说的“Staff 项目”。定义是这样的 — "complex and important enough that the person who completes it has proven themselves as a Staff engineer"。它有三个特征：一开始范围一塌糊涂（"poorly scoped but complex and important"），利益相关方众多且彼此分裂，而且醒目到领导层会在全公司会议上提起它。成功也好，失败也好，所有人都看着。

胶水工作的陷阱 — Reilly 到底说了什么

Tanya Reilly 的“Being Glue”，是这场讨论里被引用最多、也被误读最多的一篇文章。

所谓胶水工作，是新人引导、指导他人、帮别人解阻、在团队之间促成共识、写文档、做设计评审 — 这些没人指派、可一旦缺席项目就会垮掉的活儿。误读正是从这里开始的。Reilly 从来没有说过“不要做胶水工作”。 她说的是，胶水工作恰恰决定了一个项目的成败。

她真正的论点有两个。

第一，分配与可见性的问题。 这些对晋升毫无帮助的工作，会不成比例地压到特定的人身上（尤其是女性）。而一到评估季，这些人偏偏被告知“技术成果不够”。Reilly 对这句反馈毫不留情：她说 "not technical enough" 是一种把关（gatekeeping），而且是一句无法付诸行动的话 — 因为你根本不知道它到底要你去做什么。

第二，替代的问题。 她最有名的一句话正是这个 — "If you only do glue, you will only get better at glue." 关键在于 only 这个词。胶水工作如果补足技术深度，那恰恰就是 Staff 工程师该有的样子；胶水工作如果取代技术深度，那就是一条职业的死胡同。

她开出的药方也一点都不浪漫。和经理把晋升的要求摆到台面上谈清楚；要求一个与实际所做工作相称的头衔；留下能当作证据的产出物。而如果这些都不管用 — 那就先把胶水放下，去做出可衡量的技术成果。"Stop being the unofficial lead." 意思是：既然你不是正式的 Lead，就别再免费替正式的 Lead 干那份活。

而这同时也是说给经理和同事听的话。Reilly 要求人们公开地认可做胶水工作的人，而且要叫对名字 — 不是“帮了忙”，而是 “主导了这件事”。 用她的原话是 — "publicly give them credit! And not for helping, but for leading."

写作就是杠杆

Reilly 的著作 The Staff Engineer's Path 把 Staff 的工作拆成三根支柱 — 看大局（big picture）、推动项目落地（execution）、把别人带上来（leveling up）。而且她把话说死：这三者都必须立在技术功底之上。

贯穿这三根支柱的那个工具，就是写作。理由在于杠杆。会议上的说服只够到房间里的那几个人，一小时后就蒸发了。而一份写得好的设计文档，会在你睡觉时替你说服，会说服半年后才入职的人，也会在你不在场的房间里替你说服。当范围越过团队边界的那一刻 — 也就是 Staff 这个定义本身成立的那一刻 — 你不可能出现在每一个房间里。能去的，只有文档。

代码也按同样的原理来写。为读代码的人而写的代码才会产生杠杆，这件事我在即使 AI 来维护你的代码，也要为人类而写里单独写过。

不靠政治，也能被看见

很多工程师把“被看见”当成政治的同义词。于是他们什么都不说，然后在晋升里被人悄无声息地挤掉。

区分其实很简单。政治，是把不存在的影响力包装得像存在；可见性，是把确实存在的影响力变得可读。 后者是诚实的劳动，而且说实话，这也是对评估你的人的一种体谅 — 他们并没有时间替你把过去半年重新拼一遍。

StaffEng 的晋升指南反复念叨的那几条，归根结底也是这个 — 找到你的 sponsor，进到做决定的那个房间里并且留下来，写好你的晋升材料（promotion packet），接下 Staff 项目。这里的 sponsor 不是你要去讨好的对象，而是在你不在场的房间里，能准确讲清你做了什么的人。要做到这一点，他必须准确地知道你做了什么。让他知道，这不是政治，这就是工作本身。

实操层面，做到这些就够了：决定要落成文档，写下的文档要真的发给受影响的人，成果用团队的名义来讲，但你自己做过的判断要说清楚。然后，每半年提前给自己写一次晋升材料。如果发现根本没什么可写 — 那正是你今天就该知道的事实。

诚实的旁注 — 阶梯本身充满噪声

读到这里，可别把阶梯误当成一把精密的尺子。

阶梯因公司而异。progression.fyi 上收集的那些框架，层级数量、轴的名字、强调的重点，全都各不相同。正如 Larson 观察到的，Architect 要到 100 名工程师的规模、Right Hand 要到 1,000 名的规模才会出现。也就是说，同一个人，在 A 公司是 Senior，在 B 公司可能就是 Staff。 这不是对你的评价，而是关于组织结构的事实。

运气的分量也很重。StaffEng 坦率地承认了拿到 Staff 项目的条件之一 — "your company having a pressing need to solve a Staff-level problem, which can require some patience"。如果公司里根本没有 Staff 级别的问题，你就造不出 Staff 级别的证据。除此之外，还得叠加上管理层愿意在你身上下注这一条。

所以，别把级别当成自我。你能控制的，是把范围一点点撑大的习惯，和把证据留下来的习惯；你控制不了的，是时机。但备齐了前两样的人，会在机会到来的那一刻已经准备好。

AI 时代的脚注

代码产出正在变得廉价。过去要花一周的实现，如今一天就能做完，而且这个差距还会继续拉大。

这里容易得出的错误结论是“所以工程师的价值在下跌”。可只要重新看一遍阶梯，故事就反转了。从一开始，就没有任何一份阶梯在衡量产出量。 阶梯一直在衡量的，是把模糊的问题变成清晰范围的能力（"defining both the what and how"）、横跨多个团队的判断，以及决定什么不去造。而这些，恰恰不是今天的模型能替你扛下来的轴。恰恰相反，实现越是便宜，把错误的东西实现得无比出色，这份代价就越是刺眼。

副作用也有。AI 造出了新的胶水陷阱。文档、摘要、原型都能几分钟量产，于是 “看起来很忙”从未像今天这样容易。 “活动量不等于范围”这条原则原封不动，甚至更需要冷静地追问一句 — 这份产出物，究竟改变了谁的哪一个决定。

在陌生环境里把模糊性转换成范围的能力，为什么会越来越贵，我在 Forward Deployed Engineer(FDE) 备战里换了个角度谈过。

结语

归纳一下就是：晋升靠的不是产出量，而是 范围与杠杆。 执行力是入场券，把你往上抬的是影响力所能触及的范围。原型是地图，不是处方，所以请看清自己公司里真正存在的席位。影响力不是造出来就完事，它还得被读到，所以请留下证据。胶水工作不可或缺，但它一旦取代技术深度，就变成了陷阱。而阶梯充满噪声，所以别把级别当成自我。

如果只留一条最诚实的建议，那就是这句。下个季度，别再问“我还能多写点什么”，而要问 “此刻还没有人认领的重要问题是什么”。 回答这个问题、并把答案写成文档的习惯，是在任何一家公司、任何一份阶梯上都通用的唯一一样东西。