The First 30 Days of Engineering Onboarding

Most onboarding programs are designed to protect the company, not to accelerate the engineer.

That’s the wrong frame. The fastest way to protect the company is to get new engineers genuinely productive, not just compliant.

What bad onboarding costs you

I once hired a strong senior engineer who was in the company for 45 days before shipping anything meaningful to production. It wasn’t her fault. We had no structured onboarding. She spent the first two weeks getting machine access, asking around for documentation that didn’t exist, and sitting in meetings that gave her company context but zero product context.

By day 45 she was frustrated and I was worried. By day 90 she had figured it out on her own and was performing well. But that’s three months of full salary for about six weeks of real output. And that cost came entirely from our failure, not hers.

After that, I built an onboarding structure. It’s evolved over several hires but the shape has stayed the same.

Week by week

Week 1: context, not code. Don’t push new hires to ship in week one. Use the week for architecture walkthroughs, reading past decisions, and understanding why things are the way they are. I give every new hire access to the decision log from day one, not to study it exhaustively, but so they know it exists and can reference it.

Week 2: first production change. Small. Trivially small, ideally. A config change, a copy fix, an error message improvement. The goal isn’t the change itself. It’s learning the deployment pipeline end to end under low pressure. Every team has quirks in how code gets to production. Better to discover them on a one-line PR than on a feature.

Week 3: own something scoped. A real ticket, with a real definition of done, end to end. Design, implementation, QA coordination, deployment. No handholding, but with a named person available for questions. This is where you start learning how the new hire thinks about problems.

Week 4: present and propose. The new hire presents what they’ve learned to the team, not as a performance, but as a way of consolidating their own understanding. Then they propose one concrete improvement: a documentation gap they found, a process that felt slow, a tool that would help. Even if the proposal never gets implemented, the act of making it tells you a lot about how they think.

The non-negotiables

Three things that have to exist or none of this works:

A named onboarding owner (not the manager, ideally). Someone on the team who is responsible for the new hire’s first month. Secondary ownership means nobody prioritizes it.

A starter backlog of real tickets. Not tutorial tasks, not internal tooling nobody cares about. Real work from the product backlog, scoped to be achievable in days not weeks.

A decision log covering why the system is built the way it is. Not a wiki full of pages nobody reads, but a chronological log of meaningful choices with the reasoning attached. This is the artifact that answers “why does this work this way?” without requiring an interrupt to a senior engineer.

The measure

Onboarding is measurable. Time to first merged PR. Time to first unassisted delivery. Whether the engineer can explain the system to someone else by day 30.

If those numbers aren’t tracked, you’re flying blind and paying for it in slow ramp times you’ve normalized without realizing it.