Hacker News Reader

Comment by TameAntelope | Hacker News Reader

Honestly? Onboarding is hard. How are you supposed to do it? Everyone who has to go through it isn’t going to fix it, because they’re new and have their actual job to get to.

It also doesn’t give the customer any value, so how do you justify losing out making stuff better for the people who pay your company money?

I just kind of assume on boarding will suck, and it’s not a reflection of the rest of your time there. Maybe I’m wrong, but it’s been true for me.

What are folks’ tips for making onboarding smoother?

View on HN

I thought the on-boarding process where I work was good when I went through it. The important part was that I felt respected and that the company was excited to have me (despite it being large enough back then that about 10 to 15 were joining a week).

1. New hires start on Monday at the HR office. Take badge photos, get badges, given basic overview of company policy. Told that the company respects and trusts us, that our badge should open any door that does not have a safety reason to be restricted.

2. After orientation I found my manager waiting in the lobby. He told me how to get to our part of the campus.

3. My manager shows me to my cube. It has a computer in it with a sticky note with a temporary password. I log in, am able to open the SSO page and change the temporary password.

4. I'm given an introductory binder with answers to lots of questions, who works around me, what they do, what I will likely be doing soon, etc.

5. My manager suggests I start doing trainings (medical company, lots of trainings to meet certification standards), but says if I get tired do something else.

6. A bit later in the day a local tech person came and helped me run a magic script that got the developer tools setup and ran a build to make sure it was all good.

7. Proceed to get my first project and get started.

Overall the process was the minimum needed to make sure I got into the building and had what I needed.

> magic script that got the developer tools setup

I wish I had that. I spent like 2 weeks installing a million different things, and configuring like 200 different files and even then, my build ran but not everything worked.

On the other hand, having to do things manually gives you a good overview of how it all works.

A magic script is great if you’re a user of the tools/software it installs but if you’re a developer you’ll sooner or later need the knowledge of how the thing works.

A magic script is great even if you are the developer who need the knowledge of how thr thing works. It is a single entry point which you can start reading and understanding.

I like to call these just "scripts" without the magic. Magic scripts install a bunch of stuff and configure your machine, but don't tell you what they're doing at all. This stuff infuriates, because the next thing I know I have an OpenJDK11 on my computer for seemingly no reason. What you really want is a script, so you can just directly run it, but it tells you what it is doing and why you need the thing. "I'm going to set up Kerberos so I can push to our Git instance"? That's what I want to see somewhere that's not just "oh you can find this in the 17th zip file we download and execute on your machine".

Presumably you can just inspect the magic script when you need to

The process described in the blog post sounds more appealing to me, it is with multiple people in a social setting where you can get to know people in different departments, rather than by yourself at a desk.

Quite often you will never get a chance to meet colleagues from different departments the same way so you should make the most of it and make connections.

Trying not to say this to sound snarky, but making onboarding easier feels like the right thing to do, regardless of customer value. It's just ... valuing people's time and goodwill? Doing something new is always a little nervy, why not make it easier for all of us kind of thing.

Looking back at what worked when onboarding my immediate team ... having equipment that "just worked" at least after a day of finagling / being personally walked through 1:1 by IT ... a mentor there to walk them through the first month, and always available via chat during work hours as well as weekly 1:1's ... specific "small potatoes" assignments ready for them at the end of week one that are kinda crafted to guide them through the branding/process ... "showing" them they can fail and be okay ...

Well first, let's dispense with the pretense that every moment of time should be devoted to churning out customer value. The way an organization treats new people shapes its culture and thus its productivity.

The biggest thing is to have comprehensive written documentation of the process and keep it updated.

I agree with the other suggestion to have SSO or official password manager practices.

And steer clear of the shitty MacBook Pros Apple made from 2016-2020. The hellish butterfly keyboard and Touch Bar era.

> Honestly? Onboarding is hard. How are you supposed to do it? Everyone who has to go through it isn’t going to fix it, because they’re new and have their actual job to get to.

