Purpose

Onboarding is the single highest-leverage investment a manager makes in a new engineer's long-term success. The evidence is clear: engineers who have a structured onboarding experience are significantly more likely to still be at the organisation in two years. Engineers who have a poor onboarding experience often cite it as a factor in leaving - sometimes years later.

Most onboarding fails in the same way. The first week is a blur of tool access, HR paperwork, and being introduced to dozens of people whose names are immediately forgotten. There is no structured ramp. There is no clear picture of what success looks like. The new engineer is expected to figure out the culture, the codebase, and their role simultaneously.

This playbook fixes that.

The goals of good onboarding:

1. The engineer feels welcomed and connected to the team within the first week
2. They understand the context - what the team does, why, and how decisions get made
3. They make a real contribution early - not token work, but something meaningful
4. They know what good looks like at their level and how they will be evaluated
5. They have a named person (buddy) who is not their manager and who they can ask anything
6. The manager knows by day 30 whether onboarding is working

When to Use This Playbook

Use this playbook when:

• You have a new engineer joining your team
• You are reviewing your current onboarding process and want to improve it
• A recent hire has told you they felt lost in their first month
• You are building a repeatable onboarding template for your organisation

This playbook is written for engineering managers but most of it applies to any technical role. Adjust the specific technical milestones (first PR, first feature) to match the role.

Before You Start

Good onboarding starts before the person joins. Most managers start thinking about onboarding on day one. That is too late.

The week before day one

Technical setup. Do not let day one become a laptop setup day. Ensure the following is ready before they arrive:

• Laptop ordered, configured, and delivered or available for collection
• Accounts created: email, Slack/Teams, GitHub/GitLab, Jira/Linear, any other tools they will need
• Access provisioned to the repositories they will work in
• Dev environment setup guide ready and tested (test it yourself - or have the buddy test it - before they arrive)
• SSH keys, VPN, and any other access configured or with clear instructions

Logistics. Confirm:

• Where they are starting (office address, floor, desk, or home address for any materials)
• Who they report to on day one if you are not available
• Where to park, badge access, or building entry if relevant
• Whether there is a welcome lunch or similar planned

The team. Tell the team before the new person arrives:

• Who is joining, what their role is, and when they start
• Ask a team member to be their buddy before they arrive (see Step 4)
• Let the team know what is expected of them - help, include, be patient

Prepare the first week plan. Not hour by hour. But a structure. What are the three things you want them to have done by the end of week one?

Assign a buddy

Before day one, assign a buddy. The buddy is:

• A peer engineer, not a manager
• Someone who has been on the team for at least six months
• Someone who is patient and communicates well
• Ideally someone who remembers what it was like to be new

The buddy role runs for the first 90 days. Their job is to be the person the new engineer can ask anything - including the things they are too embarrassed to ask their manager.

Tell the buddy explicitly:

"Your job is to be the person [name] can come to with any question, no matter how basic. You are not responsible for their work output - just their sense of connection and context. Check in with them daily for the first two weeks, weekly after that."

The Process

Step 1 - Day one agenda

Day one is not a paperwork day. It is a belonging day. The goal is that by the end of day one, the new engineer knows a few people's names, has had at least one real conversation, understands what the team does in broad terms, and feels like they are in the right place.

A good day one agenda:

Do not try to cover everything on day one. The context session should be high-level and orienting, not comprehensive. There will be time. The goal today is: they feel welcome, they know a few people, and they are not overwhelmed.

Step 2 - The first 1:1

The first 1:1 with the new engineer should happen on day one or day two - not the following week.

What to cover:

Set the tone.

"My job in the next 90 days is to make sure you have everything you need to do your best work. That means context, connections, and real work that matters. If something is not working, I want to know. I will not wait until a formal review to tell you how things are going."

Ask about them - their preferences, not their CV.

• "How do you prefer to receive feedback?"
• "What does a bad week look like for you? What makes a week feel productive?"
• "What kind of work do you find most energising? Most draining?"
• "What were you hoping this role would give you that your last one didn't?"

Share the 30/60/90 plan. Walk through what you are expecting at each stage (see Step 3). Be specific about what success looks like.

Agree the 1:1 cadence. Weekly for the first 90 days. Not fortnightly. Weekly.

Ask what is already confusing. After two days, something will already be unclear. "What is the thing that has confused you most so far?" is a better question than "how are you settling in?"

