I've hired nearly a dozen members to my teams in the last year. The process of on-boarding was sometimes more and sometimes less successful. Here are some of the things that worked for us:
Everything is easier when you have an experienced guide. In a new job, a person who's been working at this company for at least a few months can be great at this. While I've never formally assigned a buddy, it clearly pays off when a new starter has someone that they work with closely from day one. The manager is not a good buddy, they are usually too busy.
The good news is there is lots of flexibility in who can be a buddy: I've seen good buddies that worked in different teams and had different responsibilities. It is also ok to assign a more Junior person as the buddy to a new Senior hire. Buddies can take you to lunch, introduce you to the right people or even just help you find the bathroom.
I realise this sounds like I'm contradicting my previous statement, but I'm not. In the first week, a developer will need to figure out what the people around them are doing. Make sure that the whole team can introduce themselves as experts. Alice can tell your new hire about Section A off the app, Bob about Section B, Charles will tell her about Section C.
This helps your existing team reflect on what they are working on and the new hire knows whom to come to with questions.
In the first 4 weeks, a new hire will have tons of questions. If you're anything like me, you're busy for most of the day and that doesn't seem particularly approachable. In the first 4 weeks it is essential that you have reserved at least 30 mins per week for 1:1 time with your new hire where they set the agenda. And you need to make sure you spend a lot more time with someone more Junior, 30 mins works for an experienced Senior.
Afterwards you can reduce it to 30 mins every 2 or 3 weeks, but in the beginning is when you will learn most about your new hire: How they like to receive feedback, if they prefer to come to work early or work late, etc.
If your deployments are small and low risk, make sure that your new hire's first contribution lands in production in the first week. When you're taking a new job, you're very worried about messing up your first task, so try to make it as easy as possible to succeed. This will instil confidence in your new team member and teach them about many possibly mysterious processes. If your process doesn't currently allow for developers to deploy their own code, that's fine. Just make sure that the first contribution lands in production quickly and successfully.
In recent months I've asked my whole team to interview candidates. These complement some deeply technical interviews with only 1 or 2 interviewers. Your team should know what's important to their new colleague and if it's someone that they can imagine working with. When your team is involved in the hiring process, it will be easier to build trust between the new hire and the existing team.
Next I'll write about hiring.