
Optimize Onboarding - tekdude
https://staysaasy.com/management/2020/08/28/Optimize-Onboarding.html
======
pathseeker
>It takes roughly 2 weeks to form a habit; it takes roughly two weeks to get
comfortable in a new environment. A common mistake is to treat a new report’s
first couple weeks like college orientation - social, light hearted, get-to-
know-you stuff. If your report spends the first two weeks reading C#
documentation and having lunch out on the town with the team, guess what,
they’ve just normalized that behavior as what the role is.

Humans are not dogs. I've worked at companies with both styles of on-boarding
(two weeks of doing nothing vs jumping right in). The output in a month was
realistically no different.

~~~
bsder
Quite so. In addition, as a manager of a new employee I make an absolute point
of being a "helicopter mom" from the moment they hit the area until about week
2 or 3.

Payment at the hotel _will_ foul up. I want overcharges and idiocies on my
card and not on my employee's.

Access cards and tokens _will_ foul up. I need to meet the new employee the
first day on the morning and probably for lunch.

Network account provisioning _will_ foul up. I need to see what the problem is
and go escort the process through.

Lots of people _will_ blow them off for asking beginner questions. I need to
be around so that people answer the question properly.

The _presence_ of a manager means that everybody who normally just fluffs off
onboarding will pay fscking attention.

As for timelines, it takes about three months for a new employee or intern to
no longer be actively hazardous. It takes another three months until they
become a positive force for productivity.

Yes, during that time they're doing something useful otherwise they won't
learn, but they're generally a productivity drag until about 6-8 months in.

~~~
no_wizard
I 100 percent agree that it takes up to 6 months on average for most
developers to become super productive in a code base and at least 2 months for
them to be at the comfortable but still not sure on everything phase.

I also agree with the helicopter aspect as well, that’s a key insight on your
part and I bet your team likes your mangement style (mostly :)

I dislike when employers don’t structure their expectations accordingly. I
once worked somewhere where we almost lost one of our most talented developers
(in terms of productivity and quality and insight, a real rock star) because
initially failed to understand this. Thankfully our director stepped in and
made it right.

Great lesson to have learned early in my career

------
interrupt_
I once got told by a manager that they didn't expect new hires to make big
contributions in the first year. That was after I complained I was feeling
very unproductive and wanted some help to speed things up. I quit after a few
months because the slowness of everything around me was making me depressed.

This was at a top5 website company.

~~~
laurent92
But this is still something we should teach youngsters. Interns this summer
started again they second-day standup with “Yesterday I installed my computer,
and today I’ll finish bug 1”. Which is good until you notice that he intends
to stay all night long and do more than expected, to exceed expectations.

And that is how you burn out. In fact, exceeding expectations takes a lot of
talent, because you need to exceed in the correct directions. And often, you
burn out because of the lack of recognition. It’s a real talent that takes
years to learn, not the kind of heroic behavior that someone should strive for
in year 1. In year 1, just learn 3 frameworks at home and change jobs often ;)

About the intern: By the middle of the second month he settled down to
developing the minimum features that satisfy a maximum of users, but polishing
the bugs and buffing out the UX (first impression, etc) and that was awesome,
by the third month he was productive at this and came back to school. Damn I
didn’t notice he’d learnt so much, but totally outside of programming. I guess
the lesson is programming is long if done correctly, don’t expect to do
everything by tomorrow or you’ll risk lowering the quality.

~~~
PragmaticPulp
It's important to teach juniors the importance of avoiding burnout. As a
manager, it's not very difficult to gauge burnout by keeping an eye on time
spent in the company Slack, when e-mails are spent, timestamps on commit
messages, and so on. More importantly, building a genuine relationship with
the employee is important for keeping the conversations open.

Having someone try to stay all night to get work done on day 1 isn't
reasonable, obviously, but I wouldn't go so far as to discourage people from
trying to exceed expectations. I'd always love to tell young people that they
should relax, never work more than 40 hours per week, never stay late under
any circumstances, avoid on-call, and so on, but then I remember that much of
my early career success came from exceeding expectations when the situation
called for it. That doesn't mean everyone should be crushing it 100% of the
time or sacrificing themselves for the company, obviously, but in the real
world it often requires going above and beyond if you want to move up and get
ahead.