Step 3 - The 30/60/90 day framework

This is the most important structure in the playbook. It gives the new engineer a clear picture of what they are expected to do and when.

Days 1-30: Listen and learn

The primary job in the first 30 days is to understand. Not to fix things. Not to propose improvements. To understand.

What this looks like in practice:

• Shadow every significant process: sprint planning, retros, architecture reviews, incident response, on-call
• Read the relevant RFC documents, architecture decision records, and team documentation
• Have a one-to-one conversation with every member of the team (the buddy can help schedule these)
• Make the first PR in week one - a small, low-risk change: a bug fix, a test, a documentation update. The goal is to complete a full cycle: understand the codebase, make a change, get a review, merge. Not to solve a hard problem.
• Ask questions freely - and note the answers. Keep a running document of what you are learning and what is still unclear.

At the end of 30 days, the manager asks:

• "What do you now understand that you did not when you arrived?"
• "What is still unclear?"
• "What surprised you?"
• "How does the actual team compare to what you expected?"

Days 31-60: Contribute and connect

The primary job from day 31 is to contribute meaningfully - with enough context to make good decisions.

What this looks like in practice:

• Own a full feature or piece of work from start to done (not "worked on a feature" - owned one end to end)
• Participate actively in planning and design discussions - not just listening
• Begin building relationships beyond the immediate team: product manager, design, adjacent engineering teams
• Start to identify one area where they can see an improvement and discuss it with their manager
• Begin to take on code review responsibilities for peers

At the end of 60 days, the manager asks:

• "What have you contributed that you are proud of?"
• "Where do you feel confident? Where do you feel less confident?"
• "What is the one thing that is still making you less effective than you want to be?"
• "Do you feel like you know the people you need to know to do your job well?"

Days 61-90: Operate independently

By day 90, the engineer should be operating with the same level of independence expected of someone at their level who has been on the team for a year. They may not have all the context yet - but their working patterns, their approach to problems, and their relationships should be fully formed.

What this looks like in practice:

• Making decisions on medium-complexity work without needing to check in on every step
• Contributing to architecture discussions with a point of view, not just questions
• Unblocking themselves most of the time
• Having opinions about how the team works and raising them appropriately
• Starting to mentor others or pair actively with less experienced colleagues (if at a senior level)

At the end of 90 days, the manager has a formal check-in:

• Review progress against the 30/60/90 plan explicitly
• Share honest feedback about what is going well and what needs to develop
• Agree a development focus for the next six months
• Ask: "Is this role what you expected? Is there anything you need from me that you are not getting?"

Step 4 - The buddy's role in detail

The buddy is not a mentor. They are a guide. The distinction matters.

A mentor helps someone develop professionally - long-term, developmental. A buddy helps someone navigate a new environment - short-term, operational.

The buddy's job:

Questions to suggest the buddy asks in check-ins:

• "What confused you today?"
• "Is there anyone you want to meet that you haven't yet?"
• "What are you still not sure about how we do things here?"
• "Is there anything you didn't want to ask in front of the team?"

At the end of month three, the buddy and manager should have a brief conversation: "How do you think onboarding is going? What did we miss?"

Step 5 - Structuring early contributions

The first contribution matters more than most managers realise. It sets the engineer's confidence, their sense of belonging, and their understanding of how quality is defined on this team.

Design the first contributions deliberately:

Week 1 - first PR. Small, low-risk, real. A failing test that you fix. A typo in the documentation that has always bothered you. A config change that has been sitting on the backlog. The goal is to complete the full cycle - write, review, merge - not to make a big impact. Choose something where the feedback will be kind and instructive, not overwhelming.

Month 1 - first feature. A meaningful but bounded piece of work. Something that ships. Not a prototype, not "work on the backend of this feature that hasn't launched yet." Something that gets to production and that they can point to. The complexity should be calibrated to their level - not so easy they are bored, not so hard they are stuck for three weeks.

Month 2-3 - first ownership. Something they own end to end. Not a task on a project someone else owns. A project, a component, a service - something where they are the person the team looks to for progress and decisions. This is the test of whether the previous two months of learning and contributing have built the foundation for real independence.

What Good Looks Like

A good onboarding at 30 days:

• The engineer has made at least one real contribution that shipped
• They know every member of the team by name and have had a real conversation with each of them
• They can explain what the team does and why in their own words
• They have a clear picture of what they need to do in the next 60 days
• They are asking good questions - which means they have enough context to know what they do not know

