Shipping in week two
New hires on my teams ship production code in their second week. Not because they are special, but because onboarding is designed backwards from that moment. What the first ten days look like and what I stopped including.
I used to run onboarding as a reading list. Architecture docs, team norms, the history of the service, a tour of the repositories. New engineers spent two weeks reading and, at the end of it, knew a great deal about the system and had touched none of it. Their first real change usually landed around week five, and their first month was mostly the anxious feeling of not yet contributing.
The onboarding I run now starts from the other end. The goal is a production change in week two. Everything in the first ten days exists to make that possible.
Day one is a working environment
The single biggest predictor of a good first month is whether the person can run the system on their machine by the end of the first day. Not the first week. The first day.
So the setup is scripted, tested by the last person who onboarded, and the new hire's first task is to run it and file a ticket for everything that broke. That ticket is their first contribution. It is small, it is real, and fixing the setup for the next person is a better introduction to the codebase than any document.
The first change is chosen, not found
I pick the first production change before the person starts. It has three properties: it is genuinely useful, it touches the main path through the system, and it is small enough to review in fifteen minutes. A bug in the logs, a missing validation, a config that should be a flag. Not a documentation fix, because documentation fixes do not teach the deploy path.
The change is assigned on day two with a named buddy who has already looked at it. The buddy's job is not to do it. It is to answer the questions that the docs cannot, quickly, and to review the pull request within an hour of it being opened. Nothing kills a new hire's momentum like a first PR that sits for three days.
The people, in the first week
By the end of week one, the new person has had a thirty minute conversation with every engineer on the team, and with the two or three people outside the team they will work with most. I schedule those, because new people will not. The conversations have one prompt: what do you work on and what do you wish someone had told you when you started.
Those conversations do more for a new hire's sense of belonging than any welcome message, and they build the map of who to ask, which is the real onboarding document.
What I stopped including
The history lesson. Nobody needs to know why the service was rewritten in 2021 in their first week. They need to know how to change it now. The history comes up naturally when it is relevant, and by then they have context for it.
The full norms document. I replaced it with one page: how we review, how we deploy, when to ask versus dig, and what to do if something breaks. The rest they absorb.
The long silence. New hires used to be left alone with their reading, on the theory that they needed space. They need the opposite. A daily check in for the first two weeks, five minutes, from me or the buddy. What did you do, what are you stuck on, what do you need.
The thirty day conversation
At thirty days I sit down with the person and ask what was confusing, what took longer than it should have, and what they would change about the first month. Then I change it. Onboarding is the process on my team that improves fastest, because every new hire is a fresh audit of it and I treat their notes as a bug list.
What AI did to onboarding
When we moved to an AI first way of working, the questions that used to consume a buddy's afternoon started going to the tool first. Where is this pattern used, what does this configuration do, why does this test exist. The buddy's role shifted from answering to reviewing: is the tool's answer right, and is the change the new hire produced with it something we would ship.
That shift is what made week two realistic instead of aspirational. It also raised the stakes on the review, because a new hire with a capable tool can produce a plausible change to code they do not understand yet. So the first month's rule is explicit: every line, explained out loud to the buddy, before it merges. By week four they do not need the rule anymore, and by then they have shipped three things.