A new developer’s first week has a dirty secret: most of it is scheduling. The architecture walkthrough is Thursday. The product context chat is Friday. The “quick sync” about deploys got moved twice. Meanwhile your expensive new hire is reading a README that was last updated by someone who no longer works here.
Small teams can’t afford that week. The good news: if your project leaves the right trail, onboarding is mostly reading — and reading doesn’t need a calendar invite.
Here’s the playbook we use and recommend.
Day 0: the artifact check
Before day one, confirm the new hire can reach the truth without asking anyone:
- The repo — with a README that answers three questions: how do I run it, how do I test it, how do I ship it.
- The board — showing current work and live activity: open PRs, recent commits, CI state. Not a museum of closed tickets.
- The decision trail — the last handful of “why we did it this way” notes, linked from the tasks where they happened.
- The whiteboard — whatever half-formed thinking exists about the next month. New people learn more from your sketches than your docs.
If any of these doesn’t exist, that’s your pre-onboarding task — not a meeting, a fix.
Day 1: read the system, then touch it
Give them the morning to read. Not documentation for its own sake — the live system: the last ten merged PRs, the open ones under review, the board’s active column. PRs are the best architecture document ever written, because they show change, discussion, and consequence in one place.
Then, before lunch ends: a real task. Small but real — a copy fix with a test, a tiny bug with a clear repro. The point isn’t the code; it’s walking the full path (branch, test, PR, review, merge, deploy) while the stakes are trivial. Every stumble on that path is a gap in your setup docs, found on day one instead of month three.
Days 2–5: escalate scope, not meetings
- Day 2: a bug that requires reading someone else’s code and asking one question. The question gets asked async, in the ticket or PR, where the answer stays.
- Day 3: a small feature slice, end to end. First design decision they make themselves — and log. Now they’re contributing to the decision trail, not just reading it.
- Day 4: their first PR review of someone else’s work. Reviewing teaches the codebase’s standards faster than any style guide.
- Day 5: they write the one-paragraph “what surprised me” note. This is gold: it’s a fresh-eyes audit of your onboarding trail, delivered while the eyes are still fresh.
None of this requires a standing meeting. Questions land in tickets and PRs, get answered async, and become searchable history. The tenth hire reads the answers the first hire got.
The one meeting you should keep
One, not zero. A thirty-minute human conversation at the end of week one: how are you, what’s confusing, what should we fix. Onboarding is async; belonging isn’t. Keep the human part human and make everything else a trail.
This is exactly the setup Kahoona is built for: the board shows live repo activity next to tasks, decisions attach to the work, and the whiteboard holds the half-formed plans — so a new hire’s first week is reading the system, not booking it.
👉 Make your project explain itself — free to start
Related: How to run async standups from your GitHub activity · The bus factor is a documentation problem