Clear expectation setting and onboarding process to maximize new hire success

Problem

When hiring a new engineer it is easy to not set them up for success. There are many things going on, especially in a startup environment, and frequently the onboarding process is not clearly defined. This has been the experience that I have had at several organizations which I have been a part of and even occurred to me when I first started at my current company. I believe I was not set up for success when I first started. My manager was very busy and I only spoke to him for five minutes over the first three days, and was left on my own to figure it out. This led to a huge amount of anxiety, and although I was able to find my way, it probably meant that it took much more time for me to start producing value for the organization. Therefore, I came up with a clear set of expectations and a process to help alleviate this issue, to help engineers to have an early and clear "win" in their new role.

Actions taken

To minimize the likelihood of failure for a new engineering hire, set clearly attainable expectations before they even begin. When a new hire starts, or in some cases before they start, whenever possible, I give them access to our private GitHub repos, and share the specific repos with them that our team owns. I point them to the areas they will be working in so that they can begin reviewing the code and so they can get up to speed before they even start. On day one, we set them up with an Onboarding buddy, who is a fellow engineer who both excels at their job and has a high level of empathy for others. These team members are there to help give new staff members someone to ask questions of, without anxiety about looking or feeling dumb. Then, I, as the manager set expectations for the first two weeks. I share our values and impress on them that we win by shipping working, high-quality code to production, and that we are responsible for making sure that we have set them up to be able to accomplish that. I set the expectation that by day three I expect that the new engineer should have a local development environment working and that they should be able to pull down the code. By the end of the first week I expect them to have committed some code towards a feature (bonus if they've been able to ship it), and by the end of the second week, I expect them to have have shipped something significant on behalf of their team. This puts the onus on us to make sure that we have prepared the engineer to be able to have something discreet to execute on, that we are available to help them remain unblocked by the many things which can occur, and that they understand the expectation. Once the engineer has done this, such as a hire on my team did a few months back, you have set them on the path to success. You should still check in frequently with them and help them to set realistic and focused goals for the first three to six months and you should then support them in achieving them. If you have hired well and set them up for success in the first two weeks and beyond, you are well on your way to having a high likelihood of success with your new engineer.

Lessons learned

By following this process we have significantly increased the confidence of our engineers, as well as reduced the time that it takes them to begin producing value. It also has created an environment where clear expectations are set from the beginning, leading to increased clarity on both my part as the Engineering Manager, and that of my engineers.