A 30-day onboarding plan built entirely in your documentation
The first month sets a new colleague’s expectations of how the company works. A plan that is current, specific and owned says more about your standards than any welcome message.
Week one: access, context and one small contribution
The first week has two jobs: remove the blockers and provide the map. Access requests, tool setup and permissions should be tasks with names against them, raised before the start date rather than discovered on the morning.
Then give the new joiner something small and real to finish by Friday. A first contribution, however minor, converts a week of reading into a week of orientation, and it exposes any setup step that is quietly broken.
Week two: the systems and the vocabulary
Every team has a private vocabulary, and nothing marks an outsider faster than not having it. A short glossary page, linked from the plan, saves weeks of guesswork and is one of the cheapest documents you will ever write.
Pair the glossary with a walk through the main systems, written down rather than delivered live. A recorded explanation can be reread; a whiteboard session cannot.
Weeks three and four: a project with an owner
By the third week the plan should hand over a piece of work with a defined scope and a named person to ask. Ambiguity at this stage is read as neglect, and it is the point at which most new joiners privately decide how the company operates.
Keep the check-in points in the plan itself, so the manager and the new joiner are reading the same document rather than reconstructing expectations from memory.
Ask the newest person to fix the plan
The person going through onboarding is the only one who can see it clearly. Ask them to correct anything wrong as they encounter it, and treat the edit as part of the work rather than a favour.
Because the change is recorded in the page history, you can see how the plan improved over a year of hires. That trail is also the most convincing argument for keeping onboarding in a document rather than a deck.
Written by the DocuRail Team.
Get the next one
One piece a month on documentation practice.
