本周的命题： 新人前 90 天，决定了你未来两年是否要为这次招聘后悔。Onboarding 不是 HR 的流程——发台电脑、拉进群、丢个 wiki 链接。它是你亲手设计 的一段"从陌生到产出"的路径。Michael Watkins 算过：一个空降的人平均要 6 个月 才到达收支平衡点（净贡献为正）。你设计得好，能把它提前到 90 天；设计得差，新人在第 100 天还在猜"我到底向谁汇报、什么叫做完"。本周四个原则：30/60/90 的地图、前 30 天的速赢、关系网与隐性文化的传递、以及用新人的"局外人之眼"反向诊断团队。
一句话原则 · 名家原话
在新人 Day 1 之前，你就该有一份写好的 30/60/90 文档：30 天学 、60 天贡献 、90 天拥有 。期望写下来，新人才不用靠读空气判断自己做得对不对。
"The actions you take during your first three months in a new role will largely determine whether you succeed or fail."
"你在新角色头三个月采取的行动，在很大程度上决定你是成功还是失败。"
— Michael Watkins,《The First 90 Days》Introduction
30/60/90 地图
Day 1-30 · 学
建立 baseline
· 跑通环境
· 提交第一个 PR
· 读 3 个核心服务
的设计文档
· 见 8 个关键的人
Day 30-60 · 贡献
独立交付
· own 一个中等
feature
· 从设计到上线
· 开始 review
别人代码
Day 60-90 · 拥有
承担责任
· 成为某子系统
的 owner
· 进 on-call 轮值
· 能独立拍板
小决策
场景示范
情境：新加入的高级工程师 Day 1，你还没准备任何入职材料。
✗ 常见做法
"先熟悉一下代码，把环境 setup 好，有问题随时问我，慢慢来。"
✓ 修后做法
给一份共享 doc，写明三段里程碑（见上图）。开场说："这是草稿，第一周我们一起调。它的目的是让你随时知道'我在轨道上吗'——而不是等三个月后的 review 才发现没对齐。"
关键：里程碑要可验证 （"提交第一个 PR"），不是"熟悉业务"这种没法判断完成的词。
检查表（Day 1 前 manager 要 ready）
账号、权限、环境 setup 文档在 Day 1 前就 ready 了吗？（别让新人第一周在等 IT）
30/60/90 doc 写好了吗？里程碑可验证，而不是"熟悉业务"？
第一个任务选好了吗？范围小到能在两周内上线？
指定了 onboarding buddy 吗？（不是你——是一位 peer）
常见错误
"慢慢来"是陷阱。 没有里程碑的"慢慢来"= 让新人自己背焦虑。期望只在你脑子里。 你以为"30 天该 ramp 好"，没说出口；60 天后你失望，他震惊。把 onboarding 整个外包给 HR / wiki。 流程性的能外包，"什么叫好"只能你定义。
本周习作： 给一位即将入职、或入职 30 天内的下属，写一份 30/60/90 草稿。思考题： 你上一个新人，第几天才第一次真正"上手产出"？是计划的问题，还是人的问题？
一句话原则 · 名家原话
新人前 30 天最该得到的不是"全面理解系统"，而是一次小而真实的上线 。一次 ship 给新人信心，给团队"这人能交付"的信号。
"Early wins build your credibility and create momentum. They create virtuous cycles that leverage the energy you are putting into your work."
"早期的胜利建立你的信誉、制造势能，形成放大你投入的良性循环。"
— Michael Watkins,《The First 90 Days》Ch. "Secure Early Wins"
场景示范
情境：你想让新人"真正理解系统"，在挑第一个任务。
✗ 常见做法
把他扔进最复杂的 legacy 计费模块去重构——"这块最硬，啃下来你就懂全局了"。
✓ 修后做法
给一个 good first issue ：范围小，但要走完整条流水线 （改代码 → 测试 → review → 部署 → 看监控）。他一次性学会"你们怎么发布"，第二周就有东西上线。
对团队说："这是 X 的第一个 PR，review 时多给点上下文。"——把速赢变成团队接纳的仪式。
检查表（怎么选第一个任务）
这个任务能在 1-2 周内真正上线吗？
它会让新人走一遍完整的 dev → deploy 流程吗？
它是真需求，还是"练习题"？（练习题没有上线的满足感）
万一失败影响可控吗？（第一个任务不该能搞挂生产）
常见错误
把最难的硬骨头当"投名状"。 你觉得是信任，新人觉得是被扔下水。速赢变成"假赢"。 一个永远不会上线的玩具项目，给不了真实信心。速赢后撤掉支持。 第一次 ship 时 buddy 要在旁边，别让他一个人摸黑闯流水线。
本周习作： 为下一个新人预留一个 scoped 好的 good-first-issue。思考题： 你团队有没有一类"只有老人才知道怎么做"的发布步骤？那正是新人速赢能暴露的文档债。
一句话原则 · 名家原话
新人失败很少因为技术，多因为没搞懂"事情在这里是怎么运转的"——谁拍板、怎么提异议、什么叫做完 。这些隐性规则你不主动教，他要用半年踩坑学会。
"Culture is a pattern of shared basic assumptions learned by a group as it solved its problems… taught to new members as the correct way to perceive, think, and feel."
"文化是一个群体在解决问题中习得的共享基本假设……并作为'正确的认知方式'传授给新成员。"
— Edgar Schein,《Organizational Culture and Leadership》
场景示范
情境：你的 onboarding doc 全是技术 setup，没人讲"事情怎么办成"。
✗ 没传递隐性规则的代价
没人告诉新人："在这家公司，跨团队的事要先在 Slack 私聊对齐，直接拉会议会被当成 aggressive。"
✓ 修后做法
给一份 "该认识的人 + 为什么" 名单："Alice — 计费 owner，你的 feature 上线前必须她点头。"指定一位 peer buddy 专门接"蠢问题"。再口头交代 2-3 条写不进 wiki 的规则：怎么提异议、谁真正拍板、什么叫做完。
检查表
我给了"该认识的 8 个人 + 为什么"的名单吗？
我指定了一位 peer buddy（不是我）来接蠢问题吗？
我口头讲过 2-3 条写不进 wiki 的隐性规则吗？
我安排他旁听一次核心决策会议（哪怕只是听）了吗？
常见错误 · 女性视角
假设"聪明人自己会观察"。 会，但要半年，且会先踩几个雷。buddy 就是你自己。 新人不敢问 manager 蠢问题。Peer buddy 才是安全的提问出口。
Female Leader's Note
新人期是 glue work / office housework 分派定型的高危期：女性、少数族裔新人更容易在头几周被"自然地"推去做记录、订午餐、组织 team building。一旦定型，后面很难甩掉。对策：onboarding 时有意识地把第一个有技术可见度的任务给到她 ，而不是让她从"团队的贴心人"角色起步。
本周习作： 给下一个新人写一份"该认识的人 + why"名单。思考题： 你团队有哪条隐性规则，是你自己当年也踩坑才学会的？
一句话原则 · 名家原话
新人头 90 天有一双团队没有的眼睛——他还没对你们的烂流程麻木。这个窗口关闭得很快。 趁他还会问"为什么要这样做"时，把信号收割下来。
"In the beginner's mind there are many possibilities, but in the expert's mind there are few."
"初学者的心里有许多可能，专家的心里却很少。"
— Shunryu Suzuki,《Zen Mind, Beginner's Mind》
收支平衡点：你设计的 ramp 把它提前还是推后
收支平衡（净贡献=0）
好 ramp ≈ 90 天
差 ramp ≈ 6 个月+
时间 →
净贡献 →
场景示范
情境：新人入职 30 天，你做第一次正式 check-in。
✗ 失败问法
"感觉怎么样？还适应吗？" → "挺好的，大家人都很好。"（你什么都没收到。）
✓ 收割 fresh eyes
"你来了 30 天，还带着外面的视角——这双眼睛我们团队已经没有了。三个问题：天经地义、你却觉得很奇怪 ？更好 的一件事是什么？困惑、但不好意思问 的是什么？"
同时这是双向的：你也给他第一次方向性反馈——30 天评绩效太早，但给"继续 / 调整"不算早。
检查表（30 / 60 / 90 节点）
30 天：我问了"什么让你觉得奇怪/困惑"来收割 fresh eyes 了吗？
30 天：我给了第一次方向性反馈（不是评分，是"继续 / 调整"）吗？
60 天：我们对齐了"接下来该 own 什么"了吗？
90 天：我对"这次招聘对不对"有诚实判断了吗？
常见错误
等 perf review 才第一次给反馈。 那时窗口早关，问题已固化。把 fresh-eyes 反馈当冒犯。 新人说"这流程很奇怪"你就辩护——下次他不再说，你失去最后的免费审计。90 天明知不 fit 却拖。 诚实不鸡汤：有些 onboarding 失败是招聘错配，不是努力能补的。拖到第 6 个月再处理，对他、对团队、对你都更残忍。
本周习作： 给一位入职 30 天内的人做一次 fresh-eyes check-in，记下他指出的第一个"你们很奇怪"的点。思考题： 你团队哪个流程，新人每次都问"为什么"，而你每次都答"历史原因"？那就是债。
深入思考
30/60/90 在不同 seniority 上该怎么变？
一刀切的模板会同时压垮新人、低估资深者。给 staff+ 的 ramp，90 天该开始影响方向 （写一份 tech vision、推动一个跨团队对齐），"独立交付中等任务"对他是侮辱性的低标。给 new grad，90 天能在指导下独立交付一个中等任务、不再需要手把手就已经很好。错配方向的标准，会让资深者觉得被当螺丝钉，让新人觉得被扔在水里。
远程 / 分布式团队的 onboarding 哪里最容易断？
办公室里靠"耳濡目染"自动发生的文化传递，在远程几乎归零：隐性规则、随口的上下文、走廊对话全部消失，新人只能看到被显式写下来的东西。远程 onboarding 必须把"本来无形的"强制显性化 ——隐性规则写进文档、关键决策录屏、刻意安排"该认识的人"的 1:1，而不是指望他自己泡进群里慢慢悟。远程下，buddy 制度和高频 check-in 不是加分项，是底线。
大厂 vs 初创的 onboarding 差异？BigCat 的真实风险在哪？
大厂"流程到位、人没到位"：新人被入职系统、合规培训、几十个工具淹没，却没有一个人真正为他的 ramp 负责。初创没流程，全靠 manager 临场救火。BigCat 在大厂，最大的风险是把 onboarding 等同于公司那套 program ，从而忽略了 team-level、manager-level 的那一层——而恰恰是这一层（30/60/90、第一个任务、隐性规则）决定 ramp 速度。公司流程管"合规上岗"，你管"什么时候开始真正产出"。
"速赢"会不会制造错误的早期印象？
会。一个精心挑选的 easy win 让新人显得很强，若后续真实难度陡增，团队会有落差感，新人也可能误判自己的 ramp 进度。诚实的做法是把预期一起给出："这是热身，帮你跑通流水线；真正的复杂度在 Q3 那个项目，到时我们会一起拆。"速赢的目的是建立动量和流程熟悉度 ，不是制造"天才人设"。把它定位准，就不会反噬。
onboarding 投入的边界在哪？什么时候是"过度保姆"？
你不可能对每个新人投入同样多，关键是按需匹配 而非平均用力。资深的人要的是 context 和自主——给太多手把手等于不信任；new grad 要的是结构和频繁 check-in——给太少自由等于放养。判断信号：如果新人开始反复问你"我可以自己决定吗"，说明你管多了；如果他频繁在小决策上卡住、反复返工，说明结构给少了。边界不是固定的，是随他能力曲线动态收放的。
BigCat · Leadership · Day 12 · 2026.06.01