Back to Details

team-onboarding-playbook

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
A repeatable framework for building an onboarding playbook that ramps new team members predictably without burning out the people training them.
一个可复用的入职手册构建框架，能让新团队成员按预期完成上手，同时避免培训人员过度劳累。

When to use

适用场景

  • A new hire is joining and you do not have a written onboarding plan.
  • An existing onboarding process is informal and inconsistent.
  • A team is growing fast and onboarding is the bottleneck.
  • A contractor or agency partner needs to ramp up quickly.
  • A team member is leaving and their knowledge needs capturing.
  • Onboarding currently takes too long and you want to reduce it.
  • 新员工即将入职，但尚未制定书面入职计划。
  • 现有入职流程不规范、缺乏一致性。
  • 团队快速扩张，入职流程成为瓶颈。
  • 承包商或合作机构需要快速上手。
  • 团队成员即将离职，需要留存其掌握的知识。
  • 当前入职耗时过长，希望缩短周期。

When NOT to use

不适用场景

  • For ongoing performance management (different problem).
  • For training on a specific technology (use targeted docs and tutorials).
  • For documentation strategy in general (use 
    documentation-strategy
    ).
  • For role definition or hiring (different upstream problem).
  • 用于日常绩效管理（属于不同问题范畴）。
  • 用于特定技术培训（应使用针对性文档和教程）。
  • 用于通用文档策略（请使用
    documentation-strategy
    ）。
  • 用于岗位定义或招聘（属于上游的不同问题）。

Required inputs

必要输入

  • The role: what the person will do, what success looks like at 90 days.
  • Existing artifacts: docs, runbooks, codebases, design files.
  • The team: who will mentor, who will pair, who answers what kind of question.
  • Tools and access: what accounts and systems the new person needs.
  • Time budget: how much time team members can invest in onboarding.
  • 岗位信息：该岗位的工作职责、90天内的成功标准。
  • 现有资料：文档、运行手册（runbooks）、代码库（codebases）、设计文件。
  • 团队信息：指定导师、配对协作人员、各类问题的对接人。
  • 工具与权限：新成员需要的账户及系统权限。
  • 时间预算：团队成员可投入到入职培训中的时间。

The framework

框架内容

A good onboarding plan operates on 4 layers. Build all four.
一份优质的入职计划包含4个层级，需全部构建完成。

Layer 1: Belonging (Day 1 to Week 1)

第一层：归属感（第1天至第1周）

The first week is mostly about belonging, not productivity. Get this right and everything else accelerates.
  • Welcome message before they start.
  • Workspace and accounts ready before day 1. No "we will get to that".
  • A buddy or onboarding partner assigned (someone other than the manager).
  • Day 1 schedule that is not 8 hours of meetings, but is also not zero meetings.
  • Introductions to the people they will work with regularly.
  • A first-week rhythm: daily check-in with manager or buddy.
第一周的核心是建立归属感，而非追求产出。做好这一点，后续所有环节都会加速推进。
  • 入职前发送欢迎消息。
  • 入职前准备好工作环境和账户，杜绝“稍后处理”的情况。
  • 安排伙伴或入职对接人（非直属经理）。
  • 第1天的日程不应是8小时连续会议，但也不能完全无会议。
  • 介绍新成员将经常合作的同事。
  • 第一周的固定节奏：每天与经理或对接人进行简短沟通。

Layer 2: Context (Week 1 to Week 4)

第二层：认知构建（第1周至第4周）

The next phase is context. The new person needs to understand the system before they can change it.
  • The product or business: what we do, who we serve, why we exist.
  • The team: who owns what, how decisions get made.
  • The technical or operational landscape: the architecture diagram, the main tools, the key files.
  • The recent past: major decisions, recent launches, current priorities.
  • Active projects: what is in flight and how it fits.
