- "Lost in space": Give your new hire a tour of the relevant facilities. Toilets, kitchen, canteen, bicycle garage, important offices (boss, secretary/team assistance, IT helpdesk, ...), etc. Same for online resources and intranet, have a proper entry page that lists everything relevant and has a proper search function (which seems to be exceedingly hard...).
- "Your chair is still on order": Have things ready on day 1. Nothing is worse than waiting on necessary accounts, hardware or people for the onboarding. If you cannot have things ready, at least have the decency to not have your new hire sit around twiddling thumbs, find something interesting and productive to do for them, e.g. learning new things.
- "Talk to the wee lass with the fangs, horns and the striped hair": Introduce people, introduce their roles and places in hierarchy. Even if things like "chain of command" are usually fuzzy at your place, at least for the first few weeks, make it easy for the new hire to fit into a simplified "command structure". Don't send a new hire to see somebody, always accompany them and make introductions.
- "Nobody likes the noob": Always make a point to include a new hire in the usual social activities. For example, go to lunch as a group (even if you usually don't) to get everyone together with the new one in a less formal setting.
A company I worked for was hiring up for a new initiative. A new hire got the job and was on vacation when he got the offer. They demanded he start immediately and leave his vacation a week early. He obliges and starts the next week cancelling the second half of his vacation. He arrives and there is no where for him to sit and they hadn't even bothered ordering his equipment.
When I started at my current job, nobody was present when I showed up to the office. Everyone was WFH. Nobody knew where my MacBook was being delivered to as I hadn't provided an address (I moved cities for the job), but it was in transit to somewhere. There was the usual onboarding documentation being out of date and inaccurate but that occurs everywhere.
Thankfully things got better or it would have been my shortest stint in a role ever. There was an understanding among my new colleagues as to how badly they fucked up.
- “all the things at once”: the new guy gets to be overwhelmed with all the information
I think it’s nice to break things up with some non work related activities because it’s really hard to catch all the names, places, tools, etc on day one. Replacing it with structure that builds over a week is a much nicer experience.
My best onboarding experience was at a ~300 person company in Munich.
They had an internal Confluence site for every new person, where every part of the onboarding process was transparently visible.
- Who greets, when and where and is the new hire informed.
- Access card handed out
- Introduction of all business units (monthly talks about what every unit does and who's part of it.)
- All accounts set up.
- And more stuff like that.
But hey, if you want to improve your onboarding process, simply start by asking new hirees how they think it went at week 1, month 1 and month 3.
One place where I found onboarding effective was one where a target was to have each new hire ship a PR on day 1. This means that all resources are available and working as well as communicating with the team to learn enough about one real problem and solution as well as the entire process loop.
Another method I found effective is simply pair programming but seriously for most of the day every day with the same person for a week or two then with someone else. It basically requires pairing to be part of the culture and not only done in specific cases like onboarding to run without being disruptive.
I direct new people to the documentation with instructions to look for things that are wrong and then when they find something wrong get it's fixed. About 80% of the time what is wrong needs an expert to fix, but 20% they can figure it out and fix it.
After a few years our documentation is pretty good and mostly up to date.
If the company is transparent enough, sometimes that makes it up if they don’t provide enough documentation for whatever process they may have. Most often than not, the following is enough for me to get up and running in any company without too much help and knowing exactly how other people like to work:
- public slack channels. If I can sneak into any team’s channel, I can get enough information about how people communicate (async vs sync, emojis or not, tagging individuals?, how much they use @here?, grammar mistakes? gifs? Do they poke their peers about unreviewed PRs via Slack? And a long etc. You practically can mimic (and learn) their best performer just by knowing how to search on Slack
- public Jira boards. With this I can know how tickets are described. One liners vs very well detailed issues, screenshots?, how long does it take in average to move a ticket from Backlog, to In progress, to Done, etc.
- public (within the company) repositories. So can I dig around and see their commit formats, merge or rebase?, do bugfixes go along with tests?, code quality, etc.
- public calendars. So i know more or less what people setup meetings for. I can check also how long they usually last, how often they happen, how many there are per week, whether or not meetings have descriptions/goals
Hell, if you even let me dig around C-level email inboxes, I can be more than just an individual contributor. One of the worst companies I worked for had almost everything private: private slack channels for teams, private repositories, private calendars… I felt like I couldn’t get to know the company culture for real.
Just completed (failed) a contract-role-as-job-interview that fell into pretty much every one of these categories. No clear goals, no measure of success, completely left to my own devices. Even had an engineer tell me not to DM them questions. Good stuff!
You mean "you and your onboarding buddy figure out the solution and update the document". It might just be me but I think it's a bit crazy to expect someone with less than 8 hours experience in the role to figure out issues that other team members either haven't noticed or chose to ignore.
This seems like the right thing to do. Lets the newcomer be useful and gets the documentation to have guaranteed recent knowledge. If it's an antipattern it's because too many people don't like documentation and don't update it.
I've hit this. It's kind of a tragedy of the commons scenario:
If I take the time to fix the docs with a high certainty of accuracy, I get behind on other stuff with getting credit for the fix.
I guess it also comes down to what the cultural norms / expectations are. Some might see it as natural in a growing company, others might see it as selfishness at the expense of new employees.
When I worked at Amazon they had an onboarding system so complex it had its own web application and was filled with trivial tasks. Lots of video courses. Specifically I attended about 8 DEI based trainings in total, some were instructor lead and some were videos with quizzes. The instructor lead ones were extremely hard to schedule because every new corporate employee had to take them and Amazon’s churn rate is bananas.
But that’s just a gripe, the real issue that people ran into consistently was setting up their laptops. We also had an “onboarding buddy” system so I was responsible for helping several new team members follow IT’s instructions. It’s worth mentioning that myself and almost all the people I worked with are software engineers and had experience with the OS they were using, we were all quite “computer savvy” and still ran into issues. Sometimes we were able to resolve on our own with trial and error but it always overran the allotted time and sometimes took a whole day.
It did not go smoothly for me, or any person I helped. Usually because something small had changed slightly either in the OS or in the software Amazon runs and IT was still shipping out laptops with old images on them or they had not updated their instructions.
It was frustrating, but I don’t think the IT people were incompetent. Quite the opposite. Just a lot of moving parts to juggle.
Are any of these anti-pattern specific to onboarding ?
Even if you're in the company for 3 years, having no clear view of what you're supposed to do, where to get the info for your following projects, and be fed philosophical BS instead of actual information doesn't look like a great situation for anyone expecting guidance.
If you feel you can figure all of the above on your own, onboarding could probably go the same route to get you warmed up.
This involves spending days to learn a lot about very abstract culture and values like being dynamic and innovative, and inclusive.
Usually also in stark contrast to actual practices. Like spending 2 days on DEI training in an office full of white 20-30 year old men, and the three token woman they hired all still in junior roles after 5 years of service.
Not sure what this part of the onboarding is about but many companies do it to a degree. It doesn’t seem useful to anyone or impacting anything in the actual culture.
That isn't just specific to onboarding, this is just normal corporate BS. Corporate values and culture are just lip service and marketing slogans. You only learn about the real values and culture later on, by what the company really does and how things are really handled. That also includes later surprises like "our culture has changed, we didn't say so, but we now only hire salespeople anymore" or whatever.
I've completed 5 weeks at a new SRE job and only have access to documentation and "corporate" stuff. Due to a blip in the onboarding I and person who started with me have no access to the technical platform to do our actual job.
There is a 90 day on-boarding roadmap and we are stuck at week two
Read a lot of documentation/tickets/slack but hard to make sense of it without context.
I recall Yelp's onboarding to be the best I've encountered anywhere. Some highlights:
- Before Day 1 I received a pleasant email on my personal account that walked me through Day 1: simple things like getting a badge, finding my team, etc was stress free as a result.
- There was a "space camp" presentation to give me a high level overview of the technology and culture, as well as step by step instructions guiding me through my first commit and first deployment (both of which are expected within the first week)
- I was assigned a dedicated mentor on my team. I'm someone who often wants to "figure it out" on my own as a response to my "asking for help" anxiety. Having someone assigned to answer my questions and who micro managed me through the first couple weeks (in a good way) really helped me get up to speed much faster.
- Always a (expensed) team lunch to welcome in a new hire.
Anyways, I'm now in the "remote till I die" camp and I have been struggling to translate this into a remote first company. It can be challenging to make a new remote team member feel comfortable, productive, and "safe" without that physical presence.
Anecdotally, Palantir’s was fantastic the multiple times I did it (internships + FTE).
Facebook’s was one of the most insulting corporate experiences I’ve had. Multiple speakers for the (very long, exhausting days of lectures) straight up didn’t show up. No comms/reschedule, just the entire onboarding class sitting and waiting for an hour.
My experience is that the best onboarding processes (at least for devs) basically boil down to getting you to have a real PR merged by the end of the first week. The period could be longer for more complex orgs, but the time from logging in to first merged PR can be consider the metric to measure the success of your onboarding.
Basically:
1. Here's how to get the dev environment setup locally.
2. Here's your first task.
3. Here's the people that will be most helpful in solving that task.
Once you can submit a PR and have code review (and ideally have it merged), you're effectively onboarded. After this it's time start worrying about the culture/philosophy/meeting people/etc.
Needless to say (hopefully), the new hire should not feel pressure to get a PR up quickly, the process and guidance should be set up for success.
> My experience is that the best onboarding processes (at least for devs) basically boil down to getting you to have a real PR merged by the end of the first week.
But then when will we have time for all the DEI training if we waste the first week getting the employee productive?
Some things are important to do in the first week, like anti-corrupt practices act compliance, and compliance for any consent decrees currently in place. DEI and anti-bias can wait for week two.
- "Lost in space": Give your new hire a tour of the relevant facilities. Toilets, kitchen, canteen, bicycle garage, important offices (boss, secretary/team assistance, IT helpdesk, ...), etc. Same for online resources and intranet, have a proper entry page that lists everything relevant and has a proper search function (which seems to be exceedingly hard...).
- "Your chair is still on order": Have things ready on day 1. Nothing is worse than waiting on necessary accounts, hardware or people for the onboarding. If you cannot have things ready, at least have the decency to not have your new hire sit around twiddling thumbs, find something interesting and productive to do for them, e.g. learning new things.
- "Talk to the wee lass with the fangs, horns and the striped hair": Introduce people, introduce their roles and places in hierarchy. Even if things like "chain of command" are usually fuzzy at your place, at least for the first few weeks, make it easy for the new hire to fit into a simplified "command structure". Don't send a new hire to see somebody, always accompany them and make introductions.
- "Nobody likes the noob": Always make a point to include a new hire in the usual social activities. For example, go to lunch as a group (even if you usually don't) to get everyone together with the new one in a less formal setting.