Many interns have no baseline, so they're constantly in fear of getting fired.
I think it's most important to set clear expectations and to provide constant,
honest feedback. Once they get over the irrational fear of getting fired, they
can start deciding how much, if any, additional effort they want to put in to
the job. I'd be lying if I told the interns they're all guaranteed return
offers, so I can't honestly tell them that they don't need to do better work
than their intern peers. It's best to explain the situation as clearly as
possible and let them make their own decisions.

~~~
bigfoot675
I'm interested in why you stuck "avoid on-call" in there. I'm about to start
my first on-call rotation next month

~~~
bregma
Nice. You're about to learn why to avoid on-call in the most practical way
possible.

~~~
ornornor
Haha, that’s the best response I think.

------
tekdude
Personal anecdote: Started in a developer position a couple years ago to work
on an internal corporate app on an isolated network.

Week 1: Get to the desk; meet my neighbors; submit request for necessary
network account; and start on mandatory security training for the systems.

Week 2: Finish the mandatory training; ping the network owners a few times
about the account request; start reading up on unfamiliar parts of the stack.

Week 3: Continue pinging network owners about the account request; ping my own
manager about the account request; stare at the workstation that I cannot log
in to; ask around, "Is this normal?" "Yes."

Week 4: Do some more newly assigned mandatory training; ping network owners
and manager again.

Week 5: Finally get the network account!

~~~
jeffbee
I recently started working at a huge financial concern and it was 12 weeks
before I got my laptop in the mail.

