How we took onboarding to the next level at Stuart
Depending on what’s going on when you start in a new company, the onboarding experience that can go from a well-defined, smooth routine to something much more chaotic and disorienting.
Since there are plenty of resources covering good practices out there, I won’t be selling you Stuart’s miracle solution that perfectly works™. Instead, I want to share with you my perspective on how our onboarding process has evolved over the past few months.
Because (to quote a cheesy cliché) sometimes the journey is more interesting than the destination itself.
My first steps
I arrived at Stuart as a backend engineer at the beginning of a sunny July. At that time, the engineering team was in the middle of big improvements and refactors, while still growing fast. The ongoing refactoring spree had been planned to be limited in time. Everybody was more than 100% focused on decision-making, improving our systems performance, and its scalability while conducting interviews in the meantime.
Since July is a popular time for people to go on holidays, the number of available people when I first started was very limited. As a result, everybody was doing their best to be caring and helpful, but they were also really stretched and so finding a helping hand was difficult. Luckily, Martin (one of my colleagues and another new hire) contacted me to see if we could help each other out.
This is where it all began.
A friend in need is a friend indeed
The first issue was that I had access to half of the tools I needed while Martin only had access to the other half. We had a short call and decided to make a list of all the tools in use. While putting this list into Confluence to forward it to our administrators, we noticed that by combining our knowledge we could start a small bugfixing task together. We fired up our editors and did some pair programming.
While investigating the bug, it became clear that I was blocked by Docker, so we talked through how to get it all up and running.
All the while, we made notes so it would be easy for others to follow the same path. This helped so much!
With all the technical difficulties we encountered we also did some cheat sheets for the dev tools we use on the team. This became the first draft of our onboarding checklist.
After a week of exploring the Stuart technical ecosystem this way, this led us to the last part of what we thought was needed for a nice onboarding: what we called an “Onboarding buddy”.
Knowing that someone is dedicated to your onboarding is an amazing thing. This person makes sure you get everything you need, takes time to describe how things work and makes the first steps in the company with you. This is so reassuring!
Passing on the torch
After nearly 4 years in my previous company, I forgot how stressful it can be to start from zero: a change of your habits, a new environment, new working methods, new everything…. By doing things this way, it made everything easier.
Just a few weeks later, Martin reached out to me and asked if I’d like to be the first onboarding friend for the next person who will join us. This way, we were able to turn this idea into a virtuous circle where the newest member of the team always gets to help the next new hire. And if we managed to keep things going this way the list would stay maintained and up-to-date.
We finally made a copy of our new onboarding process as a document template on confluence. At the top was my name, the name of my “onboarding buddy” Martin, and a checklist of all the important tasks to perform when arriving as an backend engineer.
Spread the love
After a short pilot test, this idea was adopted and became our new process for the backend team. Since then, most of us have been the “onboarding buddy” of someone else. The onboarding checklist has been a success and we’re seeing its usage spread through the whole company. Feedback is overwhelmingly positive from all our new hires, too — their first day anxieties are put to rest with a simple, clear, transparent set of first steps.
A few weeks ago, our Data Science team had a newcomer and decided to give this idea a shot while tweaking a few things (mostly in the list of tools). Happily, it proved to work just fine. All we need to do now is to come up with a more abstract template keeping mostly the guidelines (list of tools you need, cheat sheets, onboarding friend etc) and I think we may have something that could be used for the whole engineering team.
In conclusion, I must admit that it felt oddly rewarding. Apart from seeing something I made working well, Stuart gave me something not a lot of companies gave me before: a possibility to be the change I wanted to see happening in my workplace right from day one.
You also like to solve problems? Maybe you’re interested to work with us!
Also you might be interested in why transparency matters for us.
