How to Onboard Software Engineers
, an independent Product Engineer, provides us with advice about onboarding new developers. In this interview, she covers the benefits of onboarding, its essential elements, areas to focus on when getting started and common mistakes made.
Read more interviews with some of the world’s best developers on * or follow us on or follow us on .*
here are 2 ways to get great engineers at your company. You can steal them or you can make them.” says Heddleston. “In this day and age, you’d probably better have outlets for both”, but you should at least have “a sustainable program of bringing on junior engineers”.
“We spend a huge amount of money recruiting and sourcing engineers” and then “we pay them huge sums of money to work” for us. But all too often when it comes to onboarding these valuable engineers, the approach is just — “you’ll figure it out,” says Heddleston.
The result is that “we’re underutilizing people, which is expensive for companies, and people are unhappy when they aren’t fulfilling their potential and that can lead to attrition”. The answer to this problem for Heddleston is onboarding. “The return on investment is incredible… you get so much more out of employees who are happy and productive and feel integrated into the team.”
“The goal with onboarding is what I call reliable independence”, says Heddleston. This is when “someone is able to reliably and independently build software on your team. For someone who is really senior, that might take 2 weeks… for someone really junior, that might take more like 6 months.”
However, according to Heddleston, the time-frame for reliable independence “varies hugely depending on the size of the company and the quality of their internal tools.” A common issue among fast-growing startups, for instance, is that “everyone has to come in and manually set up everything… and that’s just going to bottleneck your company.” So before you even start to think about an onboarding program, first take stock of your tools. Heddleston recommends that new hires “shouldn’t spend a lot of time having to do all these installations that you do once and that have no learning value”.
Once your tooling is sorted, “the second thing is to put together a Trello board and come up with some goals of what you want to see. You can section it basically by the rough seniority level of someone coming in: senior, mid-level, junior”. This helps because “someone who is junior is going to need a little bit more hands-on attention and someone who is senior is probably going to want freedom earlier. Then just set up goals of what you want to see them doing in the first day, the first week, the first month.”
So an example goal that Heddleston suggests is “being able to ship something on the first day”. “This new engineer comes onboard and in their first day, they actually push something to production. Even if it’s just a small bug fix or… some config files that you might need for something, it’s a really nice thing to feel like you can contribute on your first day.”
Beyond that, goals should fall into what Heddleston says are the “3 major categories that people need to develop in order to become reliably independent. They’re each about a third of what someone needs to know. We focus a lot on technical knowledge… but another third is company structure, the internal tools that you have, the way that you build, the way that your code is set up.” The final third “is personal development, things like confidence, the ability to research problems, the ability to debug independently and judgment.”
Your program should also take into account the fact that “people are going to come in stronger in different categories,” says Heddleston. “Everyone is going to come in not knowing that much about your internal company structure, but some people might have more confidence, more debugging skills. Some people might know a lot more about the technologies that you use”. So the goals should be flexible and focus on “filling in the gaps in the areas that they aren’t as strong in.”
Who is involved in onboarding new hires is often an area where mistakes are made. According to Heddleston, often “the common first approach to onboarding is to place new employees with really senior mentors, but mentoring is actually really hard. It’s a lot like teaching in the sense that it’s very emotionally draining.” What happens then is that you can “burn out all your senior mentors”. So instead she recommends that you “spread out the load, and instead of pairing every junior who comes in with a super senior engineer, you pair them with the last people who joined”. Heddleston says this is a much better approach anyway, because “the best person to teach something is usually the last person who did it.”
What’s more “really senior people are not necessarily that great at teaching junior people. They’ve forgotten what it was like to learn things for the first time so it can be really painful. It’s nice to have the intermediate people turning around and teaching because they grow a lot.”
Regardless of who is involved, one pre-requisite that Heddleston recommends is “executive level sign-off” — “there’s nothing worse at a company than fighting a Director of Engineering” who doesn’t believe in the goal.
When setting goals you should understand that “one of the tenets of expertise is the ability to recognize boundaries and scope really well. Whereas, one of the tenets of being a beginner is that you cannot recognize boundaries and you are unable to scope problems”. So Heddleston cautions against making the mistake of “expecting a junior engineer to be really good at scoping a feature. That’s one of the skills that they have to learn. Whatever you give them to do, just scope it. Then let them go play. Give them a feature that’s really well defined, that has a clear area where they’re working on and then let them go and fumble around with it.”
“The final thing for junior engineers, and beginners, in general, is helping to bolster confidence,” says Heddleston. “People think that confidence follows skills, but it’s usually the other way around where skills follow confidence. If someone feels good about what they’re doing, they’re more likely to explore it and ask questions and to believe that they’re able to solve the problem”.
Read more interviews with some of the world’s best developers on * or follow us on or follow us on .*