
Ask HN: Best practices for onboarding new employees? - mud_dauber
I&#x27;m starting a new gig as a product manager with a startup in a few days. ~20 employees (most but not all in one building). Good customer traction.<p>I&#x27;m building a personal checklist of onboarding items. It contains the usual categories - hr&#x2F;payroll stuff, phone&#x2F;email&#x2F;slack setups, product details, customer commits&#x2F;requests, risks&#x2F;issues, etc.<p>The main concern is how to be productive from day 1 without being a time suck for the CEO &amp; CTO. 
Does anybody have 1) a shareable best-practice checklist, or 2) a methodology of quizzing my new coworkers?<p>Appreciate it.
======
projectramo
This is how I've seen it done in very small companies:

1\. Greet the new person and ask them what they are doing there? Are they a
vendor? client? someone who accidentally walked in? Oh, they're a new
employee.

2\. Ask them if they know what their job is supposed to be. If not, find them
a spot to sit down while you ask around.

3\. Ask IT to get them a laptop. If they don't have one, send out to get one
from best buy. When they ask what type say "good, but not too expensive"

4\. Ask them how their day is, if they want coffee

5\. Get back to work, forget about them.

6\. Go back and realize that no one knows what they are supposed to do.

7\. Randomly assign them various tasks.

Whatever best practices are must surely be the opposite of this.

At large companies I have seen:

1\. 12 binders full of details about healthcare, policies, what happens if you
pass away and other remote events

2\. Orientation that feels like an abstract business school course

3\. On day 1, you are asked to do something really simple to get your
bearings.

4\. Day 2, you are asked to do something really massive because by now you
must surely know your way around.

~~~
Adamantcheese
Just don't spend 2 weeks on step 5, because that happened to me at my current
job. They completely forgot they even hired me and wondered who that guy was
in that cubicle over there.

~~~
laythea
I cant tell whether you are joking. Seriously. What did you do for 2 weeks?

~~~
pc86
He's on HN on day 3, just hoping it turns into 2 weeks

~~~
harlanji
I would say this, and I can’t find a time period after which it becomes OK.
And that’s fine. Seems you have some covert contracts. I’ve been the black
sheep at several SF jobs, not in on the FB and Slack OFftopic channel fun.
Invited, but not partaking, and eventually being ousted by same people if I
don’t leave first. The importance of a right fit and fail fast mentality. But
it’s a 2 way street. Observe the specimen for a statistically meaningful time
period, or chill and trust the hiring process.

------
lostphilosopher
When I start at a new company I create the "Onboading Guide" I wish I would
have had. I take notes on all the things I had to do and where (and sometimes
how) to do them. I include a "Link Bank" of all the random URLs that no one
knows because they all have them in their history or bookmarks, and all the IT
requests / installs that need to happen. As I continue with the company I
update this doc as things change or new things come up and refer back to it
myself when I need to remember how to do a rare but important task. This is
the third company I've done this at and each time I get a bit better at
creating it, and the feedback I get from new team members I send it to is
really positive. Crucial - This doc is online in a format that others can
contribute to and I encourage new team members (and interested current team
members) to update it themselves.

~~~
nathanaldensr
Haha, I just did this for my current employer. It is really appreciated, too.
Sometimes long-time employees even realize things they need to do that they
should've done during on-boarding.

------
laurentl
What follows is my usual way of working and/or the type of behavior I
appreciate when onboarding someone in my team. YMMV.

1) You're going to have plenty of questions, and a lot of the stuff you'll see
/ hear / read won't make sense at first.

\- Accept this fact

\- When you get stuck on something or don't understand it, make a note of it
and move on to another topic. You'll have plenty to look at anyway.

\- Keep a running list of questions and ask for some dedicated time slots with
your managed / mentor / peers to go over the list. 30 min a day or so should
be enough to go over all your questions without being a time leech.

\- Armed with your answer, go back to the documents that didn't make sense.
Read them again. Is it all clear now? If not, write down new questions.

\- When you're really stuck and can't make any forward progress without an
answer, raise your hand (metaphorically or literally) and ask for help. DON'T
wait for the next dedicated slot - I'd rather "waste" 15 minutes dealing with
an employee issue than have them waste an entire day.

2) You'll see things that surprise you, or don't make sense, or could
obviously (from your point of view) be improved.

