For a lot of people – especially engineers, who can tend to be quite introvert – joining a new team can be both an exciting and nervous experience. Hopefully while recruiting you’ve used the interview process to select not only technically the best candidate but also someone who will fit into the team, which reduces the stress and risk all round. The challenge now is to bring in the new starter as smoothly as possible, and to help them settle into the team and to be productive as quickly as possible. The longer it takes for a new starter to feel like they are part of the new team, the more risk there is that they will not feel welcome and will move on quickly; meanwhile it can be very troubling for a new starter who feels like they aren’t able to contribute, while of course as a business you want to get the most from the team.
If you had more than one person involved in the selection process – especially phone or face-to-face interviews – this can help with onboarding, because when the new starter arrives they will have more than one familiar face. It’s sad but true that many team leads have more demands on their time than others, so it can be quite possible for the actual recruiting manager not to be available on day one because of meetings or other things. If this applies to you, being able to duck out of these meetings and spend time with the new team member will count for a lot. There may be an organizational culture where this doesn’t happen, and if so making this change can be beneficial. Perhaps you can send a delegate to these things – giving another member of the team a chance to see a broader context, that they might appreciate for their own progression and freeing yourself up for other things. For a new starter, unfamiliarity can be unsettling, so simply being around as someone that they recognize can help alleviate this.
A nice way to introduce new starters is via a “buddy system”. The new starter is assigned to a member of the team, who takes them under their wing. They will work on features as a pair, but more importantly, the “buddy” will help the new starter to find their way around. There is often a vast amount of information about the day-to-day workings of a company that isn’t written down anywhere, because everyone “just knows it” – except the new starter! Anything from how to get around the building with security badges, where to find things, who to ask for help, or what systems are being used will all be unfamiliar.
As a developer, there’s a quaint day 1 ritual in many teams of setting up their new machine; in some teams the new starter is simply left in a corner with some notes to do this by themselves, which is disheartening at best. In a modern team, there should be scripts for the main setup activities, and the rest should be well-documented. However, a new starter with a buddy doesn’t even necessarily need a computer on day 1 – and next to things like spending time with the team or learning about the project, setting up a computer is not top priority! If the new starter spends a couple of days pairing with someone who’s been in the team a while, working on their machine, when they do come to set up their own (with the buddy, of course) they will have a better understanding of why the steps in the setup are there, and what the end result looks like. The exception to this is messaging platforms – email, Slack, or whatever else the team use to communicate. Getting a new starter set up with the communication tools very early gives them another way they can interact with team members, and piece together a mental model of who’s who. I like tools like Slack, because a new starter can read back through recent conversations, and quickly get an idea of who their team mates are and what kind of things they talk about before joining in themselves.
The team’s standup is a great potential ice-breaker; the buddy and new starter can introduce themselves first (sometimes a new starter may be nervous, so doing this at the start means there is no time for these worries to build up), and the whole team can introduce themselves as part of their updates. I’ve seen examples where introductions are done by floor-walking, meeting lots of people in a short time; this helps the team know who the new starter is, but does little to help the new starter who can feel overwhelmed by so many names and faces so quickly. It can be better to introduce people a few at a time, and in a context of something else rather than as an exercise in its own right, so that it’s easier to link the names to things.
Another part of the buddy’s responsibilities is in showing the new starter the team’s processes and how they work. Some of this may seem strange, and teams can be defensive about these questions from someone coming from outside. In my experience, the questions a newcomer asks can be very useful as feedback for the team, because the newcomer doesn’t know the history or the reasons, and if the reasons why something is done are no longer relevant the newcomer will have no attachment to a process that doesn’t fit. Encouraging newcomers to ask “why” can highlight opportunities to improve things that the rest of the team may have overlooked because of their familiarity with the current methods. Of course there’s a balance to this, but that balance should appear quite naturally if the reasons for doing things a certain way are sound.
I like to plan a piece of work for a new starter to pick up with a buddy, to make sure there is something that is suitable. Ideally this is something where the new starter will see something of the systems the team are working on, but also where they can contribute early. Psychologically it’s important for the new starter to feel like they’ve offered value as soon as possible, and if they are thrown into something too challenging too soon it can be very harmful. If they can be involved in shaping this feature, better still – it gives them a chance to explore the problem rather than work only on a solution to something they don’t understand the full context of.