Yes, so 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 gonna be quite as funny. It's a linear talk, unlike our choose your own adventure story last time. This was 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 okay. 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,

there wasn't any onboarding. I've mostly worked at companies that are smaller than 12 people when I joined, so onboarding is 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. All right, 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, that sounds like a really great engineering environment. Unfortunately, that isn't the case a lot of times.

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 bit more welcoming. I was 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, 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, many things that you would think would happen.

So what they do with prisoners is they give them the right to choose 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 significantly. So basically, you wanna 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, when they think confidence, 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, the belief is really important also. They did a study. So how many of you have heard of the concept of stereotype effect? The stereotype, no, 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 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 these 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 if 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 your own personal qualities, that's helpful. What happened was they saw that everyone's performance improved and there was actually no difference across these different lines. So the stereotype effect is really important. It's this belief that you are good 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? 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 gonna 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 to 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 gonna lose them, and that's really expensive. So having good onboarding, just getting everyone off to a good start, is really important for individuals.

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. Adding engineers to our team is actually decreasing our productivity. This is a nightmare. 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 kinda cut corners, and then six months later, you're like, oh 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, 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, because I played sports for a long time, and I coached 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.

Most of the girls couldn't swim, they couldn't throw a ball. We're talking very basic skills. Playing a full game with all seven players on the field was, I mean, it was like, you know when you watch peewee soccer and all the kids kinda 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 gonna have to work really hard

to build their skills. But that's fine, because if they focused a lot on working together, if they focused a lot on getting things done as a cohesive unit, they could 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 the most popular tools out there were built by teams of less than 10. Gmail, for example, was built by a team,

I think, of like five to seven people. It's maintained by 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. All right, the bonus section, diversity. So, to illustrate diversity, I have Sneetches. The story of Sneetches, it's 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 versus extroverts, 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 on board 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 want to do. Because not everyone wants to go out drinking at 10 p.m. on a Tuesday night if you have a really young party-oriented company. So, you want to give everyone a fair chance

because they're 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 drew all these myself, by the way. Not a very good artist.

Anyone can onboard. And in fact, onboarding should be a collective effort. This distributes the load. One person alone trying to onboard everyone is going to burn them out. Similarly, I was talking to someone about mentorship, and someone 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 who'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 gonna be the ones who just did it. They're gonna still have empathy for what it's like to take that step. They're gonna 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.

We're like, everything's gonna break and it's all going to hell, and I don't know why we care and come into work every day. 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 at 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 gonna 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, 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 gonna go through now is a little bit philosophically about how to do this, but we're also gonna go through some concrete examples and ideas for how you can build your 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 wanna maximize your return on investment? Like, you don't wanna 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 mentoring a junior engineer. Like, 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 gonna do everything together. We're gonna take these courses.

By the time they're done with these three months, they're gonna 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 gonna grow at the rate they're gonna grow.

You can help make that better. You can help focus their path, but you're not gonna 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 mentor again for another year. And your company's like, well, okay, I guess we can't hire any more junior engineers. 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 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 people think it's like 80% of what engineers do. It's probably about a third. Like, another third is the 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. In fact, it's usually the reverse. People who are confident will gain skills at a much more rapid rate than people who lack confidence.

Okay, week one. Week one 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 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 gonna 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, I don't know, some other random thing. This is just the 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 gonna be really important. They're probably not gonna know a lot of things, and you're gonna 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 is just, we're gonna hang out, I'm gonna learn everyone on my immediate team's name, because if I wanna ask a question, it's really nice to know that person's name.

And I'm gonna feel more comfortable talking to the other people on my team. Because a huge amount of what you need when you're new, regardless of level, is just the ability to go talk to someone else on your team. All right, week two. Week two, 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 year and out the other. So I recommend doing history of the company and team map second week. So history of the company. Where did the company come from? Why was it started? Who are the founders? What was the reason that it got here? What's some of the pitfalls that have 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. So go talk to him about that. Or like so-and-so is really good at building fully-fledged feature 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 kind of like a new engineer AMA. So it's the 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 three. 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, I really have 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 on 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, I'm like, yeah, Python is awesome. They noticed. All right, week four. Week four is review concepts, check in regularly, elective shadowing, and start copilating a larger project. So basically now you're just kind of getting set into like a rhythm.

You want to be able to check in with them, you want them to feel as though 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 themselves. Copilating a larger project is a little bit like driver's ed. They can do this with someone who's much more senior, but the senior person really has an emergency break

on their side, so they can give them tasks. Actually, 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 all of these, I don't know, 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 you can get 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 anymore. All right, 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 informal apprenticeships, and you start doing assessments, 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 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 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. All right, 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'll make it easier to onboard new engineers, and for startups who don't have resources, it's gonna 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.