Somebody's first five days
A new person decides in the first week whether asking questions here is safe. Almost nothing you teach them matters as much as that.
Access and accounts are the easy half of onboarding and the half everyone prepares. The other half is what someone actually does with their first five days, and it is usually improvised.
Day one is about people, not tools
A new person can learn any tool in an afternoon. What they cannot work out alone is who to ask about what, and getting that wrong costs them weeks of quiet guessing.
So spend day one on names and territories: who owns which area, who to go to when something is broken, who to go to when something is unclear — often not the same person. Write it down, because nobody remembers eleven names from a single conversation, and asking for them twice feels embarrassing in a way that asking once does not.
Do not sit them down with documentation for three days
It looks thorough and it is the worst possible start. Reading about a system you have never touched produces nothing that stays, and it teaches the new person that their first week is a formality rather than work.
Give them something small and real by day two. The documentation becomes useful the moment there is a reason to read a specific page of it, and not before.
The first task should be real, small, and shippable
Real, because a practice task tells them nothing about how work actually moves here. Small, because they should finish it. Shippable, because the point is to take them once through the whole path — the board, the review, the release, the announcement — while someone is standing next to them.
What they learn is not the task. It is the shape of your process, which is the thing that takes new people longest to absorb and that no document conveys.
Make asking cheap in the first week
Everyone says "ask me anything" and almost nobody makes it easy. A new person still has to interrupt someone visibly busy, and the calculation usually ends with them guessing instead.
Name one person as theirs for the first two weeks, and put a short daily check-in in the calendar. Fifteen minutes, same time each day. It turns every question into something that has a scheduled home, so nobody has to weigh up whether it is worth interrupting for — and it is the single change that most reliably shortens how long someone takes to become useful.
Questions people actually ask
What should the first day cover?
People, not tools. Who owns which area, who to ask when something is broken, and who to ask when something is unclear — often different people. Write it down; nobody retains eleven names from one conversation.
Should a new person read the documentation first?
No. Reading about a system you have never touched leaves nothing behind and teaches them their first week is a formality. Give them something small and real by day two; documentation becomes useful when there is a reason to read a specific page.
What makes a good first task?
Real, small and shippable. The point is to walk them once through the whole path — board, review, release, announcement — with someone beside them. What they learn is the shape of your process, not the task.
