A new colleague’s first week is a preview of their whole first year. When access arrives on time, the workspace makes sense, and someone visibly owns their ramp-up, they start contributing within days. When it doesn’t, they spend a month quietly confused — asking the wrong people, in the wrong channels, for things that were documented somewhere they can’t find.
This guide treats onboarding as a workspace workflow: a repeatable sequence you run for every new hire, improved a little each time, instead of a heroic scramble by whoever remembers.
Onboarding starts before day one
The most valuable onboarding work happens before the new person logs in:
- Accounts and licenses requested in advance — the account, the platform license, and group memberships, so day one starts with working software, not a ticket queue.
- Access list decided on paper — which teams, channels, file libraries, and tools the role actually needs. Doing this thinking before the person arrives forces the question “why is this role in that team?” for the first time in years.
- A buddy assigned — the colleague who answers the small questions nobody wants to take to a manager.
- The welcome message drafted — where it will be posted, what it says, who it introduces.
The first hour: access and orientation
Goal: the new person can log in, knows where to look, and knows who to ask.
- Verify access together — a fifteen-minute sit-down (or call) where they open each workspace, join each channel, and confirm they can see the file libraries. Silent access gaps found now cost minutes; found in week three, they cost credibility.
- Walk through the map — the one-page diagram of teams, channels, and what each is for. If you don’t have one, creating it for the first onboarding is the forcing function that finally produces it.
- Set up their profile — photo, display name, role in the bio. Small thing; people will be meeting them through these pixels for months.
- Post the introduction — in the team’s main channel: who they are, what they’ll work on, who the buddy is. Colleagues can welcome them without hunting for context.
- Channel tour, prioritized. Start with the three channels where their work happens; the long tail can wait. Mute anything low-signal so their first experience of your chat isn’t a firehose.
- The canonical files. Open the team wiki, the handbook, and the current project’s folder together. The lesson isn’t the documents themselves — it’s that this is where documents live.
- Norms in writing. Point them at the team’s communication charter: response expectations, meeting rhythms, where decisions get recorded. If your team hasn’t written one, the template is one page — see Creating Clear Internal Communication Guidelines.
- Notification defaults set for them — help them configure alerts deliberately rather than inheriting the platform’s interrupt-everything defaults. An hour with Managing Notifications Without Losing Important Updates pays for itself in their first month.
- Assign a small, real task in week one — something that ships, uses the team’s actual workflow (a PR, a document, a customer reply), and lets them practice the tools on work that matters.
- Include them in the rhythms — the sync, the async standup, the reviews. Observing how the team actually communicates teaches more than any document.
- Schedule two check-ins — day 7 and day 30, with the manager. Same three questions each time: What’s confusing? What would you change about how we work? What do you still not know where to find?
- Harvest the beginner’s view. A new person sees friction the team has stopped noticing. Their “why is it like this?” questions are free process consulting — capture them.
- Pick someone adjacent to the role, not the busiest expert.
- Time-box it: “first four weeks, questions welcome” — an open-ended obligation quietly decays into guilt.
- Rotate the assignment; everyone who has been onboarded once is qualified to buddy the next person.
- Access trickle-in. Credentials arriving on day three teaches the new hire that the organization solves problems slowly. Front-load the tickets.
- Everything-at-once channel blast. Adding someone to forty channels in their first hour guarantees they mute all of them. Curate the start; expand later.
- No map, no charter. Without a written map of teams and channels, every new hire rebuilds it in their head — differently. The structure guide’s workspace inventory is the fix.
- Onboarding by improvisation. If each onboarding is assembled fresh by whoever’s available, quality depends on who’s around. The checklist is the cure — which is the next section.
- One-and-done. A great first day followed by silence in week two. The day-7 and day-30 check-ins exist precisely to prevent this.
- Before arrival: account and license requested · access list decided · buddy assigned · intro message drafted
- First hour: verify access together · walk the workspace map · set profile · post introduction
- First week: channel tour (top three) · open wiki, handbook, project folder · read the communication charter · configure notifications deliberately
- First 30 days: small real task shipped · included in team rhythms · day-7 and day-30 check-ins · access list refined · beginner’s feedback captured
The first week: channels, files, and norms
Goal: the new person knows how work flows, not just where buttons are.
The first 30 days: contribution and feedback
Goal: a real contribution and a real feedback loop, both early.
The day-30 check-in is also the natural moment to revisit access: add the channels they actually need, remove the ones they never open. Early access lists are approximations; refine them once.
Assign a buddy
The buddy role is deliberately separate from the manager: their job is the small questions — which channel is which, how the release process actually works, whether it’s okay to ask that in the group. A few rules make buddies work:
Common mistakes
A checklist you can copy
Adapt to your platform and paste into the wiki:
Run it twice and it will start editing itself — the checklist tells you which steps were missing, and the new hires tell you which steps were wrong. That loop, more than any single best practice, is what makes onboarding reliably good.