WEBVTT 00:00:00.100 --> 00:00:00.200 KATE HEDDLESTON: Hi everyone. 00:00:00.300 --> 00:00:00.400 Welcome to my talk. I'm Kate Heddleston 00:00:00.500 --> 00:00:00.600 and this is Technical Onboarding, 00:00:00.700 --> 00:00:00.800 Training and Mentoring. 00:00:00.900 --> 00:00:01.000 So I'm a software engineer out of San Francisco. 00:00:01.100 --> 00:00:01.200 I do mostly contract work now. Full stack, web 00:00:01.300 --> 00:00:01.400 apps. And I work with a lot of really 00:00:01.500 --> 00:00:01.600 early-stage start ups. And this was originally written as 00:00:01.700 --> 00:00:01.800 a co-presentation with Nicole Zuckerman. She's a software engineer 00:00:01.900 --> 00:00:02.000 at Eventbrite. And she couldn't be here today because 00:00:02.100 --> 00:00:02.200 she is vacationing in Italy. So I feel not 00:00:02.300 --> 00:00:02.400 bad for her at all. 00:00:02.500 --> 00:00:02.600 All right. So she's the one on the right. 00:00:02.700 --> 00:00:02.800 I'm the one on the left. And, and Nicole 00:00:02.900 --> 00:00:03.000 attended a Code Academy called Hack Brite Academy, which 00:00:03.100 --> 00:00:03.200 I teach at one day a week. And we 00:00:03.300 --> 00:00:03.400 came together to write this talk because we work 00:00:03.500 --> 00:00:03.600 at separate companies and had experiences at these separate 00:00:03.700 --> 00:00:03.800 companies that were fairly similar. 00:00:03.900 --> 00:00:04.000 So, when I was right out of college, I 00:00:04.100 --> 00:00:04.200 joined a small start up. I was the sixth 00:00:04.300 --> 00:00:04.400 engineer, twelfth person, and I worked there for a 00:00:04.500 --> 00:00:04.600 time and it grew a lot, and after awhile, 00:00:04.700 --> 00:00:04.800 I reached a certain level of proficiancy. I looked 00:00:04.900 --> 00:00:05.000 back and I thought, I could have gotten here 00:00:05.100 --> 00:00:05.200 a lot faster with just a little bit of 00:00:05.300 --> 00:00:05.400 help and a little bit of structure. 00:00:05.500 --> 00:00:05.600 And so, I turned around and created the Onboarding 00:00:05.700 --> 00:00:05.800 program at my company. And Nicole had a similar 00:00:05.900 --> 00:00:06.000 experience at Eventbrite, and so she has been doing 00:00:06.100 --> 00:00:06.200 a lot of work there with onboarding. So we 00:00:06.300 --> 00:00:06.400 wrote this presentation and submitted it. It's important to 00:00:06.500 --> 00:00:06.600 note that this presentation was written specifically with junior 00:00:06.700 --> 00:00:06.800 engineers in mind. However, about 90 to 90% of 00:00:06.900 --> 00:00:07.000 what I say can very, very easily be adapted 00:00:07.100 --> 00:00:07.200 to people who are more experienced. 00:00:07.300 --> 00:00:07.400 All right. What is onboarding? So for the purposes 00:00:07.500 --> 00:00:07.600 of this talk, onboarding is the process of taking 00:00:07.700 --> 00:00:07.800 someone from outside of the group, outside the company, 00:00:07.900 --> 00:00:08.000 outside the team, and making them a productive, independent 00:00:08.100 --> 00:00:08.200 and confident member of the team. 00:00:08.300 --> 00:00:08.400 And I picked these three characteristics because I think 00:00:08.500 --> 00:00:08.600 they're, they're incredibly important. Productivity seems a bit self-explanatory. 00:00:08.700 --> 00:00:08.800 It seems kind of like, the goal that we're 00:00:08.900 --> 00:00:09.000 focusing on. Like, of course we would like productive 00:00:09.100 --> 00:00:09.200 engineers. And it's about creating efficient employees. 00:00:09.300 --> 00:00:09.400 Independence, and another word for independence is autonomy, is 00:00:09.500 --> 00:00:09.600 about creating engineers that can operate in your organization 00:00:09.700 --> 00:00:09.800 without needing a ton of oversight, that can make 00:00:09.900 --> 00:00:10.000 decisions and understand your company structure well enough to 00:00:10.100 --> 00:00:10.200 not have the overhead of having to go ask 00:00:10.300 --> 00:00:10.400 four levels of management for something. 00:00:10.500 --> 00:00:10.600 Also, independence and autonomy speaks to this, this need 00:00:10.700 --> 00:00:10.800 that we have to have some control over our 00:00:10.900 --> 00:00:11.000 own destiny. I was reading an article recently and 00:00:11.100 --> 00:00:11.200 it was talking about the need for autonomy, and 00:00:11.300 --> 00:00:11.400 it was citing inmates in prisons. So, in a 00:00:11.500 --> 00:00:11.600 lot of prisons, inmates are allowed to choose the 00:00:11.700 --> 00:00:11.800 channel. They're allowed to rearrange their furniture. And they 00:00:11.900 --> 00:00:12.000 found that this drastically reduced rebellions within prisons. So, 00:00:12.100 --> 00:00:12.200 independence is important, cause you don't want your engineers 00:00:12.300 --> 00:00:12.400 to rebel. But it's also important because feeling independent 00:00:12.500 --> 00:00:12.600 and autonomous helps people feel motivated and invested in 00:00:12.700 --> 00:00:12.800 what they're doing. 00:00:12.900 --> 00:00:13.000 Finally, confidence I think is the most important of 00:00:13.100 --> 00:00:13.200 the three. Confidence is about creating employees who believe 00:00:13.300 --> 00:00:13.400 that they are valuable. It's not about the actual 00:00:13.500 --> 00:00:13.600 act of creating employees that are valuable. The study, 00:00:13.700 --> 00:00:13.800 which is at, the links are at the bottom 00:00:13.900 --> 00:00:14.000 actually, that I was reading about recently, they split, 00:00:14.100 --> 00:00:14.200 this was a gendered study, but what they found 00:00:14.300 --> 00:00:14.400 didn't really have to do with gender. 00:00:14.500 --> 00:00:14.600 They split the participants into six groups. Three groups 00:00:14.700 --> 00:00:14.800 of men, three groups of women. So there was 00:00:14.900 --> 00:00:15.000 a control and two test groups for each gender. 00:00:15.100 --> 00:00:15.200 And, for one of the groups of men, they 00:00:15.300 --> 00:00:15.400 told them, they're doing some sort of spatial reasoning 00:00:15.500 --> 00:00:15.600 activity, they told them, men are really good at 00:00:15.700 --> 00:00:15.800 spatial reasoning. You should be good at this task. 00:00:15.900 --> 00:00:16.000 That group performed significantly better than the control. The 00:00:16.100 --> 00:00:16.200 next group of men they told, men are really 00:00:16.300 --> 00:00:16.400 bad at spatial reasoning. You'll be bad at this 00:00:16.500 --> 00:00:16.600 task. And that group performed significantly worse than the 00:00:16.700 --> 00:00:16.800 control. And they found the exact same thing with 00:00:16.900 --> 00:00:17.000 women. 00:00:17.100 --> 00:00:17.200 And so what this means is that confidence actually 00:00:17.300 --> 00:00:17.400 affects how well people perform. So confident people will 00:00:17.500 --> 00:00:17.600 perform better in a measurable way. 00:00:17.700 --> 00:00:17.800 So why do you care? I assume that everyone 00:00:17.900 --> 00:00:18.000 here cares because you came to my talk. But 00:00:18.100 --> 00:00:18.200 I would like to convince you that you should 00:00:18.300 --> 00:00:18.400 care now. You should care immediately, and that you 00:00:18.500 --> 00:00:18.600 should start building an onboarding program at your company 00:00:18.700 --> 00:00:18.800 as soon as possible. 00:00:18.900 --> 00:00:19.000 And I'm gonna talk about four things in this 00:00:19.100 --> 00:00:19.200 session. I'm gonna talk about the individual who's joining 00:00:19.300 --> 00:00:19.400 the company, the company that they are joining, the 00:00:19.500 --> 00:00:19.600 specific team within the company that they are becoming 00:00:19.700 --> 00:00:19.800 a member of, and then there's a bonus category, 00:00:19.900 --> 00:00:20.000 which is diversity. 00:00:20.100 --> 00:00:20.200 So, the individual. What can go wrong if you 00:00:20.300 --> 00:00:20.400 don't have onboarding? Or basically if you don't have 00:00:20.500 --> 00:00:20.600 investment in your employees? 00:00:20.700 --> 00:00:20.800 Attrition is something that most companies and most of 00:00:20.900 --> 00:00:21.000 us are terrified of. And for a good reason. 00:00:21.100 --> 00:00:21.200 Attrition can cost thousands of dollars per employee. Up 00:00:21.300 --> 00:00:21.400 to 1.5 to 2x their salary. And it's not 00:00:21.500 --> 00:00:21.600 that people quit specifically because your company does or 00:00:21.700 --> 00:00:21.800 not have onboarding. People quit for a meriad of 00:00:21.900 --> 00:00:22.000 reasons. The number one is actually that they are 00:00:22.100 --> 00:00:22.200 dissatisfied with their managers. But onboarding can address a 00:00:22.300 --> 00:00:22.400 lot of the issues that people ultimately quit for, 00:00:22.500 --> 00:00:22.600 or quit because of, and it can address them 00:00:22.700 --> 00:00:22.800 really early. 00:00:22.900 --> 00:00:23.000 So getting someone up to speed so that they're 00:00:23.100 --> 00:00:23.200 confident, they have this upward trajectory, they're building their 00:00:23.300 --> 00:00:23.400 skill set early, is going to set them up 00:00:23.500 --> 00:00:23.600 for success in the long term, so that eight 00:00:23.700 --> 00:00:23.800 months to twelve months down the road, they aren't 00:00:23.900 --> 00:00:24.000 leaving because they never felt like they were part 00:00:24.100 --> 00:00:24.200 of the team. Or they never felt like they 00:00:24.300 --> 00:00:24.400 were contributing. Address this early at onboarding is one 00:00:24.500 --> 00:00:24.600 of the best ways to do that. 00:00:24.700 --> 00:00:24.800 For the company. Companies care hugely about the productivity 00:00:24.900 --> 00:00:25.000 of their employees. This is a graph of productivity 00:00:25.100 --> 00:00:25.200 decreasing as you add new engineers to the team. 00:00:25.300 --> 00:00:25.400 And, anecdotally, this actually happened at LinkdIn not too 00:00:25.500 --> 00:00:25.600 long ago. Every engineer that they added to their 00:00:25.700 --> 00:00:25.800 team decreased their overall productivity and ultimately affected the 00:00:25.900 --> 00:00:26.000 company's bottom line. 00:00:26.100 --> 00:00:26.200 So, when their new SVP of engineering came on 00:00:26.300 --> 00:00:26.400 board, Kevin Scott, he had to do a whole 00:00:26.500 --> 00:00:26.600 bunch of work revamping their organization, building onboarding. And 00:00:26.700 --> 00:00:26.800 this is, I mean, LinkdIn is thousands of people 00:00:26.900 --> 00:00:27.000 at this point. So this is a huge amount 00:00:27.100 --> 00:00:27.200 of work. To try to get the graph to 00:00:27.300 --> 00:00:27.400 look like this. To try to get each new 00:00:27.500 --> 00:00:27.600 employee to add value to the company. And this 00:00:27.700 --> 00:00:27.800 doesn't have to do with the employees. It's not 00:00:27.900 --> 00:00:28.000 like they're hiring engineers that are then negative in 00:00:28.100 --> 00:00:28.200 their value. It has to do with their process, 00:00:28.300 --> 00:00:28.400 and onboarding is one of the great ways to 00:00:28.500 --> 00:00:28.600 make sure that you're taking a good look at 00:00:28.700 --> 00:00:28.800 your process. 00:00:28.900 --> 00:00:29.000 This speaks to something I like to call team 00:00:29.100 --> 00:00:29.200 debt. How many of you have heard of the 00:00:29.300 --> 00:00:29.400 concept of code debt? A lot of people. Yeah, 00:00:29.500 --> 00:00:29.600 we talk about that a lot as engineers. How 00:00:29.700 --> 00:00:29.800 if you build something fast and don't think about 00:00:29.900 --> 00:00:30.000 it, you accrue this code debt, and over time 00:00:30.100 --> 00:00:30.200 you have to go back through your code base, 00:00:30.300 --> 00:00:30.400 take a look at things, rewrite them, and ultimately 00:00:30.500 --> 00:00:30.600 address that. 00:00:30.700 --> 00:00:30.800 Well, the same thing happens with people. So if 00:00:30.900 --> 00:00:31.000 you aren't doing a good job investing in your 00:00:31.100 --> 00:00:31.200 employees, if you're not onboarding them, if you're not 00:00:31.300 --> 00:00:31.400 training them, you're going to accrue team debt. And 00:00:31.500 --> 00:00:31.600 I've seen this a lot. I've talked to a 00:00:31.700 --> 00:00:31.800 lot of companies that are starting to get into 00:00:31.900 --> 00:00:32.000 the hundreds of people range. They're starting to hit 00:00:32.100 --> 00:00:32.200 a hundred engineers. And they're like, oh my goodness, 00:00:32.299 --> 00:00:32.400 we need onboarding. We need, we need to get 00:00:32.500 --> 00:00:32.600 these people up to speed. And at, at four 00:00:32.700 --> 00:00:32.800 hundred people, I mean, yeah. You've accrued a huge 00:00:32.900 --> 00:00:33.000 amount of team debt. 00:00:33.100 --> 00:00:33.200 Every person that you add and try to onboard 00:00:33.300 --> 00:00:33.400 is going to be increasingly difficult. Your code base 00:00:33.500 --> 00:00:33.600 is quite large at that point. You have a 00:00:33.700 --> 00:00:33.800 lot of teams. And so going and making all 00:00:33.900 --> 00:00:34.000 of those onboarding materials at a hundred people is 00:00:34.100 --> 00:00:34.200 way harder than starting when you're smaller than a 00:00:34.300 --> 00:00:34.400 hundred people and then maintaining it incrementally. 00:00:34.500 --> 00:00:34.600 The third aspect is the immediate team that the 00:00:34.700 --> 00:00:34.800 engineer joins. So there's a saying that you don't 00:00:34.900 --> 00:00:35.000 know something until you teach it. And this is 00:00:35.100 --> 00:00:35.200 absolutely true for your company's culture and code process. 00:00:35.300 --> 00:00:35.400 So if you don't know how to explain to 00:00:35.500 --> 00:00:35.600 a new engineer what your company's culture is or 00:00:35.700 --> 00:00:35.800 how you ship code or how you decide what 00:00:35.900 --> 00:00:36.000 features are built or who approves things, who reviews 00:00:36.100 --> 00:00:36.200 things, then you don't actually know it yourself. And 00:00:36.300 --> 00:00:36.400 that's a massive red flag for your company if 00:00:36.500 --> 00:00:36.600 you can't explain your process. 00:00:36.700 --> 00:00:36.800 Additionally, when people join small teams, small teams fundamentally 00:00:36.900 --> 00:00:37.000 change every single time you add a new person 00:00:37.100 --> 00:00:37.200 to them. So iterating your team's process to the 00:00:37.300 --> 00:00:37.400 new engineer is not just important for them, it's 00:00:37.500 --> 00:00:37.600 also important for your existing engineers, so that you 00:00:37.700 --> 00:00:37.800 get something that looks a little bit more like 00:00:37.900 --> 00:00:38.000 this, where everyone is on the same page. 00:00:38.100 --> 00:00:38.200 And because the team changes every time you add 00:00:38.300 --> 00:00:38.400 people to it, you're gonna have to reiterate this 00:00:38.500 --> 00:00:38.600 to everyone pretty much every time you add a 00:00:38.700 --> 00:00:38.800 new employee. 00:00:38.900 --> 00:00:39.000 So, something about me, I love sports anecdotes. I 00:00:39.100 --> 00:00:39.200 played sports for most of my life. And when 00:00:39.300 --> 00:00:39.400 I was done playing sports, I coached JV girls 00:00:39.500 --> 00:00:39.600 water polo at a high school nearby. And I 00:00:39.700 --> 00:00:39.800 used to have these really deep, philosophical team meetings 00:00:39.900 --> 00:00:40.000 with them, and I'd come in with these posters, 00:00:40.100 --> 00:00:40.200 and one day I came in with this, a 00:00:40.300 --> 00:00:40.400 poster with this written on it. They always just 00:00:40.500 --> 00:00:40.600 sat there and kind of rolled their eyes at 00:00:40.700 --> 00:00:40.800 me, like. 00:00:40.900 --> 00:00:41.000 But, I was trying to explain to them that 00:00:41.100 --> 00:00:41.200 their ability to win games was not wholly dependent 00:00:41.300 --> 00:00:41.400 on their skills. These girls were beginners. They didn't 00:00:41.500 --> 00:00:41.600 really know how to throw. They didn't really know 00:00:41.700 --> 00:00:41.800 how to swim. They basically didn't have the skill 00:00:41.900 --> 00:00:42.000 set necessary to play water polo. But, they were 00:00:42.100 --> 00:00:42.200 playing all these games. And so I wanted them 00:00:42.300 --> 00:00:42.400 to understand that their skill set was important, but 00:00:42.500 --> 00:00:42.600 team work was more important, so they could actually 00:00:42.700 --> 00:00:42.800 beat teams that were theoretically more skilled than them 00:00:42.900 --> 00:00:43.000 but didn't work together as well as they did 00:00:43.100 --> 00:00:43.200 if they all banded together, because teamwork is a 00:00:43.300 --> 00:00:43.400 multiplication factor. 00:00:43.500 --> 00:00:43.600 And this is true in engineering as well. Your 00:00:43.700 --> 00:00:43.800 productivity as an engineering team is the sum of 00:00:43.900 --> 00:00:44.000 the engineering talent that you have multiplied by how 00:00:44.100 --> 00:00:44.200 well you work together. So if your team is 00:00:44.300 --> 00:00:44.400 working well together, that's great. If not, your team 00:00:44.500 --> 00:00:44.600 can actually pull itself apart. And, anecdotally, a lot 00:00:44.700 --> 00:00:44.800 of, a lot of products have been built by 00:00:44.900 --> 00:00:45.000 teams that are less than ten or five people. 00:00:45.100 --> 00:00:45.200 So Gmail is a really great example. It was 00:00:45.300 --> 00:00:45.400 built by a team of less than five. And 00:00:45.500 --> 00:00:45.600 now that it's successful it's maintained by a team 00:00:45.700 --> 00:00:45.800 of over four-hundred, I think. 00:00:45.900 --> 00:00:46.000 So our bonus category, diversity. How many of you 00:00:46.100 --> 00:00:46.200 have read Dr. Seuss's book about sneetches? Yeah? It's 00:00:46.300 --> 00:00:46.400 a great, it's a childrens' poem, like all of 00:00:46.500 --> 00:00:46.600 his books are. But it's about this community of 00:00:46.700 --> 00:00:46.800 sneetches. And sneetches are what I have drawn there. 00:00:46.900 --> 00:00:47.000 And at some point, some sneetches start developing stars 00:00:47.100 --> 00:00:47.200 on their bellies. And it's the story about kind 00:00:47.300 --> 00:00:47.400 of the rifts that happen in the community as 00:00:47.500 --> 00:00:47.600 a result of some sneetches having stars on their 00:00:47.700 --> 00:00:47.800 bellies and some sneetches not. 00:00:47.900 --> 00:00:48.000 But I like to use sneetches to represent diversity, 00:00:48.100 --> 00:00:48.200 cause diversity can mean a lot of things. It 00:00:48.300 --> 00:00:48.400 can be gender diversity, it can be racial diversity, 00:00:48.500 --> 00:00:48.600 it can be introverts versus extraverts as far as 00:00:48.700 --> 00:00:48.800 diversity goes. So communication styles. But the idea is 00:00:48.900 --> 00:00:49.000 that onboarding is gonna be really critical if you 00:00:49.100 --> 00:00:49.200 want to hire people who are different from each 00:00:49.300 --> 00:00:49.400 other in any way. 00:00:49.500 --> 00:00:49.600 This is pretty typical in tech. Companies are started 00:00:49.700 --> 00:00:49.800 by a small group of people, and it's homogenous. 00:00:49.900 --> 00:00:50.000 The phenomenom is called homophaly. We tend to associate 00:00:50.100 --> 00:00:50.200 and like to be around people who are like 00:00:50.300 --> 00:00:50.400 ourselves. So companies tend to get started as homogenous 00:00:50.500 --> 00:00:50.600 groups. 00:00:50.700 --> 00:00:50.800 If you don't have any onboarding, the people who 00:00:50.900 --> 00:00:51.000 are most likely to be successful joining your organization 00:00:51.100 --> 00:00:51.200 are people who are like the existing group. This 00:00:51.300 --> 00:00:51.400 is because they likely share similar communication styles, interests 00:00:51.500 --> 00:00:51.600 and hobbies. There might be tacit acceptance because they 00:00:51.700 --> 00:00:51.800 look the same as the rest of the group. 00:00:51.900 --> 00:00:52.000 So what you're doing is you're relying on homopholy 00:00:52.100 --> 00:00:52.200 and the existing social structure for peoples' success at 00:00:52.300 --> 00:00:52.400 the company and onboarding. 00:00:52.500 --> 00:00:52.600 And what you don't want to have happen is 00:00:52.700 --> 00:00:52.800 something like this. You hire someone new who's different, 00:00:52.900 --> 00:00:53.000 and they feel socially ostracized upfront. Not for any 00:00:53.100 --> 00:00:53.200 particular malicious reason, but just because they're different. They 00:00:53.300 --> 00:00:53.400 communicate differently. And so what you want is you 00:00:53.500 --> 00:00:53.600 want an explicit onboarding structure that helps bring people 00:00:53.700 --> 00:00:53.800 into the fold, that helps people become a part 00:00:53.900 --> 00:00:54.000 of the team in some sort of systematic way 00:00:54.100 --> 00:00:54.200 so that everyone who joins, no matter how different 00:00:54.300 --> 00:00:54.400 they are from the existing group, has a solid 00:00:54.500 --> 00:00:54.600 chance at being successful. 00:00:54.700 --> 00:00:54.800 So, hopefully now you guys are all convinced that 00:00:54.900 --> 00:00:55.000 onboarding is super important. 00:00:55.100 --> 00:00:55.200 Who at your company can onboard? 00:00:55.300 --> 00:00:55.400 So anyone of your team can onboard. This is 00:00:55.500 --> 00:00:55.600 not a, senior engineers have to be paired with 00:00:55.700 --> 00:00:55.800 junior engineers. They can learn the most. In fact, 00:00:55.900 --> 00:00:56.000 going back to sports analogies, some of your best 00:00:56.100 --> 00:00:56.200 people to onboard are going to be people, kind 00:00:56.300 --> 00:00:56.400 of like if a freshman athelete were to join 00:00:56.500 --> 00:00:56.600 a team, the sophomore athletes might be the best 00:00:56.700 --> 00:00:56.800 people to help them out. 00:00:56.900 --> 00:00:57.000 This is because they have the most empathy for 00:00:57.100 --> 00:00:57.200 what they're going through. They also experienced it the 00:00:57.300 --> 00:00:57.400 most recently, so they have relevant information and stories. 00:00:57.500 --> 00:00:57.600 So your sophomore engineers might be some of your 00:00:57.700 --> 00:00:57.800 best onboarders at the company, in addition to the 00:00:57.900 --> 00:00:58.000 expertise of your senior engineers. 00:00:58.100 --> 00:00:58.200 When? 00:00:58.300 --> 00:00:58.400 So onboarding can start as soon as an offer 00:00:58.500 --> 00:00:58.600 is accepted. I'm going to talk about an onboarding 00:00:58.700 --> 00:00:58.800 plan coming up soon, and we're gonna talk about 00:00:58.900 --> 00:00:59.000 from the start date to what I call reliable 00:00:59.100 --> 00:00:59.200 independence, which is where this person can build things 00:00:59.300 --> 00:00:59.400 and build features to an adequate level and be 00:00:59.500 --> 00:00:59.600 left on their own to the same degree as 00:00:59.700 --> 00:00:59.800 other engineers on the team. 00:00:59.900 --> 00:01:00.000 All right. How? 00:01:00.100 --> 00:01:00.200 So, the how category I'm gonna talk about some 00:01:00.300 --> 00:01:00.400 concepts to think about, when you're thinking about how 00:01:00.500 --> 00:01:00.600 to onboard others. And then I'm gonna launch into 00:01:00.700 --> 00:01:00.800 a four-week plan that goes through some of the 00:01:00.900 --> 00:01:01.000 specific things that you can do with engineers. 00:01:01.100 --> 00:01:01.200 So, first off, the concepts. It's pretty straight forward. 00:01:01.300 --> 00:01:01.400 You want to maximize your return on investment. You 00:01:01.500 --> 00:01:01.600 don't really want to be putting more into engineers 00:01:01.700 --> 00:01:01.800 than you're getting out of them. And most people 00:01:01.900 --> 00:01:02.000 don't really want more put into them than they're 00:01:02.100 --> 00:01:02.200 giving back. That's kind of a strange dynamic. 00:01:02.300 --> 00:01:02.400 So, a really inefficient but really common way that 00:01:02.500 --> 00:01:02.600 people try to onboard is this, like, hand-holding model. 00:01:02.700 --> 00:01:02.800 New onboarding mentors are really prone to this. They 00:01:02.900 --> 00:01:03.000 think, I'm gonna be the best onboarding mentor ever. 00:01:03.100 --> 00:01:03.200 We're gonna do everything together. We're gonna do all 00:01:03.300 --> 00:01:03.400 of these code tutorials. They're gonna watch me code 00:01:03.500 --> 00:01:03.600 every day, and by the time we're done with 00:01:03.700 --> 00:01:03.800 three months, they're gonna know everything that I know. 00:01:03.900 --> 00:01:04.000 And, in addition to being inefficient, because this is 00:01:04.099 --> 00:01:04.200 a huge time sink, it's also unrealistic. People do 00:01:04.300 --> 00:01:04.400 not become senior engineers in three months. You need 00:01:04.500 --> 00:01:04.599 time. You just, you just do. And so this 00:01:04.700 --> 00:01:04.800 burns people out and also disappoints them. 00:01:04.900 --> 00:01:05.000 A more efficient way to think abou things is, 00:01:05.099 --> 00:01:05.200 my example is bumper bowling, which is pretty much 00:01:05.300 --> 00:01:05.400 the only way I should be allowed to bowl. 00:01:05.500 --> 00:01:05.600 But, you set up an environment that's constrained, where 00:01:05.700 --> 00:01:05.800 they're able to play freely. They're able to go 00:01:05.900 --> 00:01:06.000 off and do what they want, come back and 00:01:06.100 --> 00:01:06.200 ask questions. But you don't have to handhold them 00:01:06.300 --> 00:01:06.400 through things. 00:01:06.500 --> 00:01:06.600 And so the way you do this with a 00:01:06.700 --> 00:01:06.800 technical environment is automation is huge. So, automating the 00:01:06.900 --> 00:01:07.000 development environment, automating deploy. Having a lot of testing 00:01:07.100 --> 00:01:07.200 for your code base, however you decide to do 00:01:07.300 --> 00:01:07.400 that. Whether it's TDD or not. Will help these 00:01:07.500 --> 00:01:07.600 junior engineers have a safe space to learn and 00:01:07.700 --> 00:01:07.800 grow and play. 00:01:07.900 --> 00:01:08.000 One of the important things to think about, too, 00:01:08.100 --> 00:01:08.200 when setting up this environment is that scoping is 00:01:08.300 --> 00:01:08.400 critical. One of the tenants of expertise is the 00:01:08.500 --> 00:01:08.600 ability to scope. So, if you're an expert, you 00:01:08.700 --> 00:01:08.800 understand the landscape incredibly well. So you're able to 00:01:08.900 --> 00:01:09.000 set these really well-defined boundaries. Junior engineers, by definition, 00:01:09.100 --> 00:01:09.200 are not good at scoping because they don't know 00:01:09.300 --> 00:01:09.400 the landscape. 00:01:09.500 --> 00:01:09.600 So, when you're thinking about giving them projects and 00:01:09.700 --> 00:01:09.800 you're thinking about setting up their environment, make sure 00:01:09.900 --> 00:01:10.000 to set boundaries for them and then slowly move 00:01:10.100 --> 00:01:10.200 them out as they know more about what's going 00:01:10.300 --> 00:01:10.400 on. Because they won't be able to set those 00:01:10.500 --> 00:01:10.600 boundaries for themselves. 00:01:10.700 --> 00:01:10.800 So, kind of three onboarding categories that map to 00:01:10.900 --> 00:01:11.000 the productive, independent, confident thing I was talking about 00:01:11.100 --> 00:01:11.200 earlier are technical knowledge, company knowledge and process, and 00:01:11.300 --> 00:01:11.400 personal development. I mention this because people think that 00:01:11.500 --> 00:01:11.600 onboarding has to do with technical knowledge. They seem 00:01:11.700 --> 00:01:11.800 to think that that's 90% of what's going on. 00:01:11.900 --> 00:01:12.000 I'd say it's actually about a third, and it's 00:01:12.100 --> 00:01:12.200 actually the easiest third, because you can go to 00:01:12.300 --> 00:01:12.400 the internet and find a ton of tutorials on, 00:01:12.500 --> 00:01:12.600 on Ruby and how to learn Rails and how 00:01:12.700 --> 00:01:12.800 to use Rails and blog posts about how to 00:01:12.900 --> 00:01:13.000 use any number of technology out there. 00:01:13.100 --> 00:01:13.200 The harder category, which is another third of what 00:01:13.300 --> 00:01:13.400 they need to know, is the company knowledge and 00:01:13.500 --> 00:01:13.600 process. And this is really, really important for them 00:01:13.700 --> 00:01:13.800 being independent. They can't be independent if they don't 00:01:13.900 --> 00:01:14.000 know how to operate within the company's infrastructure. This 00:01:14.100 --> 00:01:14.200 is harder because most companies don't write this down. 00:01:14.300 --> 00:01:14.400 So it's in someone's head somewhere, and the junior 00:01:14.500 --> 00:01:14.600 engineer, or the new engineer, is tasked with going 00:01:14.700 --> 00:01:14.800 and extracting it from whoever on the team knows 00:01:14.900 --> 00:01:15.000 this. So the more explicit you can be about 00:01:15.100 --> 00:01:15.200 your company knowledge and process, the better. 00:01:15.300 --> 00:01:15.400 And then third, personal development. That has to do 00:01:15.500 --> 00:01:15.600 with confidence, career trajectories. Again, this is, this is 00:01:15.700 --> 00:01:15.800 important because confident people are willing to reach. They're 00:01:15.900 --> 00:01:16.000 willing to be outgoing and they're willing to try 00:01:16.100 --> 00:01:16.200 new things. They also perform better. 00:01:16.300 --> 00:01:16.400 OK. So now I'm gonna talk about a fairly 00:01:16.500 --> 00:01:16.600 specific plan. This was written with junior engineers in 00:01:16.700 --> 00:01:16.800 mind. So some of the tasks are very specific 00:01:16.900 --> 00:01:17.000 to junior engineers, as is the time frame. A 00:01:17.100 --> 00:01:17.200 lot of these things will be relevant for people 00:01:17.300 --> 00:01:17.400 with more experience. The time frame just might be 00:01:17.500 --> 00:01:17.600 more condensed. 00:01:17.700 --> 00:01:17.800 So, for week one for a junior engineer, it's 00:01:17.900 --> 00:01:18.000 all about shipping code and kind of getting to 00:01:18.100 --> 00:01:18.200 know their immediate team. So dev environment setup is 00:01:18.300 --> 00:01:18.400 critical for anyone joining an engineering team. The last 00:01:18.500 --> 00:01:18.600 person who joined the company is going to be 00:01:18.700 --> 00:01:18.800 the best person to get them up to speed 00:01:18.900 --> 00:01:19.000 on their dev environment, because they are the one 00:01:19.100 --> 00:01:19.200 who knows the most about how to set up 00:01:19.300 --> 00:01:19.400 a dev environment. Someone who started two years ago 00:01:19.500 --> 00:01:19.600 is probably not going to know the ins and 00:01:19.700 --> 00:01:19.800 outs of getting started. 00:01:19.900 --> 00:01:20.000 Additionally, you should have a goal about how quickly 00:01:20.100 --> 00:01:20.200 you want someone's dev environment to be set up 00:01:20.300 --> 00:01:20.400 so that they can reasonably ship code. So like 00:01:20.500 --> 00:01:20.600 a config file, for example, or something static. A 00:01:20.700 --> 00:01:20.800 great goal is the first week. An awesome goal 00:01:20.900 --> 00:01:21.000 is the first day. And, if you want to 00:01:21.100 --> 00:01:21.200 try to match, I think it's Debian in the 00:01:21.300 --> 00:01:21.400 opensource world, their goal is five minutes, which is 00:01:21.500 --> 00:01:21.600 probably a little bit of a reach. But I'd 00:01:21.700 --> 00:01:21.800 say the first day is a fantastic goal. If 00:01:21.900 --> 00:01:22.000 someone can be set up with their dev environment 00:01:22.100 --> 00:01:22.200 and able to ship a config file the first 00:01:22.300 --> 00:01:22.400 day, that means that you have pretty great automation 00:01:22.500 --> 00:01:22.600 and a really great onboarding process. 00:01:22.700 --> 00:01:22.800 The next thing is shipping code. You should ship 00:01:22.900 --> 00:01:23.000 small changes and you should teach junior engineers to 00:01:23.100 --> 00:01:23.200 ship small changes as early as possible. So, give 00:01:23.300 --> 00:01:23.400 them a task as soon as they've got their 00:01:23.500 --> 00:01:23.600 dev environment set up and they're ready to go. 00:01:23.700 --> 00:01:23.800 Maybe have them fix a bug or rewrite tests 00:01:23.900 --> 00:01:24.000 or a small feature that's really well-scoped, so that 00:01:24.100 --> 00:01:24.200 they can ship something and be productive and part 00:01:24.300 --> 00:01:24.400 of the team as soon as possible. This is 00:01:24.500 --> 00:01:24.600 great both for your onboarding process, but also it 00:01:24.700 --> 00:01:24.800 helps them feel valuable, which, as we talked about 00:01:24.900 --> 00:01:25.000 earlier, is really key. 00:01:25.100 --> 00:01:25.200 Journaling and note-taking. People will naturally do this. We 00:01:25.300 --> 00:01:25.400 don't memorize all of the commands that we need 00:01:25.500 --> 00:01:25.600 to know, and so we'll write them down. Just, 00:01:25.700 --> 00:01:25.800 just give them a central place to do it. 00:01:25.900 --> 00:01:26.000 Talk to them about it. Ask them about three 00:01:26.100 --> 00:01:26.200 things they learned that day or that week. Just 00:01:26.300 --> 00:01:26.400 kind of put a communication structure around the fact 00:01:26.500 --> 00:01:26.600 that they're probably already taking notes. It will help 00:01:26.700 --> 00:01:26.800 you understand what's confusing for them and it will 00:01:26.900 --> 00:01:27.000 help them remember things. 00:01:27.100 --> 00:01:27.200 And then, finally, have a social event. And do 00:01:27.300 --> 00:01:27.400 this for any engineer that joins your team. No 00:01:27.500 --> 00:01:27.600 one should join a company and sit off in 00:01:27.700 --> 00:01:27.800 the corner alone, not knowing their immediate team mates. 00:01:27.900 --> 00:01:28.000 Have some sort of coffee. Have everyone sit together 00:01:28.100 --> 00:01:28.200 at lunch. Go out for dinner or drinks. It 00:01:28.300 --> 00:01:28.400 doesn't matter what it is. They just need to 00:01:28.500 --> 00:01:28.600 put names to faces and feel comfortable asking questions 00:01:28.700 --> 00:01:28.800 of, at least, their immediate team. Like, you know, 00:01:28.900 --> 00:01:29.000 the five people that they work with. If they 00:01:29.100 --> 00:01:29.200 want to ask someone where a pen is, or 00:01:29.300 --> 00:01:29.400 the bathroom, or they don't know something really simple 00:01:29.500 --> 00:01:29.600 and they feel uncomfortable asking, that's gonna be a 00:01:29.700 --> 00:01:29.800 bad experience right off the bat. And this one 00:01:29.900 --> 00:01:30.000 is so easy. It's just a gimme. 00:01:30.100 --> 00:01:30.200 All right. Week two. Week two is more about 00:01:30.300 --> 00:01:30.400 the context of the company, and also starting to 00:01:30.500 --> 00:01:30.600 have them shadow and, and learn from more senior 00:01:30.700 --> 00:01:30.800 engineers. So, you should tell them the history of 00:01:30.900 --> 00:01:31.000 your company. The history of your company hopefully is 00:01:31.100 --> 00:01:31.200 a pretty interesting story. The history of your company 00:01:31.300 --> 00:01:31.400 is also something they're not really gonna be able 00:01:31.500 --> 00:01:31.600 to absorb the first week. They aren't gonna know 00:01:31.700 --> 00:01:31.800 the characters in, in the story as well as 00:01:31.900 --> 00:01:32.000 they will the second week. So who are the 00:01:32.100 --> 00:01:32.200 founders? Why did they make this company? Who are 00:01:32.300 --> 00:01:32.400 the people that were hired early on? It actually 00:01:32.500 --> 00:01:32.600 is probably gonna tell you a lot about your 00:01:32.700 --> 00:01:32.800 process and your culture as well. 00:01:32.900 --> 00:01:33.000 Additionally, a team map is fantastic. So if you 00:01:33.100 --> 00:01:33.200 have some place where you can put everyone's picture 00:01:33.300 --> 00:01:33.400 and name, generally what they do and what they 00:01:33.500 --> 00:01:33.600 work on, if you can make it a seating 00:01:33.700 --> 00:01:33.800 chart, even better, or put their names above their 00:01:33.900 --> 00:01:34.000 computers. People are gonna forget someone's name. They're gonna 00:01:34.100 --> 00:01:34.200 forget that that guy they talked to five times 00:01:34.300 --> 00:01:34.400 is Andy. And they're gonna be embarrassed to ask 00:01:34.500 --> 00:01:34.600 just like I always am when I forget someone's 00:01:34.700 --> 00:01:34.800 name after talking to them for five times. 00:01:34.900 --> 00:01:35.000 Code labs and shadowing. So code labs are something 00:01:35.100 --> 00:01:35.200 that Eventbrite started doing, and this is a really 00:01:35.300 --> 00:01:35.400 awesome idea. It's basically a safe space for an 00:01:35.500 --> 00:01:35.600 hour once, twice, three times a week, however many 00:01:35.700 --> 00:01:35.800 times, where they can ask someone that's more senior 00:01:35.900 --> 00:01:36.000 any kind of question they want. So you can 00:01:36.100 --> 00:01:36.200 have a code lab for an hour that's on 00:01:36.300 --> 00:01:36.400 frontend development. Or a code lab for an hour 00:01:36.500 --> 00:01:36.600 on dev ops. And the most important thing about 00:01:36.700 --> 00:01:36.800 these code labs is actually not the topic. It's 00:01:36.900 --> 00:01:37.000 that it's safe. So when you're thinking about picking 00:01:37.100 --> 00:01:37.200 engineers to run these code labs, think about picking 00:01:37.300 --> 00:01:37.400 engineers who are going to create a safe space 00:01:37.500 --> 00:01:37.600 for these junior developers to ask questions. Feeling stupid 00:01:37.700 --> 00:01:37.800 when asking questions is pretty typical, especially when you're 00:01:37.900 --> 00:01:38.000 new. You want some place where they don't feel 00:01:38.100 --> 00:01:38.200 that way. 00:01:38.300 --> 00:01:38.400 Shadowing is also a great way to get people 00:01:38.500 --> 00:01:38.600 up to speed. This actually is a great thing 00:01:38.700 --> 00:01:38.800 to do at any level. But pair them with 00:01:38.900 --> 00:01:39.000 someone who's more senior. Have them sit with them 00:01:39.100 --> 00:01:39.200 for an hour a day or a week. And 00:01:39.300 --> 00:01:39.400 just watch their process. How do they build code? 00:01:39.500 --> 00:01:39.600 How do they get things done? What tools do 00:01:39.700 --> 00:01:39.800 they use? One of the things to think about, 00:01:39.900 --> 00:01:40.000 though, when pairing people for shadowing, is that we 00:01:40.100 --> 00:01:40.200 will forgive a lot of bad habits in more 00:01:40.300 --> 00:01:40.400 mid-level or senior engineers that we won't forgive in 00:01:40.500 --> 00:01:40.600 junior engineers. 00:01:40.700 --> 00:01:40.800 So I've seen this happen a lot where junior 00:01:40.900 --> 00:01:41.000 engineers are following someone who's more senior, and they're 00:01:41.100 --> 00:01:41.200 doing a great job, actually, of picking things up. 00:01:41.300 --> 00:01:41.400 They're learning a ton. And some of the things 00:01:41.500 --> 00:01:41.600 they're learning are not so good. And so they 00:01:41.700 --> 00:01:41.800 end up getting punished for these habits that they 00:01:41.900 --> 00:01:42.000 learned directly from a senior engineer. So make sure 00:01:42.100 --> 00:01:42.200 that you take a look, whenever you see someone 00:01:42.300 --> 00:01:42.400 doing something, who's new or young, take a look 00:01:42.500 --> 00:01:42.600 at where they learned that from. If they learned 00:01:42.700 --> 00:01:42.800 it from someone else, try to just encourage them 00:01:42.900 --> 00:01:43.000 to go in the right direction. 00:01:43.100 --> 00:01:43.200 There's nothing worse, when you're new, than spending all 00:01:43.300 --> 00:01:43.400 this time following someone, learning something, and then later 00:01:43.500 --> 00:01:43.600 being told that you're doing it wrong. You're like, 00:01:43.700 --> 00:01:43.800 well then why did I follow this person around? 00:01:43.900 --> 00:01:44.000 All right. Week three is a lot about communication. 00:01:44.100 --> 00:01:44.200 Goal-setting. Feedback. Presentations. So for a junior engineer, at 00:01:44.300 --> 00:01:44.400 this, up to this point, you've probably been doing 00:01:44.500 --> 00:01:44.600 a lot of high-touch interactions. You've probably been working 00:01:44.700 --> 00:01:44.800 with them fairly constantly. By week three you can 00:01:44.900 --> 00:01:45.000 start scaling back. Give them more independence. Give them 00:01:45.100 --> 00:01:45.200 more free time. But set up weekly one-on-ones. This 00:01:45.300 --> 00:01:45.400 is a structured, expected thing where they can give 00:01:45.500 --> 00:01:45.600 you feedback. Maybe they can spend ten minutes talking 00:01:45.700 --> 00:01:45.800 about something they learned this week. You can start 00:01:45.900 --> 00:01:46.000 doing goal-setting. 00:01:46.100 --> 00:01:46.200 Which, by week three, hopefully they have a better 00:01:46.300 --> 00:01:46.400 idea of what they want to do next. Maybe 00:01:46.500 --> 00:01:46.600 not what they want to do with their whole 00:01:46.700 --> 00:01:46.800 life, but maybe next they want to focus on 00:01:46.900 --> 00:01:47.000 frontend. They want to get really, really good at 00:01:47.100 --> 00:01:47.200 implementing features for users. Or maybe they absolutely love 00:01:47.300 --> 00:01:47.400 dev ops and infrastructure and they want to work 00:01:47.500 --> 00:01:47.600 more on that. 00:01:47.700 --> 00:01:47.800 So you can start setting these short and long-term 00:01:47.900 --> 00:01:48.000 goals so that they feel like they're moving forward. 00:01:48.100 --> 00:01:48.200 Feedback is also really important. Give feedback early. Give 00:01:48.300 --> 00:01:48.400 feedback often. Some of the biggest complaints that people 00:01:48.500 --> 00:01:48.600 have about their managers is that they don't get 00:01:48.700 --> 00:01:48.800 any feedback from them. So, as engineers, we tend 00:01:48.900 --> 00:01:49.000 to be fairly critical and a little bit cynical, 00:01:49.100 --> 00:01:49.200 which I think is healthy. But when you're giving 00:01:49.300 --> 00:01:49.400 feedback to someone, especially if they're junior, remember, they 00:01:49.500 --> 00:01:49.600 don't know what they're doing well, either. They actually 00:01:49.700 --> 00:01:49.800 don't, they don't really have a good idea of 00:01:49.900 --> 00:01:50.000 what they're doing that's good or bad. 00:01:50.100 --> 00:01:50.200 And I'll give you another sports analogy. When I 00:01:50.300 --> 00:01:50.400 was coaching, so I'm coaching beginners. Absolute beginners. And 00:01:50.500 --> 00:01:50.600 I'm standing on the pool deck, kind of yelling 00:01:50.700 --> 00:01:50.800 things at them. And they'd go to do, like, 00:01:50.900 --> 00:01:51.000 they'd go to throw the ball, like they'd go 00:01:51.100 --> 00:01:51.200 to shoot and they'd drop their elbow, and I'd 00:01:51.300 --> 00:01:51.400 yell don't drop your elbow! And it look like 00:01:51.500 --> 00:01:51.600 these kids hit a brick wall. They would just 00:01:51.700 --> 00:01:51.800 stop and sink in the water and look at 00:01:51.900 --> 00:01:52.000 me. Which I realized was exactly not the behavior 00:01:52.100 --> 00:01:52.200 that I wanted from them. What I wanted them 00:01:52.300 --> 00:01:52.400 to do was I wanted them to keep their 00:01:52.500 --> 00:01:52.600 elbow up. 00:01:52.700 --> 00:01:52.800 So I thought about this for awhile, and then 00:01:52.900 --> 00:01:53.000 I decided to just start yelling at them all 00:01:53.100 --> 00:01:53.200 the things that I wanted them to do. So 00:01:53.300 --> 00:01:53.400 I took the words no and don't out of 00:01:53.500 --> 00:01:53.600 my vocabulary, which is a really, really fun game, 00:01:53.700 --> 00:01:53.800 if anyone wants a hobby. So I started yelling 00:01:53.900 --> 00:01:54.000 things at them like, keep your elbow up. Keep 00:01:54.100 --> 00:01:54.200 your hips up. And I saw the most amazing 00:01:54.300 --> 00:01:54.400 thing happen. They all started doing exactly what I 00:01:54.500 --> 00:01:54.600 wanted. 00:01:54.700 --> 00:01:54.800 They started, they started moving forward faster. They were 00:01:54.900 --> 00:01:55.000 excited. They felt confident. And there was no, there 00:01:55.100 --> 00:01:55.200 was nothing except that I just took all of 00:01:55.300 --> 00:01:55.400 these negative words and negative phrases out and told 00:01:55.500 --> 00:01:55.600 them what I wanted and they did it. So, 00:01:55.700 --> 00:01:55.800 when you're thinking about yelling things at your junior 00:01:55.900 --> 00:01:56.000 engineers, try yelling at them what you want them 00:01:56.100 --> 00:01:56.200 to do as opposed to what you don't want 00:01:56.300 --> 00:01:56.400 them to do. 00:01:56.500 --> 00:01:56.600 Presentations are also really great for communication. We don't 00:01:56.700 --> 00:01:56.800 program in vaccuums. We often work on teams. We 00:01:56.900 --> 00:01:57.000 need to be able to communicate technical concepts to 00:01:57.100 --> 00:01:57.200 other people in a really clear and concise way. 00:01:57.300 --> 00:01:57.400 So make them practice. Give them a topic once 00:01:57.500 --> 00:01:57.600 a month, a technical topic, maybe it's regexes, maybe 00:01:57.700 --> 00:01:57.800 it's the ORM layer, and have them give a 00:01:57.900 --> 00:01:58.000 five to ten minute presentation to the rest of 00:01:58.100 --> 00:01:58.200 the team on it. 00:01:58.300 --> 00:01:58.400 Week four. Week four, you're gonna continue scaling back. 00:01:58.500 --> 00:01:58.600 You want them to be independent. You want them 00:01:58.700 --> 00:01:58.800 to be autonomous. So you're gonna continue taking yourself 00:01:58.900 --> 00:01:59.000 out. Review concepts. Check in regularly in your one-on-ones. 00:01:59.100 --> 00:01:59.200 You can start to tell them things like, if 00:01:59.300 --> 00:01:59.400 you hit a bug, I want you to research 00:01:59.500 --> 00:01:59.600 things for an hour before you come talk to 00:01:59.700 --> 00:01:59.800 me. So set really clear expectations, but have them 00:01:59.900 --> 00:02:00.000 go off on their own. Have them do research 00:02:00.100 --> 00:02:00.200 on their own. Have them get used to that 00:02:00.300 --> 00:02:00.400 feeling of hitting your head up against a wall 00:02:00.500 --> 00:02:00.600 because you're super frustrated with a problem. This is 00:02:00.700 --> 00:02:00.800 good. They need to learn those things. 00:02:00.900 --> 00:02:01.000 Also, make shadowing elective. Let them choose who they 00:02:01.100 --> 00:02:01.200 want to shadow and when. So start off-loading decisions 00:02:01.300 --> 00:02:01.400 about what they do to the engineer. Also, have 00:02:01.500 --> 00:02:01.600 them start co-piloting a larger project with someone else. 00:02:01.700 --> 00:02:01.800 The concept is kind of like drivers' ed in 00:02:01.900 --> 00:02:02.000 the U.S. In drivers' ed in the U.S., you're 00:02:02.100 --> 00:02:02.200 paired with an instructor who actually has a break 00:02:02.300 --> 00:02:02.400 on their side, so if you decide to careen 00:02:02.500 --> 00:02:02.600 on a cliff or something, they can hit the 00:02:02.700 --> 00:02:02.800 breaks and stop you. So pair them with someone 00:02:02.900 --> 00:02:03.000 who still has enough control that they can stop 00:02:03.100 --> 00:02:03.200 them from doing anything that's really dangerous, but they're 00:02:03.300 --> 00:02:03.400 also working on bigger projects now and learning from 00:02:03.500 --> 00:02:03.600 someone who's more senior. 00:02:03.700 --> 00:02:03.800 Beyond. So, keep checking in on goals. Keep talking 00:02:03.900 --> 00:02:04.000 to them. Make sure you have really structured channels 00:02:04.100 --> 00:02:04.200 for communication. Start tailoring their projects, code labs, et 00:02:04.300 --> 00:02:04.400 cetera to their progress. And this is the part 00:02:04.500 --> 00:02:04.600 where you can start doing things like informal apprenticeships 00:02:04.700 --> 00:02:04.800 and assessing their progress. Although you should be assessing 00:02:04.900 --> 00:02:05.000 it this whole time. 00:02:05.100 --> 00:02:05.200 Apprenticeship is a concept that has worked for many 00:02:05.300 --> 00:02:05.400 thousands of years in many, many different trade industries. 00:02:05.500 --> 00:02:05.600 So, blacksmithing, roof-thatching, I don't know. But at this 00:02:05.700 --> 00:02:05.800 point, they should know more specifically what they're gonna 00:02:05.900 --> 00:02:06.000 want to work on long-term. So have them be 00:02:06.100 --> 00:02:06.200 an apprentice to someone who's more senior at this. 00:02:06.300 --> 00:02:06.400 So if they want to do dev ops, they 00:02:06.500 --> 00:02:06.600 can go work on the dev ops team with 00:02:06.700 --> 00:02:06.800 a more senior engineer, and they might do a 00:02:06.900 --> 00:02:07.000 lot of grunt-work tasks. They might do a lot 00:02:07.100 --> 00:02:07.200 of the things that no one else wants to 00:02:07.300 --> 00:02:07.400 do at this point. But they're learning. And as 00:02:07.500 --> 00:02:07.600 they learn and they grow they get more involved 00:02:07.700 --> 00:02:07.800 tasks, and they get to solve more exciting problems. 00:02:07.900 --> 00:02:08.000 Assessment. So you're gonna see wildly different trajectories with 00:02:08.100 --> 00:02:08.199 people. And hopefully the more systematic your process gets, 00:02:08.300 --> 00:02:08.400 the more you're able to deal with this. But 00:02:08.500 --> 00:02:08.600 some people are just gonna take off running and 00:02:08.699 --> 00:02:08.800 they're gonna be fine. Other people are gonna have 00:02:08.900 --> 00:02:09.000 ups and downs. And so you're gonna want to 00:02:09.100 --> 00:02:09.199 have some sort of way of assessing how they're 00:02:09.300 --> 00:02:09.400 doing. And when someone's not doing the way you 00:02:09.500 --> 00:02:09.600 expect, the answer isn't always they're a bad programmer. 00:02:09.699 --> 00:02:09.800 In fact, we came up with five assessment categories. 00:02:09.900 --> 00:02:10.000 Confidence, code quality, communication, judgement, and technical knowledge. And 00:02:10.100 --> 00:02:10.199 this is just a start. If someone is afraid 00:02:10.300 --> 00:02:10.400 to ship code, they might lack confidence. And so 00:02:10.500 --> 00:02:10.600 helping to bolster their confidence will see huge results. 00:02:10.699 --> 00:02:10.800 Additionally, if they're building features that don't make sense, 00:02:10.900 --> 00:02:11.000 they might lack judgment. And in order to have 00:02:11.100 --> 00:02:11.200 good judgment, you need a lot of context about 00:02:11.300 --> 00:02:11.400 who uses your product and why. So maybe they 00:02:11.500 --> 00:02:11.600 should go spend more time working with customer support 00:02:11.700 --> 00:02:11.800 and answering support tickets so that they can learn 00:02:11.900 --> 00:02:12.000 how people use the product so they have better 00:02:12.100 --> 00:02:12.200 judgement. Sometimes they just need to learn more about 00:02:12.300 --> 00:02:12.400 a particular tool, and that one's pretty easy. 00:02:12.500 --> 00:02:12.600 OK. Hopefully you guys have had a fair number 00:02:12.700 --> 00:02:12.800 of take-aways. Hopefully you now know about the concept 00:02:12.900 --> 00:02:13.000 of team debt. You're thinking about doing an onboarding 00:02:13.100 --> 00:02:13.200 plan now. But, if you take away only three 00:02:13.300 --> 00:02:13.400 things, I hope you take away these three things. 00:02:13.500 --> 00:02:13.600 First off, the goal of onboarding is to make 00:02:13.700 --> 00:02:13.800 people confident, productive, and independent. Reliably independent. And so 00:02:13.900 --> 00:02:14.000 that can have to do with their level. But 00:02:14.100 --> 00:02:14.200 it's not about making someone into a senior engineer 00:02:14.300 --> 00:02:14.400 overnight. 00:02:14.500 --> 00:02:14.600 Second, onboarding benefits everyone in the long run. It 00:02:14.700 --> 00:02:14.800 benefits the individual joining, it benefits your company's bottom-line, 00:02:14.900 --> 00:02:15.000 it benefits the productivity of the team, and it's 00:02:15.100 --> 00:02:15.200 also great for diversity. 00:02:15.300 --> 00:02:15.400 And finally, anyone at your company can be involved 00:02:15.500 --> 00:02:15.600 in onboarding. So, as I said before, some of 00:02:15.700 --> 00:02:15.800 your best onboarders are not gonna be senior engineers. 00:02:15.900 --> 00:02:16.000 They're gonna be the people who were just junior 00:02:16.100 --> 00:02:16.200 engineers themselves. 00:02:16.300 --> 00:02:16.400 OK. So, start improving your onboarding process now. There's 00:02:16.500 --> 00:02:16.600 actually a code repository, or not code, but just 00:02:16.700 --> 00:02:16.800 a GitHub repository that has some assessment rubrics. It 00:02:16.900 --> 00:02:17.000 has the plan in a lot more detail. It 00:02:17.100 --> 00:02:17.200 also has some tools for, for learning, like, online 00:02:17.300 --> 00:02:17.400 tools for learning Ruby and Rails. And if you 00:02:17.500 --> 00:02:17.600 have questions, feel free to ask them now. If 00:02:17.700 --> 00:02:17.800 you are terrified of yelling questions out in a 00:02:17.900 --> 00:02:18.000 pubilc forum, which I absolutely am, you can come 00:02:18.100 --> 00:02:18.200 find me later. I'll also be around for the 00:02:18.300 --> 00:02:18.400 rest of the conference. So thank you.