\- Write these down as you notice them. You'll be amazed at how quickly you'll
grow used to them and cease to notice them.

\- After you've settled in (a few weeks), raise them to you manager. "I was
surprised by X", "how come everyone does Y", "at my previous job we used to do
Z to manage X"... External feedback is always appreciated (or should be
anyway) and this is your only opportunity to take stock of the issues with an
external perspective.

3) Unsure what to do? Ask what needs to be done. What's the current hot topic,
is there something urgent that nobody can get around to do or has the skills
to handle?

\- There's ALWAYS something (or more likely a huge list of somethings) that
needs to be done but somehow isn't making progress in a startup. It's not that
they're unimportant tasks, merely that there's just too much to do.

\- This can score you quick points with the team, help you get a handle on the
context, and fight the feeling of non-productivity.

~~~
mud_dauber
OP here. Agreed - #2 is great. I've bought a squeaky-clean notebook for the
new gig. Page 1 is already titled "onboarding questions". /fistbump.

~~~
privacypoller
This is good but (and it's a big but) DO NOT ACT ON THEM IMMEDIATELY.

There are likely plenty of things that seem askew or just plan wrong - and
many of them are - but you have neither the understanding or earned authority
to act on them. I love the idea of inventorying things you think are issues,
problems or mistakes then reviewing them after 3,6,12 months (you'll know when
you have the right to question the status quo) and tackling the ones that you
now KNOW are wrong.

A very common mistake of new members of a company or the workforce is to blow
into an organization, shit on everything and destroy any chance of affecting
change. Covey is right in "seek first to understand, then to be understood".

Now if you're a management consultant, do exactly the opposite of the above;
that's why you get paid the big bucks - to rattle some cages!

~~~
acct1771
I'd not say the opposite, just that same process, but much faster, and more
blunt.

------
inertiatic
Assign a mentor and give the onboardee free reign over them. Make sure that
the mentor is okay with it and make it clear to them that this can take as
much out of their time as needed and it won't reflect badly on their perceived
performance. If need be, allow them to be unavailable for X specific hours a
day to allow for uninterrupted work on important tasks but otherwise remain
totally there for the onboardee.

Accept that your employees won't be productive from day one, and they don't
have to. If your employees can be productive from day one on tasks, you're
probably postponing the real onboarding and making yourself feel good.

~~~
kernoble
I have been on both the mentee and mentor side of this, and it's been my
favorite approach. I would add a couple things.

1) Make sure the mentor likes this role, and that they understand it's their
responsibility to guide the new person or to reach out for assistance if
needed.

2) This person should be a peer, but that they should be able assign exercises
to the new hire to advance their knowledge. Maybe this could be pairing on bug
fixes.

Also, I don't know how well this would work at firms where nobody "has enough
time" for this. How does one make the time, or change things so that people
don't feel that way?

~~~
scruple
I recently found myself in this role as the mentor and I really appreciate the
pragmatism of the approach. It wasn't deliberate, rather the new hire lacks
professional experience and no one else knew what to do with them. So, I made
myself available from day 1 and have been pairing with them extensively over
the last few weeks. It's working out well. They are able to take their own
tasks on now and don't require a lot of assistance. This thread gave me the
idea that, now that I am at the end of this immediate on-boarding phase, I
should take some notes and make them available for the rest of the team /
department.

------
privacypoller
You will probably need to push your boss(es) to be accountable but I like to
define 3 broad goals over the first week: what you want to accomplish your
first month, quarter and year (or 6 months). I further break this down into
operational, strategic and personal. It will take you a little bit of time to
define longer term strategic goals so this can evolve over your first month or
two.

I recently started a new role (~ 2 months ago) and here's mine: First 30 days:
* Learn product & team process so I can start to contribute to initiatives *
Deep dive 3 areas * Review strategic roadmap for possible participation First
Quarter: * improve understanding of function area/ application of product to
customer needs * Master 1 core component of product * Map/Plan contribution to
strategic initiative that matches org needs and my skills * Increase
velocity/effectiveness of team contribution First 9-12 months: * Participate
in a cross function/team initiative (like shared components, an integration
project) * Take lead role on a part of the technical road map or strategic
plan (execution)

Observations:

My plan still has some gaps & harder to measure things (vs true "goals") but
is a good baseline and it will evolve,

I had to take the lead in pushing this with my managers, but they were
receptive.

