Thank you. Yes. So, um, for those of you who were at the last talk, thank you for your loyalty. I'm gonna talk about technical onboarding training and mentoring now; it's probably not going to be quite as funny. It's a linear talk, unlike our choose-your-own-adventure story last time. Uh. This is originally a joint talk that was given at PyCon. I'm Kate Heddleston; that's my Twitter handle, so you can, you know, tweet thoughts at me. I'm a software engineer at Runscope. We make these sweet shirts that say "everything is going to be 200 OK". Um, if you want one of them, you can come find me afterwards. And Nicole Zuckerman was originally my co-presenter. She's a software engineer at Eventbrite. And I'll let you figure out which one of these two people is her. But basically Nicole and I came together to create this talk because we had similar experiences at separate companies. Nicole went to Hackbright Academy and then went to Eventbrite right afterwards. I went to a small startup out of college and at both of our respective companies, we -- there wasn't any onboarding. I've mostly worked at companies that were smaller than 12 people when I joined, so onboarding was not a huge priority. About a year later, I had gained some confidence, many skills, like real-world skills. And I looked back and I thought, there's some things that we can do, even as small startups, to make the onboarding experience better. To make it easier for people to get up to speed at your company without having a huge overhead. Without having to build these massive onboarding programs that they have at large companies. Alright. So, what is onboarding? For the purposes of this talk, onboarding, as a definition, is going to be the act of taking someone from outside of the company, the team, whatever group of people it is, and making them a productive, independent, and confident member of your team. And this sounds really nice, right? If all employees were productive and confident and independent, like, that sounds like a really great engineering environment. Unfortunately, that isn't the case a lot of times. Um, someone shared a blog post with me the other day with their thoughts on onboarding, and he was like yeah, our company is trying to change onboarding so that it's not so much about lighting someone on fire and then telling them to find water and it's a little more welcoming. It's like, that's good. So to go through these three things - productivity, independence, and confidence - Productivity is pretty simple. It's about creating efficient employees. This has to do with giving them the tools to write code, deploy code, understand how features get built. Basically get their jobs done. Independence and autonomy is actually huge. Autonomy, uh, being an autonomous agent is really important to people. The greatest motivations, in fact, come through things that we choose for ourselves. The anecdote that I have for this is in prisons. They discovered that autonomy is really important. So when people are in prison environments, a lot of their rights and abilities to do things are removed. This leads to riots, dissatisfaction, and many things that you would think would happen. So what they do with prisoners is they give them the right to change the channel, and they give them the right to move their furniture around. And this little bit of autonomy, this ability to choose for themselves what they get to do, even though it's very small, reduced prison riots by - significantly. You want to reduce riots at your company by giving people the ability to choose the TV channel. Confidence. Confidence is about creating employees who believe that they are valuable. And the word 'belief' is actually really, really important. So a lot of people think - they might think 'arrogance' and they might think 'confidence' and they might think a lot of things, but this belief in your value to the company is paramount. And this is very much a human thing. This doesn't really have to do with computers. This just has to do with creating an environment where companies feel as though they can enact change, and that they are capable of enacting change. Oh. This - the belief is really important. Also they did a study. So how many of you have heard of the concept of 'stereotype effect'? Stereotype - do I smell? Okay. So the stereotype effect works like this. There are stereotypes in the world. "Asians are good at math." "Women are bad with computers." And what they've found is that, before tests, tests on things like physics or math, what they'll do is they reminded one group of this stereotype. "Women are bad at math; men are better at math. Asians are better at math than all of those groups." And what they found was, when they reminded people of those stereotypes, people performed to the stereotype. If they didn't tell anyone at all, people performed in a control group setting, and then the third group that they did is that they told people that their ability to do well on the test came from these sort of intrinsic motivators, like if you work hard you'll be good at math, if you think about like your own personal qualities that's helpful, what they saw was that everyone's performance improved and there was actually no difference across these different lines. So stereotype effect is really important. It's this belief that you are good at - at something or not. And what's funny is just being told that you are good at this might actually change your performance. Okay. Why do you care? Um, you're all already here, so you probably care about technical onboarding and training at your company. Maybe you have to hire a bunch of new engineers out of college, maybe you have a bunch of interns coming on board and you're like terrified, because what are you going to do with all of those interns. There's four categories that you should care about when thinking about onboarding. There's the individual, there's the company, there's the team, and then there's also a bonus section on diversity. Onboarding is really important for the individual. The cost of losing an employee can range from tens of thousands of dollars to 1.5-2x their salary. If someone gets off to the wrong foot at your company, if they're not happy, if they never get up to speed, if they never feel autonomous, confident, and productive at your company, you're probably going to lose them. And that's really expensive. So having good onboarding, just getting everyone off to a good start, is really important for individuals. It gets them going upwards like this. It builds their skills, their confidence, their happiness. The next one is the company. Onboarding is really important for the collective productivity of the company, and the anecdote for this one is at LinkedIn. For a while, LinkedIn was actually losing productivity for every engineer that was added to their team. And this was a huge crisis. They actually had to bring in some new executives, some new managers, and they were like, we have to stop hiring. Like, adding engineers to our team is actually decreasing our productivity. This is a nightmare. Uh. What you really want is something more like this. We want every new engineer we add to the team to increase productivity. So LinkedIn had to do this massive reorganization. They had to do a whole bunch of getting rid of some things, adding some things, adding onboarding and training, and basically streamlining everything so that new engineers could come in and be productive. So onboarding and having onboarding early is going to stave off some of these problems that you might run into later. Team. So we talk a lot about technical debt - how many people have talked about, or heard about, the term 'technical debt'? - yeah, you went to build something really fast, you kind of cut corners, and six months later you're like aw crap, we have to rebuild this, we have a lot of bugs, this is completely unmaintainable. Nobody knows how to change this system. Well, similarly there's team debt. If you add a lot of engineers really fast and really thoughtlessly, you can get something like this happening. Everyone's running in a different direction. And since people are the most important component for building software, um, this is really, really detrimental. You want something that's more like this. Obviously. This is my favorite equation that I've ever made up. The story behind this equation, and I have a lot of sports anecdotes, 'cause I played sports for a long time, and I coached sports for a long time. But in college when I was done playing, I actually coached JV girls' swimming and water polo. So - JV girls' water polo, very new to most of the girls. They couldn't swim, they couldn't throw a ball, we're talking like very basic skills. Playing a full game, with like all seven players on the field, was, I mean it was like, you know when you watch like peewee soccer and all the kids kind of like chase the ball around? It's a little bit like that. And so a huge amount of what I did was just basic skills. But the other half was kind of the emotional team-building part. And I told them this. I was like, look. Your ability to win games, and your ability to do well at this sport, even at this very introductory level, is the sum of your talent multiplied by your ability to work together as a team. Some of the people on the team didn't have a lot of natural talent. They were going to have to work really hard to build their skills. But that's fine. Because if they focused a lot on working together, they focused a lot on getting things done as a cohesive unit, they can actually beat teams that had more collective talent, but didn't work together quite as well. And we've actually seen this in software engineering. A lot of, uh, the most popular tools out there were built by teams of less than ten. Gmail, for example, was built by a team of I think like five to seven people? It's maintained by, like, a team of over 400 engineers. So you can get a lot done collectively as a small group in terms of productivity, in terms of building really cool products, without having super talented engineers. If they all work really well together, a lot of mediocre engineers can do more than a few talented engineers who are kind of assholes. Alright. The bonus section is diversity. So to illustrate diversity, I have sneetches. The story of sneetches is a Dr. Seuss book. There's the star-bellied sneetches and the non-star-bellied sneetches. And it's this story about the rift that's caused in the community of sneetches based on those who had star bellies and those who did not have star bellies. And I use it to represent diversity because diversity can mean a lot of things. There's the classic ones, there's gender and racial diversity. There's also things like introverts vs extroverts. Um. Communication styles. I don't know. Philosophical backgrounds. Cultural backgrounds that don't have to do with race but have to do with how you were brought up. So diversity can mean a lot of things at companies. And why is diversity critical? And why is onboarding a really useful tool for increasing diversity? Well, basically what happens is this. If you have no onboarding, people coming into the company are going to rely on the existing social structures to get up to speed. So that means whatever the original group of people is, they probably have a way that they talk about things. They probably have certain social events that they do. They probably look fairly similar. And if someone comes onboard who's like them, who's able to communicate, who's able to go out with them, who's able to connect with this core group based on these existing social structures, they're going to do better than someone who's not like the original group. Because what you have when you have no onboarding is not no onboarding. You have onboarding that relies on the social structures that you have in place. So creating an onboarding program that's slightly more structured, slightly more explicit, will benefit people who are different, people who don't naturally speak the way that people at your company already speak, that don't naturally want to do the types of activities that people at your company wanna do. Because not everyone wants to go out drinking at 10pm on a Tuesday night if you have a really young, party-oriented company. So you want to give everyone a fair chance because there's very talented people who look very different from each other. Who can onboard? Anyone can onboard! This is a team of people carrying a canoe, this is not a group of ants carrying a taco, just to let you know. I draw these myself, by the way. I'm not a very good artist. Um. Anyone can onboard, and in fact onboarding should be a collective effort. This distributes the load. One person alone trying to onboard everyone is gonna burn them out. Similarly, I was talking to someone about mentorship, and someone else was saying, oh, you have to have a lot of experience to mentor. And depending on the type of mentoring you're doing, that's true. But going from junior engineer to senior engineer is not a one-step process. It involves going from junior engineer to less-junior engineer, to less-junior engineer, to maybe mid-level engineer, to slightly more mid-level engineer, to 'hey! oh! I kind of think I get this now!' And so having someone that's very experienced, who can guide the overall path is important, but some of the best people to mentor and train your new junior engineers are going to be the ones who just did it. They're going to still have empathy for what it's like to take that step. They're going to understand the problems that they're running into. They're going to actually care about what this person is doing, and the more senior you get and the further away from that you get, the less empathy that you have for people. And in fact we all know this. Senior engineers are total curmudgeons. They're like, 'everything is going to break and it's all going to hell and I don't know why we care and come into work every day.' And junior engineers are like, 'oh my god, that's awful, I'm so excited about what I'm doing.' When? Okay. Onboarding starts as soon as the offer is accepted. Basically, onboarding is not just about teaching someone the skills that they need to be successful about your company; it's about bringing another human being into a group of human beings. So: making someone feel welcome. Figuring out how to integrate them into the team. That's going to start as soon as they've decided to come on board. Onboarding roughly ends when someone is reliably independent. And this can mean different things to different companies, and I left it kind of vague on purpose, but the idea for a junior engineer at least is that we bring them into the company and they're kind of - like our onboarding program is done when they're reliably independent. We can give them tasks and trust that they're going to come up with a semi-reasonable solution in a semi-reasonable amount of time. And we can manage that effectively. So the how section that we're going to go through now is a little bit philosophically about how to do this, but we're also going to focus on concrete examples and ideas for how you can build the onboarding program at your company. The first thing to think about when onboarding people is to maximize your return on investment. And this might seem somewhat callous, but at the end of the day why wouldn't you want to maximize your return on investment? Like you don't want to put a ton of resources into something and get less out of it than you put in. That just doesn't even make sense. It's a really, really common pitfall for mentors, especially first-time mentors. So if you have people onboarding junior engineers at your company and they've never onboarded someone, what you essentially have is you have a junior mentor onboarding a junior engineer. That you have someone who's never done this before, they don't know what's going on. I love talking to people who are first-time mentors. They're like, I'm going to be the best onboarding mentor ever. We're going to do everything together, we're going to take these courses, we're just going to - by the, by time they're done with these three months they're going to know everything I know. And that's highly unrealistic because people only absorb information at certain rates. Also your expertise has to do with the number of issues that you've seen, and it just takes time. Over time you see more issues, you solve them, you fix them. So people are going to grow at the rate they're going to grow. You can help make that better, you can help focus their path, but you're not going to make them into a senior engineer overnight. This tends to burn out mentors, so people do this, they burn themselves out in three months because it's exhausting teaching someone, and then they're like, I can't be a mentor again for another year. And your company's like, well, OK, I guess we can't hire any more junior engineers. Like, we don't have anyone to train them. Instead I like to think of it as bumper bowling. One of the tenets of expertise is that you're able to set boundaries. You know the landscape. You know everything about this arena. So you can set boundaries. You can scope problems. You can figure out exactly what needs to be done, and exactly what doesn't need to be done. Junior engineers, by definition, are not good at scoping. They don't know what the boundaries are. So what you need to do is set them for the junior engineers. Bumper bowling is a great example. You just - you set up the bumpers. It's fine if they just hit the bumper on each side going down. They're still going in that direction, and that's where we want them to go. You don't have to handhold them through the process. You don't have to spend tons of time with them. Instead you can just create an environment where they can kind of mess up and learn on their own, and you can come in and help them grow when that needs to happen. So the onboarding plan - there's three major categories. There's technical knowledge, company knowledge and process, and personal development. These are about equal thirds for someone. We tend to think that the technical knowledge is the most important thing, and it's, people think it's like 80% of what engineers do. It's probably about a third. Like, another third is domain knowledge of that company. How do I build a feature at this company. How do I ship code at this company. How do I deploy, given our deployment system. And then personal development. Like the confidence, the autonomy, all of those different things, that's another third. People tend to think that skills - or that confidence follows skills, but in practice it's usually the reverse. People who are confident will gain skills at a much more rapid rate than people who lack confidence. OK. Week 1. Week 1 should be pretty simple for new engineers. Dev environment setup is really important. The thing that you can do to help new engineers is just automate as many tools as possible. The more automation the better. The more maintainability the better. As engineers, that is one of the best things we can do for people's process, is make sure that a lot of these things are automated. So shipping code as well. If shipping code is really well-automated, and it's super easy for you to ship code, it's going to be easy to bring someone, even someone who's junior, on board, and get them to a place where they can ship code. So for dev environments, again, automation. Have the last person who set up the dev environment help the new person. They know all the pitfalls. They just did it. They just had to go through setting up their development environment. You don't need a senior engineer, you don't need someone who knows a lot about some other random thing. It's just dev environment setup. So the last person who joined does dev environment setup. Have them ship small changes as soon as possible. If you can have someone deploy on the first day, that's awesome. That means you have really good automation tools. Third, journaling and note-taking. Have them start taking notes. Three things that they learned this week. For junior engineers, this is going to be really important. They're probably not going to know a lot of things, and you're going to be surprised at what they do and don't know, so having them take notes that you can talk about once a week is really great. And then finally, a social event. And a social event's actually a really good activity, even for people who are not junior. A social event's just: we're gonna hang out, I'm going to learn everyone on my immediate team's name, because if I want to ask a question, it's really nice to know that person's name. And I'm going to feel more comfortable talking to other people on my team. Because a huge amount of work that you need when you're new, regardless of level, is just the ability to go talk to someone else on your team. Alright. Week 2. Week 2 you can start throwing more information at your new engineer. The first week is so overwhelming a lot of times that things just go in one ear and out the other. So I recommend doing history of the company and team map second week. So history of the company - where does the company come from, why was it started, who were the founders, what was the reason that it got here, what were some of the pitfalls that happened along the way, why do we target the markets that we target. And a team map, which seems really simple, but just giving them a map - like, this is Bob, Bob sits over there, Bob is really good at redis, he deals with all of our asynchronous task queues, um, so go talk to him about that. Or, like, so-and-so is really good at building fully-fledged future products. They have a great design sense, but they're also good at building front-end features. So knowing those things is super helpful to new engineers. Shadowing and code labs are good activities to get started the second or third week. Shadowing is what it sounds like. Have them sit down with someone who's more senior, either mid-level or senior, whatever you want to do, and watch what that other person does. What kind of keyboard shortcuts do they use? What type of bash commands do they use? What does that bash command do? Why are they doing all of the things that they're doing? They can learn and absorb a lot of information just by watching other people for an hour, either once a week or every day if you want to be really aggressive. Code labs are something that was started at Eventbrite. Basically it's like a new engineer AMA. So it's a safe space - emphasis on the word safe, no judgment, your questions are not stupid - it's totally fine if they want to ask concepts that might seem really beginner, but they can just ask one of the engineers at your company anything. So you can rotate the engineers, people with different expertise can come in, but really what you want for the person running a Code Lab is someone who makes people feel safe. Again, if people are terrified of asking questions they're not going to ask questions. Week 3. Now we start to get into some of the higher-level stuff. One-on-ones, goal-setting, feedback, presentations. One-on-ones. Most companies have totally bought into the idea that you need to do these now, but weekly one-on-ones are really important. Emphasis on weekly. Having channels for feedback, for easy communication, is so important. If someone runs into an issue, the overhead for telling someone who's more senior about this problem that they've run into is really high. Having to schedule a meeting to give someone bad news is one of the worst things that anyone has to do. So creating these channels for constant feedback is really important. Even if every week they're like, 'I'm doing great, there's nothing to talk about!' That's totally fine. This is still a really good thing to do. Goal-setting and feedback: it might seem really silly and simple and kind of like, second-grade - what are your goals for this? But people are goal-oriented, and they do really well if they set goals. 'In the next three months I would like to learn more about how to build features in JavaScript. In the next six months, I'd really like to learn how to build the API layer for the features that I've built in JavaScript.' Presentations. The best way to learn something is to teach it. This has been proven over and over again. So, force your new engineers to do five-minute presentations on topics. 'I want you to present on regular expressions. Tell us everything that you can figure out about regular expressions, do a short presentation about them, teach us regular expressions.' And by the end of that presentation, they'll know how to use regular expressions. By the way, I gave this talk at RailsConf, which is ruby, and I totally didn't even think about what I'd written on this slide here, but multiple people at the end came up and they were like, you do know that that was in Python, right? I was like, yeah, Python is awesome. They notice. Alright. Week 4. Week 4 is review concepts, check in regular, regularly, elective shadowing, and start co-piloting, co-piloting a larger project. So basically now you're just kind of setting, getting set into a rhythm. You want to be able to check in with them, you want them to feel as if they can talk to you, shadowing can become elective, hopefully they have enough confidence now to say, oh I want to shadow that person and learn that thing, and go set it up for themselves. Co-piloting a larger project is kind of like driver's ed. They can do this with someone who's much more senior, but the senior person really has an emergency brake on their side, so they can give them tasks - Actually, the way I, the way I like to do it is, if you put them with someone who's more senior, they do all of the grunt tasks. The senior person doesn't want to do, I don't know, all of these grunt tasks that are too trivial for them, but just work that has to get done, but that is really valuable learning for someone who's junior. They've never seen any of it before. So it's exciting. So then you have these really great pairings of someone who's very senior and someone who's very junior, and the junior person's running around doing all the grunt work and super-excited about it, and the senior person is thrilled that they don't have to do the grunt work any more. Alright. Beyond. If onboarding has gone well, hopefully this comes and it's really easy. You just check in on progress, you tailor projects and code labs to their needs, you start doing formal apprenticeships, and you start doing assessment, and hopefully those assessments are positive. Apprenticeships - that has to do a little bit with what I talked about. Just being taken under someone's wing. The best way to learn is from imitating someone who's really good at something. In fact they find that that's true with athletes. Athletes who are put under someone who's, like, really good and much more experienced at the sport will learn it at a faster rate. So just put them around people who are good at this that they can watch and imitate and follow. If you put them with someone who has bad practices, and I've seen this happen, and it's a pet peeve of mine - if you put them with someone who's senior but who has really bad practices, and that junior person picks up those bad practices, and you punish that junior person for the bad practices that they picked up from the person that you paired them with, that is a really bad experience. So a lot of times we let senior engineers get away with behavior that we wouldn't let junior engineers get away with. Be cognizant of that. So know what bad practices some of your engineers might be passing on to junior engineers, and don't punish them for it. Just explain to them why that's bad, or put them with someone who has a really good practice in that area. Assessment is really important. People's trajectories are gonna be wildly different. Some people are gonna do awesome and they're gonna shoot straight up, some people are gonna plateau, some people are gonna be really up and down. So having a plan for assessment is important. As we've said before, technical ability is not the only category to assess. There's confidence, there's code quality, communication, judgment, and technical knowledge. Judgment is one of the bigger ones. It's slightly more difficult to assess, but if you can hire people who have great judgment, you can trust them to do things, even if they're really junior, that are going to be good. And the example of this is one of my friends at Hearsay Social, the last company I was at, she worked in support for a long time. And she taught herself engineering on the side. So when she first started engineering, by every definition she was very junior at engineering. But she knew the product inside and out. She knew the customers inside and out, and she knew exactly what needed to be built in any given situation. In other words, she had excellent judgment. So I could give her tasks, tasks that, I mean, they were pretty simple but she might take a little bit longer on, but when she came back to me with the feature that she had built, I was like, yes, This exactly solves the problem that we wanted to solve. This is awesome. You've saved us all time. Conversely, engineers with bad judgment will build terrible things very quickly for your site, and then you're like, no no, please don't merge that, and you're like, taking code out. So judgment is something that's really really great if you can find it in someone, and it's hard to assess, but I recommend that as something to look for in junior engineers. Alright. The main takeaways. Onboarding aims to make new team members confident, productive, and independent. If you focus on these three things, and you really try to get people to that place, you're gonna have successful engineers most of the time. It benefits everyone in the long run. The individual gains skills, the company is more productive, the team is more productive, and diversity is better at your company. And finally anyone can be involved in onboarding, so you don't have to be super senior. Getting everyone involved will spread out the load, it will make it easier to onboard new engineers, and for startups who don't have resources, it's going to make it possible to hire junior engineers. And since there's two ways to get great engineers at your company, stealing them or making them, it's good to have channels for making engineers. And that's it!