A good onboarding at 90 days:

• They are operating with the independence expected at their level
• They have at least one relationship outside the immediate team
• They can identify one thing they would do differently in their onboarding (that is healthy self-awareness, not criticism)
• Their manager has given them substantive feedback at least three times - not just "you're doing great"
• They are not thinking about leaving

A good manager through onboarding:

• Has weekly 1:1s for all 90 days without cancelling
• Gives specific, real feedback - including things that need to improve
• Does not leave all the orientation to the buddy
• Checks the 30/60/90 milestones explicitly, not just implicitly
• Adjusts the plan when reality diverges from the plan

Common Failures

The laptop setup day. Day one is consumed by IT tickets, account provisioning, and HR paperwork. The engineer goes home feeling like they have not met anyone and do not know what they will be working on. Fix: front-load admin before day one.

No buddy, or the wrong buddy. The buddy is assigned because they had capacity, not because they are good at it. Or no buddy is assigned at all and the new engineer is expected to figure things out from Confluence. Fix: choose the buddy carefully and brief them properly.

The 30/60/90 plan exists but is not used. The manager creates the plan, hands it over, and never refers to it again. At 30 days there is no check-in. At 90 days there is a vague conversation. Fix: make the 30/60/90 check-ins non-negotiable calendar events from day one.

The first contribution is too big. The manager assigns a complex, ambiguous piece of work to the new engineer to "give them something meaningful." They spend four weeks making slow progress, getting frustrated, and feeling like they are failing. Fix: start small, ship something, then increase complexity.

No feedback in the first 90 days. The manager does not want to overwhelm the new engineer with feedback while they are still settling in. The engineer reaches day 90 with no clear picture of how they are doing. Fix: feedback starts from week two. Keep it specific and kind, but start it.

Onboarding is treated as a one-way information transfer. The manager talks. The engineer listens. There is no space for the engineer to ask questions, share concerns, or push back on the way things are done. Fix: make every 1:1 two-way. Ask more than you tell.

The team is not prepared. The new engineer arrives and feels like they are an interruption. Team members are too busy to introduce themselves. Code reviews are dismissive. The culture of "we don't have time to onboard you properly" is communicated implicitly from day one. Fix: tell the team explicitly what is expected of them and why it matters.

Checklist

Before day one

• Laptop ordered and configured
• All accounts created and access provisioned
• Dev environment setup guide prepared and tested
• Buddy assigned and briefed
• Team notified of new joiner
• First week plan prepared
• First 1:1 scheduled for day one or two
• Day one agenda prepared

Week one

• Day one agenda followed
• First 1:1 completed
• 30/60/90 plan shared and discussed
• First PR identified and started
• Buddy checking in daily
• Team introductions completed

End of week one

• First PR open or merged
• Engineer knows everyone on the team by name
• Manager has checked in at end of day on day one and day five
• Any setup issues resolved

30-day check-in

• Formal 30-day check-in completed
• Progress against 30-day goals reviewed explicitly
• First feature work underway
• Three or more pieces of specific feedback given
• Buddy check-in completed
• Plan for days 31-60 agreed

60-day check-in

• Formal 60-day check-in completed
• Feature shipped or nearly shipped
• Relationships outside immediate team building
• Any concerns raised and addressed
• Plan for days 61-90 agreed

90-day check-in

• Formal 90-day check-in completed
• Progress against all three phases reviewed
• Honest feedback about trajectory shared
• Development focus for next six months agreed
• Engineer asked: "Is this role what you expected?"
• Buddy role formally concluded

Reference: Red Flags That Onboarding Is Not Working

Watch for these in the first 90 days:

Reference: First 1:1 Agenda

Duration: 45 minutes

1. Welcome and tone-setting (5 minutes) - this is what I want these 1:1s to be
2. Questions about their preferences (10 minutes) - how they work, what they need, what drains them
3. Context about the team and role (10 minutes) - what you do, how decisions get made, what matters
4. The 30/60/90 plan walkthrough (10 minutes) - what success looks like at each stage
5. Their questions (10 minutes) - anything, no question is too basic

Close with:

"You will get specific feedback from me starting this week. If I haven't given you feedback by the end of next week, please ask me for it. I want you to know how you are doing, not guess."