I'm experienced and confident enough to push for this approach; junior or new
employees could easily do nothing beyond the typical corporate "justify your
existence" career plans, which I think would be a real waste.

------
mathie25
What we are doing at my company (we have a general onboarding process):

Before the onboarding: \- we make sure all access has been give to every
SaaS/software/etc needed for the employee to be able to work day one. We have
defined a list of access needed for each job (engineering, finance, customer
success, etc). \- we make sure that we have all necessary hardware (e.g
macbook, screens, keyboard etc.) and that all necessary software/update are
already there.

Onboarding day: \- First meeting is about presenting our company, what we do,
our values, the market in which we work, etc. \- Second meeting is finalizing
the computer setup (e.g. password) \- Third meeting is about security (my
job). I'm presenting security, talking about our policies and etc. It's a
pretty lightweight discussion. \- Fourth meeting is the HR meeting (e.g. sign
the NDA, talk about insurance, etc.) \- Final meeting is a presentation of our
application.

All along the day, we make it clear that they can ask any questions, anytime.

After the onboarding: 1 week after the onboarding day, we sent a survey about
the onboarding day (what did you like, what could be improved, etc.). Only the
Head of HR see this (for confidentiality).

------
halbritt
Check out the book "Work Rules!" by Laszlo Block. It describes the onboarding
process at Google and specifically what impact certain behaviors had on
retention.

It's a useful read and the practices they've adopted can be utilized in any
size company as they're fairly straightforward. Things like: use a checklist,
assign a mentor peer, etc.

------
dirktheman
I usually prepare a laptop with all the necessary software, give all coworkers
a heads up that the new guy/gal is starting next monday. On his/her first day
I show them around, introduce the rest of the staff and cover the basic office
stuff (where to find food, supplies, etc.). I encourage all staff to sit down
with the new guy/gal to get to know each other.

You'll notice that at this point the new employee hasn't touched his/her new
laptop yet. I think it's very important that the new one feels comfortable in
the team before he/she can be productive. So I'm not convinced you should aim
for maximum productivity from day 1.

When I look at the past when I started a new job there were two things that I
hated:

1\. Not knowing who everybody was / feeling ignored 2\. Having to ask all the
time for everything (PC, accounts, passwords, access to office, toilets,
printer, etc.)

Good onboarding isn't hard. Just make sure that the new one feels welcome!

~~~
onion2k
_Not knowing who everybody was / feeling ignored_

We give new starters a map of where everyone sits in the office as part of
their first day paperwork (I drew my own on my first day.. it became standard
practice after that I think). It's goes a long way to helping people know
who's who, plus it means no one has to ask someone to repeat their name if
they forget.

~~~
dirktheman
That's a great idea! Once I couldn't remember the name of a co-worker and
after a couple of weeks it becomes _really_ awkward to have to ask...

------
mikece
A piece of advice I was given once: "Listen with your eyes." Translated: when
you're the new person in management meetings, pay attention to which person
commands the most attention at a meeting. At one previous company when the
owner/CEO spoke, very few of the C-level people would look at him, other
didn't put down their phones. But when the CFO spoke, EVERYONE paid attention.
It was a pretty solid leading indicator that this person had the most sway in
the company. Later experience proved this out: he had the CEO's ear and
anything he requested became official (solid CFO -- what he asked for was good
for the company and the CEO knew it and appreciated it).

------
jaquetheduck
Something I wish the companies did at my last jobs was tell me more about how
the business operates. The first week or so at a job usually overwhelms
employees with very low-level work (how the release pipeline works, coding
best practices) , that it's easy to lose track of what the overall goal of the
business is.

Taking the time to explain some of the higher level processes can provide a
lot of context for why certain operations work the way they do.

I personally like to know:

1\. The history of the business

2\. Which problems it solves well, and which it needs improvement in.

3\. Which problems it has failed at solving in the past.

------
scabbycakes
Take all their time that you need and don't hold back. If due to all your
questions they realize their onboarding process is weak then they'll at least
know they have to put more thought into it. If you avoid asking questions then
nothing might improve.

What's cool though is if YOU write the onboarding process from a new person's
perspective as you go. Someone already working there trying to set up an
onboarding process is maybe going to be blind to the things that new people
might want to know.

