Onboard a New Teammate

Help a new teammate understand where they have joined, get the access they need, meet the right people, and begin useful work quickly.

Build onboarding around the person's actual role and first priorities rather than handing them every document the company has.

1. Confirm the onboarding boundary

Begin only after:

• hire is accepted;
• or internal role change is agreed.

Recruiting owns:

• candidate evaluation;
• hiring decision;
• offer process.

This workflow does not handle:

• offboarding;
• access removal;
• retention decisions;
• employment decisions.

2. Understand the person, role, and start

Infer what is already known.

Confirm only details that materially change onboarding:

• identity;
• role;
• manager;
• start date;
• location;
• working pattern;
• first outcomes;
• first responsibilities;
• onboarding owner;
• accepted policy/checklist;
• relevant tools;
• relevant projects;
• relevant meetings;
• relevant people;
• pre-day-one requirements.

If identity, role, manager, or start date is not confirmed, prepare the plan but do not create:

• accounts;
• permissions;
• invitations;
• messages

that depend on those facts.

3. Build only the context they need

Use approved company sources such as:

• Notion;
• Slack;
• Drive;
• project tools;
• calendars;
• org material;
• handbooks;
• files;
• browser tabs.

Follow links into the real source so the user can inspect what is included.

Prioritize:

• company goals;
• team goals;
• teammate's role;
• near-term outcomes;
• decision boundaries;
• active projects;
• recent decisions;
• current risks;
• open questions;
• people they need to know;
• how the team communicates;
• how decisions are documented;
• how work gets done;
• short reading path.

Avoid information dumps.

Prefer role-aware, current context.

Flag:

• stale docs;
• conflicting docs;
• missing docs;
• ownerless docs.

Do not silently present them as settled truth.

4. Protect sensitive information

Keep these out of the teammate-facing pack unless the approved onboarding process requires them:

• private messages;
• compensation;
• health information;
• performance information;
• candidate information;
• other sensitive material.

5. Build the access and setup plan

Use:

• role;
• accepted policy;
• comparable roles;
• project needs;
• manager input.

Do not copy the broadest access another employee has.

Classify access as:

• required before day one;
• useful during first week;
• optional;
• pending real need;
• blocked.

Track dependencies such as:

• identity;
• approval;
• license;
• hardware;
• security.

6. Execute setup only with authority

Use visible admin pages, forms, portals, calendars, and communication tools when the user is authorized.

Possible actions include:

• invitation;
• access request;
• group membership;
• calendar update;
• setup message.

Let the user take over when steps require:

• identity;
• security approval;
• payment;
• personal verification.

Before consequential changes, show:

• teammate;
• system;
• account;
• access level;
• action.

Verify the resulting state in the source system.

Do not mark an access task complete merely because a request was submitted.

7. Build a practical first-week path

Combine:

• context;
• people;
• setup;
• work

into one usable plan.

Do not force a generic 30/60/90 structure.

A useful onboarding plan may include:

• welcome context;
• role overview;
• first outcomes;
• first project;
• priority reading;
• source links;
• introductions;
• meetings;
• reason for each meeting;
• tool/access status;
• owner;
• timing;
• first-week tasks;
• checkpoints;
• open questions;
• blockers.

Use real project work and existing meetings when they are the best learning path.

8. Separate audiences

Draft separately where needed:

• teammate-facing guide;
• internal coordination tracker;
• welcome message;
• introduction notes;
• calendar invitations;
• manager notes.

Each audience should see only what they need.

9. Launch and verify

Give the onboarding owner a compact status view:

• ready;
• scheduled;
• waiting;
• blocked;
• verified.

Only send messages, create invitations, change calendars, provision access, or update systems with relevant approval.

After launch, verify critical setup and surface anything that could prevent productive work.

10. Improve future onboarding

Use feedback from:

• teammate;
• manager;
• onboarding owner

to improve:

• reading path;
• setup logic;
• first-week structure;
• verification.

Fix stale source material at its authoritative owner rather than copying the correction into a private checklist.

When the process becomes shared operational practice, preserve it as a team workflow with explicit privacy boundaries.

Recurring milestone checks may be appropriate for organizations onboarding frequently.

They may review:

• onboarding tracker;
• calendar;
• access systems;
• source docs.

Keep messages and access changes reviewable.

Stop when:

• identity is unclear;
• authority is unclear;
• policy is unclear;
• sensitive context changes scope.