How To Create a Successful Onboarding Plan for New Hires

Problem

When I joined my current company, there were only 3 to 4 people in a newly established DC office and I was hired to build up that office from scratch. The office was rapidly growing and I was bringing on a great number of people. As part of onboarding, we were given some time to ramp up and learn more about the company and the new job. I saw that as an opportunity to be seized and wanted to make the most of orienting new hires to our company and culture.

I decided to come up with a plan to ramp up newly arrived engineers and make them effective contributors to our engineering organization by providing them with a holistic view of the organization.

Actions taken

As I realized there was no onboarding plan in place, I reached out to the main office HR, my boss and peers. However, I was not satisfied with the onboarding plan they had proposed. I felt that the honeymoon period of a new job was a golden opportunity not to be missed.

I came up with an idea of a structured onboarding plan and pitched it to HR and my boss who had been very supportive and encouraged me to develop it further.

By virtue of my own ramp-up, I had absorbed a lot of information -- I had read marketing and strategic material, watched numerous videos, read blog posts and technical presentations, went through the code and code repository, etc. I decided to take key information from all those sources, filter it out, and organize it in a clear and structured manner that would allow people to digest it easily.

The outline was initially made in Google Doc and consisted of several sections organized in weeks and days. The key sections were: business strategy (who we are and what we do), competition (who are our competitors), financial analysis (what is our market size, how much revenue do we make, what is our overall product offering, how many customers do we have and what is their setup), marketecture of the product (how the product is organized, what are the different modules that the company sells and how they all fit together), technical architecture of the system (what are the key aspects of our architecture, how is our platform work organized and what are key architectural drawings and internal tech docs they should familiarize with), project management (how we run Scrum, how long are the cycle and what tools do we use to manage software delivery), software management (what are the tools and languages that we use and they should learn, how we build software and apply CI/CD, how we do DevOps, how we release and manage software in production) and support (how to support software we build and what is the incident management process), etc.

The plan contained links to internal and external sources that included audio, video, podcasts, Powerpoint presentations, blog posts, articles, technical drawings, etc.

Initially, the content was meant to be only read, but I was continuously receiving feedback to include some more “doing” segments. Doing segments were predominantly geared around technology. For example, set up your local laptop with the dev environment, configure your email with your signature, change your calendar sharing options, etc.

I presented my onboarding plan to engineering leadership and their feedback was incredibly valuable and it allowed me to reiterate the original document and collect more information. In addition, as new people were continually joining in and going through that document, I was continuously collecting feedback from them as well.

I managed the process for a year -- adding/removing content and finding links. I would share it with every single manager and once I got enough adoption I went to the CTO and proposed to make it a standard. And standard it became. As a result, a new role was hired with the Training and Learning team and their sole job was to upkeep the document on a day to day basis. They would replace an old presentation with a new one, add new links, fill the gaps, collect feedback, etc. Before I handed that off, I moved the document from Google Doc to a tool called Degreed -- a tool we used to help us with improving the training of new hires. It took me a lot of time to convert it, but it became more structured and people could track their progress more easily.

Lessons learned

• Be iterative. Don’t expect the first version to be the final one. The only way to be iterative is to constantly solicit feedback and listen to what other people have to say.
• Don’t be afraid to take on and do things by yourself before you get more support. Don’t give up if the support, in the beginning, is not sufficient enough.
• When I started to collect feedback I was receiving various opinions, thoughts, often very critical or outright negative. I didn’t take it personally and I knew that that type of feedback can also help me improve the product. It is not feedback on you, it’s feedback on the product.