Onboarding and offboarding

Both ends are cross-functional processes that fail at the handoffs. The failures are predictable, which means they are preventable by design rather than by diligence.

Onboarding starts before day one

Everything procurable in advance should be ready: accounts, hardware, access, a first assignment, and a named person responsible for the human side. A first day spent waiting for a laptop is a permanent first impression, and it is entirely a coordination failure.

The identity and equipment steps are executed by it-operations:identity-lifecycle-administration and it-operations:endpoint-management; access policy — what a role should be entitled to — belongs to security:access-and-identity. This skill owns the sequence and whether it actually completed.

Ramp deliberately

Separate the three things a new person is learning, because they need different support:

• The job — often the part they already have.
• The context — the systems, the codebase, the customers, the history.
• The people — who decides what, who to ask, how things really get done.

The third is the one nobody plans and the one that most determines how quickly someone becomes useful. Make introductions explicit assignments rather than leaving them to chance and extroversion.

Give real work early, scoped to succeed. A meaningful contribution in the first fortnight does more for confidence and belonging than any amount of orientation material.

Check in at deliberate intervals — a week, a month, a quarter — with the question phrased so problems can surface. "What has been more confusing than it should be?" gets an answer; "how's it going?" does not.

Offboarding: knowledge before access

Knowledge capture has to precede the access cutoff, which means starting on the day notice is given, not the day before departure.

Prioritize what is genuinely undocumented and only in one head: the systems they alone maintain, the relationships they hold, the decisions whose reasoning exists nowhere. Ask directly — "what will break, and who will not know why?" — because they know and will usually say.

Then run the mechanical steps as a checklist with an owner: access revoked across every system including those outside single sign-on, assets returned, delegations and approvals reassigned, and handover confirmed by the person receiving it rather than by the person leaving.

Exits are data

Exit conversations produce candid information that is unavailable any other way, and it is routinely collected and never used. Aggregate themes over time and look by manager and by team; a single exit is an anecdote, a pattern across four is a finding for people:chief-human-resources-officer.

Sources

references/sources.md in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding.

Tooling

HRIS as the record of who works here and when they started or left: Workday, BambooHR, Rippling, HiBob, Gusto, ADP, and similar.

Onboarding workflow: the HRIS's own, or Sapling, Enboarder, or a checklist in the ticketing system, and similar.

Offboarding has to reach identity, devices, and payroll the same day. Whatever the tools, one owner runs the checklist end to end. Split ownership is how accounts stay live.

Never

• Let a start date arrive without access and equipment confirmed ready.
• Leave relationship introductions to chance.
• Cut access before knowledge capture has happened.
• Collect exit feedback nobody ever reads in aggregate.