Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Best practices for onboarding new employees?
168 points by mud_dauber on June 6, 2018 | hide | past | favorite | 82 comments
I'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.

I'm building a personal checklist of onboarding items. It contains the usual categories - hr/payroll stuff, phone/email/slack setups, product details, customer commits/requests, risks/issues, etc.

The main concern is how to be productive from day 1 without being a time suck for the CEO & CTO. Does anybody have 1) a shareable best-practice checklist, or 2) a methodology of quizzing my new coworkers?

Appreciate it.




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.


Out of undergrad I was recruited by a major defense contractor and selected for a leadership development program. Aside from making me fly various places and do nothing they also made me do nothing at my "home" desk in a secure facility (so no cell phone or playful browsing) by myself.

I found a bunch of old math texts and starting reading them and doing practice problems out of sheer boredom. It was then without the stress of juggling other subjects and exams that I realized I actually liked math and just had terrible teachers for most of my education. I went through Calc I,II, III in the first month or two (some was review) and by the time I quit about a year later I had enough momentum and interest to go through differential equations, linear algebra, some analysis, and more advanced matrix methods.

It was one of my favorite jobs.


Very jealous. There was a defense contractor in my city I admittedly applied to out of undergrad mostly because I wanted to peruse their library, mostly texts on discrete maths. Glad you could discover your interest in the subject.


You passed up a leadership career at a defense contractor to read some books you could have read at home? Sounds like they recognized that this person they hired wasn't all that and decided that rather than fire you and risk a lot of paper work they tucked you away knowing that you would quit eventually, this is often preferable to termination. The odds that your lack of productivity went unnoticed is slim, they noticed. I've been in a similar situation, the appropriate action and the path worthy of leadership would be to self seek out innovations and begin drafting proposals for business process improvements. You might have actually been stealing time. What were your interactions with your direct supervisors like, what would you talk about?


Oh it was all fine, just the work wasn’t hard or interesting and there wasn’t that much of it (except for crazy spikes for 2-3 weeks sometimes) I dont feel like I passed on anything significant. I was just really under utilized. I got poached by a startup and they offered to match but I declined. If your great goal is leadership at a DoD shop I would recommend a better goal. Even if you make it up the ladder over 15-35 years the top of that ladder just isn’t that great, or at least it wasn’t for me. I keep in touch with some other people from the program, all have since moved on. I would say this indicates the program didn’t know how to utilize and retain the “talent” it selected for. And sure you can argue we all weren’t that talented, I don’t particularly care, I am very happy with that particular career choice.


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

My biggest pet peeve. Oh, you're a 23 year old college grad? Better take time during your first hour of being in the real world to pick your life insurance policy and memorize what building alarm code to use if you happen to be the only one in the office at 4am on a Sunday (during a holiday weekend).


This was an actual exchange during my onboarding at a previous job:

"Please provide six contact addresses for the company's emergency notification system."

"I don't have six contact addresses."

"Just repeat some on the form."


I had to create and then maintain an excel file for this reason. There is no other way I am remembering who witnessed me living somewhere 15 years ago.


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.


That happened to me. I was hired at a company, left to go to army basic training, came back and they didn't manage me at all for months. Then they gave me a job to do with about two minutes of explanation, forgot about me, then almost fired me 6 months later because I was doing it wrong. No management, no training. But I am still here almost 8 years later.


You being there for 8 more years was an unexpected twist. Any other "situation" that you could share?


Did it go better after those 6 months? I'd be keen to hear more of this story!


I once spent 6 months at a job where they forgot that I still worked there. I was outsourced, but when the project was finished I expected a call that my contract was finished also. Call never came, I kept showing up, outsourcing company kept paying me and the client was apparently very happy with me, even though I didn't do much.

I taught myself how to code and GTFOT.


That was your opportunity to take over.

You should have started drawing up strategic vision charts, cheesy motivational posters and started talking to people about getting in touch with their authentic values.


I have a guy like that in my job. I don't really understand why we hired him.


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


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


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.


Oh crap I didn't realize people would actually respond to me. I just kinda sat at my cubicle and did nothing. Everything was blocked on the internet so I couldn't really do much. Went home and cried.


I cant tell whether you are joking. Seriously.

That's what life in a Big Corp is quite often like, actually.


Yes but, what did he do?


You have an actual cubicle? What heaven employer is this?


>Ask IT to get them a laptop

Hah! It's never ready in time :-)

Although one startup I worked for was bought by IBM. We were issued our new (Thinkpad) laptops on takeover day (very organized) and were introduced to this thing called "Lotus Notes". We had all been using Thunderbird so this was quite a shock.


Generally true - I had a contracting engagement start where they paid me to sit there and "program without a computer" for more than a week while they tried to get one built.

My most recent start however was super-refreshing; Brand new computer with all standard developer software, network connections and accounts setup and waiting for me at the start of day 1. The phone that I never use but was required to get took another week to get setup & configured however...


The sad thing is that Outlook is better than Notes.


How small is very small (given that they have an IT department)? 96% of private companies in the UK are less than 10 people, for example, covering 1/3 of the workforce. 99.9% are < 250 people. The remaining 0.1% (big corps) employ 40% of the working population.

0-9 is small enough that a few of those points are less likely to happen. It's still possible to be ignored, but you're a significant percentage of the workforce and the comapny is throwing money away if you're not productive quickly. Under 10 and you likely report directly to a CEO/CTO, or possibly one person below.


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

At big companies, my experience has been that if you know either where something is or what color something is, you are now the goto expert on that something for the rest of your life.


(Very) big company onboarding story:

On day one, a battle tested project manager talked to me 8 hours straight, telling me every single detail about everything. He even talked during lunch.

On day two, he asked me to do something really massive because by now I must surely know me way around.


highly astute


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.


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.


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.


I like to keep this kind of info on 4x6 index cards. Easy to reorder, toss, review. Group them into a few categories, like how to, questions, that's weird, diagrams of how things fit together, etc.

Then set aside time to go through them on a regular basis. Make scripts from them, checklists, docs...


Sounds just like my Google Keep home page :-)


As a manager I appreciate all these tactics from my team members. Committing to a system like this facilitates communication and can greatly reduce onboarding stress and friction for the entire team. Thanks.


> 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.

What I tell people is that they should try to figure it out themselves. If they get stuck without any progress for 15 minutes, then they should ask a question.

I like to think that following this helps people build confidence and become more independent. And that it is a good balance between not wasting their own time or wasting the time of the person they ask.


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.


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!


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


Thanks!

I'd also add the advice from lostphilosopher: write down the glitches, gotchas, obscure URLs, etc. and make a kick-ass onboarding cheat sheet for the next recruit (who might just be someone joining your team ;)


Hey these are all really good ideas, thank you for sharing them!


This is a really good list. I especially like #2—your fleeting ignorance is an asset that can be leveraged.


Thank you for such a useful details notes ..


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.


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?


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.


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.


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).


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!


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.


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...


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.


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).


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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).


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!).


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!


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.


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.


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.


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.


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


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.


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... ).


Full disclosure I work on Greenhouse's onboarding product, Greenhouse 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!


You should look at www.rippling.com


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.


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/ . 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.


See here for templates that might help pull somethings together:

https://www.smartsheet.com/free-onboarding-checklists-and-te...

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.


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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: