1 00:00:00,100 --> 00:00:00,200 KATE HEDDLESTON: Hi everyone. 2 00:00:00,300 --> 00:00:00,400 Welcome to my talk. I'm Kate Heddleston 3 00:00:00,500 --> 00:00:00,600 and this is Technical Onboarding, 4 00:00:00,700 --> 00:00:00,800 Training and Mentoring. 5 00:00:00,900 --> 00:00:01,000 So I'm a software engineer out of San Francisco. 6 00:00:01,100 --> 00:00:01,200 I do mostly contract work now. Full stack, web 7 00:00:01,300 --> 00:00:01,400 apps. And I work with a lot of really 8 00:00:01,500 --> 00:00:01,600 early-stage start ups. And this was originally written as 9 00:00:01,700 --> 00:00:01,800 a co-presentation with Nicole Zuckerman. She's a software engineer 10 00:00:01,900 --> 00:00:02,000 at Eventbrite. And she couldn't be here today because 11 00:00:02,100 --> 00:00:02,200 she is vacationing in Italy. So I feel not 12 00:00:02,300 --> 00:00:02,400 bad for her at all. 13 00:00:02,500 --> 00:00:02,600 All right. So she's the one on the right. 14 00:00:02,700 --> 00:00:02,800 I'm the one on the left. And, and Nicole 15 00:00:02,900 --> 00:00:03,000 attended a Code Academy called Hack Brite Academy, which 16 00:00:03,100 --> 00:00:03,200 I teach at one day a week. And we 17 00:00:03,300 --> 00:00:03,400 came together to write this talk because we work 18 00:00:03,500 --> 00:00:03,600 at separate companies and had experiences at these separate 19 00:00:03,700 --> 00:00:03,800 companies that were fairly similar. 20 00:00:03,900 --> 00:00:04,000 So, when I was right out of college, I 21 00:00:04,100 --> 00:00:04,200 joined a small start up. I was the sixth 22 00:00:04,300 --> 00:00:04,400 engineer, twelfth person, and I worked there for a 23 00:00:04,500 --> 00:00:04,600 time and it grew a lot, and after awhile, 24 00:00:04,700 --> 00:00:04,800 I reached a certain level of proficiancy. I looked 25 00:00:04,900 --> 00:00:05,000 back and I thought, I could have gotten here 26 00:00:05,100 --> 00:00:05,200 a lot faster with just a little bit of 27 00:00:05,300 --> 00:00:05,400 help and a little bit of structure. 28 00:00:05,500 --> 00:00:05,600 And so, I turned around and created the Onboarding 29 00:00:05,700 --> 00:00:05,800 program at my company. And Nicole had a similar 30 00:00:05,900 --> 00:00:06,000 experience at Eventbrite, and so she has been doing 31 00:00:06,100 --> 00:00:06,200 a lot of work there with onboarding. So we 32 00:00:06,300 --> 00:00:06,400 wrote this presentation and submitted it. It's important to 33 00:00:06,500 --> 00:00:06,600 note that this presentation was written specifically with junior 34 00:00:06,700 --> 00:00:06,800 engineers in mind. However, about 90 to 90% of 35 00:00:06,900 --> 00:00:07,000 what I say can very, very easily be adapted 36 00:00:07,100 --> 00:00:07,200 to people who are more experienced. 37 00:00:07,300 --> 00:00:07,400 All right. What is onboarding? So for the purposes 38 00:00:07,500 --> 00:00:07,600 of this talk, onboarding is the process of taking 39 00:00:07,700 --> 00:00:07,800 someone from outside of the group, outside the company, 40 00:00:07,900 --> 00:00:08,000 outside the team, and making them a productive, independent 41 00:00:08,100 --> 00:00:08,200 and confident member of the team. 42 00:00:08,300 --> 00:00:08,400 And I picked these three characteristics because I think 43 00:00:08,500 --> 00:00:08,600 they're, they're incredibly important. Productivity seems a bit self-explanatory. 44 00:00:08,700 --> 00:00:08,800 It seems kind of like, the goal that we're 45 00:00:08,900 --> 00:00:09,000 focusing on. Like, of course we would like productive 46 00:00:09,100 --> 00:00:09,200 engineers. And it's about creating efficient employees. 47 00:00:09,300 --> 00:00:09,400 Independence, and another word for independence is autonomy, is 48 00:00:09,500 --> 00:00:09,600 about creating engineers that can operate in your organization 49 00:00:09,700 --> 00:00:09,800 without needing a ton of oversight, that can make 50 00:00:09,900 --> 00:00:10,000 decisions and understand your company structure well enough to 51 00:00:10,100 --> 00:00:10,200 not have the overhead of having to go ask 52 00:00:10,300 --> 00:00:10,400 four levels of management for something. 53 00:00:10,500 --> 00:00:10,600 Also, independence and autonomy speaks to this, this need 54 00:00:10,700 --> 00:00:10,800 that we have to have some control over our 55 00:00:10,900 --> 00:00:11,000 own destiny. I was reading an article recently and 56 00:00:11,100 --> 00:00:11,200 it was talking about the need for autonomy, and 57 00:00:11,300 --> 00:00:11,400 it was citing inmates in prisons. So, in a 58 00:00:11,500 --> 00:00:11,600 lot of prisons, inmates are allowed to choose the 59 00:00:11,700 --> 00:00:11,800 channel. They're allowed to rearrange their furniture. And they 60 00:00:11,900 --> 00:00:12,000 found that this drastically reduced rebellions within prisons. So, 61 00:00:12,100 --> 00:00:12,200 independence is important, cause you don't want your engineers 62 00:00:12,300 --> 00:00:12,400 to rebel. But it's also important because feeling independent 63 00:00:12,500 --> 00:00:12,600 and autonomous helps people feel motivated and invested in 64 00:00:12,700 --> 00:00:12,800 what they're doing. 65 00:00:12,900 --> 00:00:13,000 Finally, confidence I think is the most important of 66 00:00:13,100 --> 00:00:13,200 the three. Confidence is about creating employees who believe 67 00:00:13,300 --> 00:00:13,400 that they are valuable. It's not about the actual 68 00:00:13,500 --> 00:00:13,600 act of creating employees that are valuable. The study, 69 00:00:13,700 --> 00:00:13,800 which is at, the links are at the bottom 70 00:00:13,900 --> 00:00:14,000 actually, that I was reading about recently, they split, 71 00:00:14,100 --> 00:00:14,200 this was a gendered study, but what they found 72 00:00:14,300 --> 00:00:14,400 didn't really have to do with gender. 73 00:00:14,500 --> 00:00:14,600 They split the participants into six groups. Three groups 74 00:00:14,700 --> 00:00:14,800 of men, three groups of women. So there was 75 00:00:14,900 --> 00:00:15,000 a control and two test groups for each gender. 76 00:00:15,100 --> 00:00:15,200 And, for one of the groups of men, they 77 00:00:15,300 --> 00:00:15,400 told them, they're doing some sort of spatial reasoning 78 00:00:15,500 --> 00:00:15,600 activity, they told them, men are really good at 79 00:00:15,700 --> 00:00:15,800 spatial reasoning. You should be good at this task. 80 00:00:15,900 --> 00:00:16,000 That group performed significantly better than the control. The 81 00:00:16,100 --> 00:00:16,200 next group of men they told, men are really 82 00:00:16,300 --> 00:00:16,400 bad at spatial reasoning. You'll be bad at this 83 00:00:16,500 --> 00:00:16,600 task. And that group performed significantly worse than the 84 00:00:16,700 --> 00:00:16,800 control. And they found the exact same thing with 85 00:00:16,900 --> 00:00:17,000 women. 86 00:00:17,100 --> 00:00:17,200 And so what this means is that confidence actually 87 00:00:17,300 --> 00:00:17,400 affects how well people perform. So confident people will 88 00:00:17,500 --> 00:00:17,600 perform better in a measurable way. 89 00:00:17,700 --> 00:00:17,800 So why do you care? I assume that everyone 90 00:00:17,900 --> 00:00:18,000 here cares because you came to my talk. But 91 00:00:18,100 --> 00:00:18,200 I would like to convince you that you should 92 00:00:18,300 --> 00:00:18,400 care now. You should care immediately, and that you 93 00:00:18,500 --> 00:00:18,600 should start building an onboarding program at your company 94 00:00:18,700 --> 00:00:18,800 as soon as possible. 95 00:00:18,900 --> 00:00:19,000 And I'm gonna talk about four things in this 96 00:00:19,100 --> 00:00:19,200 session. I'm gonna talk about the individual who's joining 97 00:00:19,300 --> 00:00:19,400 the company, the company that they are joining, the 98 00:00:19,500 --> 00:00:19,600 specific team within the company that they are becoming 99 00:00:19,700 --> 00:00:19,800 a member of, and then there's a bonus category, 100 00:00:19,900 --> 00:00:20,000 which is diversity. 101 00:00:20,100 --> 00:00:20,200 So, the individual. What can go wrong if you 102 00:00:20,300 --> 00:00:20,400 don't have onboarding? Or basically if you don't have 103 00:00:20,500 --> 00:00:20,600 investment in your employees? 104 00:00:20,700 --> 00:00:20,800 Attrition is something that most companies and most of 105 00:00:20,900 --> 00:00:21,000 us are terrified of. And for a good reason. 106 00:00:21,100 --> 00:00:21,200 Attrition can cost thousands of dollars per employee. Up 107 00:00:21,300 --> 00:00:21,400 to 1.5 to 2x their salary. And it's not 108 00:00:21,500 --> 00:00:21,600 that people quit specifically because your company does or 109 00:00:21,700 --> 00:00:21,800 not have onboarding. People quit for a meriad of 110 00:00:21,900 --> 00:00:22,000 reasons. The number one is actually that they are 111 00:00:22,100 --> 00:00:22,200 dissatisfied with their managers. But onboarding can address a 112 00:00:22,300 --> 00:00:22,400 lot of the issues that people ultimately quit for, 113 00:00:22,500 --> 00:00:22,600 or quit because of, and it can address them 114 00:00:22,700 --> 00:00:22,800 really early. 115 00:00:22,900 --> 00:00:23,000 So getting someone up to speed so that they're 116 00:00:23,100 --> 00:00:23,200 confident, they have this upward trajectory, they're building their 117 00:00:23,300 --> 00:00:23,400 skill set early, is going to set them up 118 00:00:23,500 --> 00:00:23,600 for success in the long term, so that eight 119 00:00:23,700 --> 00:00:23,800 months to twelve months down the road, they aren't 120 00:00:23,900 --> 00:00:24,000 leaving because they never felt like they were part 121 00:00:24,100 --> 00:00:24,200 of the team. Or they never felt like they 122 00:00:24,300 --> 00:00:24,400 were contributing. Address this early at onboarding is one 123 00:00:24,500 --> 00:00:24,600 of the best ways to do that. 124 00:00:24,700 --> 00:00:24,800 For the company. Companies care hugely about the productivity 125 00:00:24,900 --> 00:00:25,000 of their employees. This is a graph of productivity 126 00:00:25,100 --> 00:00:25,200 decreasing as you add new engineers to the team. 127 00:00:25,300 --> 00:00:25,400 And, anecdotally, this actually happened at LinkdIn not too 128 00:00:25,500 --> 00:00:25,600 long ago. Every engineer that they added to their 129 00:00:25,700 --> 00:00:25,800 team decreased their overall productivity and ultimately affected the 130 00:00:25,900 --> 00:00:26,000 company's bottom line. 131 00:00:26,100 --> 00:00:26,200 So, when their new SVP of engineering came on 132 00:00:26,300 --> 00:00:26,400 board, Kevin Scott, he had to do a whole 133 00:00:26,500 --> 00:00:26,600 bunch of work revamping their organization, building onboarding. And 134 00:00:26,700 --> 00:00:26,800 this is, I mean, LinkdIn is thousands of people 135 00:00:26,900 --> 00:00:27,000 at this point. So this is a huge amount 136 00:00:27,100 --> 00:00:27,200 of work. To try to get the graph to 137 00:00:27,300 --> 00:00:27,400 look like this. To try to get each new 138 00:00:27,500 --> 00:00:27,600 employee to add value to the company. And this 139 00:00:27,700 --> 00:00:27,800 doesn't have to do with the employees. It's not 140 00:00:27,900 --> 00:00:28,000 like they're hiring engineers that are then negative in 141 00:00:28,100 --> 00:00:28,200 their value. It has to do with their process, 142 00:00:28,300 --> 00:00:28,400 and onboarding is one of the great ways to 143 00:00:28,500 --> 00:00:28,600 make sure that you're taking a good look at 144 00:00:28,700 --> 00:00:28,800 your process. 145 00:00:28,900 --> 00:00:29,000 This speaks to something I like to call team 146 00:00:29,100 --> 00:00:29,200 debt. How many of you have heard of the 147 00:00:29,300 --> 00:00:29,400 concept of code debt? A lot of people. Yeah, 148 00:00:29,500 --> 00:00:29,600 we talk about that a lot as engineers. How 149 00:00:29,700 --> 00:00:29,800 if you build something fast and don't think about 150 00:00:29,900 --> 00:00:30,000 it, you accrue this code debt, and over time 151 00:00:30,100 --> 00:00:30,200 you have to go back through your code base, 152 00:00:30,300 --> 00:00:30,400 take a look at things, rewrite them, and ultimately 153 00:00:30,500 --> 00:00:30,600 address that. 154 00:00:30,700 --> 00:00:30,800 Well, the same thing happens with people. So if 155 00:00:30,900 --> 00:00:31,000 you aren't doing a good job investing in your 156 00:00:31,100 --> 00:00:31,200 employees, if you're not onboarding them, if you're not 157 00:00:31,300 --> 00:00:31,400 training them, you're going to accrue team debt. And 158 00:00:31,500 --> 00:00:31,600 I've seen this a lot. I've talked to a 159 00:00:31,700 --> 00:00:31,800 lot of companies that are starting to get into 160 00:00:31,900 --> 00:00:32,000 the hundreds of people range. They're starting to hit 161 00:00:32,100 --> 00:00:32,200 a hundred engineers. And they're like, oh my goodness, 162 00:00:32,299 --> 00:00:32,400 we need onboarding. We need, we need to get 163 00:00:32,500 --> 00:00:32,600 these people up to speed. And at, at four 164 00:00:32,700 --> 00:00:32,800 hundred people, I mean, yeah. You've accrued a huge 165 00:00:32,900 --> 00:00:33,000 amount of team debt. 166 00:00:33,100 --> 00:00:33,200 Every person that you add and try to onboard 167 00:00:33,300 --> 00:00:33,400 is going to be increasingly difficult. Your code base 168 00:00:33,500 --> 00:00:33,600 is quite large at that point. You have a 169 00:00:33,700 --> 00:00:33,800 lot of teams. And so going and making all 170 00:00:33,900 --> 00:00:34,000 of those onboarding materials at a hundred people is 171 00:00:34,100 --> 00:00:34,200 way harder than starting when you're smaller than a 172 00:00:34,300 --> 00:00:34,400 hundred people and then maintaining it incrementally. 173 00:00:34,500 --> 00:00:34,600 The third aspect is the immediate team that the 174 00:00:34,700 --> 00:00:34,800 engineer joins. So there's a saying that you don't 175 00:00:34,900 --> 00:00:35,000 know something until you teach it. And this is 176 00:00:35,100 --> 00:00:35,200 absolutely true for your company's culture and code process. 177 00:00:35,300 --> 00:00:35,400 So if you don't know how to explain to 178 00:00:35,500 --> 00:00:35,600 a new engineer what your company's culture is or 179 00:00:35,700 --> 00:00:35,800 how you ship code or how you decide what 180 00:00:35,900 --> 00:00:36,000 features are built or who approves things, who reviews 181 00:00:36,100 --> 00:00:36,200 things, then you don't actually know it yourself. And 182 00:00:36,300 --> 00:00:36,400 that's a massive red flag for your company if 183 00:00:36,500 --> 00:00:36,600 you can't explain your process. 184 00:00:36,700 --> 00:00:36,800 Additionally, when people join small teams, small teams fundamentally 185 00:00:36,900 --> 00:00:37,000 change every single time you add a new person 186 00:00:37,100 --> 00:00:37,200 to them. So iterating your team's process to the 187 00:00:37,300 --> 00:00:37,400 new engineer is not just important for them, it's 188 00:00:37,500 --> 00:00:37,600 also important for your existing engineers, so that you 189 00:00:37,700 --> 00:00:37,800 get something that looks a little bit more like 190 00:00:37,900 --> 00:00:38,000 this, where everyone is on the same page. 191 00:00:38,100 --> 00:00:38,200 And because the team changes every time you add 192 00:00:38,300 --> 00:00:38,400 people to it, you're gonna have to reiterate this 193 00:00:38,500 --> 00:00:38,600 to everyone pretty much every time you add a 194 00:00:38,700 --> 00:00:38,800 new employee. 195 00:00:38,900 --> 00:00:39,000 So, something about me, I love sports anecdotes. I 196 00:00:39,100 --> 00:00:39,200 played sports for most of my life. And when 197 00:00:39,300 --> 00:00:39,400 I was done playing sports, I coached JV girls 198 00:00:39,500 --> 00:00:39,600 water polo at a high school nearby. And I 199 00:00:39,700 --> 00:00:39,800 used to have these really deep, philosophical team meetings 200 00:00:39,900 --> 00:00:40,000 with them, and I'd come in with these posters, 201 00:00:40,100 --> 00:00:40,200 and one day I came in with this, a 202 00:00:40,300 --> 00:00:40,400 poster with this written on it. They always just 203 00:00:40,500 --> 00:00:40,600 sat there and kind of rolled their eyes at 204 00:00:40,700 --> 00:00:40,800 me, like. 205 00:00:40,900 --> 00:00:41,000 But, I was trying to explain to them that 206 00:00:41,100 --> 00:00:41,200 their ability to win games was not wholly dependent 207 00:00:41,300 --> 00:00:41,400 on their skills. These girls were beginners. They didn't 208 00:00:41,500 --> 00:00:41,600 really know how to throw. They didn't really know 209 00:00:41,700 --> 00:00:41,800 how to swim. They basically didn't have the skill 210 00:00:41,900 --> 00:00:42,000 set necessary to play water polo. But, they were 211 00:00:42,100 --> 00:00:42,200 playing all these games. And so I wanted them 212 00:00:42,300 --> 00:00:42,400 to understand that their skill set was important, but 213 00:00:42,500 --> 00:00:42,600 team work was more important, so they could actually 214 00:00:42,700 --> 00:00:42,800 beat teams that were theoretically more skilled than them 215 00:00:42,900 --> 00:00:43,000 but didn't work together as well as they did 216 00:00:43,100 --> 00:00:43,200 if they all banded together, because teamwork is a 217 00:00:43,300 --> 00:00:43,400 multiplication factor. 218 00:00:43,500 --> 00:00:43,600 And this is true in engineering as well. Your 219 00:00:43,700 --> 00:00:43,800 productivity as an engineering team is the sum of 220 00:00:43,900 --> 00:00:44,000 the engineering talent that you have multiplied by how 221 00:00:44,100 --> 00:00:44,200 well you work together. So if your team is 222 00:00:44,300 --> 00:00:44,400 working well together, that's great. If not, your team 223 00:00:44,500 --> 00:00:44,600 can actually pull itself apart. And, anecdotally, a lot 224 00:00:44,700 --> 00:00:44,800 of, a lot of products have been built by 225 00:00:44,900 --> 00:00:45,000 teams that are less than ten or five people. 226 00:00:45,100 --> 00:00:45,200 So Gmail is a really great example. It was 227 00:00:45,300 --> 00:00:45,400 built by a team of less than five. And 228 00:00:45,500 --> 00:00:45,600 now that it's successful it's maintained by a team 229 00:00:45,700 --> 00:00:45,800 of over four-hundred, I think. 230 00:00:45,900 --> 00:00:46,000 So our bonus category, diversity. How many of you 231 00:00:46,100 --> 00:00:46,200 have read Dr. Seuss's book about sneetches? Yeah? It's 232 00:00:46,300 --> 00:00:46,400 a great, it's a childrens' poem, like all of 233 00:00:46,500 --> 00:00:46,600 his books are. But it's about this community of 234 00:00:46,700 --> 00:00:46,800 sneetches. And sneetches are what I have drawn there. 235 00:00:46,900 --> 00:00:47,000 And at some point, some sneetches start developing stars 236 00:00:47,100 --> 00:00:47,200 on their bellies. And it's the story about kind 237 00:00:47,300 --> 00:00:47,400 of the rifts that happen in the community as 238 00:00:47,500 --> 00:00:47,600 a result of some sneetches having stars on their 239 00:00:47,700 --> 00:00:47,800 bellies and some sneetches not. 240 00:00:47,900 --> 00:00:48,000 But I like to use sneetches to represent diversity, 241 00:00:48,100 --> 00:00:48,200 cause diversity can mean a lot of things. It 242 00:00:48,300 --> 00:00:48,400 can be gender diversity, it can be racial diversity, 243 00:00:48,500 --> 00:00:48,600 it can be introverts versus extraverts as far as 244 00:00:48,700 --> 00:00:48,800 diversity goes. So communication styles. But the idea is 245 00:00:48,900 --> 00:00:49,000 that onboarding is gonna be really critical if you 246 00:00:49,100 --> 00:00:49,200 want to hire people who are different from each 247 00:00:49,300 --> 00:00:49,400 other in any way. 248 00:00:49,500 --> 00:00:49,600 This is pretty typical in tech. Companies are started 249 00:00:49,700 --> 00:00:49,800 by a small group of people, and it's homogenous. 250 00:00:49,900 --> 00:00:50,000 The phenomenom is called homophaly. We tend to associate 251 00:00:50,100 --> 00:00:50,200 and like to be around people who are like 252 00:00:50,300 --> 00:00:50,400 ourselves. So companies tend to get started as homogenous 253 00:00:50,500 --> 00:00:50,600 groups. 254 00:00:50,700 --> 00:00:50,800 If you don't have any onboarding, the people who 255 00:00:50,900 --> 00:00:51,000 are most likely to be successful joining your organization 256 00:00:51,100 --> 00:00:51,200 are people who are like the existing group. This 257 00:00:51,300 --> 00:00:51,400 is because they likely share similar communication styles, interests 258 00:00:51,500 --> 00:00:51,600 and hobbies. There might be tacit acceptance because they 259 00:00:51,700 --> 00:00:51,800 look the same as the rest of the group. 260 00:00:51,900 --> 00:00:52,000 So what you're doing is you're relying on homopholy 261 00:00:52,100 --> 00:00:52,200 and the existing social structure for peoples' success at 262 00:00:52,300 --> 00:00:52,400 the company and onboarding. 263 00:00:52,500 --> 00:00:52,600 And what you don't want to have happen is 264 00:00:52,700 --> 00:00:52,800 something like this. You hire someone new who's different, 265 00:00:52,900 --> 00:00:53,000 and they feel socially ostracized upfront. Not for any 266 00:00:53,100 --> 00:00:53,200 particular malicious reason, but just because they're different. They 267 00:00:53,300 --> 00:00:53,400 communicate differently. And so what you want is you 268 00:00:53,500 --> 00:00:53,600 want an explicit onboarding structure that helps bring people 269 00:00:53,700 --> 00:00:53,800 into the fold, that helps people become a part 270 00:00:53,900 --> 00:00:54,000 of the team in some sort of systematic way 271 00:00:54,100 --> 00:00:54,200 so that everyone who joins, no matter how different 272 00:00:54,300 --> 00:00:54,400 they are from the existing group, has a solid 273 00:00:54,500 --> 00:00:54,600 chance at being successful. 274 00:00:54,700 --> 00:00:54,800 So, hopefully now you guys are all convinced that 275 00:00:54,900 --> 00:00:55,000 onboarding is super important. 276 00:00:55,100 --> 00:00:55,200 Who at your company can onboard? 277 00:00:55,300 --> 00:00:55,400 So anyone of your team can onboard. This is 278 00:00:55,500 --> 00:00:55,600 not a, senior engineers have to be paired with 279 00:00:55,700 --> 00:00:55,800 junior engineers. They can learn the most. In fact, 280 00:00:55,900 --> 00:00:56,000 going back to sports analogies, some of your best 281 00:00:56,100 --> 00:00:56,200 people to onboard are going to be people, kind 282 00:00:56,300 --> 00:00:56,400 of like if a freshman athelete were to join 283 00:00:56,500 --> 00:00:56,600 a team, the sophomore athletes might be the best 284 00:00:56,700 --> 00:00:56,800 people to help them out. 285 00:00:56,900 --> 00:00:57,000 This is because they have the most empathy for 286 00:00:57,100 --> 00:00:57,200 what they're going through. They also experienced it the 287 00:00:57,300 --> 00:00:57,400 most recently, so they have relevant information and stories. 288 00:00:57,500 --> 00:00:57,600 So your sophomore engineers might be some of your 289 00:00:57,700 --> 00:00:57,800 best onboarders at the company, in addition to the 290 00:00:57,900 --> 00:00:58,000 expertise of your senior engineers. 291 00:00:58,100 --> 00:00:58,200 When? 292 00:00:58,300 --> 00:00:58,400 So onboarding can start as soon as an offer 293 00:00:58,500 --> 00:00:58,600 is accepted. I'm going to talk about an onboarding 294 00:00:58,700 --> 00:00:58,800 plan coming up soon, and we're gonna talk about 295 00:00:58,900 --> 00:00:59,000 from the start date to what I call reliable 296 00:00:59,100 --> 00:00:59,200 independence, which is where this person can build things 297 00:00:59,300 --> 00:00:59,400 and build features to an adequate level and be 298 00:00:59,500 --> 00:00:59,600 left on their own to the same degree as 299 00:00:59,700 --> 00:00:59,800 other engineers on the team. 300 00:00:59,900 --> 00:01:00,000 All right. How? 301 00:01:00,100 --> 00:01:00,200 So, the how category I'm gonna talk about some 302 00:01:00,300 --> 00:01:00,400 concepts to think about, when you're thinking about how 303 00:01:00,500 --> 00:01:00,600 to onboard others. And then I'm gonna launch into 304 00:01:00,700 --> 00:01:00,800 a four-week plan that goes through some of the 305 00:01:00,900 --> 00:01:01,000 specific things that you can do with engineers. 306 00:01:01,100 --> 00:01:01,200 So, first off, the concepts. It's pretty straight forward. 307 00:01:01,300 --> 00:01:01,400 You want to maximize your return on investment. You 308 00:01:01,500 --> 00:01:01,600 don't really want to be putting more into engineers 309 00:01:01,700 --> 00:01:01,800 than you're getting out of them. And most people 310 00:01:01,900 --> 00:01:02,000 don't really want more put into them than they're 311 00:01:02,100 --> 00:01:02,200 giving back. That's kind of a strange dynamic. 312 00:01:02,300 --> 00:01:02,400 So, a really inefficient but really common way that 313 00:01:02,500 --> 00:01:02,600 people try to onboard is this, like, hand-holding model. 314 00:01:02,700 --> 00:01:02,800 New onboarding mentors are really prone to this. They 315 00:01:02,900 --> 00:01:03,000 think, I'm gonna be the best onboarding mentor ever. 316 00:01:03,100 --> 00:01:03,200 We're gonna do everything together. We're gonna do all 317 00:01:03,300 --> 00:01:03,400 of these code tutorials. They're gonna watch me code 318 00:01:03,500 --> 00:01:03,600 every day, and by the time we're done with 319 00:01:03,700 --> 00:01:03,800 three months, they're gonna know everything that I know. 320 00:01:03,900 --> 00:01:04,000 And, in addition to being inefficient, because this is 321 00:01:04,099 --> 00:01:04,200 a huge time sink, it's also unrealistic. People do 322 00:01:04,300 --> 00:01:04,400 not become senior engineers in three months. You need 323 00:01:04,500 --> 00:01:04,599 time. You just, you just do. And so this 324 00:01:04,700 --> 00:01:04,800 burns people out and also disappoints them. 325 00:01:04,900 --> 00:01:05,000 A more efficient way to think abou things is, 326 00:01:05,099 --> 00:01:05,200 my example is bumper bowling, which is pretty much 327 00:01:05,300 --> 00:01:05,400 the only way I should be allowed to bowl. 328 00:01:05,500 --> 00:01:05,600 But, you set up an environment that's constrained, where 329 00:01:05,700 --> 00:01:05,800 they're able to play freely. They're able to go 330 00:01:05,900 --> 00:01:06,000 off and do what they want, come back and 331 00:01:06,100 --> 00:01:06,200 ask questions. But you don't have to handhold them 332 00:01:06,300 --> 00:01:06,400 through things. 333 00:01:06,500 --> 00:01:06,600 And so the way you do this with a 334 00:01:06,700 --> 00:01:06,800 technical environment is automation is huge. So, automating the 335 00:01:06,900 --> 00:01:07,000 development environment, automating deploy. Having a lot of testing 336 00:01:07,100 --> 00:01:07,200 for your code base, however you decide to do 337 00:01:07,300 --> 00:01:07,400 that. Whether it's TDD or not. Will help these 338 00:01:07,500 --> 00:01:07,600 junior engineers have a safe space to learn and 339 00:01:07,700 --> 00:01:07,800 grow and play. 340 00:01:07,900 --> 00:01:08,000 One of the important things to think about, too, 341 00:01:08,100 --> 00:01:08,200 when setting up this environment is that scoping is 342 00:01:08,300 --> 00:01:08,400 critical. One of the tenants of expertise is the 343 00:01:08,500 --> 00:01:08,600 ability to scope. So, if you're an expert, you 344 00:01:08,700 --> 00:01:08,800 understand the landscape incredibly well. So you're able to 345 00:01:08,900 --> 00:01:09,000 set these really well-defined boundaries. Junior engineers, by definition, 346 00:01:09,100 --> 00:01:09,200 are not good at scoping because they don't know 347 00:01:09,300 --> 00:01:09,400 the landscape. 348 00:01:09,500 --> 00:01:09,600 So, when you're thinking about giving them projects and 349 00:01:09,700 --> 00:01:09,800 you're thinking about setting up their environment, make sure 350 00:01:09,900 --> 00:01:10,000 to set boundaries for them and then slowly move 351 00:01:10,100 --> 00:01:10,200 them out as they know more about what's going 352 00:01:10,300 --> 00:01:10,400 on. Because they won't be able to set those 353 00:01:10,500 --> 00:01:10,600 boundaries for themselves. 354 00:01:10,700 --> 00:01:10,800 So, kind of three onboarding categories that map to 355 00:01:10,900 --> 00:01:11,000 the productive, independent, confident thing I was talking about 356 00:01:11,100 --> 00:01:11,200 earlier are technical knowledge, company knowledge and process, and 357 00:01:11,300 --> 00:01:11,400 personal development. I mention this because people think that 358 00:01:11,500 --> 00:01:11,600 onboarding has to do with technical knowledge. They seem 359 00:01:11,700 --> 00:01:11,800 to think that that's 90% of what's going on. 360 00:01:11,900 --> 00:01:12,000 I'd say it's actually about a third, and it's 361 00:01:12,100 --> 00:01:12,200 actually the easiest third, because you can go to 362 00:01:12,300 --> 00:01:12,400 the internet and find a ton of tutorials on, 363 00:01:12,500 --> 00:01:12,600 on Ruby and how to learn Rails and how 364 00:01:12,700 --> 00:01:12,800 to use Rails and blog posts about how to 365 00:01:12,900 --> 00:01:13,000 use any number of technology out there. 366 00:01:13,100 --> 00:01:13,200 The harder category, which is another third of what 367 00:01:13,300 --> 00:01:13,400 they need to know, is the company knowledge and 368 00:01:13,500 --> 00:01:13,600 process. And this is really, really important for them 369 00:01:13,700 --> 00:01:13,800 being independent. They can't be independent if they don't 370 00:01:13,900 --> 00:01:14,000 know how to operate within the company's infrastructure. This 371 00:01:14,100 --> 00:01:14,200 is harder because most companies don't write this down. 372 00:01:14,300 --> 00:01:14,400 So it's in someone's head somewhere, and the junior 373 00:01:14,500 --> 00:01:14,600 engineer, or the new engineer, is tasked with going 374 00:01:14,700 --> 00:01:14,800 and extracting it from whoever on the team knows 375 00:01:14,900 --> 00:01:15,000 this. So the more explicit you can be about 376 00:01:15,100 --> 00:01:15,200 your company knowledge and process, the better. 377 00:01:15,300 --> 00:01:15,400 And then third, personal development. That has to do 378 00:01:15,500 --> 00:01:15,600 with confidence, career trajectories. Again, this is, this is 379 00:01:15,700 --> 00:01:15,800 important because confident people are willing to reach. They're 380 00:01:15,900 --> 00:01:16,000 willing to be outgoing and they're willing to try 381 00:01:16,100 --> 00:01:16,200 new things. They also perform better. 382 00:01:16,300 --> 00:01:16,400 OK. So now I'm gonna talk about a fairly 383 00:01:16,500 --> 00:01:16,600 specific plan. This was written with junior engineers in 384 00:01:16,700 --> 00:01:16,800 mind. So some of the tasks are very specific 385 00:01:16,900 --> 00:01:17,000 to junior engineers, as is the time frame. A 386 00:01:17,100 --> 00:01:17,200 lot of these things will be relevant for people 387 00:01:17,300 --> 00:01:17,400 with more experience. The time frame just might be 388 00:01:17,500 --> 00:01:17,600 more condensed. 389 00:01:17,700 --> 00:01:17,800 So, for week one for a junior engineer, it's 390 00:01:17,900 --> 00:01:18,000 all about shipping code and kind of getting to 391 00:01:18,100 --> 00:01:18,200 know their immediate team. So dev environment setup is 392 00:01:18,300 --> 00:01:18,400 critical for anyone joining an engineering team. The last 393 00:01:18,500 --> 00:01:18,600 person who joined the company is going to be 394 00:01:18,700 --> 00:01:18,800 the best person to get them up to speed 395 00:01:18,900 --> 00:01:19,000 on their dev environment, because they are the one 396 00:01:19,100 --> 00:01:19,200 who knows the most about how to set up 397 00:01:19,300 --> 00:01:19,400 a dev environment. Someone who started two years ago 398 00:01:19,500 --> 00:01:19,600 is probably not going to know the ins and 399 00:01:19,700 --> 00:01:19,800 outs of getting started. 400 00:01:19,900 --> 00:01:20,000 Additionally, you should have a goal about how quickly 401 00:01:20,100 --> 00:01:20,200 you want someone's dev environment to be set up 402 00:01:20,300 --> 00:01:20,400 so that they can reasonably ship code. So like 403 00:01:20,500 --> 00:01:20,600 a config file, for example, or something static. A 404 00:01:20,700 --> 00:01:20,800 great goal is the first week. An awesome goal 405 00:01:20,900 --> 00:01:21,000 is the first day. And, if you want to 406 00:01:21,100 --> 00:01:21,200 try to match, I think it's Debian in the 407 00:01:21,300 --> 00:01:21,400 opensource world, their goal is five minutes, which is 408 00:01:21,500 --> 00:01:21,600 probably a little bit of a reach. But I'd 409 00:01:21,700 --> 00:01:21,800 say the first day is a fantastic goal. If 410 00:01:21,900 --> 00:01:22,000 someone can be set up with their dev environment 411 00:01:22,100 --> 00:01:22,200 and able to ship a config file the first 412 00:01:22,300 --> 00:01:22,400 day, that means that you have pretty great automation 413 00:01:22,500 --> 00:01:22,600 and a really great onboarding process. 414 00:01:22,700 --> 00:01:22,800 The next thing is shipping code. You should ship 415 00:01:22,900 --> 00:01:23,000 small changes and you should teach junior engineers to 416 00:01:23,100 --> 00:01:23,200 ship small changes as early as possible. So, give 417 00:01:23,300 --> 00:01:23,400 them a task as soon as they've got their 418 00:01:23,500 --> 00:01:23,600 dev environment set up and they're ready to go. 419 00:01:23,700 --> 00:01:23,800 Maybe have them fix a bug or rewrite tests 420 00:01:23,900 --> 00:01:24,000 or a small feature that's really well-scoped, so that 421 00:01:24,100 --> 00:01:24,200 they can ship something and be productive and part 422 00:01:24,300 --> 00:01:24,400 of the team as soon as possible. This is 423 00:01:24,500 --> 00:01:24,600 great both for your onboarding process, but also it 424 00:01:24,700 --> 00:01:24,800 helps them feel valuable, which, as we talked about 425 00:01:24,900 --> 00:01:25,000 earlier, is really key. 426 00:01:25,100 --> 00:01:25,200 Journaling and note-taking. People will naturally do this. We 427 00:01:25,300 --> 00:01:25,400 don't memorize all of the commands that we need 428 00:01:25,500 --> 00:01:25,600 to know, and so we'll write them down. Just, 429 00:01:25,700 --> 00:01:25,800 just give them a central place to do it. 430 00:01:25,900 --> 00:01:26,000 Talk to them about it. Ask them about three 431 00:01:26,100 --> 00:01:26,200 things they learned that day or that week. Just 432 00:01:26,300 --> 00:01:26,400 kind of put a communication structure around the fact 433 00:01:26,500 --> 00:01:26,600 that they're probably already taking notes. It will help 434 00:01:26,700 --> 00:01:26,800 you understand what's confusing for them and it will 435 00:01:26,900 --> 00:01:27,000 help them remember things. 436 00:01:27,100 --> 00:01:27,200 And then, finally, have a social event. And do 437 00:01:27,300 --> 00:01:27,400 this for any engineer that joins your team. No 438 00:01:27,500 --> 00:01:27,600 one should join a company and sit off in 439 00:01:27,700 --> 00:01:27,800 the corner alone, not knowing their immediate team mates. 440 00:01:27,900 --> 00:01:28,000 Have some sort of coffee. Have everyone sit together 441 00:01:28,100 --> 00:01:28,200 at lunch. Go out for dinner or drinks. It 442 00:01:28,300 --> 00:01:28,400 doesn't matter what it is. They just need to 443 00:01:28,500 --> 00:01:28,600 put names to faces and feel comfortable asking questions 444 00:01:28,700 --> 00:01:28,800 of, at least, their immediate team. Like, you know, 445 00:01:28,900 --> 00:01:29,000 the five people that they work with. If they 446 00:01:29,100 --> 00:01:29,200 want to ask someone where a pen is, or 447 00:01:29,300 --> 00:01:29,400 the bathroom, or they don't know something really simple 448 00:01:29,500 --> 00:01:29,600 and they feel uncomfortable asking, that's gonna be a 449 00:01:29,700 --> 00:01:29,800 bad experience right off the bat. And this one 450 00:01:29,900 --> 00:01:30,000 is so easy. It's just a gimme. 451 00:01:30,100 --> 00:01:30,200 All right. Week two. Week two is more about 452 00:01:30,300 --> 00:01:30,400 the context of the company, and also starting to 453 00:01:30,500 --> 00:01:30,600 have them shadow and, and learn from more senior 454 00:01:30,700 --> 00:01:30,800 engineers. So, you should tell them the history of 455 00:01:30,900 --> 00:01:31,000 your company. The history of your company hopefully is 456 00:01:31,100 --> 00:01:31,200 a pretty interesting story. The history of your company 457 00:01:31,300 --> 00:01:31,400 is also something they're not really gonna be able 458 00:01:31,500 --> 00:01:31,600 to absorb the first week. They aren't gonna know 459 00:01:31,700 --> 00:01:31,800 the characters in, in the story as well as 460 00:01:31,900 --> 00:01:32,000 they will the second week. So who are the 461 00:01:32,100 --> 00:01:32,200 founders? Why did they make this company? Who are 462 00:01:32,300 --> 00:01:32,400 the people that were hired early on? It actually 463 00:01:32,500 --> 00:01:32,600 is probably gonna tell you a lot about your 464 00:01:32,700 --> 00:01:32,800 process and your culture as well. 465 00:01:32,900 --> 00:01:33,000 Additionally, a team map is fantastic. So if you 466 00:01:33,100 --> 00:01:33,200 have some place where you can put everyone's picture 467 00:01:33,300 --> 00:01:33,400 and name, generally what they do and what they 468 00:01:33,500 --> 00:01:33,600 work on, if you can make it a seating 469 00:01:33,700 --> 00:01:33,800 chart, even better, or put their names above their 470 00:01:33,900 --> 00:01:34,000 computers. People are gonna forget someone's name. They're gonna 471 00:01:34,100 --> 00:01:34,200 forget that that guy they talked to five times 472 00:01:34,300 --> 00:01:34,400 is Andy. And they're gonna be embarrassed to ask 473 00:01:34,500 --> 00:01:34,600 just like I always am when I forget someone's 474 00:01:34,700 --> 00:01:34,800 name after talking to them for five times. 475 00:01:34,900 --> 00:01:35,000 Code labs and shadowing. So code labs are something 476 00:01:35,100 --> 00:01:35,200 that Eventbrite started doing, and this is a really 477 00:01:35,300 --> 00:01:35,400 awesome idea. It's basically a safe space for an 478 00:01:35,500 --> 00:01:35,600 hour once, twice, three times a week, however many 479 00:01:35,700 --> 00:01:35,800 times, where they can ask someone that's more senior 480 00:01:35,900 --> 00:01:36,000 any kind of question they want. So you can 481 00:01:36,100 --> 00:01:36,200 have a code lab for an hour that's on 482 00:01:36,300 --> 00:01:36,400 frontend development. Or a code lab for an hour 483 00:01:36,500 --> 00:01:36,600 on dev ops. And the most important thing about 484 00:01:36,700 --> 00:01:36,800 these code labs is actually not the topic. It's 485 00:01:36,900 --> 00:01:37,000 that it's safe. So when you're thinking about picking 486 00:01:37,100 --> 00:01:37,200 engineers to run these code labs, think about picking 487 00:01:37,300 --> 00:01:37,400 engineers who are going to create a safe space 488 00:01:37,500 --> 00:01:37,600 for these junior developers to ask questions. Feeling stupid 489 00:01:37,700 --> 00:01:37,800 when asking questions is pretty typical, especially when you're 490 00:01:37,900 --> 00:01:38,000 new. You want some place where they don't feel 491 00:01:38,100 --> 00:01:38,200 that way. 492 00:01:38,300 --> 00:01:38,400 Shadowing is also a great way to get people 493 00:01:38,500 --> 00:01:38,600 up to speed. This actually is a great thing 494 00:01:38,700 --> 00:01:38,800 to do at any level. But pair them with 495 00:01:38,900 --> 00:01:39,000 someone who's more senior. Have them sit with them 496 00:01:39,100 --> 00:01:39,200 for an hour a day or a week. And 497 00:01:39,300 --> 00:01:39,400 just watch their process. How do they build code? 498 00:01:39,500 --> 00:01:39,600 How do they get things done? What tools do 499 00:01:39,700 --> 00:01:39,800 they use? One of the things to think about, 500 00:01:39,900 --> 00:01:40,000 though, when pairing people for shadowing, is that we 501 00:01:40,100 --> 00:01:40,200 will forgive a lot of bad habits in more 502 00:01:40,300 --> 00:01:40,400 mid-level or senior engineers that we won't forgive in 503 00:01:40,500 --> 00:01:40,600 junior engineers. 504 00:01:40,700 --> 00:01:40,800 So I've seen this happen a lot where junior 505 00:01:40,900 --> 00:01:41,000 engineers are following someone who's more senior, and they're 506 00:01:41,100 --> 00:01:41,200 doing a great job, actually, of picking things up. 507 00:01:41,300 --> 00:01:41,400 They're learning a ton. And some of the things 508 00:01:41,500 --> 00:01:41,600 they're learning are not so good. And so they 509 00:01:41,700 --> 00:01:41,800 end up getting punished for these habits that they 510 00:01:41,900 --> 00:01:42,000 learned directly from a senior engineer. So make sure 511 00:01:42,100 --> 00:01:42,200 that you take a look, whenever you see someone 512 00:01:42,300 --> 00:01:42,400 doing something, who's new or young, take a look 513 00:01:42,500 --> 00:01:42,600 at where they learned that from. If they learned 514 00:01:42,700 --> 00:01:42,800 it from someone else, try to just encourage them 515 00:01:42,900 --> 00:01:43,000 to go in the right direction. 516 00:01:43,100 --> 00:01:43,200 There's nothing worse, when you're new, than spending all 517 00:01:43,300 --> 00:01:43,400 this time following someone, learning something, and then later 518 00:01:43,500 --> 00:01:43,600 being told that you're doing it wrong. You're like, 519 00:01:43,700 --> 00:01:43,800 well then why did I follow this person around? 520 00:01:43,900 --> 00:01:44,000 All right. Week three is a lot about communication. 521 00:01:44,100 --> 00:01:44,200 Goal-setting. Feedback. Presentations. So for a junior engineer, at 522 00:01:44,300 --> 00:01:44,400 this, up to this point, you've probably been doing 523 00:01:44,500 --> 00:01:44,600 a lot of high-touch interactions. You've probably been working 524 00:01:44,700 --> 00:01:44,800 with them fairly constantly. By week three you can 525 00:01:44,900 --> 00:01:45,000 start scaling back. Give them more independence. Give them 526 00:01:45,100 --> 00:01:45,200 more free time. But set up weekly one-on-ones. This 527 00:01:45,300 --> 00:01:45,400 is a structured, expected thing where they can give 528 00:01:45,500 --> 00:01:45,600 you feedback. Maybe they can spend ten minutes talking 529 00:01:45,700 --> 00:01:45,800 about something they learned this week. You can start 530 00:01:45,900 --> 00:01:46,000 doing goal-setting. 531 00:01:46,100 --> 00:01:46,200 Which, by week three, hopefully they have a better 532 00:01:46,300 --> 00:01:46,400 idea of what they want to do next. Maybe 533 00:01:46,500 --> 00:01:46,600 not what they want to do with their whole 534 00:01:46,700 --> 00:01:46,800 life, but maybe next they want to focus on 535 00:01:46,900 --> 00:01:47,000 frontend. They want to get really, really good at 536 00:01:47,100 --> 00:01:47,200 implementing features for users. Or maybe they absolutely love 537 00:01:47,300 --> 00:01:47,400 dev ops and infrastructure and they want to work 538 00:01:47,500 --> 00:01:47,600 more on that. 539 00:01:47,700 --> 00:01:47,800 So you can start setting these short and long-term 540 00:01:47,900 --> 00:01:48,000 goals so that they feel like they're moving forward. 541 00:01:48,100 --> 00:01:48,200 Feedback is also really important. Give feedback early. Give 542 00:01:48,300 --> 00:01:48,400 feedback often. Some of the biggest complaints that people 543 00:01:48,500 --> 00:01:48,600 have about their managers is that they don't get 544 00:01:48,700 --> 00:01:48,800 any feedback from them. So, as engineers, we tend 545 00:01:48,900 --> 00:01:49,000 to be fairly critical and a little bit cynical, 546 00:01:49,100 --> 00:01:49,200 which I think is healthy. But when you're giving 547 00:01:49,300 --> 00:01:49,400 feedback to someone, especially if they're junior, remember, they 548 00:01:49,500 --> 00:01:49,600 don't know what they're doing well, either. They actually 549 00:01:49,700 --> 00:01:49,800 don't, they don't really have a good idea of 550 00:01:49,900 --> 00:01:50,000 what they're doing that's good or bad. 551 00:01:50,100 --> 00:01:50,200 And I'll give you another sports analogy. When I 552 00:01:50,300 --> 00:01:50,400 was coaching, so I'm coaching beginners. Absolute beginners. And 553 00:01:50,500 --> 00:01:50,600 I'm standing on the pool deck, kind of yelling 554 00:01:50,700 --> 00:01:50,800 things at them. And they'd go to do, like, 555 00:01:50,900 --> 00:01:51,000 they'd go to throw the ball, like they'd go 556 00:01:51,100 --> 00:01:51,200 to shoot and they'd drop their elbow, and I'd 557 00:01:51,300 --> 00:01:51,400 yell don't drop your elbow! And it look like 558 00:01:51,500 --> 00:01:51,600 these kids hit a brick wall. They would just 559 00:01:51,700 --> 00:01:51,800 stop and sink in the water and look at 560 00:01:51,900 --> 00:01:52,000 me. Which I realized was exactly not the behavior 561 00:01:52,100 --> 00:01:52,200 that I wanted from them. What I wanted them 562 00:01:52,300 --> 00:01:52,400 to do was I wanted them to keep their 563 00:01:52,500 --> 00:01:52,600 elbow up. 564 00:01:52,700 --> 00:01:52,800 So I thought about this for awhile, and then 565 00:01:52,900 --> 00:01:53,000 I decided to just start yelling at them all 566 00:01:53,100 --> 00:01:53,200 the things that I wanted them to do. So 567 00:01:53,300 --> 00:01:53,400 I took the words no and don't out of 568 00:01:53,500 --> 00:01:53,600 my vocabulary, which is a really, really fun game, 569 00:01:53,700 --> 00:01:53,800 if anyone wants a hobby. So I started yelling 570 00:01:53,900 --> 00:01:54,000 things at them like, keep your elbow up. Keep 571 00:01:54,100 --> 00:01:54,200 your hips up. And I saw the most amazing 572 00:01:54,300 --> 00:01:54,400 thing happen. They all started doing exactly what I 573 00:01:54,500 --> 00:01:54,600 wanted. 574 00:01:54,700 --> 00:01:54,800 They started, they started moving forward faster. They were 575 00:01:54,900 --> 00:01:55,000 excited. They felt confident. And there was no, there 576 00:01:55,100 --> 00:01:55,200 was nothing except that I just took all of 577 00:01:55,300 --> 00:01:55,400 these negative words and negative phrases out and told 578 00:01:55,500 --> 00:01:55,600 them what I wanted and they did it. So, 579 00:01:55,700 --> 00:01:55,800 when you're thinking about yelling things at your junior 580 00:01:55,900 --> 00:01:56,000 engineers, try yelling at them what you want them 581 00:01:56,100 --> 00:01:56,200 to do as opposed to what you don't want 582 00:01:56,300 --> 00:01:56,400 them to do. 583 00:01:56,500 --> 00:01:56,600 Presentations are also really great for communication. We don't 584 00:01:56,700 --> 00:01:56,800 program in vaccuums. We often work on teams. We 585 00:01:56,900 --> 00:01:57,000 need to be able to communicate technical concepts to 586 00:01:57,100 --> 00:01:57,200 other people in a really clear and concise way. 587 00:01:57,300 --> 00:01:57,400 So make them practice. Give them a topic once 588 00:01:57,500 --> 00:01:57,600 a month, a technical topic, maybe it's regexes, maybe 589 00:01:57,700 --> 00:01:57,800 it's the ORM layer, and have them give a 590 00:01:57,900 --> 00:01:58,000 five to ten minute presentation to the rest of 591 00:01:58,100 --> 00:01:58,200 the team on it. 592 00:01:58,300 --> 00:01:58,400 Week four. Week four, you're gonna continue scaling back. 593 00:01:58,500 --> 00:01:58,600 You want them to be independent. You want them 594 00:01:58,700 --> 00:01:58,800 to be autonomous. So you're gonna continue taking yourself 595 00:01:58,900 --> 00:01:59,000 out. Review concepts. Check in regularly in your one-on-ones. 596 00:01:59,100 --> 00:01:59,200 You can start to tell them things like, if 597 00:01:59,300 --> 00:01:59,400 you hit a bug, I want you to research 598 00:01:59,500 --> 00:01:59,600 things for an hour before you come talk to 599 00:01:59,700 --> 00:01:59,800 me. So set really clear expectations, but have them 600 00:01:59,900 --> 00:02:00,000 go off on their own. Have them do research 601 00:02:00,100 --> 00:02:00,200 on their own. Have them get used to that 602 00:02:00,300 --> 00:02:00,400 feeling of hitting your head up against a wall 603 00:02:00,500 --> 00:02:00,600 because you're super frustrated with a problem. This is 604 00:02:00,700 --> 00:02:00,800 good. They need to learn those things. 605 00:02:00,900 --> 00:02:01,000 Also, make shadowing elective. Let them choose who they 606 00:02:01,100 --> 00:02:01,200 want to shadow and when. So start off-loading decisions 607 00:02:01,300 --> 00:02:01,400 about what they do to the engineer. Also, have 608 00:02:01,500 --> 00:02:01,600 them start co-piloting a larger project with someone else. 609 00:02:01,700 --> 00:02:01,800 The concept is kind of like drivers' ed in 610 00:02:01,900 --> 00:02:02,000 the U.S. In drivers' ed in the U.S., you're 611 00:02:02,100 --> 00:02:02,200 paired with an instructor who actually has a break 612 00:02:02,300 --> 00:02:02,400 on their side, so if you decide to careen 613 00:02:02,500 --> 00:02:02,600 on a cliff or something, they can hit the 614 00:02:02,700 --> 00:02:02,800 breaks and stop you. So pair them with someone 615 00:02:02,900 --> 00:02:03,000 who still has enough control that they can stop 616 00:02:03,100 --> 00:02:03,200 them from doing anything that's really dangerous, but they're 617 00:02:03,300 --> 00:02:03,400 also working on bigger projects now and learning from 618 00:02:03,500 --> 00:02:03,600 someone who's more senior. 619 00:02:03,700 --> 00:02:03,800 Beyond. So, keep checking in on goals. Keep talking 620 00:02:03,900 --> 00:02:04,000 to them. Make sure you have really structured channels 621 00:02:04,100 --> 00:02:04,200 for communication. Start tailoring their projects, code labs, et 622 00:02:04,300 --> 00:02:04,400 cetera to their progress. And this is the part 623 00:02:04,500 --> 00:02:04,600 where you can start doing things like informal apprenticeships 624 00:02:04,700 --> 00:02:04,800 and assessing their progress. Although you should be assessing 625 00:02:04,900 --> 00:02:05,000 it this whole time. 626 00:02:05,100 --> 00:02:05,200 Apprenticeship is a concept that has worked for many 627 00:02:05,300 --> 00:02:05,400 thousands of years in many, many different trade industries. 628 00:02:05,500 --> 00:02:05,600 So, blacksmithing, roof-thatching, I don't know. But at this 629 00:02:05,700 --> 00:02:05,800 point, they should know more specifically what they're gonna 630 00:02:05,900 --> 00:02:06,000 want to work on long-term. So have them be 631 00:02:06,100 --> 00:02:06,200 an apprentice to someone who's more senior at this. 632 00:02:06,300 --> 00:02:06,400 So if they want to do dev ops, they 633 00:02:06,500 --> 00:02:06,600 can go work on the dev ops team with 634 00:02:06,700 --> 00:02:06,800 a more senior engineer, and they might do a 635 00:02:06,900 --> 00:02:07,000 lot of grunt-work tasks. They might do a lot 636 00:02:07,100 --> 00:02:07,200 of the things that no one else wants to 637 00:02:07,300 --> 00:02:07,400 do at this point. But they're learning. And as 638 00:02:07,500 --> 00:02:07,600 they learn and they grow they get more involved 639 00:02:07,700 --> 00:02:07,800 tasks, and they get to solve more exciting problems. 640 00:02:07,900 --> 00:02:08,000 Assessment. So you're gonna see wildly different trajectories with 641 00:02:08,100 --> 00:02:08,199 people. And hopefully the more systematic your process gets, 642 00:02:08,300 --> 00:02:08,400 the more you're able to deal with this. But 643 00:02:08,500 --> 00:02:08,600 some people are just gonna take off running and 644 00:02:08,699 --> 00:02:08,800 they're gonna be fine. Other people are gonna have 645 00:02:08,900 --> 00:02:09,000 ups and downs. And so you're gonna want to 646 00:02:09,100 --> 00:02:09,199 have some sort of way of assessing how they're 647 00:02:09,300 --> 00:02:09,400 doing. And when someone's not doing the way you 648 00:02:09,500 --> 00:02:09,600 expect, the answer isn't always they're a bad programmer. 649 00:02:09,699 --> 00:02:09,800 In fact, we came up with five assessment categories. 650 00:02:09,900 --> 00:02:10,000 Confidence, code quality, communication, judgement, and technical knowledge. And 651 00:02:10,100 --> 00:02:10,199 this is just a start. If someone is afraid 652 00:02:10,300 --> 00:02:10,400 to ship code, they might lack confidence. And so 653 00:02:10,500 --> 00:02:10,600 helping to bolster their confidence will see huge results. 654 00:02:10,699 --> 00:02:10,800 Additionally, if they're building features that don't make sense, 655 00:02:10,900 --> 00:02:11,000 they might lack judgment. And in order to have 656 00:02:11,100 --> 00:02:11,200 good judgment, you need a lot of context about 657 00:02:11,300 --> 00:02:11,400 who uses your product and why. So maybe they 658 00:02:11,500 --> 00:02:11,600 should go spend more time working with customer support 659 00:02:11,700 --> 00:02:11,800 and answering support tickets so that they can learn 660 00:02:11,900 --> 00:02:12,000 how people use the product so they have better 661 00:02:12,100 --> 00:02:12,200 judgement. Sometimes they just need to learn more about 662 00:02:12,300 --> 00:02:12,400 a particular tool, and that one's pretty easy. 663 00:02:12,500 --> 00:02:12,600 OK. Hopefully you guys have had a fair number 664 00:02:12,700 --> 00:02:12,800 of take-aways. Hopefully you now know about the concept 665 00:02:12,900 --> 00:02:13,000 of team debt. You're thinking about doing an onboarding 666 00:02:13,100 --> 00:02:13,200 plan now. But, if you take away only three 667 00:02:13,300 --> 00:02:13,400 things, I hope you take away these three things. 668 00:02:13,500 --> 00:02:13,600 First off, the goal of onboarding is to make 669 00:02:13,700 --> 00:02:13,800 people confident, productive, and independent. Reliably independent. And so 670 00:02:13,900 --> 00:02:14,000 that can have to do with their level. But 671 00:02:14,100 --> 00:02:14,200 it's not about making someone into a senior engineer 672 00:02:14,300 --> 00:02:14,400 overnight. 673 00:02:14,500 --> 00:02:14,600 Second, onboarding benefits everyone in the long run. It 674 00:02:14,700 --> 00:02:14,800 benefits the individual joining, it benefits your company's bottom-line, 675 00:02:14,900 --> 00:02:15,000 it benefits the productivity of the team, and it's 676 00:02:15,100 --> 00:02:15,200 also great for diversity. 677 00:02:15,300 --> 00:02:15,400 And finally, anyone at your company can be involved 678 00:02:15,500 --> 00:02:15,600 in onboarding. So, as I said before, some of 679 00:02:15,700 --> 00:02:15,800 your best onboarders are not gonna be senior engineers. 680 00:02:15,900 --> 00:02:16,000 They're gonna be the people who were just junior 681 00:02:16,100 --> 00:02:16,200 engineers themselves. 682 00:02:16,300 --> 00:02:16,400 OK. So, start improving your onboarding process now. There's 683 00:02:16,500 --> 00:02:16,600 actually a code repository, or not code, but just 684 00:02:16,700 --> 00:02:16,800 a GitHub repository that has some assessment rubrics. It 685 00:02:16,900 --> 00:02:17,000 has the plan in a lot more detail. It 686 00:02:17,100 --> 00:02:17,200 also has some tools for, for learning, like, online 687 00:02:17,300 --> 00:02:17,400 tools for learning Ruby and Rails. And if you 688 00:02:17,500 --> 00:02:17,600 have questions, feel free to ask them now. If 689 00:02:17,700 --> 00:02:17,800 you are terrified of yelling questions out in a 690 00:02:17,900 --> 00:02:18,000 pubilc forum, which I absolutely am, you can come 691 00:02:18,100 --> 00:02:18,200 find me later. I'll also be around for the 692 00:02:18,300 --> 00:02:18,400 rest of the conference. So thank you.