Onboarding Antipatterns

I&#x27;d add a few more:<p>- &quot;Lost in space&quot;: Give your new hire a tour of the relevant facilities. Toilets, kitchen, canteen, bicycle garage, important offices (boss, secretary&#x2F;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...).<p>- &quot;Your chair is still on order&quot;: 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.<p>- &quot;Talk to the wee lass with the fangs, horns and the striped hair&quot;: Introduce people, introduce their roles and places in hierarchy. Even if things like &quot;chain of command&quot; 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 &quot;command structure&quot;. Don&#x27;t send a new hire to see somebody, always accompany them and make introductions.<p>- &quot;Nobody likes the noob&quot;: 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&#x27;t) to get everyone together with the new one in a less formal setting.

I’ll add one<p>- “all the things at once”: the new guy gets to be overwhelmed with all the information<p>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.<p>They had an internal Confluence site for every new person, where every part of the onboarding process was transparently visible.<p>- 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&#x27;s part of it.) - All accounts set up. - And more stuff like that.<p>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.<p>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&#x27;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.<p>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:<p>- 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<p>- 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.<p>- 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.<p>- 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&#x2F;goals<p>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!

I’ll add another:<p>“Follow these steps and if something doesn’t work figure out the solution and update the document”.

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.<p>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.<p>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.<p>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 ?<p>Even if you&#x27;re in the company for 3 years, having no clear view of what you&#x27;re supposed to do, where to get the info for your following projects, and be fed philosophical BS instead of actual information doesn&#x27;t look like a great situation for anyone expecting guidance.<p>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.

your website is badly misconfigured. Going to the <a href="https:&#x2F;&#x2F;www.dcaulfield.com&#x2F;onboarding-antipatterns&#x2F;kudos" rel="nofollow">https:&#x2F;&#x2F;www.dcaulfield.com&#x2F;onboarding-antipatterns&#x2F;kudos</a> page shows people your application source code

One more: abstract cultural onboarding<p>This involves spending days to learn a lot about very abstract culture and values like being dynamic and innovative, and inclusive.<p>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.<p>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.

I&#x27;ve completed 5 weeks at a new SRE job and only have access to documentation and &quot;corporate&quot; 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.<p>There is a 90 day on-boarding roadmap and we are stuck at week two<p>Read a lot of documentation&#x2F;tickets&#x2F;slack but hard to make sense of it without context.

This is a great list! It reminds me of the Teamicide chapter in Peopleware, where the authors focused on antipatterns in team formation.

Shameless plug: <a href="https:&#x2F;&#x2F;leadership.garden&#x2F;onboarding-engineers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;leadership.garden&#x2F;onboarding-engineers&#x2F;</a>

I have never worked at a company with a functional onboarding process; are there any examples&#x2F;anecdotes of onboarding processes that worked well?