~~~
yjftsjthsd-h
I just... What did you even _do_ in that time? (Sincere question; if I started
a job and didn't have a machine I don't think I could work, and I assume a
financial place won't let you BYOD)

~~~
jeffbee
That's the crazy thing actually, virtually the entire company is BYOD with
Citrix access to a Windows VM hosted in a datacenter. Only software developers
need a specific machine.

I spent the whole time watching compliance training videos, no joke.

------
seneca
I once started as a senior engineer at a company most folks here would have
heard of and was told on arrival that every engineer first has to work a short
period in support. The idea was to learn the product and customers.

In theory this sounds like a good idea. In practice, it was a poorly thought
out system that left me frustrated with the company, disconnected from my
team, and looking for a new job before I even finished the half implemented on
boarding process. It felt more like a hazing ritual than a useful learning
process and completely soured me on the company.

Doing support isn't something I find particularly egregious, but you should
absolutely not segregate new hires away from their team for a long period of
time immediately after hiring them. More generally, you need to equip new
hires to do their job as soon as possible, less you risk smothering their
enthusiasm for what they were hired to do.

~~~
doteka
An old employer did this, but instead of just at the beginning this was a
monthly rotation thing (3 days each month or so). Being forced to do support
definitely was a major factor in my quitting. I don’t even mind support so
much, used to do it for a job in university. But you don’t hire a highly
educated professional and stick them in an entry tier role part of each month,
not if you respect them.

------
dougdonohoe
I agree with pretty much all the OP has to say.

In my experience, onboarding is something that is usually an afterthought, if
it is considered at all. Which is why, when starting from scratch as CTO at
two companies, I set it as a top priority from day one. In both instances,
onboarding was optimized as much as possible. In one company, we used Okta,
and 90% of accounts needed to be productive (Git, Jira, Confluence, the HR
system, etc) were auto-created prior to the start date. We reduced, as much as
possible, the need to manually create or request access to needed systems.
Instead, based on your job function, we already knew what you would need
access to and automatically made those requisitions. I realize this is easier
to do when you are starting from scratch, but it demonstrates that it is
feasible. It’s simply a matter of will and valuing the importance of a smooth
onboarding experience. After all, you spent a ton of time and money finding
this candidate - why not get them productive as fast as possible?

Setting up the development environment was also scripted. We had scripts for
setting up and installing the tools needed for frontend and backend
development. Common aliases and scripts were shared via a shared “dot files”.
In most cases, it was possible to checkout the relevant repos, run unit tests,
commit code and deploy to production on the first or second day. There is no
reason one can’t have all you need ready to go on day one. Certainly things
get out of date as time passes, but the expectation of every new hire was to
improve the documentation and fix any flaws. This “onboarding as code”
mentality also made it easier when an experienced engineer needed to set up a
new laptop. Documentation is like a garden - it needs to be constantly weeded
and pruned.

Finally, there’s the matter of learning the tech stack, code base and current
toolset. Again, this needs to be a deliberate, well thought out experience
rather than an ad-hoc, thrown into the deep-end of the pool, sink-or-swim
challenge. A manager needs to make it their top priority to figure out how to
get new employees (or internal transfers) up to speed and confident as quickly
as possible. This requires special skills in writing good documentation and
figuring out the various learning styles of engineers.

I agree - if you onboard, and struggle getting code to compile, can’t find the
right documentation about how things work - then it sours your experience with
the company. In some cases it feels like onboarding is a struggle and it’s a
badge of honor to have survived. That you “made it through” and “paid your
dues.” This may work with certain engineers, but I don’t think it is healthy
or wise.

~~~
hinkley
For me setting up my dev tools was always part of orienting myself. It’s
foreshadowing of what’s to come. Oh we’re installing this tool I bet that
means yada yada.

If you want to install and set up Office, Chrome, a virus scanner, backup and
VPN software then more power to ya. Having dev tools automated might not save
all that much time overall.

------
blululu
This article rings true, but I can't tell if it's a chicken or the egg
problem. Are firms with long on boarding processes less effective because bad
habits are setup and normalized at the start, or are they dysfunctional from
the get go and dysfunctional teams setup poorly thought out onboarding
processes. At a previous job at a large tech company I was given a period of
~6 weeks of onboarding. This was rather excessive, but the organization did
not have a clear sense of what needed to be accomplished in the first place. I
doubt that things would have been more effective if the onboarding simply a
day or two of setup.

~~~
PragmaticPulp
I had the same thought. At some point, loading employees up with structured
activities and obligations that aren't entirely related to doing their job
becomes counterproductive. It can be a sign that the company has lost focus.

My favorite onboarding process was to simply give the person's team a budget
to do whatever they wanted with the new hire for a day or two, then get to
work. Managers would write up a document with all account info, login info,
key communication info, and then let the teams fill the new person in on the
day-to-day details while they went out to lunches or went go-karting or
whatever they wanted.

The more HR tries to structure things, the less effective it becomes at
onboarding people. Let the teams handle it and make them responsible for
getting the person up to speed quickly. They're closest to the work, and
therefore they know best what the person actually needs.

------
01100011
Obviously it depends on the role and the seniority of the new hire to some
degree.

I think, as a senior embedded software engineer, the first couple weeks
(months?) should be spent with the last new hire figuring out tools,
processes, and keeping internal documentation up to date as you go. Questions
should be escalated as necessary, but generally this should not involve much
interaction with more senior engineers so their work is not interrupted. New
hires should start out with big fixing tasks and not be expected to
participate in architecture or feature creation yet. If they display the
ability, fine, but set the bar low.

Some companies I've worked at have such complicated development workflows that
it regularly takes 3 months for an engineer to become independently
productive.

------
hashkb
Getting engineers to commit code ASAP can become entrenched to the point that
it's unhelpful; the tail wags the dog and all of a sudden you're leaving easy
bugs unfixed or small UX issues or whatever to make sure you have "first day"
tickets. Just so you can say "our new hires ship code on day one" or whatever
your flex is.

Does it really matter? Aren't you teaching the lesson that speed is the first
principle?

It's just another excuse to avoid building actual onboarding, whatever that
looks like for you. Too relaxed, too aggressive... are you really doing it
thoughtfully?

~~~
wink
My experience is more that there's always a bunch of tickets/bugs that are a)
not critical b) not 5-minute fixes and c) tend to be "we should really..." \-
those are optimal, because they wouldn't get done otherwise anyway.

~~~
hashkb
That's a serious problem. Whether work gets done should be independent of
whether or not you have new hires around. And what lesson are you teaching if
that's how you complete that kind of work? Onboarding is "hey do this thing
nobody else will ever do, so we can say engineers ship on day one"

~~~
wink
I disagree, it's a much more helpful way to let them explore the code base
than "here, write a test for some feature you also don't understand".

