Ask HN: Best practices for onboarding new employees?
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.
86 comments
[ 2.6 ms ] story [ 149 ms ] threadThe 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!
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.
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?
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.
Then set aside time to go through them on a regular basis. Make scripts from them, checklists, docs...
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 ;)
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!
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.
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.
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).
"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."
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.
That's what life in a Big Corp is quite often like, actually.
I taught myself how to code and GTFOT.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
- 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.
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.