Starting a new job as an engineer can be overwhelming at with all the technologies one has to learn, the processes they have to get accustomed to, and all the new people they have to meet and create a relationship with. Getting a good grip of those things can make the difference in how it sets them up for success on the role.
In this article, we’re going to look at a few things we use at Babylon Health, and that we believe makes a good onboarding experience for new engineers. Any manager or team can leverage those to welcome new people to their team.
Why is this important?
- First impressions matter
- Structured start means happier engineer and better and faster productivity
- Happy engineers stay for longer and recommend others
- Ownership and accountability from the get to go motivate people
- Hiring is super expensive, don’t waste the investment
- An ad-hoc process is neither efficient nor scalable
First things first, when should we start onboarding new joiners? The answer is simple, straight away after they accepted the offer or signed their contract. From that moment on, they’re part of the team and you want them to feel exactly like that, they should feel not only welcome but excited to start.
The People team can do a fantastic job sorting all the paperwork, their start date and even any company inductions, but having someone arriving on day one without having had any interactions with their actual team and/or manager is a bad experience. This can be easily solved by sending them one or more welcome emails even before they start. If their start date is not that soon, inviting them for lunch or a coffee with some members of the team can be a nice touch as well. Imagine how less stressful a first day can be if they’re already familiar with their manager and even some of their new team-mates.
Who doesn’t love spreadsheets?
Sending a couple of emails before their start date sounds great, but how do you remember to send them and at the right time? And how are we keeping track of all the other things we always need to set up prior to their start date (e.g. sorting out their laptop and desk)? An onboarding spreadsheet sounds like a plan. This is a template of the Google Sheet we use in the Android and iOS teams. Have to give credit to its creator Tom Harman that was also using it in the Design team and shared it with us.
Having a sheet like this, in a checklist format and broken down in specific dates related to the engineer starting date helps us massively by keeping track of everything that needs to happen and also by keeping us, buddies (more below) and the new starter accountable for it. Our onboarding process within the Android team has a couple of these at its core. Feel free to make a copy, and if you do use it, we would love to know how it worked out for you and your team. Please comment below or tweet us @Babylon_Eng.
What’s up buddy?
As engineering managers, as much as we would love to spend more time with new starters on their initial days, this is in practice impossible with all the other responsibilities we usually have. We wouldn’t be able to give the required level of attention a new starter requires and deserves. For that reason, having a buddy system is crucial. While everyone on the team should be able to help out and onboard the new starter, having one or more colleagues dedicated to this role improves the onboarding experience massively.
By having this system in place, as managers, we can focus on the tasks and actions that really require a manager and delegate the others to the new starter buddy. The buddy should own all tasks and actions related to the project setup and codebase onboarding that generally don’t require us to be deeply involved. In our case, we decided to split the onboarding sheet in two, and have one followed by the line managers and the other by the buddies. New starters also get access to both lists from day one and are encouraged to explore both and proactively tick items off. This helps them have a sense of ownership from day one.
Would ya pair with me?
Taking a new starter through the codebase and giving them an overview of the project explaining the most important parts and even some caveats is super important and can be a very valuable experience for them, but without a few code pairing sessions, it might be just information that is not going to be properly digested, especially with a really big codebase.
It’s impossible to ensure every piece of documentation is updated when something changes, but there’s one thing we did that helped a lot with that. It’s essential to give them some time to go through the codebase and get an initial understanding of it. It’s also imperative to have a few pairing sessions to put the last pieces together and answer any questions they might have. One of the buddy jobs should be to pair with the new starter in any feature they’re working on, the more project parts it touches the better. Working on a new feature after their onboarding will become a much more enjoyable experience.
This is especially important if we have a really large codebase where there are different architectures for example or just different way of doing things. In our experience, after introducing the pairing sessions as part of the onboarding process, we started seeing way fewer questions on what’s the right way to do something, or what architecture or pattern to follow for specific parts of the codebase.
If you have to pick one thing for your onboarding process, pairing should probably be the one. It’ll not only help with all of the above but will straight away nurture a good relationship between the new starter and one or more colleagues. Not only that, the buddies themselves will see their communication and mentorship skills grow with these experiences. Plus, helping people is really rewarding so it’s a win-win situation for everyone.
Document all the things
Most people don’t really like writing or maintaining documentation, but documentation, be it technical or around team processes is important for the good functioning of the team, and especially important when new engineers join the team.
What do we want?
We want to document as much as possible, a good mix of technical and team processes documentation on top of the onboarding specific documentation (e.g. initial tasks, systems they need to get access to) provides them with a good overall picture. Adding some documentation pairing sessions with their buddy to go a bit deeper in some specific topics helps them get up to speed with everything in our project fairly quick.
When do we want it?
All the time. Keeping the project and team documentation up to date is a difficult job. Both the project and the team ways of working are evolving constantly, so it’s really important to have a process around this, otherwise, the documentation will become outdated fairly quick and eventually obsolete.
It’s impossible to ensure every piece of documentation is updated when something changes, but there’s one thing we did that helped a lot with that. All our documentation lives in the codebase as markdown files. This makes it extremely easy and quick to just open a documentation file and update it in any PR containing relevant project changes. It also allows us to have all our documentation scanned by a linter that one of our engineers wrote in their spare time. This ensures all of our documents respect the same style and also validates all the links between documents.
How do we get it?
That alone helps a lot but doesn’t solve the whole problem. Particularly any update that is not directly related with the project (e.g. ways of working or some other process), because it doesn’t happen in sync with other changes in the code base, is fairly easy not to document it straight away. While everyone on the team should have the responsibility to update any document, having a definition of ownership helps with accountability and motivating people to engage more and keep their pieces of documentation up to date.
One other thing we run in the team which has been a massive success is what we like to call documentation hackathons. We run a 2h meeting once a month where everyone in the team goes through the documentation and adds or updates anything required. We also ask new starters to provide feedback on the documentation and encourage them to open PRs and update anything they feel was missing.
What do you expect?
If we want to get the most out of new starters and want them to be happy and invested in the team, we need to set them up with proper expectations. We all want to congratulate new starters by the end of their probation period, but we can’t expect they figure out what’s required of them if they’re not given a clear path and vision of what needs to be achieved. As managers, we need to offer them the best conditions to do so, and that is a crucial part of the onboarding process.
Equally crucial is a consistent feedback loop. Handing a new starter a set of objectives and checking up on them when their probation review comes is not a solution. They should be aware of what is going to be the outcome of their probation period, and it should never be a surprise for them. If for some reason an engineer is not passing their probation and they are surprised with that outcome, they’re not the only ones at fault, we probably failed as managers as well.
The sooner we identify the issues, the better. This will allow us to work together with them on a solution and help guide their probation period to the desired outcome. On our team, for example, while the buddy system runs for around 2/3 weeks, the line managers onboarding process runs until 2 weeks after probation to provide more support to new starters.
Let’s wrap it up
In summary, onboarding is probably the most critical time an engineer goes through in a new job. The way we set them up will impact massively the way they behave and deliver afterwards.
Above are some of the tools we use while onboarding new team-mates in the Android team that have worked well for us. We scaled from around 10 engineers early last year up to almost 40 as of today, and we couldn’t imagine going through that process without these tools and helpers.
If you have any useful tools you use to onboard people in your teams, or any feedback please share, as mentioned above we love feedback and improving our processes continuously.
Does this sound interesting?
If you want to help build the future of healthcare, you can check our open roles here.