Where I was it was never a stated goal to have them ship asap, the goal was a)
to let them learn quickly and b) let them not hate their new job.

Incidentally, everyone except one person liked this approach. Hands-on, have
the genuine feeling to do something sensible (maybe not important, but hey,
it's your first week) and NOT spend 2w just reading docs.

~~~
hashkb
I think that's a false dichotomy. For example, have new hires pair with
someone who is making good progress on something medium sized and medium
impact. Share in a nearly guaranteed success, learn, and no need to hoard one-
pointers.

------
oxfordmale
Committing code on day 2....I guess the author had never worked for a Fortune
500 company. It usually takes at least two weeks before you get a level of
access that allows you to commit code.

~~~
jrott
I work for a non tech fortune 500 company and was committing code by day 2.
It's really about being willing to figure out what the blocker's to access are
and making sure they are taken care of before hand.

~~~
phist_mcgee
I've heard this a few time about submitting your first PR within one or two
days at a company. It's cool and all for you to get code out there, and if
you've got good CD it probably won't screw anything up, but I know my stack at
work. I know there are nuances, and deliberate details, and designs, and
prioritize and a million other things. How can a person be expected to write a
bug fix and truly understand what is happening, when they may not even yet
full understand the product yet?

~~~
lmm
If you're working at these big companies then working in a codebase you don't
fully understand will just be a fact of life. I worked at a Fortune 500
company for 4 years, but of course I didn't understand even half of the
million-line Scala codebase I was working on by the time I left.

The way you make people productive in that environment is you have, and
enforce, good coding and design standards so that code will do what you expect
and you can rely on parts of the codebase that you don't necessarily
understand the internals of. Frankly, having to consider "nuances, and
deliberate details, and designs, and prioritize and a million other things" is
not a good use of people's mental capacity, and you should aim not to have a
codebase where people have to do that. Write your codebase like a tower of
libraries/DSLs, where each layer presents a solid abstraction to the layer
above it, and the topmost layer is just the business logic written in the
language of the domain; then it's easy to make a simple change to that
business logic because you just have to make the same simple change to your
code.

------
wnd_pn
From a personal experience, the onboarding process should be gradual and
proceeds by steps (which doesn't mean it should be slow). As others said in
the comments, it depends a lot on the role the person has (junior vs. senior)
but starting a new position in a new company can be stressful for anyone. That
is why a business should give its new employees the time to fit in rather than
creating an overwhelming environment around them. By doing so, people will
give their best and the outcome will be higher at the end. An interesting
article I read on the matter is the following -->
[https://hronboard.me/blog/employee-onboarding-best-
practices...](https://hronboard.me/blog/employee-onboarding-best-practices/)

~~~
albigiu
i actually agree

------
bfung
The article doesn't provide good context on WHEN in a company's life to
optimize EMPLOYEE onboarding. It could even be detrimental to optimize
onboarding during the startup stage, when one could've been using the time and
resources optimizing CUSTOMER ONBOARDING.

When the company is like a 10 person startup, find people who can onboard
themselves. When it's like 100 person company, then start thinking about
optimizing employee onboarding. Between the 10 and 100, I'd say find that
product market fit and onboard customers faster than you onboard employees for
a successful company...

------
stevenjohns
This isn’t great advice for technical hires. Maybe for seniors experienced
with the stack, but for anyone else you’d get a lot more mileage out of the
on-boarding process by having them do stack-related tutorials, explaining
things like the deployment process and setting the standard for
collaboration/communication within the team.

Ultimately what it comes down to is that lazy engineers will be lazy and that
motivated engineers won’t lose their spark just because they spent a week
meeting the team. The author seems to think that the opposite is what takes
place both counts. I don’t agree with that.

------
bloopernova
Anecdotally: The best jobs I've had were ones where I was able to contribute
to the team on day 1 or 2. The worst jobs were the ones where it took me 3+
weeks before I got assigned enough permissions to make a single change.

Which goes a little against the idea of slowly introducing trust, but these
were sysadmin/devops jobs, not coding. YMMV.

EDIT: By "best" I mean "most productive, most enjoyable, most memorable". All
accusations of selective memory or bias on my part are of course accepted.

