Thoughts On Onboarding Engineers
Hiring Engineers is hard. That’s an established problem and various ways to tackle it are well documented. Onboarding these newly hired engineers is also acknowledged as a tough task but doesn’t get the same treatment/respect as hiring does. Literature on it seems light weight and most places just hand roll their own take on it. Very few places are disciplined about this stage Once hired, a lot of folks consider job done. It’s the classic ‘dogs chasing cars’ scenario.
Onboarding process is a tough process to get right as it comes right after a small win (of hiring) and people tend to loose focus. Hence, It needs discipline to execute right. It is also full of seemingly very varied set of practices depending upon place to place, which makes it harder to document and standardize and eventually execute well for a lot of software shops.
In this post, I will outline one seemingly common practice in Onboarding, the concept of ‘Sidekick’ and how it can be improved.
Solo Sidekick might be a bad idea
The concept of a ‘Sidekick’ has been fairly popular when you discuss Onboarding. However, the definition of a ‘Sidekick’ varies from company to company. In principle, A technical sidekick is a great idea and is ideally thought of as a single person amongst the team who is responsible for handling most of the ramp up questions and activities.
I have personally seen that idea fall flat on its face a couple of times now for a variety of reasons. Lack of motivation, lack of interpersonal skills, or simply bad timing where the sidekick has an impending deliverable all can cause a silent issue that goes unnoticed. To mitigate such situations, I believe a sidekick should not be a single person but a group of people with clear directions/schedules to ramp up the new engineer well.
So, its should be a sidekick team not ‘a sidekick’ and the whole onboarding process should be thought of like a 1–2 week medium size project for a couple of people(with 1 project lead for accountability purposes). This is additionally beneficial as then you get an opportunity to collate insights/feedbacks from more than 1 person in regards to the skill level of the new engineer. Remember at this time, you are still trying to scope out on how good the new engineer is. That job was (hopefully) not done when you simply made the hire.
Ultimately, the size of this ‘Sidekick’ team would vary from situation to situation but no matter what the situation is, I think a solo sidekick is not an ideal setup. Onboarding necessitates ramping up the new engineer at various levels of the stack and typically, one existing team member might not be adept at all those layers. This can lead to frustration for both parties and cause expectation mismatch.
Another thing that can further aggravate the already bad idea is when the ‘Engineering Manager’ on the team take up on that sidekick role. An engineering manager’s day mostly gets thrashed across several responsibilities/groups and very often, actual physical presence is not possible. This leads to a terrible situation where expectation mismatch happens very often and can be a very frustrating experience for the new employee. It can also be annoying for the rest of the team as there time/focus can get thrashed ramping up this new employee in a very ad-hoc manner.
Additionally in this scenario, It’s harder for the new engineer to be open/vocal about several ramp-up silly questions and question things and it gets harder for you to get feedback on the sidekick as you are the sidekick and also the team manager/lead.
You need a Product Sidekick
To further extend on the concept of the ‘Sidekick’, most of the thinking I have seen seems to have been done from a purely tactical and technical viewpoint. Engineer needs to be ramped up on our tech stack quickly and needs to jump in and crank code as soon as possible.
Writing software is changing rapidly and engineers are becoming more publicly ‘product savvy’. It is highly imperative today to have a product sidekick in my opinion. The role of the product sidekick is to make sure that the new engineer is fully bought into the vision he’ll be participating in creating. More and more engineers care about the impact of their creation, who and what they are building for. These are extremely important questions and need to be answered well if you want the newcomer to feel part of your vision and to really care about the goals.
The product sidekick’s role is to elucidate the roadmap (both backward and forward looking) and slowly build upon the vision by showcasing both past and future projected metrics.Product sidekicks should also actively engage the new employee in a variety of cross team communication exercises that enables the new hire to get a glimpse of how other teams work to ship the product that he/she would be building. This cross team visibility can go a long way in building deep understanding of how and what to build. Unfortunately, some of these things are still not discretely measurable and hence, very easy to ditch and overlook in the haste of chasing numbers.
Personally, I have been lucky to come across some Product Managers (who work very closely with engineering teams) that seem to be naturally good at understanding this aspect of onboarding but it’s a rare skill from what I’ve come across. Another engineer is another task executer for many, a habit that shapes a group not a team.
There is a case to be made here that not all engineers might want or enjoy this. That’s fair, as its largely dependent on the kind of engineer(dev ops v/s product), the kind of product and the company. That might mean you would have to tailor this aspect as per the engineer and the role you are onboarding for. However, complete lack of thought here is a gap in my opinion.
Onboarding practices can differ widely from one company to another. That is good as each company is different and the whole culture thing is always a hot topic of debate, but maybe we can benefit more by standardizing certain aspects of it than not.
I would love to hear your thoughts on how you think about Onboarding engineers.