Onboarding Plans

An onboarding plan is document that’s written for a new hire to help guide them through there first 90 days. It’s about 3 hours to write the first one. It’s 1 hour to do each one going forward. I don’t have stats; but I promise increases the success rate of onboarding to the team and I’m sure it has sped things along.

Compared to other scenario - you join a company. You’ve met the hiring manager, maybe once during the interview process for 30 minutes. You’ve been communicating with HR if large company. You have a start date, and equipment. If it’s a new startup, it’s the founder or the hiring manager, you are connecting with. The day you join - you get dropped into the Slack channel or other internal systems, and you’re first question is “What do I start with?”.

Most engineers will jump into the codebase and try to get that working. This skips learning about the company, the problem and the customers. They get the codebase working. What now? Or they don’t and they need to ping you about each tool.

The onboarding plan is a document that you include in your welcome email. You email their personal email about how to get started (if remote). You include an email or Slack message saying “Start Here” in the subject line. This message and the entire onboarding plan can be written ahead of time.

As a hiring manager, you can be busy with other stuff and make someone’s first day more complicated than it needs to be.

The onboarding plan is:

• Welcome Note - Why you are excited to have them join, what they can get excited about
• Schedule
  • What they can expect for the next two weeks and I tend to schedule per day for week 1. Week 1 is:
    • Setup admin (payroll, benefits, etc.)
    • What meetings are happening in the week (get them added to recurring meetings (All hands, eng sync, schedule welcome call with team on Day 1).
    • Learning about the company and company values. Any suggested reading.
    • Learning about the problem and any suggested reading.
    • Thursday - Friday: Environment setup and a quick fix change. Try to give it a one line change (Most accidentally give too hard because they forget about context).
    • At the end of each day, schedule 15-30 minutes to check in and answer any questions.
  • Week 2 will be a more general task list.
    • Schedule 1 on 1’s with the team. The goal is that they feel comfortable with the team and you want people to know each other. 30 minutes is plenty. Pre-book them for each team member.
    • First fix which is a smaller project that is fairly scoped. It’s your job to make sure all context is well documented, they are new to your codebase. It’s fine for job level.
    • Start tagging them on PRs of team members.
• Tools
  • Knowing what tools they should be aware of is harder than you expect. You can find our codebase here (ask XYZ for permission by messaging a username), we use GCP here (Ask XYZ for permission), we use Temporal, etc. Large companies have active directory. Startups don’t and knowing what tools to look for, who to ask for access, and why we have it is very important.
  • This includes payroll and HR tools! Make it very obvious.
• Week 1 Reading Materials
  • Anything important about the company. Why it was startup, backstory, company values, etc.
  • Anything important about the problem and customers.
  • Explain how we work. Scrum, Shape up, etc.
• 30, 60, 90 Day Plan

Some observations about the schedule:

• If they are skipping the company values and learning about the problem, but don’t have a strong background in it and going straight to the Engineering work, that’s bad sign. They will forever be busy with the codebase and this only time they can actually “catch up” on understand the problem domain.
• At end of day syncs, they have zero questions, comments, or don’t share about how the day went. That’s a bad sign.
• If they aren’t able to get the 1 line code change done, that’s a bad sign.
• If your existing team is skipping or cancelling the 1-1’s, that’s a bad sign. They don’t remember what’s it’s like to be new in a company. If it’s prioritization problem or they don’t see it as important, then I question why they are an early employee at a start up. “Many hands make light work” or the basic laws of compounding is the easiest way to explain it.

You will be busy this week. By doing all the setup a head of time, you create a way for them to move forward without you. That doesn’t mean ignore them. Check in throughout the day and at least once. If they are more junior, it should be way more often.

The final component of the onboarding plan is the 30, 60, 90 day plan. It’s to provide them with clear direction on expectations. Within the first 30 days, they are new and onboarding to the company. At 30 days, they should be onboarded. What do you expect them to know? What experience do they have from a previous company that they can bring here? At 60 days, they should be actively contributing and leading projects (If L3), but still needing assistance on some of the specific customer context. 90 days - they should feel like a seasoned vet at the company and know exactly how to continue to improve.

On day 1, setup a sync for the end of Week 2 to discuss their plan. They will author it with some guidance for you. Then setup the 30, 60, 90 day sync on each of the respective days. This would be to talk about the plan and how it went. A senior engineer should be able to nail the 30 and 60 day plan well. 90 is harder but you can still get the “area of improvement” correct. This is done at the end of week 2 because they talked to the whole team. They should have an idea of how to contribute based on those conversations.

For example, when I joined Convictional. My 30 day plan was to onboard onto the new tech stack and contribute to the product with some small features. I did that. 60 days - I was going to improve the frontend because every existing Engineer said they hated working on it, and they actively avoided it. The 90 day was specific learnings and contributing to hiring. I did that too. It doesn’t need to be perfect, but some direct you and the new hire can agree on.

Most employees start on probation of some sort and commonly it’s 90 days. This plan lets you expectation set from day 7 - 14, re-approach it on day 30 and day 60. By day 80 (I recommend putting something in your calendar), you can determine if the new hire is meeting expectations, or determine if it was a bad hire. Ideally, it’s caught way before this. But dismissing on probation vs off is very different.

The goal of this is to clearly expectation set and guide from day 1 to 14, then put together a plan from day 14 to day 90. In terms of going past that, it’s too hard to predict. You’ll have the 1-1’s keep track of individual performance.