A reading list is part of this. Keep it short. Annotated. Curated.
下一阶段是构建认知。新成员需要先理解整个体系，才能参与优化。
  • 产品或业务：我们的业务内容、服务对象、存在的意义。
  • 团队架构：各职责归属、决策流程。
  • 技术或运营全景：架构图、核心工具、关键文件。
  • 近期动态：重大决策、近期发布的产品、当前优先级事项。
  • 进行中项目：各项目进展及整体定位。
此阶段需提供一份阅读清单，清单要精简、带有注释且经过精心筛选。

Layer 3: Contribution (Week 2 to Week 6)

第三层：贡献参与（第2周至第6周）

By week 2 or 3, the new person should be making real contributions. Not because they are fully ramped, but because contribution is how ramping happens.
  • A first task that is small, scoped, and shippable in week 2.
  • Pairing or shadowing on a real piece of work in week 3.
  • Independent ownership of a small project by week 4 or 5.
  • Code review, design critique, or equivalent peer feedback from the start.
The first task matters. Pick something that touches the main systems but cannot break anything important. Something that ships gives confidence and visibility.
到第2或第3周，新成员应开始做出实际贡献。并非因为他们已完全上手，而是贡献本身就是上手的过程。
  • 第2周安排一项小型、范围明确且可交付的初始任务。
  • 第3周参与真实工作的配对协作或观摩学习。
  • 第4或第5周独立负责一个小型项目。
  • 从一开始就提供代码评审、设计评审或同类的同伴反馈。
初始任务至关重要。选择既涉及核心系统但又不会破坏重要功能的任务。完成交付能提升信心和可见度。

Layer 4: Mastery (Month 2 to Month 3)

第四层：能力精通（第2个月至第3个月）

By the end of 90 days, the new person should be a full member of the team.
  • Owning a project end to end.
  • On-call or on-rotation if the team has one.
  • Contributing to roadmap discussions, not just executing them.
  • Mentoring or supporting the next new hire.
90 days is a checkpoint, not a finish line. Document what worked and what was missing for the next person.
到90天结束时，新成员应成为团队的正式一员。
  • 独立负责一个完整项目。
  • 若团队有轮值机制，参与值班或轮值。
  • 参与路线图讨论，而非仅执行任务。
  • 指导或支持下一位新成员。
90天是一个检查节点，而非终点。记录有效经验和缺失环节，为后续成员优化。

The 30/60/90 plan

30/60/90天计划

Every onboarding plan should have explicit milestones at 30, 60, and 90 days.
每份入职计划都应在30天、60天和90天设置明确的里程碑。

30 days

30天目标

  • Workspace, tools, and access fully set up.
  • Has met every team member.
  • Understands the product, the team, and the recent context.
  • Has shipped or contributed to at least one real piece of work.
  • Has a clear picture of their first major project or area.
  • 工作环境、工具及权限全部配置完成。
  • 已认识所有团队成员。
  • 理解产品、团队及近期动态。
  • 已交付或参与至少一项真实工作。
  • 明确自己首个重大项目或负责领域。

60 days

60天目标

  • Owns a project or area independently.
  • Knows where to find answers without asking every time.
  • Has formed working relationships beyond the immediate team.
  • Has made at least one meaningful improvement to a process, doc, or codebase.
  • 独立负责一个项目或领域。
  • 知道如何自行查找答案，无需事事询问。
  • 与直属团队外的同事建立工作关系。
  • 至少对某一流程、文档或代码库做出一项有意义的改进。

90 days

90天目标

  • Fully productive in the role.
  • Participating in roadmap and planning discussions.
  • Capable of training the next new hire on parts of the system.
  • Comfortable raising concerns and pushing back.
If someone is significantly behind these markers at the 30/60/90 checkpoints, address it directly. Either the plan is wrong, the support is wrong, or the role fit is wrong. Hoping it resolves itself does not work.
  • 完全胜任岗位工作。
  • 参与路线图和规划讨论。
  • 能够指导下一位新成员掌握部分系统内容。
  • 敢于提出问题和表达不同意见。
