DjangoCon 2014- Technical Onboarding, Training, and Mentoring

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!