 My name is Kate Hiddleston. This talk is called technical onboarding training and mentoring. It was originally written and co-presented at PyCon with Nicole Zuckerman. She's not here today, but she is a software engineer at Eventbrite. She's the one that's not me, so I will let you use your powers of deductive reasoning. So I'm a software engineer. I work at a company called Runscope. I usually work at really small early stage startups. I've never joined one larger than 12. So I usually join companies that don't have any onboarding. And this talk was originally written because Nicole and I had separate experiences, completely independent, where we joined companies and there was no onboarding. And we learned a bunch of stuff and about a year later we looked back and we were like, a little bit of onboarding would have gotten us to this point much faster. And so we turned around and started implementing onboarding for the new employees at our respective companies. So first, what is onboarding? This talk focuses a lot on junior engineers. Many of the things that I talk about can be co-opted for mid-level or senior engineers. But I specifically focus on junior engineers because there are a lot of code academies that are putting out a lot of junior engineers and companies are having a hard time absorbing these engineers into their organizations. But onboarding is the process of taking someone from outside of the company, outside of the team, outside of the group, and making them a productive, confident and independent member of your team. And I picked these three things very specifically and I'll go over them. Although productivity is pretty straightforward, there's a lot of apps and blog posts about how to be more productive and efficient. It's important but the bulk of this talk is about independence and autonomy and confidence. So autonomy is hugely important, independence in new engineers. It's a big motivator. I also have two somewhat depressing anecdotes about the importance of autonomy. The first is in prison systems. So prisoners, by definition, have no autonomy. They're stripped of all autonomy, all ability to make decisions. And when they started doing their research on the sociology of inmates, they realized that giving inmates the ability to choose the TV channel and to rearrange their own furniture, seemingly mundane choices, significantly reduced prison riots. So autonomy reduces riots. This is good. The second depressing anecdote has to do with nursing homes. It's another place where people are stripped of autonomy, although in this case they're usually stripped of autonomy in order to provide good care. But they're also, they don't have any choices about what they do. And they found that people in nursing homes who had choices like what to eat and had some small responsibilities like chores and cleaning lived significantly longer than those that had no choices. So autonomy also prevents death. So you want independent people on your team. It's a great motivator, but it actually also is really critical both to life and our happiness. Confidence. Confidence is, most people will agree, very, very important. But what is confidence? Confidence is really the belief that you are valuable. And the fact that it's the belief that you are valuable is hugely important. How many of you have heard of the stereotype threat? Anyone? A few? It's actually a pretty well researched and documented phenomenon. Someone decided to basically go figure out if people play to stereotypes, if stereotypes are true. And what they found was that statistically people will play to stereotypes. So some examples of stereotypes, and I in no way condone or justify these, that Asians are better at math, men are better with computers, women are better at nurturing, et cetera. So what they did is they took some of the quantifiable stereotypes. And if you remind a group of people before they take a math test, for example, that men are better at math, what happens is men perform better on that test and women perform worse than the control group where they're not reminded of the stereotype. What they also found was that if you flip that on its head, if you tell a group women are better at math, we've actually found that women perform better on these types of spatial reasoning problems. Women will perform better and men will perform worse than the control group. So it's not really about whether or not the stereotype is true, it's about this belief, this idea that I am capable of learning these things or I am capable of being good at these things. So why do you care? I think a lot of people care about onboarding. What I want to convince you of is not that you should care in general, it's that you should care right now. That onboarding isn't something that you should do next month or next year, that onboarding is something that you should do immediately, like automating your deploy. So there's four major categories that I'm going to talk about as to why onboarding is important. The first is the individual, the second is the company in the bottom line, the third is the immediate team that a person joins, and the fourth, the bonus category is diversity. So the individual, it's pretty obvious for individuals that training is important, learning skills, having an upward trajectory, confident, productive, independent, but also losing an engineer at a company is really expensive. And having engineers that are not as productive as they could be is also a loss of money. So losing an engineer can be 1.5 to 2x the annual salary of that engineer. And while onboarding or a lack of onboarding doesn't lead directly to attrition, good onboarding will mitigate things like that. So for the company's bottom line, companies care about money. They build products and they sell them and hopefully they make more money than they burn. For companies, when you add a new engineer to the team, you want to make more money, or you want to build product that will make more money. And so what you don't want is this, this is bad. And LinkedIn found a couple of years back that this is exactly what was happening at their organization. They hired a new senior vice president of engineering and they had to freeze all hiring. They had to stop hiring engineers because every engineer they added to the team decreased their productivity. So they had to do all of this reorganization. They had to put in place onboarding and figure out what was going on so that they could get something like this and they could hire new engineers. So this is incredibly expensive. Not only are engineers really expensive employees, but if you're losing money for every expensive employee that you add, that's a pretty bad business model. So the individual team that a person joins is also really important. You don't know something until you teach it. That's kind of an old adage. And so when a new person comes on board, you need to teach them about your processes, your team culture, how you get things done, your values. And this is good for the existing team because every time a new person is added, that team fundamentally changes. So I played a lot of sports, I coached and I have a lot of sports anecdotes, but basically this is true on sporting teams. Every time the senior class leaves and a freshman class comes in, it's a fundamentally different team. So as you're scaling your company and you're adding new engineers, you're not the same team. If you go from 10 to 20, you're a different team. So what you need to do is reiterate the values, not just to the new people coming on board, but also to the existing team members. You want everyone going in the same direction and that's not something that can just happen on its own. It's something that every single incremental step of the way you need to reiterate. So having good onboarding is a little bit like having good deploy automation. It's absolutely critical and having it will pay off hugely. The amount of time you put into having good onboarding and having good deploy will pay off enormously, especially if you do it early. Because rather than having to go build this huge heroic system, later on you can just incrementally add to the one that you already have. So this is my favorite equation that I've ever made up. Back when I finished playing water polo, I coached JV girls swimming in water polo and I used to have these really great philosophical team meetings with them that they absolutely loved. And I came in with a poster board one day with this written on it. Like this is really important everyone, like I have this equation, I need you to understand this. Your ability to win gains, your ability to be successful as a team is the sum of your talent or the sum of your skill sets multiplied by your ability to work together as a team. So you can all be medium skilled or beginners, but if you work together incredibly well, you can beat teams that are quote unquote more talented than you are. So there's a lot of Disney movies about this as well, but you can overcome challenges through teamwork. And we found that that's true in software engineering as well. Really small teams can be hugely productive if they work together efficiently. In fact, a lot of the biggest products that we use today are built by teams of less than 10 engineers. Gmail is a really good example. It was built by a team I think of less than seven and it's now maintained by a team of over 400, I wanna say. So you can build awesome stuff with a small team that's highly productive and works together really well. Conversely, if you have a bunch of really talented engineers who don't work together at all, you're just gonna completely fall apart. So our bonus section, diversity. I use sneaches to represent diversity. So for those of you who don't know the Doctor Sue story, the Doctor Sue story is about a community of sneaches and some of them start developing stars on their bellies and this separates them from the non-star bellied sneaches and it causes rifts and it's supposed to represent different demographics. I use sneaches because diversity can mean a lot of things to a lot of different teams. There's the classic examples of gender diversity and racial diversity but there's also things like introverts versus extroverts. So if you have a team of introverts and you bring on an extrovert or vice versa, that can also be something that you need to think about. So onboarding is really important for diversity. If you have a homogenous group which is pretty common with startups and companies to have a homogenous core existing group and you have no onboarding, the people who are gonna be most successful and have the best time getting up to speed are people who are like the existing group. This is because a lot of onboarding has to do with communicating and someone who's like the existing group is gonna be able to communicate more easily. They're probably gonna have similar hobbies, shared interests, so they're gonna be able to talk to the existing group, learn about the product, learn about engineering and get up to speed faster. So you're gonna have this feedback loop of hiring more and more people like the core group. Conversely, people who are different, who don't necessarily communicate the same way, who don't have the same hobbies or interests, maybe people have children and they join a team of young adults who like to go out and drink. It's gonna be harder for them if there's not explicit onboarding. So explicit onboarding makes it possible for people who are different from the core group to learn about the product, to learn about the company, to come onboard and get up to speed and it doesn't disadvantage them disproportionately against basically the existing group. So who should onboard? Everybody should onboard. This is not ants carrying a taco. This is people carrying a canoe. I drew all of these myself. So everyone should onboard, spread out the load. There's a common misconception that only senior people can teach. The best rule of thumb is actually that the last person who did something should teach it. First off, they're still excited about it. Second off, they know it the best and third you can spread out the load that way. So someone who just learned about your automation configuration system is gonna be great to turn around and teach it. The best people to onboard junior engineers are not senior engineers. They are the people who were just junior engineers. So when you go into college and you play a sport, the freshmen are not actually onboarded by the seniors on the team. It's the sophomores. Because the sophomores were just freshmen last year. They know what it's like. They still have empathy for the problems whereas the further you get away from them, the less empathy you have. And also you get really cynical as you get more senior. So you want someone who still has a little bit of that enthusiasm. So when should you onboard? Onboarding starts from offer acceptance in the start date and it goes all the way until reliable independence. And this is true no matter what the level of the engineer. So someone who's junior reliable independence might take six months. Someone who's really senior could come onboard and be reliably independent within about like a day, three days, I mean who knows it could be really, really fast. But that's the whole point of onboarding is to take someone and make them reliably independent in your organization. And how? So how has two sections? The first is a little bit of the philosophy about how you should think about onboarding. And then I'm gonna go into an example of an onboarding plan that you can pick and choose from to create your own onboarding plan. You don't have to be completely altruistic when you're thinking about onboarding. You really want to maximize the return on investment. You don't want to put way more into onboarding people than you get out of it. That doesn't make sense. That's not sustainable. That's actually crazy. I don't know why you'd want to do that. But it's actually a really common pitfall. So this is a really common first time mentor thing that happens where they want to handhold the new junior engineer. They're so excited about being a mentor. They're like, this is gonna be awesome. We're gonna do everything together and I'm gonna teach them everything we know. We're gonna do tutorials. But the time I'm done with them, they're gonna know everything that I know. And this is wildly unrealistic and it also leads to high burnout rates. So the senior engineer is putting in so much time to this junior engineer that by the time the junior engineer is finally onboarded, the senior engineer is exhausted. And they're like, I can't onboard anyone else. And so the company's like, well, we can't really hire more junior engineers if we don't have anyone to mentor them and onboard them. So instead, you should think about it kind of like bumper bowling. You wanna put in place enough structure and enough process to get them going in the right direction but it doesn't really matter if they hit the lane the whole way down. They'll get better, they'll practice, it'll be fine. They're going in the right direction. And a lot of putting in place a structure like this without having to handhold people involves creating really good automation at your company. Really good dev environment setup, really good testing, really good deploy system. So a huge amount of creating a great environment for junior engineers is very technical. You want a lot of automation. It's also important to remember that one of the tenants of expertise is the ability to set boundaries. So when you're an expert, you have a really, really in-depth understanding of the landscape. You're able to scope and set boundaries and break problems down into really small, manageable pieces. By definition, beginners cannot do this. They don't know what the landscape is so how could they possibly scope problems down to the appropriate size? So it's important to remember that part of your job in setting up onboarding tasks is to scope them. To just scope things really, really well for new junior engineers. Bug fixing is a good example of well-scoped projects. So a bug has a clearly defined problem, usually has a pretty clearly defined solution for a lot of them. And so they're by nature well-scoped projects. Those are great, actually really great to give to junior engineers. So an example onboarding plan. It covers three major categories. Each one of these is about a third of what someone needs to learn when they come onboard. We think, for some reason as engineers, that the technical knowledge is 90% of it. It's not. There's a ton of online documentation and a ton of resources. A third of what someone needs to know is the company knowledge and process. How do I build here? How have we built here? What framework do we use? How did we hack this framework to pieces so that it doesn't look anything like the original framework? And I need to know about that and there's no documentation. And then the third category is personal development. So developing confidence and excitement around what you're doing so that you go off and you learn things on your own and you believe that you're capable of learning all of the millions of things thrown at you as a new engineer. So I've broken it into phases. These were originally weeks, but I decided phases makes more sense because it doesn't really matter how long each section takes. It just matters that each section is dealt with. In phase one is shipping stuff. So when someone comes on board, you want them to ship things. So the first step of that is dev environment setup. And someone should be able to set up their development environment in a day. That is an awesome goal. If someone can't set up their development environment in the first week, it's worth dedicating a lot of resources to it, especially because this isn't something that junior engineers have to do, it's something that all engineers have to do. The best person to help someone set up their dev environment is going to be the last person who did it. So you should never have burnout on mentorship for dev environment setup because the last person who did it is always gonna change. Shipping code. Preferably you want someone to ship code the first day. If you can get them to do it the first day, that is awesome, you get a gold star. If they can do it in the first three days, that is still really good. The first week is preferable and if it's not in the first week, I would highly recommend dedicating some resources to DevOps so that people can ship code within the first week of joining the company. Have them ship small changes, it can be a config file. The point of this isn't to have them alter your code base significantly, it's to have them understand the process for how you ship code. How do you open a pull request? How does that pull request get merged? Who decides that pull request is ready to go? How is that pull request then deployed out to production? The third thing is journaling and note-taking. People will naturally do this because they can't remember all of the things they need to do. So just give them a notebook, basically. Just tell them that they're gonna have a lot of stuff that they need to remember so they should write it down. It's a nice way to check back in too because if they've written it all down, you can go take a look at it. And then finally a social event and this should be done for everyone. This should be done the first week and the reason that you wanna have a social event the first week is because people need to talk to their teammates. They would like to know who they are. This can just be the immediate team, the five people that they have to work closely with if they join one specific team, you can go get lunch, go get coffee. People just wanna know other people's names so that when they have a problem, they can go and say, hey, Amanda, instead of standing awkwardly beside their desk and staring at them until they look up. Phase two. Phase two is the big section on talk to your teammates. So after phase one, someone's able to ship code. They are able to open pull requests, push them out to production, do kind of the core of what it is that we do as an engineer. Phase two is a lot about integrating with the team more. So the history of the company and a team map are some of the best things to do in this phase. The history of the company people love to do on the first day and I don't know if you guys have joined a new company lately but on the first day you're still trying to figure out where the bathroom is and so the history of the company is just not gonna sink in. You also don't know any of the characters in the story because you haven't met anyone at the company. So do this the second week or the third week but do it when people can actually absorb the story about how this company was started and why all of the different people are there and then give them a map. Where do people sit? What are their names and what do they do most often? You know, this person is the person who works with Chef at our company. This person works mostly with APIs. They can then look at the map rather than having to go ask people what someone else's name was or who do I go talk to for this? They can just go find that person. So it gives them independence fairly early. Shadowing in code labs are good to get started at this point. Code labs are something that they actually do at Eventbrite. Eventbrite has, they've done a really good job of hiring people from Hackbrite, the Code Academy, it's a Python Code Academy for women. So they've put together a fairly robust onboarding process and it involved code labs which was a weekly safe space to ask questions. And the emphasis is on safe because when someone is really new they feel like all of their questions are stupid. Even if they aren't. And so having someone host this who's really good at making people feel comfortable asking stupid questions is hugely important. And the code labs can be about anything. It can be on any topic, it can be run by any engineer who's interested in running it. Shadowing and pairing is really important at this point. I was having a discussion earlier about the difference between shadowing and pairing. Shadowing is following someone and watching their workflow. Pairing is working with someone to achieve a task. Both are valuable, both are really good. Shadowing sometimes you can, if you shadow someone who's too far advanced you can lose track of what's going on. But it is a bit of a fine art form to figure out exactly how much shadowing and exactly how much pairing someone needs. So I don't have an exact response to whether or not you should do this all the time or how much. Phase three. Phase three is decide who you wanna be when you grow up. So now that the person can chip code and do basic engineering tasks, they feel connected to their teammate and their company. They need to decide what they wanna do next. Do I want to build product features? Do I wanna be in the UX space? Do I wanna do DevOps? And at this point, they should hopefully have a better idea of the landscape and the people on the team. So companies should have weekly one-on-ones. Everyone should have a weekly one-on-one with their manager. I also believe that people should be able to electively have one-on-ones with anyone they want at the company. This is hugely important. Having communication channels, even if they come in once a week and tell you that everything is great, I'm doing fine, like I'm so happy here, you should still meet with them once a week. Because if something is bad, if something's going wrong, that communication channel is gonna become critical really fast. And you have no idea of knowing when that's gonna happen. So if you don't have weekly one-on-ones and you don't have these communication channels, you basically put the onus on people with less power to come to people with more power with bad news. And that is a terrible, terrible thing to have to do. Goal setting and feedback? Goal setting sounds really lame. I don't know why, but it's so important. This is basically the what do I wanna, what kind of engineer do I wanna be? Who do I wanna be? And so sitting down with someone and talking about this and setting goals is so important. I don't know why we don't do more of it. And then giving them feedback, constant feedback, not only about what they need to improve, but what they're doing well. Because remember, someone who's junior doesn't know what they're doing well. So having that feedback is great. Positive feedback is so important because if you only come with negative feedback, every time you walk up to their desk, there's gonna be a little ping of fear. I've had managers like that. They only come up to me whenever they tell me that I did something wrong. And so whenever they walk up to my desk, I'm like, oh no. Even if they wanted to do something fun. So don't do that. Give them positive feedback. And then presentations. The best way to learn something is to teach. So if you want someone to learn regular expressions, have them give a 10 minute presentation on regular expressions. If you want someone to learn about your deploy system, have them give a 10 minute presentation on your deploy system. It's pretty simple. I think it's great to get started organizing things into presentations. They can be entirely internal. They can be just to one person. So if someone has a lot of stage fright, they don't have to speak publicly to your company. And then phase four is repeat. So review concepts, check in regularly. Kind of let them electively shadow, let them start to make decisions about their own life, how they want to learn things, how they want to grow. Let them co-pilot a larger project. So let them work with someone who's more senior, who has an emergency break on the passenger side. But also remember that junior engineers go really, really well with senior engineers. Because junior engineers are still excited about the mundane tasks that senior engineers don't want to build. So you put them together, and you have one person who's so excited about getting all of these introductory tasks done, and someone else who's so excited about not having to do them. And then beyond. The assessment category is really important. Well, assessment and apprenticeship. So similar to co-piloting, apprenticeship is a time-tested tool for people to learn. You basically just put them next to someone else who's really good at something, and eventually over time they learn it. That's how all trades were passed on for a very long time. That's how it works in sports. You usually just pair with someone who's really good at something. And the better the person you're paired with, the better you end up being when it's all over. And then assessment. So assessment can be really tricky because people have wildly different trajectories. Some people just take off, other people have ups and downs. Sometimes people don't work out, and that is a reality. You want to give everyone the best shot possible. You want to have faith in them. You want to give them chances. But you also want to identify when someone is not doing well and when someone is not a good fit for something. Because nobody wants to be unhappy. Nobody wants to be unappreciated at a company. So the better that you can get a handle on assessment, the better off all your employees will be. These are some of the assessment categories that we originally came up with. So confidence, code quality, communication, judgment and technical knowledge. Judgment is a huge one, especially in junior engineers. And I wish I had some sort of objective scale for measuring that, but I don't. Communication and confidence are also really big. And then code quality and technical knowledge are actually only two of the five that we came up with. Okay, so that is my overview of technical onboarding training and mentoring. The main takeaways are that onboarding aims to make people productive, independent and confident. It benefits everyone in the long run, the individual, the company, the company's bottom line, the team. And it also is really helpful for diversity. And anyone can be involved in onboarding. So however many people you have on your team, no matter what level of seniority, they can all be involved in training. I work for a company called Runscope, and we have these cool t-shirts. So if you want one, you can come find me. We build dev tools to help people inspect their feelings. I'm kidding, it's, it's de- I wish, that would be really awesome. It's dev tools to help people inspect their API requests. So anyways, if you want a t-shirt, you should come find me because the t-shirts are pretty funny. And thank you so much. I think there's two minutes for questions. There's also a repo on GitHub that has some of this information. I need to update the slides, but it has some assessment categories and how you can think about assessing people based on all of the things that I mentioned. And you can also tweet at me if you feel like it.