Staff 晋升 · 校准委员会打法
01 / 08
如何写出委员会挑不出毛病的晋升报告

像校准委员会内部人一样,
写一份 Staff 工程师晋升报告

一份真实的 Payments Platform 晋升包——范围、证据、还有 材料,缺一不可。

委员会晋升的不是潜力,
而是能证明你 已经在 Staff 岗位上跑的 证据。
Chapter · 01
02 / 08
第一章

先说清 范围

陈玛雅,Payments Platform 高级工程师——三个团队、一次事故、一套没人愿意认领的系统。

委员会反复圈出的四个证明时刻
03 / 08

撑起整份报告的 证明时刻

事故
主导账本漂移事故恢复
跨 3 个团队、11 小时内零客户资损
架构
提出幂等键重构方案
RFC 还没结项,4 个小组已采纳
带教
一个周期带出两名高级工程师
两人都说她的 1:1 笔记是转折点
跨团队
拉齐 Payments 与 Risk 的共用 schema
一次会议结束 8 个月的僵局
报告是怎么做出来的
04 / 08

一句范围声明,带出 整份材料

1
范围备忘:一页纸说清系统、影响半径、现在依赖她的人
2
事故复盘:账本漂移的时间线、压力下的决策、真正见效的修复
3
设计文档:幂等键 RFC,连同它打败的备选方案
4
同事材料:来自合作团队的六条校准评价,不只是主管一个人的话——打消疑虑
每一份材料都指向同一个结论——
不是 要求信任,而是 摆出证据。
委员会 6 分钟就能读完的材料
05 / 08

不是一篇作文——
只是一份 SCOPE.md

# promotion/maya-chen/SCOPE.md
level: L7(Staff)
scope: "Payments Platform —— 账本、幂等、清算重试"

evidence:
  - incident:   "账本漂移恢复,零客户资损,11 小时,3 个团队"
  - design:     "幂等键 RFC —— 批准前已被 4 个小组采纳"
  - mentoring: "一个周期带出 2 名高级工程师"
  - alignment: "Payments/Risk 在 8 个月僵局后达成 schema 一致"
委员会真正核对的数字
06 / 08

范围扩大了多少,影响 走了多深——证据 说了算

她独立主导的事故 6 起 评审通过的架构方案 3 个 带教出的高级工程师 2 人 校准中引用她的同事 9 条 账本漂移涉及的营收风险 $420 万
提交前她做的三件事
07 / 08

不只是收集证据——
还要 讲清楚诉求

复盘
承认了一次失误
schema 上线延期
主动认领缺口,反而让其他证据更可信
联署
让 skip-level
联合签署材料
主管一个人签是站台,skip-level 签是校准
诉求
明确要求本周期
晋升 Staff
具体的诉求才能逼出委员会具体的回答
这份材料不是让委员会想象她能做 Staff,
而是证明 她已经在这么做了。
Thanks for reading
08 / 08
L7 · 诉求

如果你也在准备自己的晋升报告:说清范围、收集证据、找 skip-level 联署——
直接提出目标职级,别说「等你觉得我准备好了」。

范围 · 证据 · 材料 · 影响 · 诉求 Staff 工程师晋升 校准委员会打法