With the new year comes new opportunities!! For many companies, it means newly approved headcounts which allows development teams the opportunity to grow their ranks!

This creates an opportunity to hire! So in the spirit of hiring, I’d like to write about the onboarding process, and how employers can successfully onboard new Software Engineers.

In a previous article, I wrote about how new joiners can best start on the right foot in, The First 90 Days - How to Start Your New Role Off with a Bang. While that article focused on the employee’s perspective, this one’s for the employers.

Let’s begin by defining the importance of the onboarding procedure.

Defined Orientation & Onboarding Process

Having a defined process reminds me of an important life quote:

“Failing to prepare is preparing to fail.”

It’s widely accepted that properly onboarding a new employee lays the foundation for success; as engineers, we should take it as seriously as upgrading a large complex system.

Every company decides and influences the culture embodied by their organization. To adequately introduce that culture, onboarding is a key step. I recommend starting with this base question: What are the goals of our organization’s orientation and onboarding process?

We can achieve each by working backwards from the answers agreed upon.

Orientation vs Onboarding

There are two main gears that drive the onboarding machine: orientation and onboarding.

Orientation introduces you to the company and the tools required for your job, while onboarding teaches you how to use them; or, metaphorically: orientation orients you to a new land, while onboarding assists in you navigating it properly.

Both lend a hand in employee success, but how can we complete either effectively?

The funnel approach!

The Funnel Approach

If you can imagine filling a funnel full of onboarding topics, then you can see that even if all onboarding topics are poured into it at once, only so many of them can exit the funnel at one time.

Bringing that idea back into the reality of onboarding, we recognize that in presenting a large amount of information via slide decks and videos, only part of it will be comprehended.

This isn’t fake news; in my experience, becoming overloaded has been common with too much information in too short of a time frame happens when joining a new company.

How could we do better? Use the funnel approach and its two principles.

1. Pour only the biggest and most important ideas first
2. Spread the detailed and less urgent ideas over time

Both principles can be followed in orientation and onboarding.

Orientation Overview

Introducing the company’s structure, culture, benefits, and office space are the main responsibilities of orientation; it’s typically handled by the HR team and volunteers. Close coordination between the HR, IT, and the team of the new joiner is important here: HR will be leading the orientation schedule and going through your new benefits, and IT teams will be assisting you to set up your computer with tools and access.

These first few days are an important part of not only telling but showing newcomers the inclusive culture they’ll be a part of.

The next stop on the train begins as orientation concludes - onboarding with the new team!

Onboarding Overview

Onboarding introduces the team members, product, tech stack, and team processes that you’ll be working with. From the team’s perspective, Onboarding a new dev team member can be a difficult task, as it requires coordination, resources, and an open mind.

Here are some questions to get you started:

• Where is the best place to begin the onboarding process?
• How can we make our team feel open and inclusive?
• We haven’t set up our development environments from scratch in a while, are instructions up to date?
• How can we best explain our architecture?
• When should we expect our new teammate to begin contributing to sprint work?

Once answered, break it down into phases; I like to break it down as such:

1. Before the new team member starts
2. Meeting the team and getting an overview of the product
3. Dev environment set up and overview of architectures
4. Learning the intricacies of the codebase and begin contributing

These four phases break down the onboarding process into manageable pieces for the team.

1 - Before They Start

Being prepared is key to creating a positive first impression. Here are a few prep items we can take care of for them!

Order Equipment

I’ve always appreciated having all the hardware ordered and delivered at my desk within the first week of starting a new gig — bonus points if it’s on the first day!

If possible, reach out before a new teammate’s first day with options of equipment available. Things such as their preferred computer model, monitors, docks, or standing desks.

Once preferences are received, order them! A proper work environment on the first day contributes to a much smoother onboarding and gives the impression that the team is productive, supportive, and organized.

Have you ever joined a new company and the first week is spent waiting for your computer to arrive? Talk about a blocker for getting things done.

Update Documentation

Another prep task - updating all documentation managed by the team. Whether that’s a wiki or repo ReadMe files, having it documented reduces the friction for getting started and set up.

Assign a Mentor

A mentor or sometimes called buddy should be known and assigned before they start. This volunteer should be available for all questions and ease any troubles that come up during the onboarding process.

Create a ticket

Creating a ticket with all of their onboarding tasks helps track and gives a methodological agenda to follow. The ticket should outline links to important documents to read, helpful resources such as slack channels to join, the people responsible for different parts of the architecture, and the software they should get access to or download.

The main idea here is to give them a clear path to follow, assuring they never have a “what should I be doing?” type of moment.

2 - Meeting the Team & Product Overview

We spend a great deal of time with co-workers, collaborating through discussions while helping each other solve challenges. Like any type of relationship, it can take time to form and strengthen - onboarding offers the first opportunity to start!

Each team member should set up a time to welcome the new teammate, learn more about their story, and give overviews on parts of the tech stack. Doing this over the course of their first week or two will help continue the funnel approach of only allowing so much information at one time.

3 - Dev Environment Set Up & Architecture Overview

Setting up local environments might take a considerable amount of time - updated documentation speeds it up. Team members presenting tech stack overviews initiate the next step of onboarding.

This should be done in conjunction with the teammate 1-on-1s or in separate sessions. The end goal here is that a new developer has all local environments set up and understands the high-level architecture, patterns, and features of the team’s application(s).

These are the biggest and most important ideas for the information funnel, and once those have exited from the funnel, diving deep into the code will happen over time as one contributes to the sprint via tickets.

4 - Contributing to the Sprint

The last phase of the onboarding process will be contributing to the sprint.

There are different approaches to doing this, but my favourite is giving simple tickets while simultaneously lowering expected capacity in the first few sprints.

A concurrent benefit task that should be considered - updating test coverage - awards both the code health and the developer, since writing tests requires an understanding of the underlying code.

The second part of this process will be collaborating and asking even more questions - this is where the high-level understandings transition into low-level code changes. Additionally, he or she will be going through code reviews as they learn new team code conventions.

Once the new team member begins to complete tickets, sprint capacity normalizes. The new dev is officially incorporated! Onboarding is complete!

Wrapping Up

Onboarding a new team member can be a daunting task, but one that leads them to success when done properly. By learning and iterating through feedback gathered after onboarding ends, we can teach new employees the culture, benefits, processes, and code-bases more effectively - leading them to faster impact, higher productivity, and of course, more fun!

Onboarding someone new has always been a fun moment for me throughout my career. I always enjoy getting to know someone’s story, learning from their experience, and watching them grow into their new role. After reading this, I hope you can find some joy in the process too!

Cheers!