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