I just started as a new dev for a medium-sized company and their onboarding
process was literally a firehose of HR communications about corporate things
and people's milestones and birthdays, a tree of links to various neglected
documents in various disconnected systems ("Confluence for this, Google docs
for that, oh and a treasure chest of MS Office documents and PDF's in
Dropbox"), a neverending series of credentials-related mysteries, and here's a
series of webinars we recorded 6 years ago for stuff we rarely use any more,
watch all of them so you can be out of our hair. Oh and good luck if you need
anything, your IT guy has better things to do than correct your stupid name in
the directory.

Probably pretty typical but coming from small companies it's a total shitshow.

------
DoofusOfDeath
Understand that different new hires have different strengths, weaknesses, and
psychologies.

Some people on the Autism spectrum probably will have more trouble figuring
out, on their own, the cultural norms of the new workplace. E.g.:

\- How okay is it to ask questions vs. figuring out things for one's self?

\- How often do coworkers want to communicate? (Particularly challenging for
remote workers to figure out.)

\- In self-organizing teams, what's acceptable in terms of assertiveness in
self-selecting what to work on.

------
meatbundragon
To answer the question raised in the title, biggest benefit is to assign an
on-boarding buddy to the new employee. The second most recent new-hire in the
same role is usually the best candidate.

For the question in the content of the post, figure out who to ask about each
topic, don't just ask the one person who knows everything - that might not be
the most efficient way to use their time.

------
mikece
A deck of flashcards with the name and photo of some the most important people
in the company, along with some of the most important people relate to the
area of the company in which they will be working is very helpful. Certainly
would have helped prevent me from exclaiming that the company org chart was
"evidence on paper of confusion and lack of direction or vision" to the Chief
Operating Officer on my first day. Fortunately she thought this was funny;
once she walked away and someone pointed out who she was I added "and senior
management is afraid to speak their mind" to the list of problems that company
had. And no, I wasn't fired... worked there for several years.

------
llcoolv
Here is my checklist.

1\. Compile a decent on-boarding checklist. This is best done during your own
on-boarding as you go through the steps yourself. I usually just drop it in a
text file and worry about formatting later. And even then most I would do is
wiki/markdown.

2\. Pick a suitable initial task, which is trivial enough to not throw the
subject in confusion mode, but still spanning through enough of the
codebase/product, as it is supposed to verify how accurately the checklist
from step one was compiled and executed.

3\. Be around to assist at any times and stress your availability - on-
boarding someone is work and it won't do itself.

------
TheBrockEllis
We're all human and changing environments can be tough. My first task as a
manager is to always make them feel welcome and comfortable on their first
day. Everyone can understand the feeling of being lost and unsure of what the
next steps are.

I always detail the stupid things in an email before the new hire shows up.
Where to park, what entrance to use, what to wear, etc. Always make it a point
to greet them at the door on their first day. It can make a huge difference to
see a smiling face first thing when you walk in as opposed to having to talk
to a receptionist to page someone.

------
notafraudster
One thing that I think would be useful is to decide IN ADVANCE a project you
think the employee can accomplish in their first week as part of getting to
know a codebase. I've been thrown into new projects where I'm expected to read
thousands of lines of code and issue histories and then just pick subsequent
issues and feature requests and implement. This kind of undirected noodling is
awful. It can be very difficult even as a subject matter expert to immediately
understand a codebase.

------
j45
Advice I'm usually hired to research, and implement: If you're looking for an
onboarding workflow you will be able to find lots out there. The sales people
will all say they can solve what you're after. Dont believe them until you can
map your proceess out in detail for them in writing. Don't belive their
technical sales person, talk directly to implementers as you will be handed
off 3 times before the project starts and the message will be lost. If you
can't it will be a mixed bag. I recommend looking at a modern hr tool like
bamboohr, or adp workforcenow. For your size something like BambooHR is the
best place to start to start and the price point is solid, and flexible enough
for you to focus our as you go.

Key feature: A tool like Bamboo (I'm not affiliated) will create onboarding
checklists and tasks for both the employee and internally to complete the
setup tasks as needed. Multiple checklists (global, department and position)
can be attached to each position and are ready for the next hire. This feature
is missing from most hris, onboarding or applicant tracking systems.

I have sytemized and automated onboarding processes taking 21 days down to a
few including external testing and checks. If you have some questions, happy
to chat offline.

------
lefstathiou
We split our onboarding into a few parts. High level below. This is iterative
so I suggest you setup an internal wiki and share so it can grow and adjust to
your company and policies.

Day 0: which we refer to as the internal check list of things that need to get
done. That includes: \- preparing all legal docs that have to be signed \-
purchasing required equipment \- setting up accounts like github, google apps,
etc \- setting up workstation \- installing software on PC

The goal of this process is to ensure that there is ensure the employee is
ready to begin training right away.

Day 1: employee familiarizes themselves with work space, people, office,
emergency contacts, tools, the wikis etc.

Day 2: business training - reviewing in detail all of our products and
services, our customers, our business model, our vision, divisions etc

Beyond this training is role specific.

------
stuntkite
At my current company, I am in charge of hiring and engineering management. We
are a small startup that is doing some very interesting but technically
difficult things.

After my own on boarding process and casually quizzing the rest of the team, I
started to realize that everyone on the team, from their perspective, worked
at almost a totally different company than everyone else. I don't think this
is too uncommon, especially in the early days of a thing, but we had a team
member leave us so I asked if I could do an exit interview. The candid
perspective I got from him was invaluable.

He had a very similar experience to my own, where from day one expectations
felt like shifting sands. I spent a few weeks really thinking about it and
came up with this on boarding plan that we are using now.

I broke it out into 3 months. I then talked to our CEO and head of development
about what they would like someone to know and be exposed to in our company. I
then broke that out into two separate on boarding plans. One was focused on
learning about our customer experience, and the other a technical track. Then
I took a look at our stack and documentation, and started an overhaul to put
easy to read and find docs in a single place and make sure that on their first
day they could type one command and run everything they would ever touch.

On your first day at you start with us I provide the outline of what you can
expect over the next three months, the customer experience track is actually
pretty fun and by the end of month two you are working on an independent study
with our data tools. The technical stuff is pretty light weight, but covers
some of the stranger parts of our system. You're given plenty of time to learn
and ask questions. The first month mostly working just with the developers and
figuring out communication patterns and stuff. The second month you'd take on
a small feature as a champion and work directly with design and product, and
you're encouraged to explore through improving our docs/tests or building one
off prototypes that you think would be neat with our product. By the third
you've been exposed to everything in our universe and hopefully if we've done
our job right, everyone feels like they have agency, know's who to talk to,
and is really excited to work on some interesting and challenging stuff.

The dual on boarding curriculum are in a git repo broken out by subject and
month and tied right to our knowledge base. I personally think creative agency
is one of the most important things for getting the most out of new hires and
setting the tone. So that was kind of the focus of the scaffolding I put
together. You can squash a fantastic asset by being aloof, having confusing
practices, or in general just not being sensitive to how people learn and
being reactive to it.

------
trjordan
Find a way to listen to what's happening around you without being overly
distracting. Bias towards current projects. Here's a couple things I've done
in the past:

\- Sit on customer calls

\- Read whatever approximates the "done recently" engineering tasks: git
commits, Jira, sprint boards, whatever.

\- Show up to meetings you weren't invited to.

\- Take 6 different people out for coffee and ask them all the same 6
questions. Whatever you want to know.

\- Sit on customer calls

\- Set up the product and try to do something with it.

\- Better yet, set up the product and try to do a thing a customer is trying
to do.

\- Did I mention sit on customer calls?

Once you know what people are working on today, it's easier to pick up and
help them. Then you can start in on your own initiatives with credibility and
support from the people you've helped.

------
bcbrown
Ask people to give you demos of what they're building. Schedule 30 minute 1:1s
with as many people as possible, 1-2 a day. Write down what people tell you as
much as possible; even if you don't go back and read it, the act of writing
helps it stick.

------
franzwong
I would try to make them feel comfortable first. Everybody needs to adopt new
environment, know about others' personalities. If you just want productive,
you can just outsource to other companies.

------
caio1982
Don't forget to treat them all as human beings and not assets (and follow
@picardtips on Twitter for other good management/random insights, it's totally
been worth my time).

------
quickthrower2
A who's who list, org chart, and a wiki page of how to set your machine up to
start working (as few steps as possible), plus a few wiki pages of house
rules.

Maybe do something fun on the first day or week to make a lasting impression
that they are valued. Taking a new employee out for lunch is a good one. I
remember the company that did that and I was impressed (you usually have to
wait until you quit!).

------
indescions_2018
Hire someone specifically for the role. Otherwise it will morph into an all-
day time suck.

The good thing is you actually don't need someone with an engineering
background for this. And that community building skill they acquire can
translate into onboarding new users as well.

In short, its the perfect entry-level position for a candidate with a liberal
arts background who wants to get into tech. Best of luck!

------
dyeje
This is one of those things where nobody can give you the list, you just have
to make it for yourself. Personally I recommend sitting down with the new
employee, get them setup, and record everything you do along the way. This
will be a bit of work, but it really does make the onboarding experience great
and requires only a little maintenance going forward.

------
mathattack
My 2 cents... Create a 1 pager in advance with:

1 - A few sentences on job description.

2 - Key metrics

3 - A list of contacts (including suppliers and customers) they should meet.

4 - A list of things to read.

5 - A list of meetings to tag along to.

6 - Someone who will take them to lunch the first few days.

This gets people who are moderately self sufficient a chance to be productive.

And if you can’t supply a laptop on day 1, you’re pissing money away.

------
drdeadringer
During one series of interviews I asked about their onboarding process. My
question was the first time the person had ever heard the word, let alone what
it meant. Their product was nice, and I am glad I don't work there.

You are ahead of the game against some at the very least by asking your
question.

------
daphneokeefe
As a software engineer in downtown SF, I invite the new teammate to lunch the
first day. Help them relax after a stressful morning. Walk around the block
for some fresh air and to see what food and retail is available. Have a nice
lunch and chill. Refeshed and ready to plunge back in.

------
Klez1993
I liked Sequoia's guide on onboarding :
[https://www.sequoiacap.com/article/the-strategic-value-of-
on...](https://www.sequoiacap.com/article/the-strategic-value-of-onboarding/)

------
vfulco2
I believe trello or one of the other successful business SaaS (zapier or
typeform) have a great onboarding board on trello. A quick google should
surface it. Looked at it 6 months ago and thought pretty comprehensive.

------
slipwalker
from your question, you just got into the company, hence, don't trust much
from your direct employees before you do something to earn their respect. All
of them truly believe to be more qualified to your position than you, a
"newcomer straight out of street", and deserving of a promotion when you
fails.

Find the person latest hired, most close to your position and pay him/her a
lunch, take notes of the next steps ( which accesses are needed, to whom to
speak, how is the politics, who are the known backstabbers, etc... ).

------
spskidmore
Full disclosure I work on Greenhouse's onboarding product, Greenhouse
Onboarding.
[https://www.greenhouse.io/onboarding](https://www.greenhouse.io/onboarding)

A lot of people on this thread have illustrated the cracks that new hires can
fall through when going through Onboarding. I don't have a list, but can share
some general thoughts.

\- Make sure everyone is aware of their responsibilities for the new
hire:(sounds like you're doing this with the checklist). At a small company
most of the responsibilities will probably fall on the Manager. Make sure the
manager knows what's expected of them, send them calendar reminders so they
know they have to meet the new hire in the lobby at 9am on Tuesday (as
example). Add a reminder that the Manager, or whoever, has to at least have
the computer in the office on the first day. Ask the manager to set up
30/60/90 day progress check ins. You end up being a task master, but it will
pay off when the new hire has a smooth and pleasant onboarding.

\- Engage with the New Hire before day one: At a minimum send them what to
expect on their first day or their first week. A common thing I've seen at
other companies, is that a lot of time and money is thrown into recruiting,
and then the offer is made, and the candidate doesn't talk to anyone until
their first day. Don't do that. The candidate has no idea what's going on, and
it looks like you don't have your stuff together.

Instead use that time to keep them excited about their choice to join your
company. What's your company culture like? What are some fun things they can
look forward to once they join? What kind of problems will they be solving in
their new role? List that stuff out and let the new hire know about it prior
to day one.

You can also use the preboarding time to check off some of the mundane tasks
that take up hours on the first day. Send them e-signature docs, benefits
info, the damn alarm code instructions, prior to day one, so you don't have to
sit there and watch them read documents for 4 hours. (obviously some paperwork
will have to be done on site).

\- Make it about more than logistics: The other common thing I see happen is
that companies think onboarding is about getting an i9 signed, and a computer
set up. That's definitely a very important part of it, but onboarding should
be focused on setting the new hire up for success. That means ingraining them
in the company culture, and helping them understand what success in their new
role looks like. Are you making sure they meet people in other departments or
on other teams, so they can start to build a friend network in your company?
Are you laying out 30/60/90 day goals for their role so they have a clear idea
of what's expected of them? Is their manager scheduling regular 1x1s? Are you
(the defacto people team) following up with them to make sure everything went
well? Are you assigning a buddy to your new hire so they have someone to go to
when they don't know where the extra paper towels are kept, or don't
understand how to load the dishwasher? Basically, think of onboarding as
building a support system for your new hire so they don't end up falling
through the cracks and sitting in a cubicle for 2 weeks by themselves.

Hope this helps!

------
hemantv
You should look at www.rippling.com

------
the_bear
My company is about the same size as yours, although we hire a lot of interns
each summer so we've probably onboarded ~40-50 people. Here are some things
I'd suggest:

First off, I'd suggest that you change your stance on whether or not they
should be productive on day 1 and whether or not they should be a time suck
for the CEO. At a 20 person company, if the CEO isn't personally owning
hiring, culture, and onboarding, then they're not doing their job. New
employees are super expensive, and it's a no-brainer to invest an extra week
or two of work to help set up long-term success. I'd suggest optimizing for
how productive they are at ~3 months rather than on day one.

For us, the first ~week is pretty much full-time onboarding. That doesn't mean
they're always doing stuff (no one can absorb that much information) but it
means we have a pretty defined schedule for that first week. It's a mix of the
following:

\- General company onboarding: this is mostly me and one of the other leaders
at the company telling our story, explaining our industry, talking about how
most startups work and then contrasting that against how we work. Going over
the employee handbook with everyone, etc. We've found that any more than an
hour per day of this type of thing turns new hires into zombies, but if you
spread it out (normally 4-5 hours over the first week) they find it really
valuable.

\- Job-specific training: For developers this means getting them into the code
base (we normally do a lot of pair programming the first week or two until
they're up to speed). For support it means learning the product, answering
sample contact forms, etc. This takes up the majority of their time.

\- Getting to know the team: we schedule several activities to give new hires
a chance to meet each other (if more than one person starts around the same
time) and the rest of the team. Their peer mentor takes them out for coffee.
They play board games or darts with various members of the team just to get a
chance to chat. We have company-provided lunch once per week, send them on a
scavenger hunt so they get to know the area around our office, etc.

\- Brain breaks: starting a new job can be really stressful, and most people
are too nervous to admit that they're exhausted and aren't really retaining
new information anymore. I'd suggest building in at least one 30-minute block
each morning and each afternoon (maybe even more than that) for them to just
go off on their own and read a book, mess around online, etc.

It took us a few years to refine this, and I'm sure your approach will be
different. But I guess my main piece of advice is to just give up on the hope
that this won't be disruptive. Whoever is primarily responsible for onboarding
(ideally the CEO at first, or the new hire's direct manager once the process
is worked out) should just cross off the first week on their calendar. Even if
you don't know what you're doing, you can overcome almost all possible
problems by just putting in face time and actually giving a shit about the
person you just hired.

------
funkjunky
Maybe this isn't quite what you are asking for, but after overhauling the
onboarding process for my last few gigs, these are my broad takeaways:

1\. There should be a clear, linear progression of items for all newhires to
"hit", along with expected timelines for each item. No "fanning" until they
are out of the onboarding woods.

2\. Everything should be documented. The first item from #1 should be a
landing page that outlines and links to every onboarding topic, list, or
general reference point, in order, and grouped logically. This page should be
the one and only place any newhire needs to go to figure out what they need to
do, or what they need to know, about anything. Docs should also include team
workflow, best-practices, and tips from previous newhires.

3\. Checklists are better than lists. Everybody has a tendency to get lost.

4\. To the extent possible, all access credentials and account registration
should be centralized to a federated SSO account, and should be automatically
handled with minimum input needed by the newhire. They should only have to set
up their password and 2fa, and everything else should be automatically ready
to go by the end of the first day. Again, this is the ideal, and the only
place I actually experienced this was at Google. All HR B.S. should be done
before the first day, or by lunch on the first day at the latest. Newhires
should be able to hit the ground running.

5\. Other commenters mentioned the importance of newhires to keep detailed
notes. Notes about what seems confusing, or strange, or important things
learned, or ideas for improvements. Every. Day....Every. Thing. New employees
are an EXTREMELY valuable resource, simply because they are the only ones with
a fresh, external perspective of everything going on. They should be keeping
detailed notes, and managers should be following up with them and their
observations/questions at least once a week.

6\. Newhires should be assigned a "mentor" they can go to for questions about
this or that, and that mentor should be one of the previous newhires that just
got through the onboarding process. Not only will they be closer to each other
in the "beginner" perspective, but this forces junior employees to get
teaching/leadership experience very early on, forges stronger team bonds,
reduces the likelihood of shy newhires from falling through the cracks, and
helps distribute the handholding load normally bore by senior managers and
employees that are probably overworked with more important stuff as it is.
Even if all the mentor can do is link them to docs or point them to who better
to ask, that is enough.

7\. Newhires should be responsible for improving and updating the onboarding
documentation, for the reasons outlined in #5. This should be one of their
first projects.

8\. Part of the documentation should also include a list of "go-to" people or
teams for certain topics as well. Half the battle of getting one's bearings is
knowing who to ask about this or that, and I've only ever seen this passed
down from oral tradition.

9\. For the more technically inclined, one should have automation scripts to
get their workstation setup the way they like as quickly as possible. Here are
mine as an example: [https://github.com/thefunkjunky/gs-
dotfiles/](https://github.com/thefunkjunky/gs-dotfiles/) . This would normally
take me days to do manually.

10\. There should be a reasonable and steady progression of tasks/projects for
newhires to complete to get them accustomed to the job, the technology, and
the general team workflow. One tiny practice project followed by "ok now
here's the job, good luck" is unacceptable.

11\. Not only should newhires be asking a lot of questions, but managers and
other team members should be asking THEM questions as well. Make sure
everybody on the team is getting familiar with each other and taking time to
reach out. Most newhires will be shy, and it is up to everyone else to make
the effort. Also, try to fit in a team social thing like beer fridays or
something the week a newhire starts so they can get comfortable with the team
outside of the context and pressure of work.

12\. "11" is a weird place to stop, but I'm supposed to be working, so here's
a "12" to make this list a nice even number. I suppose that's enough to chew
on for now.

------
ptrott2017
See here for templates that might help pull somethings together:

[https://www.smartsheet.com/free-onboarding-checklists-and-
te...](https://www.smartsheet.com/free-onboarding-checklists-and-templates)

Assuming you have HR/IT set up and onboarding guides done and the general
intro to company stuff set up etc: I have found the following to be helpful to
getting team productive but your mileage may vary:

For engineers -intro projects with assigned mentor. short project (from few
days to a week) on a specific small feature that is designed to take them
through all tooling, codebase and environments that you use. Idea is to expose
new hire to development environment in a controlled way, give them a chance to
learn, document their frustrations/questions, discover who to ask, how to ask
(e..g do you use slack, in person etc), how peer and code review are done etc
and get them productive with a win that contributes to the product.

It takes time to set up - but its worth while and if you know your onboarding
- its easy enough to review sprint plans and id suitable tasks ahead of time
and after you do it a few times it becomes routine and expected.

For marketing team - similar usually get them to review a marketing plan in an
area they are going to be working in and how that fits across marketing tools
and evaluate it and present insights back to team at following weeks marketing
meeting. Same idea - expose them, get their insights and get them talking with
their team and have them work on something that is needed.

For sales team - take them through structures sales training: Product,
customer value prop, competitive analysis, target customer profiles, critical
problems we solve, scenario role play finishing with sales and product
qualification (ie have a test they must pass so you know they have a minimum
level of product and target customer knowledge)

For all new hires assign a mentor - person who will help them through their
first week and first weeks tasks. At end of on boarding Ask new hires to rate
their mentors and the onboarding process - you want your onboarding experience
to be positive for everyone and you want it to get better.

You will be tempted to have recent hires mentors the next in- since many
things will be fresh in their memory- this works but its also useful to remind
established folks what entry is like and expose senior team to new team
members and map mentors to incoming expertise (e.g. some senior engineers may
know a specific area of codebase so will be a better mentor for that position
etc) so don't do it exclusively.

with any new hire - do a end of day 1, mid week and end of week check in to
make sure all is going ok and they have opportunity to ask questions/follow up
(it is surprising how many HR questiosn come up on day 4).

This sounds like a lot - but its worth investing in it. Most onboarding sucks
- it shouldnt.

