Engineering Manager's Guide to Onboarding a New Developer Fast

2026-07-13 · 7 min read · Hiring & Onboarding

Most engineering onboarding is accidental. There's usually some documentation, a laptop setup guide, and a general expectation that the new engineer will "figure it out" by asking questions and reading code. This works eventually, but it's slow, wasteful, and leaves new hires feeling more lost than they need to be.

Good onboarding isn't just about getting someone up to speed faster — it's about setting the foundation for how they'll work on your team for years. The investment in the first 30 days pays back for the entire tenure.

The Three Things New Engineers Need

Before designing an onboarding plan, it helps to be clear about what a new engineer actually needs to be effective:

Context: Why does this team exist? What are we trying to build? What decisions have been made and why? Without this, new engineers can't make good decisions — they're just executing instructions.

Technical orientation: Where is everything? How does the system work? What's the development workflow? How do we deploy? Where are the sharp edges?

Relationships: Who does this team work with? Who can I ask when I'm stuck? Who makes which decisions? The informal map of the organisation is often more important than the org chart.

Most onboarding programmes address technical orientation reasonably well and badly underinvest in context and relationships.

Week 1: Orient, Don't Overwhelm

The first week is not about productivity. It's about orientation. Don't put pressure on the new hire to ship anything — the goal is for them to understand enough to function in week two.

Day 1 agenda:

That first 1:1 matters more than you might think. It sets the tone. Come prepared with genuine questions: "What made you choose this role?" "What are you most excited to work on?" "What concerns do you have?" This signals from day one that you're invested in them specifically, not just filling a headcount.

Documentation review, not documentation dump. A new hire who receives 40 Confluence pages on day one will retain none of it. Curate ruthlessly: what are the three or four documents that will be most useful in the first two weeks? Point them at those and nothing else to start.

Week 2: Get Into the Code

By week two, the new engineer should be in the codebase. Pair programming sessions with team members are worth more than solo reading for most people — watching someone navigate the code teaches more about how work actually happens than any documentation.

The first PR should be easy but real. A good starting ticket is something small, clearly defined, and in a part of the codebase the new engineer needs to understand anyway. It should have a real outcome — fixing a bug, improving documentation, adding a small feature — not a fabricated "practice" task. Real work builds confidence in a way that made-up work doesn't.

Make the first PR review a teaching moment, not a formal evaluation. Go through it in detail. "Here's what you did well. Here's what we typically do differently here and why. Here's something to watch for in this part of the codebase."

The Buddy System

Assign a technical buddy — not you, a peer — who is the default "dumb question" contact for the first month. The value here is psychological: new engineers often don't want to interrupt the manager with basic questions. A peer buddy removes this barrier.

Choose the buddy carefully. It should be someone who:

Set explicit expectations with the buddy: "This is a real part of your role for the next four weeks, not a side task. Please check in with them proactively at least once a day."

The 30-60-90 Framework

Give new engineers explicit expectations for what success looks like at 30, 60, and 90 days. Without this, they're guessing — and they'll either aim too low (feeling unproductive) or too high (feeling overwhelmed).

A rough framework:

30 days: Understands the development workflow end-to-end, has shipped at least two small changes, knows who to ask for what, can navigate the main repositories independently.

60 days: Contributing to sprint work reliably, can review PRs in their area of ownership, has formed working relationships with key collaborators inside and outside the team.

90 days: Owns at least one area or component, is raising ideas and concerns proactively, is functioning as a full team member rather than a learner.

Share this framework in writing during week one. Review it together at each milestone. This makes the expectations concrete rather than implicit.

Common Onboarding Mistakes

Leaving them alone too much. The independent nature of most engineering work makes it tempting to leave new hires to work through problems solo. This is inefficient and lonely. Check in daily in the first two weeks.

Burying them in meetings. The opposite mistake. An engineer who spends their first week in orientation sessions has less time to touch the code. Introductory conversations should be short and targeted.

Onboarding to the happy path only. Show new engineers where things break, what the known pain points are, where the legacy code is that nobody wants to touch. Understanding the problems is part of understanding the system.

Treating the 30-day mark as graduation. Onboarding doesn't end at 30 days. Formal onboarding does. The first six months still require more than the usual management attention — checking in on whether expectations match reality, whether the engineer is building the relationships they need, whether anything is getting in the way.

The Onboarding Retrospective

At 30 and 90 days, ask the new engineer to reflect on the onboarding itself: "What was most useful? What was missing? What took longer to figure out than it should have?" This feedback improves future onboarding and gives you information about whether the new engineer is where they should be. It also signals that their experience matters to you — which it does.