Craft, quality & teams · Mixed

Onboard a new developer in a week, not a month

In one line: The metric is how long until the first change in production — and most of the delay is access and local setup, not understanding code.

Prepare in advance

An orderly access list activated on day one; a local environment that comes up with one command; and dummy data that lets you work without touching real data.

Every hour wasted on permissions is an hour not spent understanding the system.

The right first task

Small, real, and touching the whole chain: code, test, review, deploy. The goal isn't the output but going through the path once with guidance.

Assign a fixed mentor for two weeks, with a set time on the calendar and not “ask if you need to” — most people won't ask.

Learn from the process

Ask the newcomer to fix the documentation in real time. A first look at a system is an asset that vanishes after two weeks and doesn't return.

Going deeper

Keep a one-page system map: the components, the main flows, and the places where most incidents occur. It's worth more than dozens of pages, and easy to maintain because it changes slowly.

Process & teams Documentation

Next: Names, structure and code you can come back to · Previous: Documentation people actually read · Back to library