若成员在30/60/90天节点明显落后于这些目标，需直接解决问题。可能是计划不合理、支持不到位或岗位匹配度有问题，寄希望于问题自行解决是无效的。

The role-specific overlay

岗位专属适配

The framework above applies to every role. The specifics differ.
上述框架适用于所有岗位，但具体细节有所不同。

Engineering

工程岗位

  • Day 1: dev environment running, first commit (a docs fix or trivial change).
  • Week 1: read the architecture doc, read the main service code paths.
  • Week 2: ship a small bug fix or refactor.
  • Week 4: own a feature or component.
  • Month 2: on-call shadow, then on-call.
  • 第1天：搭建开发环境，完成首次提交（文档修复或微小改动）。
  • 第1周：阅读架构文档，熟悉核心服务代码路径。
  • 第2周：交付一个小型bug修复或重构任务。
  • 第4周：负责一个功能或组件。
  • 第2个月：观摩值班，随后参与值班。

Design

设计岗位

  • Day 1: design tools set up, design system access, brand guidelines reviewed.
  • Week 1: studio crit and design review participation.
  • Week 2: own a small surface (a setting page, an empty state).
  • Week 4: lead a design review for a feature in flight.
  • Month 2: own a feature design end to end.
  • 第1天：配置设计工具，获取设计系统权限，审阅品牌指南。
  • 第1周：参与工作室评审和设计评审。
  • 第2周：负责一个小型界面（如设置页面、空状态界面）。
  • 第4周：主导一个进行中功能的设计评审。
  • 第2个月：独立完成一个功能的全流程设计。

Product

产品岗位

  • Day 1: read the strategy doc, the roadmap, and the latest 3 PRDs.
  • Week 1: shadow customer calls, attend support sync, join standup of all relevant teams.
  • Week 2: write a discovery doc or competitive analysis.
  • Week 4: own a feature spec.
  • Month 2: own a roadmap area.
  • 第1天：阅读战略文档、路线图及最新3份PRD。
  • 第1周：观摩客户访谈、参与支持同步会议、加入所有相关团队的站会。
  • 第2周：撰写一份探索文档或竞品分析报告。
  • 第4周：负责一份功能规格文档。
  • 第2个月：负责一个路线图领域。

Marketing or content

营销或内容岗位

  • Day 1: brand voice doc, recent campaigns, top performing content.
  • Week 1: customer research artifacts and persona docs.
  • Week 2: ship a small piece of content (a social post, a blog edit).
  • Week 4: own a content piece end to end.
  • Month 2: own a campaign or channel.
Adapt to your role and stack. The shape stays the same.
  • 第1天：查阅品牌调性文档、近期营销活动、表现最佳的内容。
  • 第1周：学习客户研究资料和用户画像文档。
  • 第2周：发布一份小型内容（如社交帖子、博客编辑）。
  • 第4周：独立完成一份内容的全流程制作。
  • 第2个月：负责一个营销活动或渠道。
可根据岗位和技术栈调整细节，框架结构保持不变。

Workflow

工作流程

  1. Start the playbook before the new person arrives. Do not write it on day 1.
  2. Pre-stage accounts, hardware, and access. This is the most common day-1 failure point.
  3. Assign a buddy. Tell the buddy what is expected of them.
  4. Send the welcome message and the day-1 schedule before they start.
  5. Run the first week with a focus on belonging and context, not output.
  6. Check in daily for the first week, weekly for the first month.
  7. Run formal 30/60/90 check-ins with explicit milestones.
  8. After 90 days, do a retrospective: what worked, what was missing.
  9. Update the playbook based on the retrospective. Onboarding is a living doc.
  1. 在新成员入职前开始编写入职手册，不要等到入职当天才着手。
  2. 提前准备好账户、硬件和权限。这是入职首日最常见的失误点。
  3. 安排对接伙伴，并明确告知其职责。
  4. 入职前发送欢迎消息和首日日程。
  5. 第一周重点关注归属感和认知构建，而非产出。
  6. 第一周每日沟通，第一个月每周沟通。
  7. 按计划进行30/60/90天正式检查，明确里程碑。
  8. 90天后进行回顾：总结有效经验和缺失环节。
  9. 根据回顾结果更新入职手册。入职手册是一份动态文档。

