
Ask HN: Best/worst way to onboard new employees? - ajuhasz
We’re hiring our first engineering employee and wondering if anyone has any advice on how best to onboard them?<p>Any great tips?
Anything to not do?
What’s the best first week experience you’ve had?
======
osullivj
1\. Start by personally introducing the new hire to all team members. This
helps them feel comfortable approaching them later on to ask questions. 2\.
Ask them to write a "how to set up a new dev env" wiki page. The next new hire
can improve it. 3\. Give them a handful of medium priority bugs to fix. Not
critical as its too early, and not trivial as that won't drive learning. A
nice mix of bugs should take your newbie to all major parts of the system, and
require them to develop understanding in a way that new code often doesn't.
The bugs should also drive conversations with the original authors of the code
that will help knowledge transfer.

------
dudul
It may be superficial, but when I show up on my first day I want my desk to be
ready. I don't want to spend my first 2 hours on the job chasing for a
keyboard, an ethernet cable, etc. Same with all the credentials to access to
the git repo, or the bug tracker, or the inbox, and etc.

In your case it may not apply if it's really your first tech hire.

I guess spending some time to give a tour of the industry, then of the share
of the market you're going after, then of your product.

~~~
ajuhasz
We decided to give everyone a laptop so hopefully we just need to hand her the
wifi password and she can enjoy the unboxing and new laptop smell!

Great idea on giving an industry/market intro! I was also thinking of trying
to give a large overview on a whiteboard of the architecture of the entire
system then slowly cover each area so she has an understanding of how her
pieces will interact with everything else.

Do you feel it's important to have a production-running commit (no matter how
small) in the first week to start feeling ownership?

~~~
dudul
Regarding production-running commit - No, not really. She should definitely be
working on something serious before the end of the first week, but it doesn't
have to de deployed necessarily. Depends on the type of product you have. If
it's a SaaS with rolling release, sure why not.

------
AnimalMuppet
How about the worst first week experience I've had?

On day 1, I got a cubicle, a chair, and an ID badge.

On day 2, I got a trash can.

On day 3, I got a phone.

On day 4, I got a computer.

On day 5, I got network access.

Moral: If you're the hiring manager, _don 't be on vacation when your new hire
starts._ If you're going to be, make sure that someone is going to handle it
for you.

Full disclosure: This was a decade ago, so I may have the exact details a bit
off. It's pretty close, though.

~~~
Spooky23
I had a first day where I was given a pentium-66 desktop (this was 2001) that
wouldn't even log in.

My boss told me my real PC was swiped by somebody and that I should "look" for
another. So my first official act was to misappropriate a gx110 being staged
for delivery to another unit.

------
kleer001
In all my new jobs I've appreciated most the solicitous and social first day.
The ergo team came to my desk and made sure I had all I needed for my body to
work well, I was introduced to my team, a couple of senior peeps went out to
lunch with me, I got a tour of the studio, etc...

What really sucked, and it's probably obvious, is the time when I had to
search out all my information: where I was sitting, who to talk to to get ergo
stuff (and worst of all when they required a doctor's note for whatever), who
my manager and coordinator were, heck who my whole team was.

Not entirely on topic, but the same place also treated me like an anonymous
cog: was interviewed for one project, told on my first day I would be on
another, ended up on a third for two weeks, went back to another (didn't have
anything to do), and then bounced two more times before they ended my contract
a month early. Ugh, never going back there again.

~~~
dudul
Damn that sounds too familiar :)

Yeah the whole "fetching everything single piece of information" on the first
day kills me all the time.

\- "Here is the git repo" \- "It says access denied" \- "Oh yeah, talk to Foo
to get credentials, just IM him" \- "How do I connect to IM?" \- "Oh, go see
Bar to get an account"

It always sets me on the wrong foot.

~~~
kleer001
Yea, work does not need to be an RPG. That's just lazy administration. I think
it happens eventually with most companies over a certain size, they can
disregard the little things, or I guess they stop having the need or ability
to address the finer things of human interaction.

I think it could be argued that information is best kept at a need-to-know-
basis, but I think that also is a cold strategy, you know, not very endearing
(who needs to work to be nice). Or it could be a trade off against pedagogy.
Not everyone likes to have their hands held all the time. Then again this is
just day one.

Abstraction? Is it that the size of a company is in proportion to how dry and
abstract its thinking becomes?

From my arm chair economics view I've always been a fan of limited lifespans
for corporations, instead of their true immortality (senescence not required).

------
Ologn
Prety much what the others have said. The desk should be ready, the phone if
they have one (with voicemail password and instructions), the computer, their
email and necessary passwords, necessary passes to the building. They should
get their HR and finance stuff done and not have their first paycheck delayed.

They should be given something to do, even if it is busy work initially, like
reading whatever existing documentation you have on your setup. They should
also be given the means and clear direction to do that work. For the next week
or two, their official or unofficial lead on the team should answer questions
and check in every hour or so on what progress has been made on the initial
assignments, inevitably they are missing some password or permission or
explanation of how things are set up at the company.

The key is to have everything ready for them, be open to questions, and
helpfully check in every hour or two for the first few days to see how things
are going. Usually I have 100 questions, but after question #30 figure I
should pace myself before bothering the lead or manager again with yet another
question. But if they approach me in a helpful, friendly, unrushed manner and
ask if I have more questions or if I am stuck, then I will get all my
questions out faster.

------
cweiss
Something my team started recently that we rather like is to put together a
Kanban-style board (Trello would be perfect for this - we used Taiga as the
tool had to be in-house) with cards like "How do I do build X?" and "How do I
troubleshoot Y" that have links to our Wiki pages that cover the relevant
topics.

