Software Engineer onboarding plan
Engineers learn a codebase by changing it. Onboarding should get them to a working environment and a small shipped change fast, then widen scope through progressively larger work.
What good onboarding achieves
Deliver scoped work independently through your review and deployment process, and understand the parts of the system they own.
Week one example
- Day 1: Laptop, repository and tooling access; meet the team and buddy.
- Day 2: Local environment running; architecture overview from a senior engineer.
- Day 3: Pick a small, well-scoped issue; read the relevant code.
- Day 4: Open a pull request and go through code review.
- Day 5: Ship the change through the normal deployment path; retro with buddy.
30/60/90 progression
- Day 30: Ships small changes regularly and understands the deployment path.
- Day 60: Delivers a scoped feature end-to-end with normal review.
- Day 90: Owns a component or joins on-call, and reviews others' code.
People to meet (examples)
- Engineering manager
- Onboarding buddy
- Product manager for the team
- Someone who knows the deployment and on-call process
Systems to learn (examples)
- Source control (for example GitHub or GitLab)
- Issue tracker
- CI/CD pipeline
- Error monitoring and logging
- Internal docs or runbooks
Manager checkpoints
- Day 5: first change shipped
- Week 3: code review quality discussion
- Day 45: first feature scoped
- Day 90: ownership area agreed
Common mistakes
- Days lost to environment setup with no help
- A first task that is too large or vague
- Reading docs for weeks instead of changing code
- Not explaining the review and release norms
Checklist
- Repository and tool access
- Local environment running
- Architecture overview done
- First issue assigned
- First pull request reviewed
- First change deployed
- On-call and incident process explained
- Ownership area discussed