What are the four layers of an onboarding plan?

Belonging (day 1 to week 1: getting the new person set up and connected, with a buddy who is not the manager), context (week 1 to week 4: the product, the team, the technical landscape, and the active work), contribution (week 2 to week 6: a small shippable first task, then pairing, then independent ownership), and mastery (month 2 to month 3: owning a project end to end and supporting the next hire). Build all four; the first week is mostly about belonging, not productivity, and getting it right accelerates everything after.

Why give a new hire real work so early?

Because contribution is how ramping happens, not a reward for finishing it. Three weeks of reading docs is demoralizing, so the plan includes a small, scoped, shippable first task in week 2 that touches the main systems but cannot break anything important. Something that ships gives confidence and visibility. By week 4 or 5 the new person owns a small project independently, which is how the context they absorbed becomes real capability.

Why milestones at 30, 60, and 90 days?

Because onboarding otherwise 'ends' whenever someone looks busy, which is not a milestone. Explicit checkpoints make the ramp checkable: at 30 days the person is set up, has met the team, and has shipped something; at 60 days they own an area and find answers themselves; at 90 days they are fully productive, joining planning, and able to train the next hire. If someone is significantly behind a marker, address it directly, because the plan, the support, or the role fit is wrong, and hoping it resolves itself does not work.

What is the buddy's role versus the manager's?

The buddy is an onboarding partner who answers day-to-day questions and is someone other than the manager, but a buddy cannot evaluate or advocate for the new hire, so the manager stays on the hook for those. Protect the buddy's time: assigning a buddy who is already drowning produces poor onboarding and burnout. And avoid gating knowledge on one person ('just ask Sara'), which works until Sara is on vacation; document the answers Sara keeps giving.

Does the same plan work for every role?

The four-layer shape and the 30/60/90 milestones apply to every role, but the specifics differ, so the playbook uses a role overlay. An engineer's day 1 is a running dev environment and a trivial first commit; a designer's is design-system access and a studio crit; a product hire reads the strategy doc and recent PRDs; a marketer starts with the brand voice doc and recent campaigns. A generic plan for every role is a failure pattern, because engineering and marketing have genuinely different first-week needs.

Skill · Team onboarding playbook

Team onboarding playbook.

Productive in 30, 60, and 90 days, without burning out the trainers.

A repeatable framework for ramping new team members predictably. A good plan operates on four layers, built in order: belonging in the first week, context through the first month, contribution from week two, and mastery by 90 days. Explicit milestones at 30, 60, and 90 days make the ramp checkable rather than a vague sense that someone seems busy.

The first week is mostly about belonging, not output, and real work comes early because contribution is how ramping happens. The playbook starts before the new person arrives, and a 90-day retro keeps it current.

Audience: managers and team leads onboarding a new hire or contractor, fixing a chaotic onboarding process, or capturing the tribal knowledge of someone leaving.

View the skill on GitHub Browse the full catalog

The framework

Four layers, built in order.

A good onboarding plan operates on four layers. Each accelerates the next, so the first week earns the rest.

01Belonging (day 1 to week 1): workspace and accounts ready before day 1, a buddy who is not the manager, introductions, and a day-1 schedule that is neither eight hours of meetings nor zero.
02Context (week 1 to week 4): the product and who it serves, the team and how decisions get made, the technical landscape, the recent past, and the active projects. A short, annotated reading list.
03Contribution (week 2 to week 6): a small, scoped, shippable first task in week 2, pairing on real work in week 3, and independent ownership of a small project by week 4 or 5. Contribution is how ramping happens.
04Mastery (month 2 to month 3): owning a project end to end, joining the on-call rotation, contributing to roadmap discussions, and supporting the next new hire.

Explicit milestones

Milestones at 30, 60, and 90 days.

Every plan has explicit checkpoints. If someone is significantly behind a marker, address it directly rather than hoping it resolves.

01
30 days
Workspace, tools, and access fully set up; has met every team member; understands the product, team, and recent context; has shipped or contributed to at least one real piece of work.
02
60 days
Owns a project or area independently; finds answers without asking every time; has working relationships beyond the immediate team; has made at least one meaningful improvement to a process, doc, or codebase.
03
90 days
Fully productive in the role; participating in roadmap and planning discussions; able to train the next new hire on parts of the system; comfortable raising concerns and pushing back.

Reference files

The reference that goes alongside the SKILL.md.

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.

Browse all reference files on GitHub

Bridges to other skills

The team-operations skills around onboarding.

Onboarding leans on the docs it hands to new hires, the retro that improves it, and the updates the new person learns to write.

The docs it relies on
documentation-strategy
Onboarding depends on docs that exist and stay fresh, and capturing the tribal knowledge one person keeps answering. Design that system there; this playbook puts it to work.
The 90-day retro
after-action-report
The 90-day retrospective that updates the playbook is a small after-action review: what worked, what was missing, what to fix for the next hire.
Managing up
stakeholder-communication
Part of ramping is learning to write the manager check-in and the status update. The craft of those messages lives there.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.md Browse the full catalog

Frequently asked questions.

What are the four layers of an onboarding plan?: Belonging (day 1 to week 1: getting the new person set up and connected, with a buddy who is not the manager), context (week 1 to week 4: the product, the team, the technical landscape, and the active work), contribution (week 2 to week 6: a small shippable first task, then pairing, then independent ownership), and mastery (month 2 to month 3: owning a project end to end and supporting the next hire). Build all four; the first week is mostly about belonging, not productivity, and getting it right accelerates everything after.
Why give a new hire real work so early?: Because contribution is how ramping happens, not a reward for finishing it. Three weeks of reading docs is demoralizing, so the plan includes a small, scoped, shippable first task in week 2 that touches the main systems but cannot break anything important. Something that ships gives confidence and visibility. By week 4 or 5 the new person owns a small project independently, which is how the context they absorbed becomes real capability.
Why milestones at 30, 60, and 90 days?: Because onboarding otherwise 'ends' whenever someone looks busy, which is not a milestone. Explicit checkpoints make the ramp checkable: at 30 days the person is set up, has met the team, and has shipped something; at 60 days they own an area and find answers themselves; at 90 days they are fully productive, joining planning, and able to train the next hire. If someone is significantly behind a marker, address it directly, because the plan, the support, or the role fit is wrong, and hoping it resolves itself does not work.
What is the buddy's role versus the manager's?: The buddy is an onboarding partner who answers day-to-day questions and is someone other than the manager, but a buddy cannot evaluate or advocate for the new hire, so the manager stays on the hook for those. Protect the buddy's time: assigning a buddy who is already drowning produces poor onboarding and burnout. And avoid gating knowledge on one person ('just ask Sara'), which works until Sara is on vacation; document the answers Sara keeps giving.
Does the same plan work for every role?: The four-layer shape and the 30/60/90 milestones apply to every role, but the specifics differ, so the playbook uses a role overlay. An engineer's day 1 is a running dev environment and a trivial first commit; a designer's is design-system access and a studio crit; a product hire reads the strategy doc and recent PRDs; a marketer starts with the brand voice doc and recent campaigns. A generic plan for every role is a failure pattern, because engineering and marketing have genuinely different first-week needs.