Ask HN: Best/worst way to onboard new employees?
We’re hiring our first engineering employee and wondering if anyone has any advice on how best to onboard them?
Any great tips? Anything to not do? What’s the best first week experience you’ve had?
Any great tips? Anything to not do? What’s the best first week experience you’ve had?
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.
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?
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.
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.
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.
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.
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).
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.
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.
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.
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.
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!
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!
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.