Image by Markus Winkler

In September 2018 I got a contract for the UK Ministry of Justice and the Video Hearings project.

I learned a lot during this project and want to share it as it is fresh in memory. As it is a real-life experience it might be relatable as well.

As it was kind of a journey, let’s start telling it from the beginning, the onboarding.

The importance of onboarding

The onboarding is the first impression a new hire will get of your team and it lasts. A good onboarding will lead to higher retention and team member satisfaction.

The whitepaper Help New Hires Succeed: Beat the Statistics shows this. It’s not surprising that companies like Google invest in onboarding and culture is a big part of this.

Culture and values define much of what we do. We show our values through our actions. Take Facebook, they rather roll out a change and watch the reactions than to have a long QA phase. Move fast and break things (since changed).

How we onboard also communicates our values to new members. To show that you value collaboration, for example, build relationships during the onboarding.

Culture from the first day

My onboarding wasn’t planned, instead, different members helped me as needed. There was a kind of autonomous “make it work” culture. In my experience, this is common in young teams or teams with poor retention.

In the interview, we talked about test automation and DevOps. This made me expect that quality and fast delivery were driving values. But when I joined, the codebase and the “make it work” culture surprised me.

It also frustrated me because I didn’t know what was being expected of me. Different people told me different things. Unless you know who has responsibility for you, it is hard to know who’s expectations to live up to.

Your mentor and the team

I wasn’t given a mentor but even if I had, everyone had their own values. It took a few months to find my bearings. Figuring out who to consult, what to ask of whom and what to step up and take responsibility for myself.

Shared responsibility is no responsibility

We can still collaborate and have a flat hierarchy even if someone is responsible

I dare say no one besides the people on the top like the pyramid shape of organisation charts. But charts or no charts it is good for new members to know who can help them with what, introduce them to the team. Walking up to someone who you have never talked to is hard, help your rookie build some bridges!

Communication or documentation

How much documentation does your project have? And how up to date is that? 😂

I find documentation to be hard and boring to write and generally outdated. I also believe very few documents stand on their own.

But documentation can be useful. Especially for bodies of information that are often shared or have a long shelf life. Pictures and diagrams are also forms of documentation. These together with someone explaining them can be a powerful tool.

To help with the onboarding, I created a single portal page. It had links to repositories, applications and other documents. It also listed some established ways of working.

You want to know what now? Let me grab my whiteboard marker.

I never leave my desk without a handful of whiteboard pens in hand.

Having architecture and design diagrams is very useful. Redraw them on a whiteboard as you explain is great though as it helps the listener grasp it step by step.

Onboarding preparations

Once you’ve prepared, the actual onboarding is a breeze. For the last member joining, I had prepared. Documentation was in place and we knew now who did what on the project. The first few days we did introductions with everyone and made an effort to free up time to help them out.

At this point, the team culture and ways of working had begun to settle. Since I had helped to drive many of the values we adopted in the team and mentored it was easy to pass these on.

We still could have done a much better onboarding though. It took almost a week after to get all accounts set up. I also hadn’t prepared tasks to get started with, nor scheduled enough time for pairing.

Conclusions

Half of the work lies in the preparation. The other half lies in building bridges and communicating culture. By the end with a bit of luck, you’ll have another member that walks and talks like you with fresh ideas and new energy!

• Have documentation ready
• Have all the accounts (and hardware) ready
• Have a mentor ready and available (schedule time!)
• Introduce the team (a few members at a time), telling them who is great at what and who does what
• Plan their first few days

In this project, I was working as a contractor and I’ve been told that this is different from joining as an employee. But we need to treat people like people and teams like teams, regardless of who is sending the payslip.

You can help out even if you are not responsible! You may be the one joining or a future colleague. As a new member, you can’t affect the preparations. What you do is to figure out and try to fit into the culture as you join. As a member of the team, you can help raise these things. You can also make yourself available for the rookie. Remember, even if you feel awkward approaching them, imagine how they feel.

I hope this post have given you some insights or ideas. Maybe you don’t agree at all? In which case, please let me hear your thoughts!

Also, don’t forget to sign up to the newsletter to get informed when the next post in the series drops! I think the next one will be on shit.. ahem, legacy code 😗

Lastly, special thanks to Juan that help proofread this a few times.