Onboarding new Engineers is a frequent task done in SW based companies, especially with the high turn over in the SW oriented industries, and it’s often a task not always done right. In this article I will try to talk about what topics a technical team lead and/or a project manager should keep in mind when onboarding a new SW engineer. The goal is for the new engineer to acquire the big picture of what’s going on around them, but without digging much into details. It can sometimes take an engineer months or even years to collect this information by themselves, because they’re concentrating on their low level tasks. However, if this information is directly provided by the person responsible for the onboarding, this will definitely improve their understanding, judgment and satisfaction level from the very first week at work.
Below are the topics I think it’s useful to talk about:
Industry Brief : 1 to 2 hours
This is about basic business information: understanding what’s the goal of the industry, how big is it, who are the big players, who are the competitors, who are the vendors and partners, what’s the current goal of the company, and most importantly, what is its revenue model. Having this information stored with an abstract level of details and presented to any new hire is definitely useful.
General SW Features Brief: 1 hour to 2 days
In some companies, an engineer is hired to work on a specific component of a SW while rarely touching other parts of the SW. However, it’s important for them to understand, not only the features of the components they’re working on but also all features provided by the SW, in an abstract way. This will help them take better decisions in their own job. Depending on the complexity of the SW, this can take from hours to days depending on the SW, but it shouldn’t take too much time or else it means that too much details are provided, that are not useful in any way to the engineer.
System Architecture Brief: 1 to 4 hours
An engineer needs to be aware of how the different components interface or communicate with each other, what services are used and why, what is the flow of the data. This can be simply provided by a number of diagrams, without getting into much details.
Component Code Brief: 1 to 5 hours
The goal of this is to introduce the new hire to the code that they’ll be working on. Having an idea about the code architecture, how the different classes are designed and what configuration files are used is crucial for the new hire to get started on their daily tasks. Part of this is also, how to compile the code and install any required SW to achieve that. Also, how is the code usually debugged, where are the log files and how do we interpret them. Part of this information can be documented but a lot of it is better presented in a meeting. The process of actually compiling and running the code can actually take days in some environments and the new hire will work on this with the help of the documentation and their collegues.
Internal & External Tools Brief: 1 hour to 4 hours
I’m not talking here about the training of the new hire on the deails of those tools, I’m just talking about understanding the big picture of what tools are used and why, which can be presented in the first week for the new hire. Internal tools are tools created by the company for various reasons and only used internally. External tools are provided by other vendors and are usually used during everyday work for people, process, task and code management.
Development Processes Brief: 30 minutes to 2 hours
How do we submit our code changes? How do we plan our work? When do we estimate our tasks? How are code changes reviewed and approved? What’s the flow of a task on the task management SW used ? When and how is the testing performed, and what automated tests do we have ? How do you communicate with the project stakeholders?
Branching and CI/CD Brief: 1 hour
What are the branches used and what’s the use of each branch? What kind of CI/CD is done on each branch.
Acknowledge well known challenges
It’s useful to inform the new hire about any well known engineering problems or challenges, to let him know that it’s being worked on, and also ask him to contribute on solving it. This will let the new hire think : “Those people are facing some challenges but they are aware about it, and doing what’s in their best to to tackle them” . That’s better than the new hire thinking: “There’s lot of issues in this company and nobody cares” . An example of that is, a buggy legacy code component that is too risky to refactor, an old technology being used that is too time-costly to upgrade, or a component that has no automated tests.
Training on specific technologies and tools: Days to weeks
This is out of the scope of the first week onboarding I’m talking about in this article, however, it’s important to mention. Let’s face it, but in the SW world new technologies arise every day and you will never find the perfect candidate who is aware about every technology they’re supposed to use. Therefore it’s expected that new hires will need to acquire some new skills. Most of the time a book or an online course will provide a good introduction, but sometimes a professional training course is required. In the first couple of weeks, it’s nice to figure out what training is needed for the new hire.