引言
成为资深工程师之后,职业路径大体分为两条:转型为工程经理(EM),或者在 Individual Contributor(IC)路线上继续成长为 Staff Engineer 及以上。在韩国,Staff Engineer 这个头衔在很多组织里还不算普及,但在全球科技公司中,它早已是职业阶梯上确立已久的关键阶段。
Staff Engineer 与资深工程师究竟有什么不同?一句话概括,不同之处在于影响力的范围。资深工程师在团队内部写出卓越的代码,而 Staff Engineer 则跨越团队边界,影响整个组织的技术方向。写好代码依然重要,但仅凭这一点已经不够。
本文以 Will Larson 的《Staff Engineer》和 Tanya Reilly 的《The Staff Engineer's Path》为基础,从实践角度依次讲解 Staff Engineer 的四种原型(archetype)、通过 RFC/ADR 进行的技术决策、影响力扩展策略、辅导与举荐(mentoring and sponsorship)、技术债务的战略管理,以及工程文化建设。
Staff Engineer 的四种原型
Will Larson 将 Staff Engineer 的角色划分为四种原型。大多数 Staff Engineer 更接近其中一种原型,但也会根据情况在多个角色之间切换。
1. Tech Lead
引领一个团队或一小群团队的技术方向。
- 主导团队的技术决策,维护代码质量
- 管理项目规划与执行中的技术层面
- 与工程经理紧密协作,在技术与人两端牵线搭桥
- 最常见的原型,约 50% 的 Staff Engineer 属于这一类型
2. Architect
对跨多个团队的技术方向与质量负责。
- 制定组织层面的技术愿景与战略
- 定义系统间的接口与集成模式
- 建立技术标准与最佳实践
- 主要存在于大规模组织(数百至数千人)中
3. Solver
专门解决特别棘手或紧急问题的专家。
- 被投入到组织内最棘手的技术问题上
- 项目完成后转移到下一个问题
- 需要深厚的技术专长与快速学习能力
- 在高度专业化的领域(安全、性能、基础设施)中发挥价值
4. Right Hand
担任 VP/CTO 等资深领导者的技术伙伴。
- 补充领导者的技术判断,支持决策的落地执行
- 协调组织范围内的技术举措
- 需要对组织政治有敏锐的理解力与出色的沟通能力
- 最罕见的原型
哪种原型更适合你
自我诊断问题
============================================
1. 我喜欢在一个团队里深耕
-> Yes: Tech Lead 倾向
2. 我关心多个团队之间的技术一致性
-> Yes: Architect 倾向
3. 解决"看似不可能"的技术问题让我兴奋
-> Yes: Solver 倾向
4. 我想理解并影响整个组织的方向
-> Yes: Right Hand 倾向
注意:原型不是固定不变的。它会随职业阶段和组织情况而变化。
技术决策:RFC 与 ADR
为什么文档化的决策很重要
Staff Engineer 最重要的职责之一,是让技术决策变得透明。只靠口头传达的决定会丢失背景信息,日后也就无法回答"当初为什么这么做"这样的问题。
RFC (Request for Comments)
RFC 是提出重大技术变更、并收集组织反馈的流程。
# RFC:引入订单服务事件溯源
## 元数据
- 作者:Youngju Kim
- 状态:审阅中
- 创建日期:2026-03-01
- 审阅人:Seojun Park、Minha Lee、Dayun Jung
- 决策截止日期:2026-03-14
## 摘要
将订单服务的状态管理从当前的 CRUD 方式迁移到事件溯源(Event Sourcing),
以满足订单历史追踪与审计日志的要求。
## 动机
1. 金融监管合规:订单状态变更历史需保留 5 年
2. 客户支持:需要准确回答"订单为什么被取消?"这类问题
3. 分析:订单漏斗分析需要细粒度的事件数据
## 提议的设计
(具体的技术设计内容)
## 备选方案分析
### 备选方案 1:CDC(Change Data Capture)+ 独立历史表
- 优点:现有代码改动最小
- 缺点:历史与当前状态之间难以保证一致性
### 备选方案 2:引入审计日志库
- 优点:实现简单
- 缺点:无法重放事件,只能保留部分历史
### 备选方案 3:事件溯源(已选定)
- 优点:完整历史、事件重放、时间旅行查询
- 缺点:学习曲线陡峭,需要额外构建读模型
## 实施计划
- 阶段 1(2 周):搭建事件存储基础设施
- 阶段 2(3 周):将订单创建/修改迁移到事件溯源
- 阶段 3(2 周):构建读模型(CQRS)
- 阶段 4(1 周):迁移现有数据
## 风险
1. 团队学习曲线(缓解:开展 2 次事件溯源工作坊)
2. 读取性能可能下降(缓解:通过 CQRS 分离读模型)
3. 运维复杂度上升(缓解:搭建事件存储监控看板)
## 未决事项
- 事件存储选型:EventStoreDB 还是 PostgreSQL + Outbox 模式
- 事件模式演进策略(upcasting 还是 versioning)
ADR(Architecture Decision Record)
ADR 是比 RFC 更轻量的格式,用于记录单项技术决策的背景与结果。
# ADR-042:选择 JWT 作为 API 认证方式
## 状态
已批准(2026-03-10)
## 背景
需要统一微服务之间的 API 认证方式。
目前各服务混用 API Key、Session、JWT 等方式,
给安全审计和调试带来困难。
## 决策
采用 JWT(JSON Web Token)作为服务间通信的标准认证方式。
- 令牌签发:Auth 服务(基于 Keycloak)
- 令牌验证:各服务基于公钥在本地验证
- 令牌有效期:Access Token 15 分钟,Refresh Token 7 天
## 结果
- 正面:认证方式统一,消除了服务间调用对 Auth 服务的瓶颈
- 负面:令牌失效不会立即生效(需等到过期)
- 中性:每个服务都需要新增 JWT 验证中间件
## 备选方案
- API Key:简单,但密钥管理复杂,难以做细粒度权限控制
- mTLS:安全性强,但证书管理开销大
- OAuth2 Opaque Token:对 Auth 服务的依赖度高
RFC/ADR 运营最佳实践
- 将 RFC/ADR 与代码一起存放在代码仓库中:让决策与代码一同纳入版本管理
- 设定评审截止日期:无限期开放的 RFC 会拖延决策
- 提供模板:统一的格式能降低撰写负担
- 保留被否决的 RFC:"为什么没有选择这个方案"同样是重要的知识
扩展影响力:超越代码
写作的力量
对 Staff Engineer 而言,写作不是可选项,而是必需品。代码只影响一个团队,而写得好的技术文档能影响整个组织。
有效的技术写作类型:
- 技术愿景文档:描绘 6~12 个月后技术栈的目标状态
- 事后复盘(postmortem):从事故中提炼组织可以学到的教训
- 入职指南:帮助新工程师快速进入高产状态
- 技术博客:与外部社区分享知识,同时提升招聘品牌
通过代码评审实现技术进阶
Staff Engineer 的代码评审,不只是发现缺陷,还承担着教育功能。
普通资深工程师的代码评审:
"把这个函数名从 getUser 改成 fetchUserById 吧。"
Staff Engineer 的代码评审:
"这个函数做的是 DB 查询,所以用 fetch 前缀会更合适。
我们团队的约定是:纯计算用 get/compute,涉及 I/O 就用
fetch/load 前缀。要不要把这个约定写成 ADR 文档化一下?
相关示例:payment-service 里的 fetchOrderHistory"
会议中的影响力
Staff Engineer 在技术会议中应当扮演推动决策的角色。
- 决策之前:预先梳理选项与权衡并加以分享
- 会议之中:讨论跑偏时,用关键问题把话题拉回来
- 决策之后:清晰地记录决策内容与行动项
辅导与举荐
辅导 vs 举荐
许多资深工程师会做辅导(mentoring),却不做举荐(sponsorship)。两者并不相同。
- 辅导(Mentoring):分享知识与经验、提供建议("这样做就可以了")
- 举荐(Sponsorship):创造机会、提升可见度("这个项目的负责人就交给你吧")
举荐之所以更强大,是因为它直接提供了成长机会本身。
有效的辅导框架
1:1 辅导结构(双周一次,30 分钟)
============================================
5 分钟 - 近况确认:"最近什么事最有挑战性?"
10 分钟 - 技术深度:讨论当前工作中的技术难题
10 分钟 - 职业成长:回顾长期目标与当前所处的位置
5 分钟 - 行动项:整理到下次见面前要做的事
导师应该做的事:
- 用提问引导思考,而不是直接给答案
- 坦诚分享自己失败的经历
- 根据学员的成长阶段调整难度
导师不该做的事:
- 替学员完成工作
- 把自己的职业路径当作唯一正确答案来展示
- 把辅导内容分享给学员的直属上级(破坏信任)
技术债务的战略管理
把技术债务翻译成业务语言
只说"我们得偿还技术债务"这句话,不会打动业务负责人。Staff Engineer 必须能把技术债务翻译成业务影响(business impact)。
不好的说法:
"测试覆盖率太低了,需要重构。"
好的说法:
"目前支付模块的测试覆盖率是 30%。
上个季度 3 起支付相关事故中,有 2 起发生在没有测试
覆盖的代码路径上。每起事故的业务影响平均是
2 小时服务中断,以及约 500 万韩元的营收损失。
花 2 周时间补齐测试,预计可以把事故率降低 60%。"
技术债务优先级矩阵
业务影响高
|
Q2: 计划性偿还 | Q1: 立即偿还
(纳入下季度路线图) | (纳入当前 Sprint)
|
──────────────────────┼──────────────────────
|
Q4: 接受 | Q3: 渐进式改进
(维持现状) | (童子军规则)
|
业务影响低
左侧:变更频率低 右侧:变更频率高
- Q1(立即偿还):业务影响大且频繁变更的代码中的技术债务。最优先解决
- Q2(计划性偿还):业务影响大但变更不频繁的代码。纳入路线图
- Q3(渐进式改进):变更频繁但业务影响小的代码。应用童子军规则
- Q4(接受):两者都低的代码。接受现状
工程文化建设
心理安全感(Psychological Safety)
正如 Google 的 Project Aristotle 研究所揭示的,高绩效团队最重要的特质是心理安全感。Staff Engineer 不仅要对技术卓越负责,也要对团队文化负责。
能提升心理安全感的 Staff Engineer 行为:
- 公开承认失误:"这个设计里有一部分是我没考虑到的"
- 欢迎提问:不只说"这是个好问题",而是具体说明它好在哪里
- 复盘中禁止追责:探究的是"哪些系统性因素"导致了事故,而不是"是谁"
- 积极征求不同意见:"有没有人有不同的看法?"
技术决策的透明度
Staff Engineer 主导的技术决策越透明,组织的信任度就越高。
- 公开说明为什么选择了这项技术、考虑过哪些备选方案
- 如果决策出错,坦诚承认并及时修正方向
- 为不同级别的工程师提供参与决策过程的机会
营造学习文化
学习文化的实践方法
============================================
每周:
- Tech Talk(30 分钟):团队成员轮流分享感兴趣的技术
- 代码评审 Power Hour:全体团队一起评审重要的 PR
每月:
- 技术书籍读书会
- 事故复盘会(分享 postmortem)
- 黑客松或 Innovation Day
每季度:
- 技术雷达更新(Adopt/Trial/Assess/Hold)
- 职业成长 1:1(经理 + Staff Engineer)
- 参加外部会议并在内部分享
Staff Engineer 职业成长路线图
从资深工程师到 Staff 的转型
从资深工程师晋升为 Staff Engineer,所需要的并不是"写更多代码"。
资深 -> Staff 转型所需的能力变化
============================================
需要做得更多:
+ 超越团队边界的技术影响力
+ 文档化的技术决策(RFC/ADR)
+ 组织层面的技术问题解决
+ 支持初级/中级工程师的成长
+ 理解业务背景并与技术战略相连接
可以少做一些:
- 亲自编写所有代码
- 掌握所有技术细节
- 参与每一次代码评审
绝对不能丢掉的:
! 保持编码能力(hands-on 比例 30~50%)
! 学习技术趋势
! 谦逊与好奇心
撰写 Impact Log
在 Staff Engineer 这个层级,系统性地记录自己的影响力(impact)非常重要。如果在绩效评审时依赖记忆,就会遗漏重要的贡献。
# Impact Log - 2026 Q1
## 组织影响
- [RFC-018] 提出并推动支付服务引入事件溯源方案获批(3/1)
- 影响范围:支付团队、订单团队、结算团队
- 预期效果:100% 满足审计日志要求
## 技术债务偿还
- 主导认证中间件统一项目(1/15 - 2/28)
- 将 5 个服务的认证方式统一为 JWT
- 解决 3 项安全审计问题
## 辅导/成长支持
- 定期辅导 2 名初级工程师(双周一次)
- 支持其中 1 人晋升资深工程师(晋升成功)
- 主持"分布式系统基础"内部工作坊(2/10, 25 人参加)
## 事故响应
- 主导支付网关超时事故的响应(1/22)
- 30 分钟内定位原因并部署热修复
- 撰写事后复盘,提出 3 项防止复发的对策
结语
Staff Engineer 的本质,是把技术上的卓越转化为组织的成果。无论个人编码水平多么出色,只要它没有转化为团队与组织能力的提升,就算不上 Staff 级别的影响力。
把要点整理如下。
- 找到自己的原型:在 Tech Lead、Architect、Solver、Right Hand 中找到适合自己的角色,并根据情况灵活切换
- 让决策变得透明:用 RFC 和 ADR 记录技术决策的背景,并保留被否决的方案
- 通过写作把影响力扩展到代码之外:借助技术愿景文档、事后复盘、入职指南等,把价值传递给整个组织
- 从辅导发展为举荐:不止于建议,成为为他人创造成长机会的举荐人
- 把技术债务翻译成业务语言:不说"需要重构",而是用业务影响和 ROI 来说服
- 打造提升心理安全感的文化:承认失误、欢迎不同意见、鼓励学习
Staff Engineer 的旅程没有"标准答案"。不同的组织、不同的人,会以不同的方式扮演这个角色。重要的是,用自己的方式扩展影响力,同时不丢失作为工程师的本质——技术卓越与好奇心。