[HN Gopher] Onboarding Antipatterns
___________________________________________________________________
Onboarding Antipatterns
Author : cauliflower99
Score : 59 points
Date : 2023-06-09 15:50 UTC (1 days ago)
(HTM) web link (www.dcaulfield.com)
(TXT) w3m dump (www.dcaulfield.com)
| ochronus wrote:
| Shameless plug: https://leadership.garden/onboarding-engineers/
| c00lio wrote:
| I'd add a few more:
|
| - "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.
| rgblambda wrote:
| > "Your chair is still on order"
|
| 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.
| ochronus wrote:
| A HUGE plus one to the last point - making social connections
| is usually even harder / not cared for than subject matter
| onboarding.
| base698 wrote:
| > Your chair is still on order
|
| 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.
| CoastalCoder wrote:
| Please, name the company if you can.
| makeitdouble wrote:
| 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.
| rf15 wrote:
| I have never worked at a company with a functional onboarding
| process; are there any examples/anecdotes of onboarding processes
| that worked well?
| joshSzep wrote:
| 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.
| CoastalCoder wrote:
| It's worked well for me at small, well-funded startups.
|
| It also worked well for me at large, stable organizations.
| I.e., more initial bureaucracy, but it was a pretty refined
| process.
|
| Fast-growing companies above a certain size are where I've had
| the most hiccups.
|
| Having a well-chosen onboarding buddy also makes a huge
| difference IME.
| ethanbond wrote:
| 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.
| PheonixPharts wrote:
| 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.
| lelanthran wrote:
| > 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?
| toast0 wrote:
| 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.
| clnq wrote:
| One more: abstract cultural onboarding
|
| 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.
| cauliflower99 wrote:
| I'd call this "Checkbox onboarding"!
| c00lio wrote:
| 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.
| tkiolp4 wrote:
| 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.
| web3-is-a-scam wrote:
| I'll add another:
|
| "Follow these steps and if something doesn't work figure out the
| solution and update the document".
| Noumenon72 wrote:
| 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.
| CoastalCoder wrote:
| 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.
| rgblambda wrote:
| 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.
| knallfrosch wrote:
| 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.
| 6DM wrote:
| I'll add one
|
| - "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.
| karmakaze wrote:
| 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.
| oksurewhynot wrote:
| 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!
| leoff wrote:
| your website is badly misconfigured. Going to the
| https://www.dcaulfield.com/onboarding-antipatterns/kudos page
| shows people your application source code
| [deleted]
| DJBunnies wrote:
| It's just a single stack trace of dependencies highlighting a
| bad verb. Not great but nothing to get in a twist over.
| JamesLeonis wrote:
| This is a great list! It reminds me of the Teamicide chapter in
| Peopleware, where the authors focused on antipatterns in team
| formation.
| dimmke wrote:
| 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.
| bluGill wrote:
| 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.
___________________________________________________________________
(page generated 2023-06-10 23:02 UTC)