Hiring support engineers: onboarding
Baby engineer on board
You found a good candidate, you have successfully danced together all the way through the hiring process, and now you have a shiny new support engineer starting Monday. Now what? Well, first of all I hope that’s not literally true for you, because setting up a good onboarding program takes time. So let’s take some of that time now to start to figure out what onboarding looks like in your team. I’ll use my own process as a base for discussion, but of course you’ll want to change things around and otherwise customize for your particular environment. In my experience, the time horizon to become a fully productive support engineer is more or less three months, with a good deal of variance depending on the complexity of the product and the other particulars of your support process.
I use these divisions because while things change rapidly over the first few days and weeks, the process slows down quite a bit as the new engineer gains confidence in the basic use cases and starts honing her skillset rather than the proverbial drinking from the firehose that takes up the first few weeks.
At a few points I’ll talk about what percent ramped up the engineer should be, which in a support team I interpret as “able to answer this percent of customer inquiries without assistance.” But always keep in mind that nobody will ever achieve 100%. Even the best engineer won’t be much more than 95% familiar with your team’s entire body of knowledge. In most environments it’s simply not possible, especially in fields where the state of the art is rapidly shifting. You know, like most startups.
Day One
Let’s be honest, not a lot usually gets done on Day One. Between setting up accounts, meeting new folks, and any company-required onboarding processes, I generally assume day one is a wash. That being said, don’t just assume everything will work out! Even if you don’t expect to get any team-specific onboarding tasks done on this day, it’s a great opportunity to meet with your new engineer, remind her again that she’s made the right decision signing on, and generally set the tone for the first weeks and months.
Week One: the neophyte
The overarching goal of Week One is ‘familiarity’. The new hire should spend this time:
Learning company and team culture and norms.
Learning as much as they can about the product or products they’ll be supporting. A good rule of thumb is ‘know as much as a typical end-user (or end-user administrator, if that exists for your product)’ by the end of the week.
Starting to understand the scope of issues they are likely to be helping customers address.
The end of Week One is the ideal time to check in again with your new employee, if you haven’t already been doing so daily. One boss of mine always focused on a single question at the end of the first week: are you excited to come back Monday? If the answer is anything but an enthusiastic ‘yes’, it’s a very strong signal to dig deeper and see what’s up. Too much training? Not enough? A general mismatch with the role? Whatever’s going on, now is the right time to figure it out, before things get too far and it becomes more difficult to cut losses on both sides.
Month One: the apprentice
Once basic familiarity is achieved, the theme of the rest of the first month is ‘apprenticeship’. During this month the new employee should be building upon the basic framework of ‘product user’ to learn more of the product internals and basic troubleshooting experience.
Now that they have their feet beneath them, the onboarding engineer should be starting to get in front of the customer. Put them in your ticket rotation and assign them to shadow a more experienced engineer every day. They should watch over their shadowee’s shoulder, in person or virtually, as they investigate customer issues, do screen shares, and draft and send customer emails. At first this shadowing will be passive, but by the end of the first month the onboarding engineer should be starting to take a more active role in the process. Throughout the whole shadowing process, check in regularly with the more experienced engineer conducting the shadowing. Weekly at a minimum, but ideally 2-3 times a week. They will be your best source of information about how the process is going so far and can alert you early if there are any issues you need to address.
At the end of this month, check in again. How does your new engineer feel things are going? Is she still excited to come in every week? Are there any snags you can assist with? But beyond this, it’s important to also hear from the rest of your team. You should already be speaking with their shadowee, but make sure you get feedback from everyone else your new engineer has been working with. What’s their take on how onboarding is going? Any particular strengths or areas of concern? Now is the time to find out.
Month Two: the journeyman
By this time the new employee should have been shadowing actively for several weeks and developing a familiarity with the house voice for customer communications. This is the month they start taking a more active role: shadowing becomes reverse shadowing as the onboarding engineer takes the lead on simpler issues and is able to assist troubleshooting more complex situations.
The focus throughout this month is about expanding on existing domain knowledge, identifying remaining gaps in knowledge and skillset, and systematically filling them in. Check in regularly with your new engineer, with their shadowing partner, and with the rest of the team to quickly pinpoint and resolve areas for improvement. At the end of this month, the engineer should be maybe 75% ramped.
Month Three and beyond: the professional
From the outside, the difference between the beginning and the end of Month Three may be almost invisible. But this is the month for polishing and perfecting the engineer’s understanding of team procedures, written voice, and live customer interactions. By the end of the month, and the end of onboarding, the new engineer should be 90% ramped up. Shadowing and reverse shadowing should be less and less effort for the experienced shadowing partner, and the new engineer may now know more in some situations than their partner!
The last thing to do, to wrap up the formal onboarding process, is some sort of graduation ceremony. It doesn’t have to be big and fancy, but an official announcement to the team, and maybe to the company at large, that Jane X is now a fully trained support engineer, helps put a bow on the whole experience. Shadowing ends, the trainee is no longer a trainee, and everyone can move on.
Everyone but you, that is! Now that this round of onboarding is complete, take some time to revisit the process as a whole. What worked well? What took less, or more, time than you expected? This is another place to have a touchpoint with your new engineer as well, to get their own thoughts on the process. Every onboarding should be smoother and more effective than the last, and the key to this improvement is regular reflection and feedback.
Onboarding new engineers is a difficult but rewarding process, and essential to ensuring your team continues to operate smoothly as it grows. Taking some time now to lock down your own onboarding process, or at least a first version of it, will pay back many-fold when it comes time to expand your team.
Thanks for reading Andy's Support Notes 💻💥📝!