Give them time for onboarding (ie. don't expect them to do their "actual job" immediately) and empower new hires to fix things as they go along.

> empower new hires to fix things as they go along.

This _sounds_ like a good idea but I haven't seen it really work in practice since new hires are by definition the least empowered.

Often problems are not small and local either but caused by general hairiness of older systems / docs / tools.

It seems like this could be made more powerful by making it the explicit task of an onboarding buddy (ie. experienced employee) to drive improvements together with them.

It's a difficult problem because there is a disappearing stakeholder, once the new hire gets through the friction with some help the motivation disappears quickly. This means for bigger problems that once they have the power to change it they have bigger fish to fry.

> empower new hires to fix things as they go along.

Sometimes things are the way they are for a reason. "This is a regulatory requirement". "This matches the style of six million lines of code and redoing it isn't on our hitlist - in fact match this way going forward." "Yeah, the CEO got drunk and made a bet with another CEO that all new lines of code could avoid 'e' in variable names, so it's a hard rule that we write it n3xt."

I certainly think it's very valuable to get an outsiders impressions and the problems that they see being raised before they get used to stupid ways of doing things. There's a continuum between the new programmer deciding they're going to convert all tabs to spaces and patching a critical security hole they see because of an out of date library.

This is what I've seen works best. It catches holes difficult to see as someone already setup or familiar with the ropes. Ideally new hires can at least improve docs, if not the ramp up tooling itself.

Exactly. One of the first steps of onboarding should be to make sure new hires are set up to fix the onboarding doc(s) themselves.

> It also doesn’t give the customer any value, so how do you justify losing out making stuff better for the people who pay your company money?

You are going to generate more value for your customers long term by having employees who feel like their time and contributions are valued. Solving these types of problems (onboarding, knowledge management, communications, internal tooling) are literal force multipliers for companies. But they are often ignored by leadership because they don't show immediate revenue value.

I'm working at an early stage startup, so for me there is no "long term"; a few weeks spent fixing the problems with our onboarding process are a few weeks where we miss out on the two or three customers who might make/break our next funding round.

And clearly this isn't addressed to you. When you scale up, you should invest in onboarding. Until then, you shouldn't.

…I asked the question, lol

I was kind of trying to answering it. Your original post said

> Onboarding is hard. How are you supposed to do it? Everyone who has to go through it isn’t going to fix it, because they’re new and have their actual job to get to.

When you hit a certain scale, it will in fact be someone's actual job to build a system to onboard people (not necessarily full time). Onboarding is both hard and expensive, and right now your onboarding is probably "here's a computer and a JIRA, etc login. Our standup tomorrow is at X, here's some documentation and see if you can address small problem by then. John's been assigned to answer your questions". Which is fine. But at some point you're going to have enough moving parts that it's worth paying someone to build an onboarding process. And it will probably have cringey humor and waste new hires time to some degree.

I'm not sure if there's great onboarding systems or generic advice for smaller teams because they're so individual to the company and the cost of making a more formal process probably outweighs the cost of just having an engineer do it by hand the few times you're doing it.

As you said, you have other, more pressing, issues. Good luck! I hope you get those customers to get (good terms on) your next round.

We spend a lot of energy on our onboarding process (a good/smooth start is critical for new hires in our organization, as it's fast-paced). But I think the main reasons we excel at this are:

--> We ensure that new equipment is ordered for when they start

--> We keep the people a new hire has to deal with to a minimum (they meet with a manager, a single mentor, and HR only - after that, it's team members)

--> We make sure everything in documents (policies, procedures, etc.) are also covered by one of the aforementioned people, leaving room for questions

--> We show new hires the location and use of the coffee machine before anything related to their job ;-)

Employee journeys should receive the same treatment as customer journeys and for the same reasons: they must help to achieve the goals while bringing the most value to business. Onboarding is the key to fast start and productive work — optimize it from the early days! Use conversion metrics, collect feedback etc. As CTO I always demand from my engineering teams that they optimize their environments for fresh start requiring no more than 15 minutes of manual work and no more than 30 minutes of total time. This requires scripting, reasonable defaults in configuration, good „Getting started“ documentation among other things. When this rule is enforced from first days, this part of the onboarding is usually the easiest.

On the other side, IT setup is hard. Things like SSO and accounts are always pain in the ass, because there’s always no budget to pay SSO tax on some subscriptions, no budget to offer corporate phones or hardware tokens, some services do not offer SSO integration etc.

> Everyone who has to go through it isn’t going to fix it,

Why not?

> because they’re new and have their actual job to get to.

No, they don't. Their job right now is to get up to speed. Part of my job is to get them up to speed. If anything, a minor diversion to spruce up the onboarding docs a little bit is one of the more concrete contributions either of us can make. And importantly, they don't have tribal knowledge crudding up the works, and if they manage to say something that is completely wrong, then that means they didn't understand something important and there is no better time to fix that than right now.

If you let an awful experience stand as it is, you aren't a neutral party, you're complicit.

Nobody is going to make the onboarding process awesome instead of getting down to coding, but it should be better every time you run through it. If not before (due to entropy), at least after.

They're also new enough where its often unclear if the docs are wrong, or they are wrong.

Obvious mistakes, by all means fix them, but for more complex things its often a net negative for a new person to try and fix before they have context.

Do you guys just dump people in the docs and abandon them?

How’s your turnover rate?

Restating facts as you have heard them is a valid form of consensus building. If they don’t match, then everyone is better off if that is corrected before you act on them. If I unload a bunch of information on you and you just nod along, I have absolutely no idea what’s going on in your head, I just have my own narrative which could be anything from wow this is going awesome to wtf is wrong with this bobble headed jackass. Unless you articulate, I won’t know which it is until you’ve done a number of things incorrectly and we finally challenge you to explain yourself.

If you think the docs are wrong, and propose a fix that is worse, then a conversation about that will save us days, weeks, or even months later on. And that will also save your standing with the team. But if you’d rather fashion a pretty necktie out of all of this rope then I can’t really stop you, but I sure am going to heckle you while you do.

Very much agree.

It is about care. If you care about your (new) team mates, if you want them to feel included, if you want them to be successful from the get go for their benefit and that of the team as a whole, then you can invest the time.

If you don't care, they can find their own way, ask around, copy someone else's half-broken configuration, and make their first commit after a month.

If you are a manager, team lead or tech lead, you likely just poured a shit-ton of time into recruiting, interviewing, hiring. Now, go spend a few hours on making sure that setup document in Confluence is updated.

It is also an iterative process. For every new hire, you spend a little bit of time, and incrementally the onboarding will improve. After a while, and particularly after having not hired anyone for a while, you use that time to just refresh the already basically good materials.

For my newest company, they'd made a page in the internal wiki with my name on it for onboarding and it had lots of stuff personalized for me, including a list of everyone on my team and how they would be relevant to my job (it's a cross-disciplinary team), and a few selected people not on my team with similar notes. Also "your first week" and "your first three months" sections. This was all in addition to the actual team onboarding checklist, which was delightfully comprehensive.

It doesn't have to be hard. And it can be part of their job to provide feedback on and make specific contributions to maintain the onboarding experience.

For example, if important dev env setup documentation is wrong and needs an update--that person should make the change or put in the change request to fix it, and follow-up. It should be no different from finding a bug in code.

The same goes for realizing key organizational or engineering patterns are going unexplained or are not explained in enough detail.

One of the key things to include is an onboarding buddy. Microsoft shared research showing the impact of an onboarding buddy: https://hbr.org/2019/06/every-new-employee-needs-an-onboardi...

There are many other articles and research studies showing that onboarding is critical to reducing the amount of time it takes a new employee to be effective and has serious implications for retention.

How to make it smoother in tech? One could do some research and come up with your own thing. Or you could just check out the articles and resources Gergely Orosz has put together.

I have seen a number of companies basically ignore onboarding and the new employee experience. When they have succeeded it was in spite of this--not because of it.

Among other things, single sign on (SSO) so new employees aren't creating a half dozen new accounts at the same time and/or a corporate-blessed password manager.

> What are folks’ tips for making onboarding smoother?

The new employee's manager should expect to escort them continuously for the first week. Onboarding is, generally by design, a rare event and something will always go wrong. Quite often, managerial authority is required to cut through the logjams that appear.

Yes, there may be a stupid HR requirement--as a manager, let the new employee know that you understand this is stupid but that we just need to get it out of the way, anyhow. As an engineer in semiconductors, I have had to sit through the "Acids are bad, mmkay?" fab worker safety lectures more times than I can count even though I was not allowed to even get close to the production fab floor. That's just life due to lawyers.

>Onboarding is, generally by design, a rare event and something will always go wrong.

It is not (both). Hypergrowth startups and large companies onboard several dozens new people every month with limited HR, IT and management resources and usually do not have luxury to make a lot of things wrong in the process. Hence the need to optimize and build a standard operating procedure for it.

>The new employee's manager should expect to escort them continuously for the first week.

This task can be delegated to a „buddy“. It helps people to grow and spares some time for the manager (who still needs to plan some more time than usual for this new team member).

> This task can be delegated to a „buddy“.

That seems to be a better solution. A new employee may hesitate to ask their manager questions that show they don't understand something. But they may feel less nervous about asking a co-worker. Also, a co-worker might have more relevant technical knowledge than a manager would.

> It also doesn’t give the customer any value, so how do you justify losing out making stuff better for the people who pay your company money?

How are you going to make stuff better when you don’t even know about the stuff?

Don't have a formal onboarding. The last company I joined they handed me my keycard, laptop, phone and merch, and then took me directly to my team. I was given a manual to work through to set everything up, there were some hitches but I had people nearby who could help. There was none of the feel good crap Rachel talks about, we were treated as adults.

This is not going to work in companies larger than 150-200 employees. Onboarding procedure when optimized should focus on self-service („how/where I can find X?“), but entry point to self-service in larger companies is big enough to offer a standard procedure.

Sounds wonderful to me. Just cut right to the chase. The best way to get familiar is to ask around when you hit a snag.

Reply on news.ycombinator.com