Onboarding Engineers: The First 90 Days by Design

Q: Should senior hires get lighter onboarding?

Less hand-holding on engineering practice, and more on context. A senior engineer will figure out the codebase; what they need is the history, the constraints, the political landscape, and who to talk to — precisely the things that aren't written down. Skipping onboarding for senior hires is a common mistake that produces confident people making decisions without the context that would have changed them.

Onboarding Engineers

Onboarding is a system, not a personality trait, and treating it as one is the difference between a new engineer contributing meaningfully in three weeks and in three months. The gap is enormous in aggregate: across ten hires a year, a six-week improvement in ramp time is more than a full engineer-year of capacity, recovered from work you were going to do badly anyway.

The most useful diagnostic is the first commit. If a new engineer can't get something small into production in their first week, you've learned that your local setup is broken, your deploy pipeline is opaque, or nobody prepared work for them — and you've learned it in a way that's cheap to act on. Every organization discovers its own dysfunction most clearly through the eyes of someone encountering it for the first time.

The second thing worth internalizing is that onboarding is the only time someone will see your systems fresh. Their confusion is information you cannot get any other way, and it expires within about a month.

TL;DR

Target a meaningful commit in production within the first week. It tests your whole system.
Prepare before day one — accounts, hardware, access, and a first task waiting.
Assign a buddy (day-to-day questions) separately from a mentor (growth), and both from the manager.
Structure the first 90 days with explicit 30/60/90 goals the new hire can see.
New hires fix the onboarding docs as they go. Their confusion is your best data, and it expires.
Context beats code. Why the system is this way matters more than how it works.
Front-load one-on-ones — weekly for the first month, at minimum.
Remote onboarding needs deliberate social design. Nothing happens by accident.

The First 90 Days

The week-one deploy is the load-bearing item. It's not symbolic — it exercises local setup, the test suite, code review, CI, and the deployment pipeline, and each of those is a place where a new engineer can be stuck for days without anyone noticing.

Core Concepts

Prepare before day one

The checklist worth maintaining: hardware ordered and configured, email and SSO, repository and cloud access, Slack channels and calendars, the on-call tool, the design tool, VPN, and any vendor accounts. Assign a person to own it — it's nobody's job by default, and that's exactly why it fails.

Also prepare the work. A first task chosen in advance — small, real, visible, and with a clear definition of done — is worth more than any welcome package. Keep a labelled backlog of good-first-issue items so this isn't a scramble each time.

Buddy, mentor, manager

Three distinct roles, and collapsing them into one overloads whoever holds it:

The buddy matters most in week one and is the most commonly skipped. A new engineer with an explicit "ask me anything, no question is too small" person asks questions; one without spends two hours on something a thirty-second answer would resolve, because interrupting strangers feels expensive.

Being a buddy is also good practice for mid-level engineers — it builds the explaining-and-context-setting skill that tech leads need.

Context over code

New engineers can read code. What they can't recover from the repository:

The most efficient way to transfer this is documented and conversational: an architecture overview and a set of ADRs they read, plus a walkthrough with someone who was there. Reading the last three postmortems is unusually high-value — it teaches the architecture, the failure modes, and the culture simultaneously.

The onboarding buddy loop

Make this an explicit expectation, stated on day one: "part of your first month is fixing our onboarding documentation." It gives them an immediate legitimate reason to make changes, it produces a genuinely useful contribution, and it captures the outsider perspective before it evaporates. Everyone loses this ability within about a month, permanently.

Remote onboarding

Everything above still applies, plus explicit design for what used to happen by accident:

The failure mode is a new remote hire who is stuck, doesn't want to interrupt anyone, and spends three days on something. In an office you'd notice. Remotely, you won't unless you ask.

Best Practices

Ship something to production in week one

Small, real, and deployed. It builds confidence, it proves the pipeline works, and it surfaces every broken step in your setup while someone is looking at it with fresh eyes.

Keep a stocked backlog of first tasks

Labelled good-first-issue, small, self-contained, and genuinely useful. Scrambling to find work on someone's first morning produces either something trivial and demoralizing or something too large to finish.

Write down the 30/60/90 expectations

Give it to the new hire, in writing. It removes the anxiety of not knowing whether they're doing well, and it gives you both something concrete to review. Vague expectations produce a new engineer who assumes they're behind.

Front-load one-on-ones

Weekly for the first month at minimum, and consider twice-weekly for the first two weeks. This is when problems are easiest to fix and when a new hire is least likely to raise them unprompted.

Have them fix the docs

Explicitly assigned, from day one. The value is bidirectional: they contribute immediately, and you capture the confusion that's invisible to everyone who has been there six months.

Introduce people with a reason

"This is Priya — she owns the payments service and is the person to ask about anything ledger-related" is useful. A list of names is not. Five to eight targeted introductions in the first two weeks builds the map of who to ask.

Shadow on-call before joining it

Watching an incident is the fastest way to understand a system's real shape. Have them shadow a rotation, then pair, then go solo — usually somewhere between day 30 and day 60 depending on the system's complexity.

Ask for feedback at 30 and 90 days

"What was confusing? What was missing? What surprised you?" This is the only reliable way to improve onboarding, and the window closes fast. Act on at least one thing visibly.

Common Mistakes

Nothing ready on day one

No first task prepared

Everything on the manager

Documentation dumps

Assuming they'll ask

Not measuring it

FAQ

How long should onboarding take?

To productive contribution on normal work: 30–60 days for most engineers on most codebases, and 90 for a complex domain or a large legacy system. If it's taking longer than 90 days consistently, that's a signal about your codebase's comprehensibility and your documentation rather than about your hires — and it's worth treating as a technical debt item with a real cost attached.

Should senior hires get lighter onboarding?

Less hand-holding on engineering practice, and more on context. A senior engineer will figure out the codebase; what they need is the history, the constraints, the political landscape, and who to talk to — precisely the things that aren't written down. Skipping onboarding for senior hires is a common mistake that produces confident people making decisions without the context that would have changed them.

What's the ideal first task?

Small enough to finish in one to three days, real enough to matter, touching the main paths of the codebase, and with a clear definition of done. A well-defined bug fix in a core service is close to ideal. Bad options: a task so trivial it's insulting, one so large it takes three weeks, or one in an isolated corner that teaches nothing about the main system.

How do we onboard onto a legacy system nobody understands?

Honestly, and with pairing. Say up front that documentation is thin and the system is complex — a new hire who was told to expect that is far more resilient than one who assumes they're failing. Pair heavily, use postmortems as teaching material since they document real behavior, and treat every question that has no good answer as a documentation task. Onboarding is also the best available forcing function for finally writing that architecture overview.

Does onboarding differ for a first job versus an experienced hire?

Substantially. A first-job engineer needs the professional practices too — code review norms, how to ask for help, how to estimate, how to disagree productively, what "done" means — none of which is obvious and all of which experienced hires bring. Budget more mentoring time, more explicit feedback, and more patience. The ramp is longer and the trajectory is often steeper.

How do we measure whether onboarding works?

Time to first merged PR, time to first production deploy, time to first solo on-call, and structured feedback at 30 and 90 days. Compare across hires and watch the trend. Also worth tracking: how many onboarding-doc fixes each new hire submits — a number that stays high means the documentation isn't improving, and a number that drops to zero may mean you stopped asking.