← Back to blog

The Engineering Manager's Onboarding Kit

Most onboarding is broken. A new engineer shows up, gets buried under a pile of wiki links and Slack channels on day one, and is then left to "figure it out." By week three, nobody is checking in anymore. By month two, the new hire is either struggling in silence or has already started wondering if they made the wrong choice. This is not a new hire problem. It is a management problem.

If you are an engineering manager, onboarding is one of the highest-leverage things you do. A new hire who ramps up in four weeks instead of eight is not just productive sooner — they are more confident, more engaged, and more likely to stay. Here is how to make that happen.

Why Most Onboarding Fails

Three patterns show up over and over:

The information dump. Day one is a fire hose of docs, tools, credentials, and architecture diagrams. The new hire retains maybe 10% of it. The rest is noise that makes them feel behind before they have even started.

No structure after week one. There is a first-day checklist, maybe a first-week plan, and then nothing. The assumption is that once someone has a laptop and access to the repo, they are good. They are not. The hardest part of onboarding is weeks two through eight — when the novelty wears off and the real learning begins.

The buddy system without accountability. Assigning a buddy is fine. But if the buddy has no clear responsibilities, no time allocated, and no check-ins with you, it is just a name on a document. A buddy without structure is a stranger who said hi on day one.

A Week-by-Week Onboarding Plan

Week 1: Orientation and Setup

The goal is not productivity. The goal is comfort. Get their environment working, introduce them to the team, and give them enough context to understand what the team does and why. Pair them with someone for a codebase walkthrough — not a comprehensive tour, just enough to know where things live. Schedule their first 1:1 with you for the end of the week.

Week 2: First Contributions

Assign a well-scoped starter task. This should be a real task, not busywork. A small bug fix, a documentation improvement, or a minor feature that touches the core codebase. The point is to get them through the full cycle — writing code, opening a PR, getting a review, and shipping — as quickly as possible. That first merged PR matters more than you think.

Weeks 3-4: Increasing Ownership

Start expanding scope. They should be picking up tasks from the sprint board with less hand-holding. Encourage them to ask questions in team channels instead of just DMing their buddy. By the end of week four, they should understand the team's current priorities and be able to contribute to planning discussions.

Months 2-3: Full Integration

By now they should be operating like any other team member. They own features end-to-end, participate in code reviews, and have opinions about the codebase. If they are not at this point, that is a signal — and the fix is usually more structure earlier, not more patience later.

The Manager's Role vs the Team's Role

Your team handles the technical onboarding: codebase access, environment setup, architecture explanations, code review norms. Your job is everything else: setting expectations, checking in on how things are going emotionally, removing blockers, and making sure the new hire is not falling through the cracks.

Do not delegate all of onboarding to the team. You are the person who sets the tone. If you treat onboarding as important, your team will too. If you treat it as an interruption, they will pick up on that instantly.

The First 1:1 with a New Hire

Schedule this at the end of their first week. It is not a status update — it is a relationship-building conversation. Cover these four things:

Expectations. What does success look like in the first 30, 60, and 90 days? Be specific. "Get comfortable with the codebase" is not an expectation. "Ship your first feature by week three" is.

Communication preferences. How do they prefer to get feedback? How often do they want to check in? Do they prefer Slack, video calls, or in-person? Ask, and then actually follow through.

Growth goals. Where do they want to be in a year? Understanding this early lets you shape their onboarding around their ambitions — not just the team's immediate needs.

Open space. Ask what is confusing, what surprised them, and what they need from you. Then listen.

Technical Onboarding Checklist

This should be a document that lives somewhere permanent, not an email that gets buried. At minimum:

  • Dev environment: Local setup guide, required tools, access credentials
  • Codebase walkthrough: High-level architecture, key directories, where to find what
  • Architecture overview: System diagram, key services, how data flows
  • First PR: A pre-identified starter task they can ship in week one or two
  • CI/CD pipeline: How code gets from their laptop to production
  • Testing expectations: What needs tests, what the coverage expectations are
  • On-call and incident response: Even if they are not on-call yet, they should understand how it works

Assign a specific person to walk them through each item. "Read the wiki" is not onboarding.

Cultural Onboarding — The Stuff Not in the Wiki

Every team has unwritten rules. How are technical decisions actually made — is it the tech lead's call, or is it consensus? What is the real expectation around working hours? How does the team handle disagreements in code reviews? Is it okay to push back on a sprint commitment?

You need to say this stuff out loud. New hires will not ask, because they do not know what they do not know. In your first few 1:1s, explicitly walk through how the team operates beyond the official process. Share the norms, the shortcuts, and the things that only make sense once someone tells you.

How to Know If Onboarding Is Working

Watch for these signals:

  • They are asking questions. Silence from a new hire is a bad sign, not a good one. If they are not asking questions by week two, they are either stuck or afraid to look incompetent.
  • Their PRs are getting smaller feedback loops. Early PRs should need significant review. By week four, the comments should be about style, not substance.
  • They are contributing to discussions. In standups, in planning, in Slack. If they are still just listening after a month, something is off.
  • They can explain what the team is working on and why. Not just their own tasks — the team's priorities and how their work fits in.

If you are not seeing these signals, do not wait. Pull them into a 1:1, ask what is blocking them, and adjust the plan.

Common Mistakes

Overwhelming with information. Spread it out. Nobody retains a full-day orientation. Deliver context just-in-time, when it is relevant to what they are actually working on.

Not checking in enough. Weekly 1:1s are the minimum during the first two months. Some new hires need more. Do not assume no news is good news.

Assuming they will "figure it out." Some will. Many will not — at least not as quickly as they could with proper support. The engineers who look like they are ramping up fast are usually the ones with the most structured onboarding, not the most talent.

Treating onboarding as a one-time event. It is a process that takes two to three months. If your onboarding plan ends after week one, you do not have an onboarding plan.

Build the System Once, Use It Every Time

The best onboarding is repeatable. Document your week-by-week plan, keep your technical checklist updated, and track how each new hire is progressing. If you are managing onboarding across multiple hires — or you want to build a structured first-90-days plan with 1:1 templates built in — Gemba handles exactly this. It gives you onboarding tracking, structured 1:1s, and a clear view of how your new hire is ramping up, so nothing falls through the cracks.

Your next new hire deserves better than a wiki link and a "good luck." Give them a plan.