In this interview with Kate Heddleston, an independent Product Engineer, we discuss technical onboarding. We cover why onboarding is important, the essential elements to effectively onboard engineers, the areas you should focus on, who should do it, as well as common mistakes, made. Kate writes about technical onboarding, training and mentoring on her blog.
Introduction
Derrick:
Kate Heddleston is an independent software engineer in San Francisco. She volunteers at Raphael House and is mentoring with PyLadies and previously at the Hackbright Academy. She also speaks at conferences about a range of software engineering topics including technical onboarding, training and mentoring. Kate, thank you so much for joining us today. Do you have a bit to share about yourself?
Kate:
I’m a self-described product engineer, which means I like to build features for people, but I keep building infrastructure tools because I decide that I absolutely have to have something in order to build my websites. I talk about web application development and web application infrastructure.
Derrick:
With your experience with onboarding specifically, what led you to start talking about it?
Kate:
I noticed that there was this discrepancy in the career trajectories of men and women at startups that I was working at. I was trying to figure out why because the people coming in were of the same experience level, which is out of college, so pretty much none, but the guys over and over again would get promoted faster and get to the next level faster. That is a whole separate topic of conversation, but the big thing I noticed first was that without onboarding, women were left behind more than men. I was really confused by that. I was like, “Why is that women are hurt more by a lack of onboarding than the men?” That’s what led me to start researching and putting together my talk.
“There are 2 ways to get great engineers at your company. You can steal them or you can make them.”
The Benefits of Onboarding
Derrick:
With onboarding, if done well, what are some of the benefits?
Kate:
Basically the way I think of it is we spend a huge amount of money recruiting and sourcing engineers. We pay them huge sums of money to work for companies, and we bring them in on the first day and then we’re just like, “Whatever. I’m sure you’ll be fine in our massively complicated website that is developed and maintained by many, many people. You’ll figure it out.” We’re under-utilizing people, which is expensive for companies and people are unhappy when they aren’t fulfilling their potential. That can lead to attrition. It’s one of those things where once I saw it, I was like, “This is so incredibly obvious that companies should have onboarding.” The return on investment is incredible. It benefits everyone. I came to it from a place of, “Why are women being left behind?”, but at the end of the day, onboarding is really for all humans. It’s one of those things where you get so much more out of employees who are happy and productive and feel integrated into the team, so why wouldn’t you do it?
Getting Started with Onboarding
Derrick:
Who within an organization should be involved in onboarding?
Kate:
Pretty much everyone. ‘It takes a village to raise a child’ kind of thing. 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 is … This is experience when companies hire a lot of junior engineers. What happens is they burn out all their senior mentors. They get tired because teaching is hard, and they’re like, “We can’t take on any more junior engineers. We can’t take on a lot of new engineers who aren’t really senior.” If you spread out the load, so if instead of pairing every junior who comes in with a super senior engineer, you pair them with the last people who joined, like sophomore engineers, how they do sports in high school and college, you can start to spread out the load because the best person to teach something is usually the last person who did it.
The best person to help someone set up their development environment is the last person who joined, regardless of seniority. The best person to teach someone about a particular part of the product is the last person who developed on it. That way you can spread out who is helping who so you don’t burn out people emotionally. In fact, 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.
Derrick:
Do you just start onboarding a new employee from their first day on the job?
Kate:
The way we’ve recommended setting up onboarding plans is setting up goals and then making them happen. For a lot of companies, if they have good enough infrastructure, being able to ship something on the first day is a really good goal. 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 I don’t know, 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, especially as a software engineer. Setting up goals like that and setting up goals for when people are able to manage their own projects or work independently, the thing I say, the goal with onboarding is what I call reliable independence. Someone is able to reliably and independently build software on your team. For someone who is really senior, that might take 2 weeks, which is awesome. For someone really junior, that might take more like 6 months.
Derrick:
What steps or first things do people need to do when implementing employee onboarding?
Kate:
There’s no real good literature out there on exactly how to set up an onboarding plan. It varies hugely depending on the size of the company and the quality of their internal tools. I’ve talked to companies where we’ve sat down and the first thing I’ve said is, “You actually need to dedicate probably 2 or 3 engineers to building internal tooling because if everyone has to come in and manually set up everything, what you have is this super painful onboarding process that’s just going to bottleneck your company.” One of the first things, I think as an engineer, that you should do is automate things. Automation is great. People should be able to get set up really easily with their development environment. They shouldn’t spend a lot of time having to do all these installations that you do once that have no learning value. That’s the first thing I think companies should do.
The second thing is 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. Just knowing that 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. I know a lot of people at companies who care a lot about this are often newer employees who went through bad onboarding and junior employees who went through bad onboarding. I think one of the big things for companies that I recommend is executive level signoff because there’s nothing worse at a company than fighting a Director of Engineering who is like, “Do we really need onboarding?” You’re like, “Yes, yes, we do.”
Derrick:
Beyond those first things, what else can you try?
Kate:
There are 3 major categories that people need to develop in 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. Everyone is like, “Getting someone onboard is about teaching them about Python or whatever technologies we use.” I say that’s only about a third of what they need to know to be an engineer at your company. Another third is company structure, the internal tools that you have, the way that you build, the way that your code is set up. That’s another third of the knowledge that somebody needs. It’s basically domain specific engineering knowledge which is huge at companies.
Another third is personal development, things like confidence, the ability to research problems, the ability to debug independently, a judgment which is huge. Probably the single most important thing in most engineers is judgment. That’s another third of what people need to develop. I think focusing on each of those areas is really good. People are going to come in stronger in different categories. 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. Just filling in the gaps in the areas that they aren’t as strong in.
“If you can’t hire any junior engineers… into your organization, you have serious problems”
Creating the Best Environment for Onboarding Junior Developers
Derrick:
Is there anything else somebody could do to create a great experience for junior engineers in onboarding?
Kate:
Recognizing a few things about the beginners is very important. First pairing them with someone who is one level above is actually most effective. Second, one of the tenets of expertise is the ability to recognize boundaries and scope really well. One of the tenets of being a beginner is that you cannot recognize boundaries and you are unable to scope problems and scope your world. Expecting a junior engineer to be really good at scoping a feature is unrealistic. 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. I always tell beginners, “If you come across an issue, research it for an hour and then come talk to me.” It’s not to be mean. I’m happy to answer questions. It’s just that learning to research something on your own is really valuable and figuring out things on your own is also really valuable.
The final thing for junior engineers and beginners, in general, is helping to bolster confidence. Some people do come in and they have an overabundance of confidence, but there’s a lot of people who come in who are very insecure. 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.
Derrick:
You’re a proponent of weekly 1-on-1s, including 1-on-1s with anyone in the company, why do you think that they’re so important?
Kate:
I think talking to other people is really valuable. There’s a whole industry where you can pay to go talk to someone for an hour every week about your problems. I think people need to be heard. I also think that a huge part of what managers should be doing is listening. It forces managers to listen, hopefully, and it gives people an outlet to talk about things. I also think that you should have channels of communication that are open at all times. One of the arguments I hear against 1-on-1s is that very often engineers will come in and they’re like, “Everything is great. I’m fine. I’m super happy.”
I’m like, “That’s awesome. That is so great that your employees are really happy, but if something bad happens, they’re not going to want to have to schedule an emergency meeting with you. You should have open channels of communication so that they can come to you at any time and be like, ‘You know what? Something happened. Things are not good this week. I am unhappy about something.’” Having a constant rapport makes it easier for them to come to you in bad times, which is really what you want. The communication channels and 1-on-1s and things like that are just to set up relationships so that people feel comfortable coming to you with bad news, which is actually a very difficult thing to do.
“I always tell beginners, ‘If you come across an issue, research it for an hour and then come talk to me.’”
Common Onboarding Mistakes
Derrick:
When organizations are onboarding, what are some common mistakes you’ve seen?
Kate:
The big ones are burning out senior mentors. Then that leads to, “We can’t take on any more junior engineers,” which is a huge travesty. When I hear companies saying that “We only hire senior engineers,” I’m like, “Who do you think is training all of these senior engineers? Where do you think they come from?” There are 2 ways to get great engineers at your company. You can steal them or you can make them. In this day and age, you’d probably better have outlets for both. You should have a sustainable program of bringing on junior engineers. Depending on the size of your team, sure, you might only be able to handle a few at a time. Totally fair, but if you can’t hire any junior engineers if you cannot hire any beginners into your organization, you have serious problems with your team structure and your internal tools probably and basically everything that has to do with bringing someone new onboard.
Let’s see, other common mistakes … Bad internal tooling. This is the whole infrastructure thing that I get on. Having a really good infrastructure means not only can you deploy code quickly and reliably, which is what a lot of people talk about, but it means that you can also bring new people onboard. If you have a really easy to use a robust system for testing all of your code and deploying it, that is much, much easier for someone new to learn. It’s also a great system for people who are beginners. It’s robust. It’s easy to use. We can train a junior engineer to deploy code. Some of the best things I’ve seen for web applications are 1-click deploys, being able to deploy code to any service with the click of a button is great. Similarly 1-click rollbacks, really good, integration testing and things like that.
Derrick:
Kate, thank you so much for joining us today.
Kate:
Thank you so much for having me.
Comments