00:00:11.469
How you onboard a junior engineer onto your team can have a lasting impact on their success, happiness, and productivity. You might be thinking that this sounds like a lot of responsibility, and you'd be right. Luckily, though, it doesn't have to be a difficult process if you take the time to prepare and follow the steps outlined in this talk. My name is Emily Giurleo, and I'm a software engineer at MongoDB. Over the past six years, I've made the transition from intern to junior engineer to mid-level engineer through various internships and full-time jobs. In that time, I've seen the onboarding process at every company I've worked for, and I planned the intern onboarding process at my first full-time job. I've seen a lot of things that worked and a lot that didn't, and I'm here to share my findings with you.
00:01:01.790
The first thing you have to realize is that you can't accomplish the perfect onboarding process alone. Ultimately, there are at least three parties involved in making sure your new junior engineer succeeds on your team. Of course, there's you, the manager or mentor of the junior engineer, there's your team, the people who are going to be working most closely with the engineer, and the junior engineer themselves. For the purposes of this talk, we're going to assume that all three of these parties want the junior engineer to succeed and are going to try their best to make that happen.
00:01:40.580
Now that you know who has to be involved, it's important to define some goals for your onboarding process. These can vary depending on the size of your company and the kind of work you do, but I think the following three are usually a good place to start. First of all, you want to enable the new engineer to be an autonomous and productive contributor on your team. Secondly, you want them to build confidence in their skills so they can take on more responsibilities and become a more senior engineer. Lastly, you want to develop trust between yourself, the new engineer, and the rest of your team. It's very hard to work with people you don't trust, so the success of the new engineer hinges on their trusting you to guide them in the right direction.
00:02:26.840
To quickly recap, we've talked about who needs to be involved in your onboarding process and the goals you've set for yourself and your team. The last element that we need to complete the equation is the steps to follow. I'm going to spend the rest of this talk explaining how you, the junior engineer, and the rest of your team can work together on each of these steps and accomplish the goals we've laid out. Are you ready? Let's get started!
00:02:53.540
So the first step in a successful onboarding process is to set expectations. You may think that this step is mainly focused on sitting down with the junior engineer and telling them exactly what you expect out of their role. However, setting expectations should actually start way earlier than that. Before the junior engineer even starts their job, you have to set your own expectations regarding their performance. Start by making a roadmap for the new engineer. What should they be doing after one month, two months, or three? Now take another look at their resume: what do they already know and what are they going to need to learn to hit the milestones in your roadmap?
00:03:39.230
Once you've done that, it's time to set expectations with your team about who's going to teach the new engineer the things they need to know to be successful at their job. Chances are, based on the previous step, you found that the new engineer is going to have to learn some skills in order to be successful on your team. That means someone on your team will have to help them learn the skills they need. Who is going to do that? It's also important to figure out how much time they should spend doing that. Obviously, onboarding new engineers to your team is a very important use of your time, but it's also vital not to derail the entire team or stop them from doing their regular work in order to accomplish this.
00:04:19.340
Once you've set expectations for yourself and with your team, then it's finally time to set expectations with the junior engineer. First, you can share your three-month roadmap with them, and this is a great time to let them express their ideas and preferences and perhaps choose between a couple of projects that you've laid out for them. This is also a great time to tell them who on the team they can go to with questions based on the conversations that you've already had with the rest of your team. In this step, you've established your own expectations about the performance of the junior engineer, set expectations with your team about who's going to spend time teaching, and you've communicated all this to the junior engineer. Now, it's time to check in with our goals and see what we've accomplished.
00:05:11.700
In this step, we've enabled the new engineer to work autonomously. Keep in mind, this doesn't mean they work alone; it just means they know what they need to do to perform well at their job and that they also know who to ask for help when they're blocked.
00:05:57.780
The next step in a successful onboarding process is to deliver feedback. Once again, you may think that this step starts with giving feedback to the junior engineer as they begin doing work and making mistakes, but you first need to spend time laying the foundations. This step actually starts with normalizing feedback on your entire team. This is entirely its own talk, so I'm not going to dwell too much on this. What I want to emphasize is that it's important that your teammates are already comfortable giving and receiving feedback because they set the tone for the new people who join the team.
00:06:44.270
It's unreasonable to expect a junior engineer to accept feedback from you if none of your other teammates can do the same. Here are some warning signs that your team is not comfortable giving and receiving feedback: one warning sign is having teammates who react defensively to feedback. Another is teammates who talk behind each other's backs instead of just giving feedback face-to-face. The last is having certain teammates who are exempt from criticism because they're considered lone geniuses or indispensable to the team. If you find that any of these things are true on your team, it's worth doing some research on how to improve the existing culture before worrying too much about giving feedback to the junior engineer.
00:07:35.480
However, no team is perfect at giving and receiving feedback, so it's probably worth it for all of us to be thinking about how we can improve in this area. Once you've started thinking about normalizing feedback on your team, it's time to start giving feedback to the junior engineer once they arrive and begin doing some work. They're going to do some good things and some not-so-good things, and you're going to want to give them feedback and guide them in the right direction. There are three aspects of giving feedback that I'm going to talk about here: the first is how to give feedback, the second is what to give feedback on, and the third is when to give feedback.
00:08:19.810
So let's start with how you give feedback to the junior engineer. I'm going to give you an example: let's say the junior engineer was making their first change to the code and they pushed directly to master instead of creating a pull request. It's your job to sit down with the junior engineer and tell them exactly what went wrong. Here are some good steps you can follow to do that: the first step is to be specific. Don't leave the junior engineer questioning what they did wrong or what they did to prompt this conversation.
00:09:17.701
So you can say something like, 'I noticed you pushed directly to master instead of creating a pull request.' That's very specific and leaves no room for doubt or misunderstanding. Next, it's important to focus on the impact that the junior engineer had with their actions. This is important because receiving feedback, especially critical feedback, can feel very personal or like an attack. So, by focusing on the impact of what happened, you're showing the junior engineer that there are objective results based on their actions and it's not about them as a person.
00:09:57.220
In this case, you can say, 'This prevents the rest of your team from being able to catch bugs in your code.' So suddenly, it's about the team and the codebase rather than the junior engineer themselves. Next, you're going to want to take a step back from your own perspective and ask questions of the junior engineer to understand why they did what they did. A great question to ask is, 'Why did you do that?' While you're listening to the answer from the junior engineer, the most important thing is just to validate their experience and hear what they have to say.
00:10:58.510
Ultimately, I think you can say something like, 'I understand why you thought this was the appropriate thing to do.' Once you understand the junior engineer's point of view, it's time to redefine your expectations. You can say something like, 'In the future, I expect you to create a pull request for every change you make to the code.' This way, the junior engineer has no doubt what they have to do to prevent themselves from making the same mistake in the future. Lastly, it's important to give the junior engineer a chance to fix their own mistake if you can.
00:11:52.350
We all have made mistakes in our careers that we remember years later because we had to spend hours and hours fixing them afterward. I think it's safe to say that most of us never made those same mistakes again. So, if you have the time and resources to allow the junior engineer to fix their own mistake, you're guaranteeing they will not make that same mistake again. One way to do that in this scenario would be to say, 'Walk me through the code you merged and then make a pull request with any changes I suggest.' You could, of course, go and fix the code yourself, but once again, the junior engineer will not fully understand the impact of what they've done unless they get to go and fix it themselves.
00:12:51.970
To recap, the steps to giving feedback are: be specific, focus on impact, ask questions, redefine expectations, and give the junior engineer a chance to fix it themselves. Now that we've talked about how to give feedback to the junior engineer, we're going to talk about what to give feedback on. In the previous example, we talked specifically about critical or constructive feedback, but it's essential to provide feedback on everything.
00:13:32.800
And I don't mean that you should carefully watch the junior engineer and nitpick every single thing they do because that does not create a healthy work environment. What I mean is that it's crucial to comment on both the things that the junior engineer does poorly and the things they do well. I say this to prevent you from falling into a trap that I've seen a few times: ignoring a new hire who is doing well. To you and your team, it might be obvious that the junior engineer is performing above expectations, but it is definitely less obvious to the junior engineer.
00:14:18.840
Many people, when not given any feedback, actually assume they are doing poorly but that no one has the guts to tell them. You can correct this misunderstanding very quickly by just saying congratulations for the things they do well in the first few months on the job. It's also important to be mindful of what kinds of positive feedback you give the junior engineer. A common problem I've seen is managers rewarding a junior engineer for doing non-technical work, which they see as going above and beyond, such as taking notes during a meeting or contributing to the recruitment process, but not commenting on the technical work that they do as part of their day-to-day job.
00:15:05.660
This can have the unintended consequence of pushing the junior engineer away from their technical role, which is not what you want to do. So, make sure you are commenting just as much on their technical work as you are on any non-technical contributions they make. And to be clear, it's okay if the junior engineer is interested in doing non-technical work; it's just crucial that you pay equal attention to their technical contributions as to their non-technical contributions.
00:16:01.260
It's also important to reward their non-technical contributions that add value to the team just as you would technical contributions of equal value. We're going to talk about rewarding the junior engineer in step three of this process, so hang tight for that. Now that we've talked about how to give feedback and what to give feedback on, I also want to touch on when to give this feedback to the junior engineer.
00:16:42.760
A great time to give feedback is during regularly scheduled one-on-ones. You should put these on your calendar every week or every two weeks and make sure you encourage the junior engineer to add discussion topics to the agenda. This is a good time to check in on their progress along your roadmap and also a good time to give them guidance if they're doing anything particularly well or if you think they've gone astray in some way. However, another good time to give feedback is not during regularly scheduled one-on-ones. You shouldn't limit your interactions with the junior engineer to these meetings.
00:17:45.290
One or two weeks is actually a long time to go without getting any feedback in the first few months of a job, so you should be taking time day-to-day to provide smaller points of feedback to get the engineer on the right path. This is a quote I like very much from Radical Candor by Kim Scott: 'You'd never let the fact that you go to the dentist for a cleaning a couple times a year prevent you from brushing your teeth every day.' This is the attitude we have to take when giving feedback to junior engineers. Giving feedback to the junior engineer is probably going to reveal some inadequacies in your planning and your onboarding process.
00:18:34.390
The third aspect of this step is actually being open to receiving feedback yourself. Let's go back to the example where the junior engineer merged to master without asking for a code review. When you confront them about this, it's very possible they'll say something like, 'Well, nobody ever told me that I had to create a pull request.' When you hear this, your first instinct is probably going to be to become defensive; after all, everybody knows that you have to create a pull request, right? I'm here to tell you not to do this. Do not become defensive; saying something like that to the junior engineer would actually be mean and would be punishing them for not knowing something that you never required them to know in order to get the job.
00:19:29.150
So, there's nothing they could have done to prevent themselves from getting into that situation. Instead, use the feedback from the junior engineer to improve the onboarding process. Maybe this is a step that you could write down in some onboarding documentation, or perhaps you should change the settings on your GitHub to prevent anyone from merging to master without getting approval first. These are easy ways to prevent future junior engineers from making the same mistakes.
00:20:21.070
So, in this step of delivering feedback, you normalized a feedback culture on your team, you delivered feedback to the junior engineer, and you've prepared yourself to get some feedback in return. Let's check in on how this contributes to our goals. In this step, we've helped the new engineer gain confidence in their ability to learn and grow. They've had the space to show off what they know, but they aren't punished for making mistakes while they learn new skills.
00:21:04.260
They're not going to be afraid to admit when they don't know something, and they're not going to be afraid to ask for help from you and the rest of the team. Up to this point, we've set expectations for the junior engineer and delivered feedback to help guide them toward meeting expectations. Now it's time for our final step in the process, which is assessing performance. At this stage, you're judging whether the junior engineer has been meeting the expectations you set out and you're going to reward them based on their performance.
00:21:44.900
As with the previous two steps, you might think that this step starts with giving a performance review to the junior engineer. However, it's crucial to take a step back and prepare your team. You have to get on the same page with the rest of your team about what constitutes good work performance. Imagine the scenario where you give a performance review to the junior engineer and tell them they did a great job on their project and you're going to give them a raise as a result. Then imagine the next day, another one of their team members says that same project took way too long and they're not happy with the outcome.
00:22:35.290
This totally undermines the junior engineer's trust in you, so it's your job to make sure the entire team is on the same page regarding what is or is not acceptable work performance before you start giving performance reviews. You can do this in a few ways, and I think one popular way is to agree with the team on a list of criteria for promotion where someone must meet many or all of them before they are considered for a raise or promotion.
00:23:28.450
Once you've gotten on the same page as the rest of your team, it's time to give a performance review to the junior engineer. If you followed the previous two steps, the contents of this performance review should not be surprising to you. And if the junior engineer is performing well, you can reward them with a raise or a promotion if possible. You should back your words with actions and prove to the junior engineer that you're willing to advocate on their behalf for more money and a better title, which are concrete rewards that will improve their quality of life.
00:24:33.260
If the junior engineer's performance is a surprise to you, it means that you've probably failed at one of the previous two steps of this process and you should be prepared to assess your own performance as the manager of the onboarding process. Some things that could have gone wrong are: you thought that the junior engineer knew more than they did when they started the job; maybe you knew the junior engineer would need to gain certain skills but didn't make a plan for them to do so; or maybe you didn't give the junior engineer timely feedback, causing them to repeat the same mistakes over and over when they could have been corrected.
00:25:29.800
Regardless of how the onboarding process turned out, this is a great time for you to collect feedback from your team and from the junior engineer to see how you can improve the process in the future. In this third step of assessing performance, you've gotten on the same page with the rest of your team about what constitutes good work performance, you've given a performance review to the junior engineer, and you've also assessed your own performance as the manager of the onboarding process.
00:26:15.900
This helps us complete our third and final goal, which is to build trust between yourself, your team, and the junior engineer. Because you backed up your feedback with concrete rewards, the engineer feels they can trust your guidance and they know that you'll keep your word in the future. If you follow these steps, you will develop an onboarding process that enables the new engineer to be an autonomous contributor on your team, helps them build confidence in their abilities, and develops trust between you, the new engineer, and the rest of your team.
00:27:11.260
This matters for a few reasons: it might seem like a lot of work, but it will be worth it once the new engineer on your team becomes a productive contributor. More importantly, the steps lay the groundwork for building a diverse team. Ideally, you want your team to be composed of people from all different backgrounds: people who have never worked in the tech industry, people who didn't go to college or didn't study computer science, and people from different countries all over the world.
00:28:31.760
Not everyone is going to come into your work environment and immediately share your criteria for success. Ultimately, when you leave people guessing about how to be successful, you're setting up the most vulnerable among them for failure. The easiest way to ensure the success of every member of your team, regardless of their background, is to clearly communicate the steps they need to take to be successful, give them feedback along the way, and reward them for the success they achieve.
00:29:14.560
Thank you very much for listening to my talk and for attending RailsConf 2020 Couch Edition. If you'd like to connect, you can find me on Twitter at Emily Giurleo or on my website at emilygiurleo.dev. Stay safe out there, and I hope we get to meet in person at a future Ruby gathering. Thanks again.