How To Onboard New Team Members To Be Productive in Existing Projects

We onboard a lot of new team members for different projects at different stages of the projects. These are some of the methods that we have used to successfully and efficiently get them up to speed.

Onboarding new team members into already existing teams mid-project has been one of the more challenging things I have had to deal with as a hiring manager. Over the years, I have found different ways to make this process less painful for myself, my teams, the new hires, and our clients.

These processes work best when you have a properly planned project. I will cover project planning techniques that we have found effective over the years in a future post.

Here are some of the things I’ve learned over the last five years and how they have contributed to improvements I have seen within our teams.

Set Precise Expectations During Interview Stage

While there are obvious common themes in the software hiring process across different companies, there are some differences as well. Some companies hire year-round without specific roles in mind while others hire for specific projects. In our case, we have the latter approach.

We hire developers knowing exactly what project we want them to work on and at what stage of the project we would expect them to be productive. Knowing these details in advance makes it very easy for us to set clear expectations for the candidates during the interview process.

I have found that this process both helps the candidates to be better prepared for the interview itself and ask relevant questions about the project but also understand clearly what is expected of them and whether they would be a good fit or not. Similarly, as the hiring manager, it gives me a clear understanding of whether the candidate will be a good fit for the existing team and/or the project in question.

First 3 to 4 Weeks Are Not Productive

We strive hard not to pack our teams with senior developers. In fact, it is usually only for really quick & dirty prototypes that we put together teams made up exclusively of senior developers. For most projects, our teams are made up of one or at most two senior developers while the rest are mid-level to junior developers.

This reduces the overall project cost for the client and gives us an opportunity to train junior developers and help them gain valuable experience within the industry.

Regardless of the level of experience, however, we generally accept that developers are not going to be very productive during the first 3 to 4 weeks of them joining the team. This timeframe is definitely shorter for more experienced developers, however, we offer this flexibility for developers to take their time, learn and make mistakes during those first weeks without the pressure to contribute to production ASAP.

Encourage Them to Break the Application

One of the things I always encourage, especially with junior developers on our projects, is to break the application they will eventually be working on. Just run the code, make changes and break it. It's the best way to learn to get over the fear of messing up someone else’s work.

I provide them with an environment that is risk-free. The system we have had in place is perhaps very archaic and could be modernized but we simply spin up isolated VMs with all the tooling and codebase set up. These VMs are not connected to the main code repository, either. This way new developers do not need to keep up with an ever-changing codebase and can, instead, focus on understanding how the application is put together. They can break it, reset it to the previous point if they don't know how to recover, and continue to make changes and continue to break it.

The developers also receive code reviews within the context of their isolated environments. I have found that this process gives new (new to the team, not necessarily juniors) developers an incredible amount of confidence to be able to work on the codebase.

After they feel comfortable with what we call the “stale codebase”, we incorporate them into the regular workflow of the rest of the team. We follow a slow ramp-up model for this stage, rather than throwing them in the deep end right away.

For this process to work properly, it is essential to have supportive senior team members.

Assign One Experienced Team Member to Mentor New Team Members

In my opinion, it is essential that one of the team members who are already familiar with the codebase and the current team culture be available at all times to answer any and all questions from new team members. This includes teaching them any intracompany jargon or specific culture within the team that they should know about to be effective.

In the first 4 weeks, I do not allow the use of “RTFM” or “you can Google this” or any of their variants to be used with new team members. Handholding is encouraged for the initial weeks with soft nudges toward resources that would help the new team members eventually get answers to any other similar questions.

Putting in this work initially pays dividends. Through this approach, I have seen new team members become part of the team much faster and start to contribute in really positive ways to not only the codebase but the overall product.

Other than experienced team members being available, recently we have started creating step-by-step manuals and video walkthroughs to cover things like expected workflow for adding features or hot-fixes to the codebase, how to set up the applications from scratch in the event of a catastrophic failure, important resources, and how to access those resources, among other things.

Clearly Define and Explain the Team Hierarchy

Most of our teams are set up with a clear hierarchy. In my experience, this produces better results than if no hierarchy is properly defined. This does not need to look like a specific structure but it needs to be clearly defined even if it’s the flattest hierarchy you can possibly come up with.

Within this hierarchy, roles and expectations also have to be clearly defined. We do this with all team members who join our teams and more so with new team members who join already established teams, mid-project.

This helps us avoid conflict and get the communication flowing properly right off the bat.

What this helps us achieve

This may sound like a lot of time and effort to get a new team member onboarded but these routines have helped us actually cut down overall time to release.

The reason is simple. Once the new team members go through the process and interact with other team members with clear expectations, it establishes good and healthy communication between the team members very quickly.

This results in less miscommunication between both the team members and the management. In my experience, I have seen more projects fail because of miscommunication alone than any other reason and these training processes and techniques have been a godsend in solving or partially solving that problem.

New team members also learn the team culture which leads to less confrontation and more comfortable interactions. This is especially important for remote teams like ours where there is a lot of room for things to be taken the wrong way and end up offending others, even if you didn’t mean to be offensive at all.

I recommend all teams try out our onboarding processes but only where appropriate. I am also interested in reading about how you guys onboard new team members and whether you do things similarly or in a completely different way.