team-onboarding

Team Onboarding

When to Use

When a new engineer joins the team and needs to go from zero to productive contributor.

Process Checklist

Week 1: Environment + Context

• Dev environment set up and working (run the app locally)
• Access granted: GitHub, Slack, Jira/Linear, AWS console, staging
• Architecture walkthrough: system diagram + key services explained
• First PR: a small, well-scoped bug fix or docs improvement (day 3–5)
• Codebase tour: where is the main logic? what are the key files?
• Team norms introduced: PR process, review expectations, on-call rotation

Week 2: First Feature

• Assigned a small feature from the backlog
• Pair programming session to unblock any questions
• Code review walkthrough: how does the team review PRs?
• Intro to monitoring: how to read dashboards, what to do if an alert fires

Week 3–4: Independence

• Owns a medium feature end-to-end
• Knows who to ask for what
• Understands the deployment process
• 30-day check-in: what's unclear? what's frustrating?

Onboarding Doc Template

Include in every project's onboarding guide:

• Before day 1 (hardware, accounts to create)
• Dev environment setup (clone, install, run, verify)
• Codebase map (where is what)
• Glossary (project-specific terms)
• Key people (who to ask for what)

Core Jobs

• Get new engineer to first PR within week 1
• Document setup steps that actually work
• Assign a buddy/mentor for the first month
• Run 30-day check-in to close feedback loop

Key Outputs

• Onboarding checklist (per new hire)
• Dev environment setup script
• Codebase tour doc
• First PR within week 1

Anti-Patterns

• Onboarding = "read the docs and ask questions"
• No first PR in week 1 (reduces confidence)
• No 30-day check-in to close feedback loop
• Docs that are outdated (setup fails → immediately demoralizing)