team-onboarding-playbook

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: team-onboarding-playbook
description: Design a structured onboarding experience that gets new team members productive in 30, 60, and 90 days. Use when a new hire is joining, when contractors or agency partners need to ramp up, when an existing team is restructuring and members are switching focus, or when current onboarding feels chaotic and slow. Also triggers when one person owns all the tribal knowledge and you need to capture it, when you keep losing people in their first 90 days, or when a new project has many fresh members joining at once. Useful for engineering, design, product, marketing, and operations roles.
category: process-and-team
catalog_summary: "30-60-90 onboarding plans for new hires and contractors"
display_order: 4
---

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).

## 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.

## The framework

A good onboarding plan operates on 4 layers. Build all four.

### Layer 1: Belonging (Day 1 to Week 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.

### Layer 2: Context (Week 1 to Week 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)

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.

### Layer 4: Mastery (Month 2 to Month 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 ex