What onboarding is for
Onboarding has three jobs: give the person what they need to work (accounts, access, a working environment), give them the context to make good decisions (the product, the codebase, the team’s habits) and help them feel part of the team. The first is easy to forget until day one, and the third is easy to forget altogether.
Before day one
- Accounts, access and equipment are ready and tested.
- A buddy is chosen and has time set aside.
- The first week’s calendar has the right meetings and no empty days.
- A short note has gone to the team to say who is joining and when.
- The first task is chosen, small and real.
The first day
- Welcome in person or on a call, and a walk through the day.
- A working development environment by lunch. If it takes longer, fix the setup guide.
- Meet the team, and say what each person does.
- Read the product overview, and see the product being used.
The first week
- Ship something small: a fix or a tiny change, end to end, through review.
- Read the key specs and decision records.
- Pair with the buddy on a real task.
- A check-in at the end of the week: what was unclear, what would have helped?
The first month
- Own a real piece of work, with a clear owner on the card.
- Join planning and the retrospective.
- A one-to-one at 30 days: how is it going, what do you need, what should we change?
- Ask the new person to improve the onboarding doc. They see its gaps better than anyone.
Keep the onboarding doc alive
An onboarding document that is not updated is a trap. Make the newest person responsible for fixing every wrong step they hit, and review it each quarter. Link the doc from the team’s main page so it is easy to find.
A 30-60-90 day plan
| Period | The aim | What it looks like |
|---|---|---|
| First 30 days | Learn | Set up, ship a small change, meet the team, read the key specs and decisions |
| Days 30 to 60 | Contribute | Own a real piece of work, join planning and reviews, give feedback on the process |
| Days 60 to 90 | Own | Lead a feature or a fix end to end, help the next new person, set goals for the next quarter |
First 30 days
The aim
Learn
What it looks like
Set up, ship a small change, meet the team, read the key specs and decisions
Days 30 to 60
The aim
Contribute
What it looks like
Own a real piece of work, join planning and reviews, give feedback on the process
Days 60 to 90
The aim
Own
What it looks like
Lead a feature or a fix end to end, help the next new person, set goals for the next quarter
What goes in the onboarding doc
- How to set up the environment, tested by the last new person.
- A map of the product and the codebase, with links.
- The team’s habits: how work is planned, reviewed and released.
- Who to ask about what.
- Where the specs, the decisions and the plans live.
- The first-week plan and the first task.
Mistakes to avoid
- Leaving the first day empty, so the new person sits with a laptop and no plan.
- Starting with the largest task in the codebase. Start small and finish it.
- Assuming that silence means everything is clear. Ask, and ask again at the end of the first week.
- A buddy who has no time set aside. A buddy needs hours, not good intentions.
- Onboarding that ends after the first week, when the real questions are only starting.
Onboarding in Kanso
Write the checklist as a doc with to-dos, copy it for each new person and assign the first task on the board. Add them to the right chat channels, give them a role that fits, and share read-only links to the key pages for anyone who is not yet a member.
