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!