KATE HEDDLESTON: Hi everyone.
Welcome to my talk. I'm Kate Heddleston
and this is Technical Onboarding,
Training and Mentoring.
So I'm a software engineer out of San Francisco.
I do mostly contract work now. Full stack, web
apps. And I work with a lot of really
early-stage start ups. And this was originally written as
a co-presentation with Nicole Zuckerman. She's a software engineer
at Eventbrite. And she couldn't be here today because
she is vacationing in Italy. So I feel not
bad for her at all.
All right. So she's the one on the right.
I'm the one on the left. And, and Nicole
attended a Code Academy called Hack Brite Academy, which
I teach at one day a week. And we
came together to write this talk because we work
at separate companies and had experiences at these separate
companies that were fairly similar.
So, when I was right out of college, I
joined a small start up. I was the sixth
engineer, twelfth person, and I worked there for a
time and it grew a lot, and after awhile,
I reached a certain level of proficiancy. I looked
back and I thought, I could have gotten here
a lot faster with just a little bit of
help and a little bit of structure.
And so, I turned around and created the Onboarding
program at my company. And Nicole had a similar
experience at Eventbrite, and so she has been doing
a lot of work there with onboarding. So we
wrote this presentation and submitted it. It's important to
note that this presentation was written specifically with junior
engineers in mind. However, about 90 to 90% of
what I say can very, very easily be adapted
to people who are more experienced.
All right. What is onboarding? So for the purposes
of this talk, onboarding is the process of taking
someone from outside of the group, outside the company,
outside the team, and making them a productive, independent
and confident member of the team.
And I picked these three characteristics because I think
they're, they're incredibly important. Productivity seems a bit self-explanatory.
It seems kind of like, the goal that we're
focusing on. Like, of course we would like productive
engineers. And it's about creating efficient employees.
Independence, and another word for independence is autonomy, is
about creating engineers that can operate in your organization
without needing a ton of oversight, that can make
decisions and understand your company structure well enough to
not have the overhead of having to go ask
four levels of management for something.
Also, independence and autonomy speaks to this, this need
that we have to have some control over our
own destiny. I was reading an article recently and
it was talking about the need for autonomy, and
it was citing inmates in prisons. So, in a
lot of prisons, inmates are allowed to choose the
channel. They're allowed to rearrange their furniture. And they
found that this drastically reduced rebellions within prisons. So,
independence is important, cause you don't want your engineers
to rebel. But it's also important because feeling independent
and autonomous helps people feel motivated and invested in
what they're doing.
Finally, confidence I think is the most important of
the three. Confidence is about creating employees who believe
that they are valuable. It's not about the actual
act of creating employees that are valuable. The study,
which is at, the links are at the bottom
actually, that I was reading about recently, they split,
this was a gendered study, but what they found
didn't really have to do with gender.
They split the participants into six groups. Three groups
of men, three groups of women. So there was
a control and two test groups for each gender.
And, for one of the groups of men, they
told them, they're doing some sort of spatial reasoning
activity, they told them, men are really good at
spatial reasoning. You should be good at this task.
That group performed significantly better than the control. The
next group of men they told, men are really
bad at spatial reasoning. You'll be bad at this
task. And that group performed significantly worse than the
control. And they found the exact same thing with
women.
And so what this means is that confidence actually
affects how well people perform. So confident people will
perform better in a measurable way.
So why do you care? I assume that everyone
here cares because you came to my talk. But
I would like to convince you that you should
care now. You should care immediately, and that you
should start building an onboarding program at your company
as soon as possible.
And I'm gonna talk about four things in this
session. I'm gonna talk about the individual who's joining
the company, the company that they are joining, the
specific team within the company that they are becoming
a member of, and then there's a bonus category,
which is diversity.
So, the individual. What can go wrong if you
don't have onboarding? Or basically if you don't have
investment in your employees?
Attrition is something that most companies and most of
us are terrified of. And for a good reason.
Attrition can cost thousands of dollars per employee. Up
to 1.5 to 2x their salary. And it's not
that people quit specifically because your company does or
not have onboarding. People quit for a meriad of
reasons. The number one is actually that they are
dissatisfied with their managers. But onboarding can address a
lot of the issues that people ultimately quit for,
or quit because of, and it can address them
really early.
So getting someone up to speed so that they're
confident, they have this upward trajectory, they're building their
skill set early, is going to set them up
for success in the long term, so that eight
months to twelve months down the road, they aren't
leaving because they never felt like they were part
of the team. Or they never felt like they
were contributing. Address this early at onboarding is one
of the best ways to do that.
For the company. Companies care hugely about the productivity
of their employees. This is a graph of productivity
decreasing as you add new engineers to the team.
And, anecdotally, this actually happened at LinkdIn not too
long ago. Every engineer that they added to their
team decreased their overall productivity and ultimately affected the
company's bottom line.
So, when their new SVP of engineering came on
board, Kevin Scott, he had to do a whole
bunch of work revamping their organization, building onboarding. And
this is, I mean, LinkdIn is thousands of people
at this point. So this is a huge amount
of work. To try to get the graph to
look like this. To try to get each new
employee to add value to the company. And this
doesn't have to do with the employees. It's not
like they're hiring engineers that are then negative in
their value. It has to do with their process,
and onboarding is one of the great ways to
make sure that you're taking a good look at
your process.
This speaks to something I like to call team
debt. How many of you have heard of the
concept of code debt? A lot of people. Yeah,
we talk about that a lot as engineers. How
if you build something fast and don't think about
it, you accrue this code debt, and over time
you have to go back through your code base,
take a look at things, rewrite them, and ultimately
address that.
Well, the same thing happens with people. So if
you aren't doing a good job investing in your
employees, if you're not onboarding them, if you're not
training them, you're going to accrue team debt. And
I've seen this a lot. I've talked to a
lot of companies that are starting to get into
the hundreds of people range. They're starting to hit
a hundred engineers. And they're like, oh my goodness,
we need onboarding. We need, we need to get
these people up to speed. And at, at four
hundred people, I mean, yeah. You've accrued a huge
amount of team debt.
Every person that you add and try to onboard
is going to be increasingly difficult. Your code base
is quite large at that point. You have a
lot of teams. And so going and making all
of those onboarding materials at a hundred people is
way harder than starting when you're smaller than a
hundred people and then maintaining it incrementally.
The third aspect is the immediate team that the
engineer joins. So there's a saying that you don't
know something until you teach it. And this is
absolutely true for your company's culture and code process.
So if you don't know how to explain to
a new engineer what your company's culture is or
how you ship code or how you decide what
features are built or who approves things, who reviews
things, then you don't actually know it yourself. And
that's a massive red flag for your company if
you can't explain your process.
Additionally, when people join small teams, small teams fundamentally
change every single time you add a new person
to them. So iterating your team's process to the
new engineer is not just important for them, it's
also important for your existing engineers, so that you
get something that looks a little bit more like
this, where everyone is on the same page.
And because the team changes every time you add
people to it, you're gonna have to reiterate this
to everyone pretty much every time you add a
new employee.
So, something about me, I love sports anecdotes. I
played sports for most of my life. And when
I was done playing sports, I coached JV girls
water polo at a high school nearby. And I
used to have these really deep, philosophical team meetings
with them, and I'd come in with these posters,
and one day I came in with this, a
poster with this written on it. They always just
sat there and kind of rolled their eyes at
me, like.
But, I was trying to explain to them that
their ability to win games was not wholly dependent
on their skills. These girls were beginners. They didn't
really know how to throw. They didn't really know
how to swim. They basically didn't have the skill
set necessary to play water polo. But, they were
playing all these games. And so I wanted them
to understand that their skill set was important, but
team work was more important, so they could actually
beat teams that were theoretically more skilled than them
but didn't work together as well as they did
if they all banded together, because teamwork is a
multiplication factor.
And this is true in engineering as well. Your
productivity as an engineering team is the sum of
the engineering talent that you have multiplied by how
well you work together. So if your team is
working well together, that's great. If not, your team
can actually pull itself apart. And, anecdotally, a lot
of, a lot of products have been built by
teams that are less than ten or five people.
So Gmail is a really great example. It was
built by a team of less than five. And
now that it's successful it's maintained by a team
of over four-hundred, I think.
So our bonus category, diversity. How many of you
have read Dr. Seuss's book about sneetches? Yeah? It's
a great, it's a childrens' poem, like all of
his books are. But it's about this community of
sneetches. And sneetches are what I have drawn there.
And at some point, some sneetches start developing stars
on their bellies. And it's the story about kind
of the rifts that happen in the community as
a result of some sneetches having stars on their
bellies and some sneetches not.
But I like to use sneetches to represent diversity,
cause diversity can mean a lot of things. It
can be gender diversity, it can be racial diversity,
it can be introverts versus extraverts as far as
diversity goes. So communication styles. But the idea is
that onboarding is gonna be really critical if you
want to hire people who are different from each
other in any way.
This is pretty typical in tech. Companies are started
by a small group of people, and it's homogenous.
The phenomenom is called homophaly. We tend to associate
and like to be around people who are like
ourselves. So companies tend to get started as homogenous
groups.
If you don't have any onboarding, the people who
are most likely to be successful joining your organization
are people who are like the existing group. This
is because they likely share similar communication styles, interests
and hobbies. There might be tacit acceptance because they
look the same as the rest of the group.
So what you're doing is you're relying on homopholy
and the existing social structure for peoples' success at
the company and onboarding.
And what you don't want to have happen is
something like this. You hire someone new who's different,
and they feel socially ostracized upfront. Not for any
particular malicious reason, but just because they're different. They
communicate differently. And so what you want is you
want an explicit onboarding structure that helps bring people
into the fold, that helps people become a part
of the team in some sort of systematic way
so that everyone who joins, no matter how different
they are from the existing group, has a solid
chance at being successful.
So, hopefully now you guys are all convinced that
onboarding is super important.
Who at your company can onboard?
So anyone of your team can onboard. This is
not a, senior engineers have to be paired with
junior engineers. They can learn the most. In fact,
going back to sports analogies, some of your best
people to onboard are going to be people, kind
of like if a freshman athelete were to join
a team, the sophomore athletes might be the best
people to help them out.
This is because they have the most empathy for
what they're going through. They also experienced it the
most recently, so they have relevant information and stories.
So your sophomore engineers might be some of your
best onboarders at the company, in addition to the
expertise of your senior engineers.
When?
So onboarding can start as soon as an offer
is accepted. I'm going to talk about an onboarding
plan coming up soon, and we're gonna talk about
from the start date to what I call reliable
independence, which is where this person can build things
and build features to an adequate level and be
left on their own to the same degree as
other engineers on the team.
All right. How?
So, the how category I'm gonna talk about some
concepts to think about, when you're thinking about how
to onboard others. And then I'm gonna launch into
a four-week plan that goes through some of the
specific things that you can do with engineers.
So, first off, the concepts. It's pretty straight forward.
You want to maximize your return on investment. You
don't really want to be putting more into engineers
than you're getting out of them. And most people
don't really want more put into them than they're
giving back. That's kind of a strange dynamic.
So, a really inefficient but really common way that
people try to onboard is this, like, hand-holding model.
New onboarding mentors are really prone to this. They
think, I'm gonna be the best onboarding mentor ever.
We're gonna do everything together. We're gonna do all
of these code tutorials. They're gonna watch me code
every day, and by the time we're done with
three months, they're gonna know everything that I know.
And, in addition to being inefficient, because this is
a huge time sink, it's also unrealistic. People do
not become senior engineers in three months. You need
time. You just, you just do. And so this
burns people out and also disappoints them.
A more efficient way to think abou things is,
my example is bumper bowling, which is pretty much
the only way I should be allowed to bowl.
But, you set up an environment that's constrained, where
they're able to play freely. They're able to go
off and do what they want, come back and
ask questions. But you don't have to handhold them
through things.
And so the way you do this with a
technical environment is automation is huge. So, automating the
development environment, automating deploy. Having a lot of testing
for your code base, however you decide to do
that. Whether it's TDD or not. Will help these
junior engineers have a safe space to learn and
grow and play.
One of the important things to think about, too,
when setting up this environment is that scoping is
critical. One of the tenants of expertise is the
ability to scope. So, if you're an expert, you
understand the landscape incredibly well. So you're able to
set these really well-defined boundaries. Junior engineers, by definition,
are not good at scoping because they don't know
the landscape.
So, when you're thinking about giving them projects and
you're thinking about setting up their environment, make sure
to set boundaries for them and then slowly move
them out as they know more about what's going
on. Because they won't be able to set those
boundaries for themselves.
So, kind of three onboarding categories that map to
the productive, independent, confident thing I was talking about
earlier are technical knowledge, company knowledge and process, and
personal development. I mention this because people think that
onboarding has to do with technical knowledge. They seem
to think that that's 90% of what's going on.
I'd say it's actually about a third, and it's
actually the easiest third, because you can go to
the internet and find a ton of tutorials on,
on Ruby and how to learn Rails and how
to use Rails and blog posts about how to
use any number of technology out there.
The harder category, which is another third of what
they need to know, is the company knowledge and
process. And this is really, really important for them
being independent. They can't be independent if they don't
know how to operate within the company's infrastructure. This
is harder because most companies don't write this down.
So it's in someone's head somewhere, and the junior
engineer, or the new engineer, is tasked with going
and extracting it from whoever on the team knows
this. So the more explicit you can be about
your company knowledge and process, the better.
And then third, personal development. That has to do
with confidence, career trajectories. Again, this is, this is
important because confident people are willing to reach. They're
willing to be outgoing and they're willing to try
new things. They also perform better.
OK. So now I'm gonna talk about a fairly
specific plan. This was written with junior engineers in
mind. So some of the tasks are very specific
to junior engineers, as is the time frame. A
lot of these things will be relevant for people
with more experience. The time frame just might be
more condensed.
So, for week one for a junior engineer, it's
all about shipping code and kind of getting to
know their immediate team. So dev environment setup is
critical for anyone joining an engineering team. The last
person who joined the company is going to be
the best person to get them up to speed
on their dev environment, because they are the one
who knows the most about how to set up
a dev environment. Someone who started two years ago
is probably not going to know the ins and
outs of getting started.
Additionally, you should have a goal about how quickly
you want someone's dev environment to be set up
so that they can reasonably ship code. So like
a config file, for example, or something static. A
great goal is the first week. An awesome goal
is the first day. And, if you want to
try to match, I think it's Debian in the
opensource world, their goal is five minutes, which is
probably a little bit of a reach. But I'd
say the first day is a fantastic goal. If
someone can be set up with their dev environment
and able to ship a config file the first
day, that means that you have pretty great automation
and a really great onboarding process.
The next thing is shipping code. You should ship
small changes and you should teach junior engineers to
ship small changes as early as possible. So, give
them a task as soon as they've got their
dev environment set up and they're ready to go.
Maybe have them fix a bug or rewrite tests
or a small feature that's really well-scoped, so that
they can ship something and be productive and part
of the team as soon as possible. This is
great both for your onboarding process, but also it
helps them feel valuable, which, as we talked about
earlier, is really key.
Journaling and note-taking. People will naturally do this. We
don't memorize all of the commands that we need
to know, and so we'll write them down. Just,
just give them a central place to do it.
Talk to them about it. Ask them about three
things they learned that day or that week. Just
kind of put a communication structure around the fact
that they're probably already taking notes. It will help
you understand what's confusing for them and it will
help them remember things.
And then, finally, have a social event. And do
this for any engineer that joins your team. No
one should join a company and sit off in
the corner alone, not knowing their immediate team mates.
Have some sort of coffee. Have everyone sit together
at lunch. Go out for dinner or drinks. It
doesn't matter what it is. They just need to
put names to faces and feel comfortable asking questions
of, at least, their immediate team. Like, you know,
the five people that they work with. If they
want to ask someone where a pen is, or
the bathroom, or they don't know something really simple
and they feel uncomfortable asking, that's gonna be a
bad experience right off the bat. And this one
is so easy. It's just a gimme.
All right. Week two. Week two is more about
the context of the company, and also starting to
have them shadow and, and learn from more senior
engineers. So, you should tell them the history of
your company. The history of your company hopefully is
a pretty interesting story. The history of your company
is also something they're not really gonna be able
to absorb the first week. They aren't gonna know
the characters in, in the story as well as
they will the second week. So who are the
founders? Why did they make this company? Who are
the people that were hired early on? It actually
is probably gonna tell you a lot about your
process and your culture as well.
Additionally, a team map is fantastic. So if you
have some place where you can put everyone's picture
and name, generally what they do and what they
work on, if you can make it a seating
chart, even better, or put their names above their
computers. People are gonna forget someone's name. They're gonna
forget that that guy they talked to five times
is Andy. And they're gonna be embarrassed to ask
just like I always am when I forget someone's
name after talking to them for five times.
Code labs and shadowing. So code labs are something
that Eventbrite started doing, and this is a really
awesome idea. It's basically a safe space for an
hour once, twice, three times a week, however many
times, where they can ask someone that's more senior
any kind of question they want. So you can
have a code lab for an hour that's on
frontend development. Or a code lab for an hour
on dev ops. And the most important thing about
these code labs is actually not the topic. It's
that it's safe. So when you're thinking about picking
engineers to run these code labs, think about picking
engineers who are going to create a safe space
for these junior developers to ask questions. Feeling stupid
when asking questions is pretty typical, especially when you're
new. You want some place where they don't feel
that way.
Shadowing is also a great way to get people
up to speed. This actually is a great thing
to do at any level. But pair them with
someone who's more senior. Have them sit with them
for an hour a day or a week. And
just watch their process. How do they build code?
How do they get things done? What tools do
they use? One of the things to think about,
though, when pairing people for shadowing, is that we
will forgive a lot of bad habits in more
mid-level or senior engineers that we won't forgive in
junior engineers.
So I've seen this happen a lot where junior
engineers are following someone who's more senior, and they're
doing a great job, actually, of picking things up.
They're learning a ton. And some of the things
they're learning are not so good. And so they
end up getting punished for these habits that they
learned directly from a senior engineer. So make sure
that you take a look, whenever you see someone
doing something, who's new or young, take a look
at where they learned that from. If they learned
it from someone else, try to just encourage them
to go in the right direction.
There's nothing worse, when you're new, than spending all
this time following someone, learning something, and then later
being told that you're doing it wrong. You're like,
well then why did I follow this person around?
All right. Week three is a lot about communication.
Goal-setting. Feedback. Presentations. So for a junior engineer, at
this, up to this point, you've probably been doing
a lot of high-touch interactions. You've probably been working
with them fairly constantly. By week three you can
start scaling back. Give them more independence. Give them
more free time. But set up weekly one-on-ones. This
is a structured, expected thing where they can give
you feedback. Maybe they can spend ten minutes talking
about something they learned this week. You can start
doing goal-setting.
Which, by week three, hopefully they have a better
idea of what they want to do next. Maybe
not what they want to do with their whole
life, but maybe next they want to focus on
frontend. They want to get really, really good at
implementing features for users. Or maybe they absolutely love
dev ops and infrastructure and they want to work
more on that.
So you can start setting these short and long-term
goals so that they feel like they're moving forward.
Feedback is also really important. Give feedback early. Give
feedback often. Some of the biggest complaints that people
have about their managers is that they don't get
any feedback from them. So, as engineers, we tend
to be fairly critical and a little bit cynical,
which I think is healthy. But when you're giving
feedback to someone, especially if they're junior, remember, they
don't know what they're doing well, either. They actually
don't, they don't really have a good idea of
what they're doing that's good or bad.
And I'll give you another sports analogy. When I
was coaching, so I'm coaching beginners. Absolute beginners. And
I'm standing on the pool deck, kind of yelling
things at them. And they'd go to do, like,
they'd go to throw the ball, like they'd go
to shoot and they'd drop their elbow, and I'd
yell don't drop your elbow! And it look like
these kids hit a brick wall. They would just
stop and sink in the water and look at
me. Which I realized was exactly not the behavior
that I wanted from them. What I wanted them
to do was I wanted them to keep their
elbow up.
So I thought about this for awhile, and then
I decided to just start yelling at them all
the things that I wanted them to do. So
I took the words no and don't out of
my vocabulary, which is a really, really fun game,
if anyone wants a hobby. So I started yelling
things at them like, keep your elbow up. Keep
your hips up. And I saw the most amazing
thing happen. They all started doing exactly what I
wanted.
They started, they started moving forward faster. They were
excited. They felt confident. And there was no, there
was nothing except that I just took all of
these negative words and negative phrases out and told
them what I wanted and they did it. So,
when you're thinking about yelling things at your junior
engineers, try yelling at them what you want them
to do as opposed to what you don't want
them to do.
Presentations are also really great for communication. We don't
program in vaccuums. We often work on teams. We
need to be able to communicate technical concepts to
other people in a really clear and concise way.
So make them practice. Give them a topic once
a month, a technical topic, maybe it's regexes, maybe
it's the ORM layer, and have them give a
five to ten minute presentation to the rest of
the team on it.
Week four. Week four, you're gonna continue scaling back.
You want them to be independent. You want them
to be autonomous. So you're gonna continue taking yourself
out. Review concepts. Check in regularly in your one-on-ones.
You can start to tell them things like, if
you hit a bug, I want you to research
things for an hour before you come talk to
me. So set really clear expectations, but have them
go off on their own. Have them do research
on their own. Have them get used to that
feeling of hitting your head up against a wall
because you're super frustrated with a problem. This is
good. They need to learn those things.
Also, make shadowing elective. Let them choose who they
want to shadow and when. So start off-loading decisions
about what they do to the engineer. Also, have
them start co-piloting a larger project with someone else.
The concept is kind of like drivers' ed in
the U.S. In drivers' ed in the U.S., you're
paired with an instructor who actually has a break
on their side, so if you decide to careen
on a cliff or something, they can hit the
breaks and stop you. So pair them with someone
who still has enough control that they can stop
them from doing anything that's really dangerous, but they're
also working on bigger projects now and learning from
someone who's more senior.
Beyond. So, keep checking in on goals. Keep talking
to them. Make sure you have really structured channels
for communication. Start tailoring their projects, code labs, et
cetera to their progress. And this is the part
where you can start doing things like informal apprenticeships
and assessing their progress. Although you should be assessing
it this whole time.
Apprenticeship is a concept that has worked for many
thousands of years in many, many different trade industries.
So, blacksmithing, roof-thatching, I don't know. But at this
point, they should know more specifically what they're gonna
want to work on long-term. So have them be
an apprentice to someone who's more senior at this.
So if they want to do dev ops, they
can go work on the dev ops team with
a more senior engineer, and they might do a
lot of grunt-work tasks. They might do a lot
of the things that no one else wants to
do at this point. But they're learning. And as
they learn and they grow they get more involved
tasks, and they get to solve more exciting problems.
Assessment. So you're gonna see wildly different trajectories with
people. And hopefully the more systematic your process gets,
the more you're able to deal with this. But
some people are just gonna take off running and
they're gonna be fine. Other people are gonna have
ups and downs. And so you're gonna want to
have some sort of way of assessing how they're
doing. And when someone's not doing the way you
expect, the answer isn't always they're a bad programmer.
In fact, we came up with five assessment categories.
Confidence, code quality, communication, judgement, and technical knowledge. And
this is just a start. If someone is afraid
to ship code, they might lack confidence. And so
helping to bolster their confidence will see huge results.
Additionally, if they're building features that don't make sense,
they might lack judgment. And in order to have
good judgment, you need a lot of context about
who uses your product and why. So maybe they
should go spend more time working with customer support
and answering support tickets so that they can learn
how people use the product so they have better
judgement. Sometimes they just need to learn more about
a particular tool, and that one's pretty easy.
OK. Hopefully you guys have had a fair number
of take-aways. Hopefully you now know about the concept
of team debt. You're thinking about doing an onboarding
plan now. But, if you take away only three
things, I hope you take away these three things.
First off, the goal of onboarding is to make
people confident, productive, and independent. Reliably independent. And so
that can have to do with their level. But
it's not about making someone into a senior engineer
overnight.
Second, onboarding benefits everyone in the long run. It
benefits the individual joining, it benefits your company's bottom-line,
it benefits the productivity of the team, and it's
also great for diversity.
And finally, anyone at your company can be involved
in onboarding. So, as I said before, some of
your best onboarders are not gonna be senior engineers.
They're gonna be the people who were just junior
engineers themselves.
OK. So, start improving your onboarding process now. There's
actually a code repository, or not code, but just
a GitHub repository that has some assessment rubrics. It
has the plan in a lot more detail. It
also has some tools for, for learning, like, online
tools for learning Ruby and Rails. And if you
have questions, feel free to ask them now. If
you are terrified of yelling questions out in a
pubilc forum, which I absolutely am, you can come
find me later. I'll also be around for the
rest of the conference. So thank you.