Get a new person to a first real shipped thing in five days — access on day one, a buddy, a done definition — instead of a wiki dump and a calendar of talks. Use when someone starts, when a teammate rotates in, or when onboarding still means "read Confluence."
--- name: onboard-someone-in-a-week category: productivity description: >- Get a new person to a first real shipped thing in five days — access on day one, a buddy, a done definition — instead of a wiki dump and a calendar of talks. Use when someone starts, when a teammate rotates in, or when onboarding still means "read Confluence." --- # Onboard Someone in a Week The goal of week one is not that they have heard the architecture. It is that they **changed the product in a way that reached users or the repo**, and they know who to ask next. Everything else can wait. A week of talks produces a person who can recite the diagram and still cannot ship. Shame on the diagram. ## Done on Friday is a real artefact Write Friday's definition **before they start**, with their manager: > By Friday they have merged X (a real, small, reversible change) and > run Y (the command this team actually uses). They know who owns Z. X is not "set up the laptop." Access is Tuesday morning's problem at latest, preferably Monday. A first week blocked on VPN and a missing licence is a process failure with their name on the calendar. Examples of honest X: - A docs typo that was actually wrong, through the real review path. - A copy change in an empty state. - A test that pinned a bug they were handed. - A small bug in a service they will live in, with a buddy on the review. If X is "finished the onboarding checklist," you have measured compliance, not onboarding.
You are reading the opening of this skill.
The rest is open to any signed-in account — free included. Reading the library costs nothing.
Shared publicly by the author and open for any use. See the Terms.