Failure patterns

常见失误模式

  • No plan. Day 1 with no schedule, no laptop, no accounts. Sets a tone.
  • Drinking from a firehose. 8 hours of meetings on day 1. People remember nothing.
  • No real work for too long. Three weeks of "reading docs" is demoralizing. Ship something small early.
  • All buddy, no manager. Buddies are great but cannot evaluate or advocate. Manager is still on the hook.
  • Tribal knowledge as gating. "Just ask Sara if you have questions" works until Sara is on vacation. Document the answers Sara keeps giving.
  • No 30/60/90 milestones. Onboarding "ends" when someone seems busy. That is not a milestone.
  • Generic plan for every role. Engineering and marketing have different first-week needs. Use the role overlay.
  • No retrospective. The same gaps catch every new hire because nobody updated the playbook.
  • Buddy with no time. Assigning a buddy who is also drowning is a recipe for poor onboarding and burnout. Protect their time.
  • Skipping the customer or product context. Engineers who do not know who the customer is build the wrong things. Marketers who do not know how the product works write thin copy.
  • 无计划：入职首日无日程、无电脑、无账户，会给新成员留下负面印象。
  • 信息过载：入职首日安排8小时会议，新成员无法记住任何内容。
  • 长期无实际工作：连续三周仅“阅读文档”会打击士气，尽早安排小型可交付任务。
  • 仅依赖伙伴，缺失经理参与：伙伴很重要，但无法进行评估或提供支持，经理仍需负责。
  • 隐性知识垄断：“有问题问Sara”在Sara休假时就失效了，应记录Sara常给出的答案。
  • 无30/60/90天里程碑：当看起来忙起来就认为“入职完成”，这不是有效的里程碑。
  • 通用计划适配所有岗位：工程和营销岗位的第一周需求不同，需使用岗位专属适配方案。
  • 无回顾环节：因未更新手册，相同问题会反复出现，影响每一位新成员。
  • 伙伴时间不足：安排已超负荷的员工担任伙伴，会导致入职质量差和员工 burnout。需保障伙伴的时间。
  • 跳过客户或产品认知：不了解客户的工程师会开发出错误的功能，不了解产品的营销人员会写出空洞的文案。

Output format

输出格式

Deliverables:
  1. Pre-day-1 checklist: accounts, hardware, access, buddy assignment, welcome message.
  2. Day-1 schedule: meeting list, intros, first deliverable.
  3. First-week reading list: 5-10 curated, annotated docs.
  4. 30/60/90 milestones: the explicit checkpoints for this role.
  5. Buddy guide: what is expected of the onboarding partner.
  6. Manager check-in cadence: scheduled 1:1s and milestone reviews.
  7. Retrospective template: to fill out at 90 days for next-time improvement.
交付物：
  1. 入职前清单：账户、硬件、权限、伙伴安排、欢迎消息。
  2. 首日日程：会议列表、人员介绍、首个交付任务。
  3. 第一周阅读清单：5-10份经过筛选、带有注释的文档。
  4. 30/60/90天里程碑：针对该岗位的明确检查节点。
  5. 伙伴指南：入职对接人的职责说明。
  6. 经理沟通节奏：安排好的一对一沟通和里程碑评审。
  7. 回顾模板：90天时填写，用于后续优化。

Reference files

参考文件

  • references/onboarding-checklist.md
    : A day-by-day, week-by-week checklist for the first 30 days, with role-specific variants and a 30/60/90 review template.
  • references/onboarding-checklist.md
    ：一份前30天的逐日、逐周清单，包含岗位专属变体及30/60/90天评审模板。