A new hire has shipped nothing after a month. What would a better onboarding have looked like?

Access and a buddy ready before day one, a working environment on day one, a small real change shipped in week one, a written 30-60-90 plan, weekly 1:1s and feedback on the onboarding at 30 days.

Why aim for a production change in a new engineer's first week?

It exercises the full toolchain and pipeline, builds confidence and belonging early, and surfaces environment or documentation problems while they're fresh.

What is a buddy's role in onboarding, and why not the team lead?

Day-to-day help: answering everyday questions, pairing and introductions. A peer is more approachable for 'basic' questions and has time to pair; the lead focuses on expectations, 1:1s and the 30-60-90 plan.

Onboarding New Hires — The Team Lead Handbook

Scenario

Example team: a new engineer joins the checkout team. Her laptop arrives on day three; nobody has time to pair; she spends two weeks reading code and asking questions in chat. After a month she has shipped nothing and wonders whether she made the right choice.

What you see on the team

New joiners take months to become productive.
Environment setup takes days.
New people hesitate to ask questions, or ask the same ones repeatedly.
Early resignations ("it wasn't what I expected").

The common mistake

Treating onboarding as "read the docs and ask questions" instead of a planned, social and hands-on programme.

Why it happens

Teams are busy and onboarding has no owner. Documentation is often out of date. New hires don't know what they don't know, and experienced engineers forget what was hard at the beginning. Google's research on team effectiveness highlights structure and clarity — understanding expectations and how to meet them — as one of the key dynamics (re:Work); new joiners have the least of it.

The playbook

Before day one: laptop and access ready; buddy assigned; a short welcome message with the first week's plan.

First week:

working environment on day one; pair with the buddy on setup;
architecture tour, team charter and working agreements, the ADR log;
one small, real change shipped to production through the full pipeline.

30-60-90 plan, written with the new hire:

Days 1-30:  ship small changes in two areas; join on-call shadowing; 1:1s weekly
Days 31-60: own a medium ticket end to end; present in a design review
Days 61-90: own a small project; take on-call independently; give feedback on onboarding

Buddy (not the lead): answers "stupid questions", pairs, introduces people.

Ask for feedback at 30 days on the onboarding itself; fix what was confusing — the new hire is your best documentation reviewer.

Connect socially: introduce them to people outside the team they'll work with.

What to say

Welcome message, the week before:

"Looking forward to Monday! Your buddy is Ana — she'll get you set up and pair with you on your first change, which we'll aim to ship by Thursday. Your first week's plan is in the doc linked below. Bring every question; there are no silly ones in week one — or week ten."

Trade-offs

Shipping in week one needs a prepared, low-risk task; keep a list of good first tasks.
Buddies lose time; plan it into their capacity.
Too much structure can feel rigid for experienced hires; adapt the plan with them.

Signals it's working

New hires ship a production change in their first week.
Time to independent on-call and project ownership shrinks.
Onboarding feedback leads to documentation fixes.
New hires stay and refer others.

Key points

Prepare before day one: access, buddy, first-week plan.
Ship a real change in week one; follow a written 30-60-90 plan.
A buddy handles everyday questions; plan their capacity.
Ask new hires for feedback and fix what confused them.