onboard-a-new-teammate

name	onboard-a-new-teammate
description	Bring a new teammate up to speed across company context, people, projects, tools, access, and first-week priorities. Use after a hire is confirmed or an internal role change is agreed, when someone needs a role-aware onboarding plan, context pack, setup coordination, and verified follow-through; do not use for recruiting decisions or offboarding.

Onboard a New Teammate

Help a new teammate understand where they have joined, get the access they need, meet the right people, and start useful work. Build the onboarding around their role and first priorities rather than handing them every document the company has.

Begin after the accepted-hire or role-change handoff. Recruiting owns candidate assessment and the offer process. This skill does not handle offboarding, access removal, retention, or employment decisions.

1. Understand the person, role, and start

Infer what is already known, then confirm only details that change the onboarding:

• the teammate's identity, role, manager, start date, location or working pattern;
• what they should understand, own, or contribute to first;
• the onboarding owner and the team's accepted policy or checklist;
• which tools, spaces, projects, meetings, and people are likely relevant; and
• what must be ready before day one versus learned during the first week.

If the role, manager, identity, or start date is not confirmed, prepare the useful context and plan but do not create accounts, permissions, invitations, or messages that depend on those facts.

2. Build the context they actually need

Use approved company sources such as Notion, Slack, Drive, project tools, calendars, org material, handbooks, files, and relevant browser tabs. Follow links through the real logged-in workspace so the user can inspect what is being included and correct stale or sensitive context.

Prioritize:

• what the company and team are trying to achieve;
• the teammate's role, near-term outcomes, and decision boundaries;
• active projects, recent decisions, current risks, and open questions they will touch;
• the people they need to know and why;
• how the team communicates, documents decisions, and gets work done; and
• a short reading path with links to the sources that remain authoritative.

Do not create an information dump. Prefer a role-aware path through current work. Flag stale, conflicting, missing, or ownerless documentation instead of silently presenting it as settled. Keep private messages, compensation, health, performance, candidate, and other sensitive material out of the teammate-facing pack unless the approved onboarding process clearly requires it.

3. Work out the right setup

Build the tool and access plan from the role, accepted policy, comparable roles, project needs, and manager input—not from the broadest access another person happens to have. Distinguish:

• required before day one;
• useful during the first week;
• optional or pending a real need; and
• blocked on identity, approval, licensing, hardware, or another dependency.

Strawberry can work through visible admin pages, forms, portals, calendars, and communication tools in the user's logged-in browser. Prepare or complete approved invitations, access requests, group membership, calendar changes, and setup messages where the user has authority. Let the user take over for identity, security, payment, or other steps that require them personally.

Show the exact teammate, account or system, access level, and action before a consequential change. Verify the result in the source system; do not mark a request complete merely because it was sent.

4. Create a practical first-week path

Bring the context, people, setup, and work into one usable plan. Adapt it to the role rather than forcing a generic 30/60/90 template. A useful result may include:

• a concise welcome and role context pack;
• the first outcomes or project to learn through;
• priority reading and source links;
• introductions and meetings with a reason for each;
• tools and access with owner, timing, and verification status;
• first-week tasks, checkpoints, and questions to resolve; and
• blockers or gaps that need an owner before the teammate starts.

Use existing meetings and real project work when they are the best way to learn. Draft welcome messages, introductions, calendar invitations, and manager notes separately so each audience sees only what they need.

5. Launch and verify the onboarding

Give the onboarding owner a compact control view: ready, scheduled, waiting, blocked, and verified. Keep the teammate-facing guide separate from the internal coordination tracker.

Send messages, invite people, change calendars, provision access, or update project systems only after the relevant action and scope are approved. After launch, check the consequential setup and surface anything that could prevent the teammate from contributing.

6. Improve the next onboarding

Use feedback from the teammate, manager, and onboarding owner to improve the reading path, setup logic, first-week shape, and verification points. Fix stale source material at its owner rather than copying corrections into a private checklist.

When the method is trusted and several people should own it, use strawberry/operations/set-up-shared-team-workflow to turn it into a team skill with clear privacy boundaries and handoffs. If the organization onboards people often, a milestone-based Routine may check the agreed onboarding tracker, calendar, access systems, and source documents before the start date and during the first week, then prepare a readiness view and draft reminders. It should leave messages and access changes reviewable and stop for missing identity, authority, policy, or sensitive context.