Note: these tips are for internal management transfers. If you’re onboarding someone new to the organization, you’ll probably need to do additional steps (including most of these steps, but a lot of additional ones).

Things to do

• Update your "About me" document, so that they can easily learn about your working styles/preferences, and refer to it when they are uncertain.
• Set up regular meetings
• Be aware of the curse of knowledge. There will be lots of context and links between things that the new employee doesn’t necessarily have. This could be as simple as clarifying who people are and how they are connected to us when you mention someone by their first name, but it can also involve explaining the basics of how some of our systems work, or why we chose to do things in a particular way.

Draft notes for one of the first 1:1s:

• Please read my "About Me" [link], and let me know if you have any questions, e.g. about:
• 1on1s
• Scheduling
• Templates/documents that you use, when they need to be filled in by.
• About me
• Other getting-to-know-you type things
• Special request: As you get acquainted with this new role, new colleagues, meetings etc, you’re likely to notice things that we could be doing better. This can be a real sweet-spot, where you get to see a lot of the details of how we work, but still have enough external perspective to notice mistakes we’re making. So I’d love it if you could keep track of things that we could do better, and share them with me. You could create a document, shared with me, to note things down.
• When working with someone new, I find it useful to check in early and often on projects, and proceed iteratively. Especially on open-ended work, I find that a new person going away for multiple weeks to work on their own without checking in purposes and intermediate products often results in wasted time and frustration. Much more frequent checking in about purposes and interim products tends to result in earlier course correction, and faster progress and iteration.
• I encourage you to Slack me liberally and request extra meetings if you think it would be helpful. When making such requests, I think it's best if you consider it my responsibility, rather than yours, to protect my time.
• I expect to become much less involved over time. I.e., I think this explicitly makes sense for early working relationships and that it makes sense for it to change over time.
• We should set or update your role description and goals
• Let's discuss your desires/needs from me as a manager. In particular, it would be great if you could respond to these prompts:
• What would you like to accomplish in the next year?
• What do you need from me to be successful?
• Any worries you have about this new job?
• If something went wrong here, what do you think that might be?
• What should I know about working with you?
• What are some things that previous managers did that you liked?
• What are some things that previous managers did that you didn’t like?

Some extra notes

A bit more relevant to onboarding someone to the org:

• On the first day, ask them “if you fail probation in 3-6 months, what do you think the most likely reasons are”, then sync up on that, so you’re aligned on the 1-3 key ways that you think they could fail. Then, from the start they know what they need to be working on, what you’re expecting from them etc.
• (Before you do this exercise you should have thought yourself about the 1-3 key ways they might fail, which you probably have from the hiring process. But asking them might uncover new things, and will help them to own the model more deeply.)
• Also highlight their strengths and why you’re excited to work with them - it shouldn’t overall feel gloomy/negative, just syncing up on risks that you both want to avoid!
• Make a plan for their first day and their first week.
• In the first day, give them like half a day just to get on to systems / get basic context.
• In their first week, set up extra meetings with key colleagues etc.
• Review the role description and goals. Then get them to draft a plan for their first 30 / 60 / 90 days (which should include both outputs and learning)
• Initially, it might be quite weighted towards learning and getting up to speed. But try to help them get some cheap object-level wins in their first day / week too.
• E.g. for someone I onboarded this was “draft a budget for the program”
• Towards the end it’ll be mostly outputs
• Getting them to draft this gives them more ownership
• Invest early in feedback on small bits of work, especially positive feedback. Again, this helps set the culture and establish what you need to see for them to succeed.
• you'll probably need to spend several hours brain dumping / sharing context with them