New team members go through the board moving cards from "New" to "Done" as
they research/answer the questions. In theory, once they're done, they should
know all the major information needed to do their jobs. This is a win in both
directions as it also forces us to write high-quality documentation. If the
person gets stuck, they generally have a good idea who to bug (the most recent
author of the page) for clarification.

For a first employee in that particular space, it would be a valuable exercise
for them to start building that deck and the associated documentation. It
might make the "time to first code contribution" take a little longer, but
should pay dividends in reducing mistakes.

------
euroclydon
Since it's your first engineering employee, I'll assume you're a small startup
and not a large company who's just getting into engineering :)

Since you are so small, you need to consider all the resources you don't have,
likely HR, Reception, Admin Assistants, any history of what information to
give a new employee, detailed knowledge of how your benefits work.

This employee will likely have questions, especially about benefits, and IT
for several weeks. It's important to be patient in answering those questions,
and treat them as high priority tasks, when you have to follow up, even though
you're a busy startup.

Consider the background of this engineer. Are they coming from another
startup? If so, they know the drill. But if they're coming for a larger
established company, take time to emphasize with their transition.

Finally, leverage your strengths. Being small and informal is a strength, as
long as your work policies reflect a high-trust environment. Working from
home, doctors appointments, vacation and sick time -- these should all be
approved quickly with ease, or not require approval at all.

------
evm9
I've seen some people here insist that they want their work station and/or
laptop ready to go. If I were in the position of hiring an engineer, and made
a hire, I would ask said engineer what they would prefer. Having everything
setup or letting them unbox and setup, or maybe a combination of both.

Other things not specific to work environment should be ready to go. Their
e-mail account, phone (if applicable), or any other virtual or physical
materials used on a frequent basis.

As others have suggested, prefer something like a 75/25 social/engineering
split for the first day. Introduction to team members and others, company
processes, goals, HR stuff, go to lunch, etc.

------
aprdm
I was the first full time engineer employee in my current company.

On my first day in the company which is in a different country from the one I
am from:

\- Cycled with the CTO through the city, he showed me where their old office
was \- Got my new computer and installed stuff on it \- Ended installing the
dev environment together with him in my machine

It was _really_ good :), still remember it!

------
davismwfl
First day, answer all the little questions first, not all are relevant in all
circumstances but you get the idea.

1\. Where's the bathroom?

2\. Where's the fridge, etc. What are the typical patterns for people. Do they
bring lunch, go out as a team etc.

3\. If they are new to the area, tell them where to find all the normal
things. Food, Grocery, Drug Store, etc.

4\. Tell them when they will get their first paycheck, if the amount will be a
partial amount tell them that. This gets looked over way too often. Tell them
the pay cycle, and any benefits information have it ready and laid out. Being
a startup you likely have little to no benefits, so remind them of that as
many times stress of changing or getting a new job has people flustered.

5\. Make sure you are ready for them, have all the documentation, legal
requirements and stuff out of the way.

6\. Make sure you tell them what to bring their first day so they don't feel
unprepared and so you don't look disorganized.

7\. For engineers, give them their machine and have them set it up. Make sure
you have all the necessary access codes and have granted their accounts to
everything they need before they get there.

8\. Have 3-4 small tasks they can get started on, but tell them your
expectations with them. If you have a lot of potential places they could
contribute have a few ideas in mind and talk to them where they might want to
fit in. That is awesome for most people.

9\. Tell them up front, you are still figuring things out, so they shouldn't
be afraid to ask questions. Make sure they feel comfortable asking questions.
People who have been in startups are far more likely to already be asking
questions, but just be prepared and don't get defensive etc.

10\. Have fun, take them to lunch day 1 or 2. Make it their choice, sometimes
day 1 is a little overwhelming and they may want to wait on lunch for a day or
two so they can get the feel for things. It sometimes helps them to get away
for 30-60 minutes the first day or two so they can gather thoughts, not
everyone, but some people are like this.

11\. Warn them of any land mines. I had a team lead one time tell me day one,
look we all work really well together etc, but here are 3 things that a lot of
people around here hold sacred. His point wasn't to say not to challenge them,
but just to get the lay of the land first before I stepped in something
unknowingly. This isn't typically an issue in startups as much.

12\. Tell them where to park their car if they are driving. Or where they can
put their bike if they rode in. etc. More important in larger cities, but
really important.

13\. Give phone numbers and email addresses in a list for anyone they are
likely to need to contact. Don't rely on them searching it out in Outlook or
some directory someplace. Print it out and hand it to them, or already have
emailed it to their new email address.

14\. Your a startup, have some sort of swag to hand out. T-shirt, mug,
stickers etc. This isn't an absolute requirement but it makes people feel
welcome. Yes, some people will say that's stupid, but usually these are the
same people that will later say geez, they didn't even have X when I started.

I could probably go on, but this is long enough. Sadly I have learned most of
these from being on both sides of the table. And you won't believe how much
less stress you feel as a founder when you knock most of this stuff off the
list and have it ready for them day one.

BTW -- Congrats on getting your first hire!

------
gitcommit
Some tips:

Break the ice. New environments can be scary. Start a conversation with a
joke. This is also good for the company, everyone remembers their first day.

Give them a face book with job and interests. This makes it easier for them to
blend in.

------
afarrell
Make sure they know when they should show up on their first day and that there
is someone with an idea of what sort of things they'll be working on.

------
Zelmor
Off-topic: your site, fynd.me completely breaks on android tablets running
firefox.

~~~
ajuhasz
Thanks for letting us know, always one more browser environment to check!

