3 More Onboarding Antipatterns

Given the success of my previous post on hackernews, here are 3 more onboarding antipatterns.

Onboarding Antipattern: Obvious Blindspots

...where the company assumes that obvious information is obvious and the onboarder will 'just know it'.

Less experienced people have less knowledge. Something that is obvious to a 20 year senior is not obvious to a junior fresh out of university. For example, steps to setup a dev environment might include "Install the docker container named 'company-dev-123'". This is a terrifying instruction for a junior. What is docker...what commands should I type...what websites should I visit. These are all questions that need to be documented.
Most information is quite complex in the beginning because the onboarder doesn't know what info is important and what isn't. They cannot separate the wheat from the chaff and regularly go down rabbit holes. I've even seen this with senior engineers who are too proud to ask their new team for clarification.
The manager often lacks empathy if this antipattern occurs. They might say "Why didn't you just ask someone for help?", without seeing that the new joiner didn't know who to ask or even that they were allowed to interrupt other people's work.

Many antipattern solutions come down to decent documentation together with a mentor. This combination gets the onborder through 95% of their issues in the first couple of weeks.
Assume every new joiner is a junior straight out of university. Assume they don't know what technologies they need to learn, who to contact or how to message another human being. Take your expectations and cut them in half. An optimistic onboarding means a bad onboarding experience. The more hand-holding in the beginning, the better.

...where the onboarder doesn't meet anyone in their first few days, making no new relationships or meaningful connections.

Contrary to popular opinion (especially in engineering circles), the most important part of any job is not what you do but who you do it with. The best onboarding experiences people remember are not when it goes perfectly, but when they make meaningful relationships and have fun with the people in their new company.
Most jobs today require group thinking. In other words, success is not dependant on a person's individual abilities, but their contributions to a larger team of people. - The onboarder does not feel part of something greater in their new job. They start asking themselves "Is this really what I signed up for?".
Companies often focus on processes and projects instead of the important part of their company - the people. A bad onboarding process where people struggle together is better than a "perfect" onboarding process with nobody to interact with. In the former, at least the onboarder is making personal connections.
The onboarder feels like an obstacle to be avoided instead of a valued employee. "If nobody talks to me, I'm not worth people's time."

Have a list of people from various areas to introduce to the onboarder in their first day and first week.
Introduce the onboarder to their team, ideally in person. If this is remote, make sure the onboarder knows what everyone looks like. I've met people who don't know what their teammates look like after a year of working with them because the team never had their cameras turned on!
Ideally, the team should do something non-work related like going for lunch together. This breaks the ice and gets the onboarder talking to their new team.

...where the onboarder finally gets comfortable with their colleagues and responsibilities, only to be told they are moving areas again.

The onboarder has spent weeks, if not months, soaking themselves in the information, practices and people of their new project. All this effort is not in vain because they have been told they are moving to a completely different area.
The onboarder is frustrated - all their efforts have been flushed away.
The company has spent weeks and months of salary on the onboarder to no avail.

This antipattern can be prevented in advance with a bit of foresight.
Don't put people into teams with projects you know will be cancelled.
Avoid putting people into teams that are likely to be moved soon.
In cases where it is unavoidable, give the onboarder as much notice as possible. Lay out a plan for their new area so they don't continue wasting time learning things they won't need.

1 kudos