Onboarding First-Week Kit

How It Works

This recipe turns onboarding into a repeatable, measurable workflow: access → local run →

first small ticket → first PR review → first merge.

Triggers

• A new engineer, QA, DevOps, or PM joins the team
• A contributor needs to work in a new repo/service for the first time
• "It takes days to get productive" keeps recurring

Steps

1. Generate an access checklist (source control, CI, secrets, dashboards, staging) with owners.
2. Define a single "happy path" setup (prefer 1 command) and validate it in CI.
3. Create a one-page architecture orientation: entrypoints, key data flows, service boundaries.
4. Select a starter task that is small, reversible, and easy to validate.
5. Pair the first PR with a "review buddy" and set a same-day review SLA.
6. Capture every onboarding bump and immediately update docs/scripts to prevent repeats.

Expected Outcome

• New contributors can run the system locally and ship a small change within days.
• Onboarding failures become visible as checklist gaps (missing access, broken docs, drift).

Example Inputs

• "New backend engineer; stack is Go + Postgres + Kafka; start date Monday."
• "New QA needs to run E2E locally and in CI."
• "PM needs to reproduce a bug and verify the fix on staging."

Tips

• Prefer repo-adjacent docs (versioned) over wikis that drift.
• Treat onboarding breakage like a production bug: fix it quickly or it compounds.