Optimize Onboarding
staysaasy.com
Optimize Onboarding
1–10 of 66 posts
Re: Optimize Onboarding
#2I once got told by a manager that they didn't expect new hires to make big contributions in the first year. That was after I complained I was feeling very unproductive and wanted some help to speed things up. I quit after a few months because the slowness of everything around me was making me depressed.
This was at a top5 website company.
Re: Optimize Onboarding
#3Personal anecdote: Started in a developer position a couple years ago to work on an internal corporate app on an isolated network.
Week 1: Get to the desk; meet my neighbors; submit request for necessary network account; and start on mandatory security training for the systems.
Week 2: Finish the mandatory training; ping the network owners a few times about the account request; start reading up on unfamiliar parts of the stack.
Week 3: Continue pinging network owners about the account request; ping my own manager about the account request; stare at the workstation that I cannot log in to; ask around, "Is this normal?" "Yes."
Week 4: Do some more newly assigned mandatory training; ping network owners and manager again.
Week 5: Finally get the network account!
Re: Optimize Onboarding
#4Committing code on day 2....I guess the author had never worked for a Fortune 500 company. It usually takes at least two weeks before you get a level of access that allows you to commit code.
Re: Optimize Onboarding
#5[deleted]
Re: Optimize Onboarding
#6>It takes roughly 2 weeks to form a habit; it takes roughly two weeks to get comfortable in a new environment. A common mistake is to treat a new report’s first couple weeks like college orientation - social, light hearted, get-to-know-you stuff. If your report spends the first two weeks reading C# documentation and having lunch out on the town with the team, guess what, they’ve just normalized that behavior as what the role is.
Humans are not dogs. I've worked at companies with both styles of on-boarding (two weeks of doing nothing vs jumping right in). The output in a month was realistically no different.
Re: Optimize Onboarding
#7Personal anecdote: Started in a developer position a couple years ago to work on an internal corporate app on an isolated network. Week 1: Get to the desk; meet my neighbors; submit request for necessary network account; and start on mandatory security training for the systems. Week 2: Finish the mandatory training; ping the network owners a few times about the account request; start reading up on unfamiliar parts of…
This have changed at my first job (a long time a go) the second day I got an hours crash course in RT/11 (a DEC OS)
I was told to learn FORTRAN IV from McCracken (A Guide to Fortran Programming)
Re: Optimize Onboarding
#8Personal anecdote: Started in a developer position a couple years ago to work on an internal corporate app on an isolated network. Week 1: Get to the desk; meet my neighbors; submit request for necessary network account; and start on mandatory security training for the systems. Week 2: Finish the mandatory training; ping the network owners a few times about the account request; start reading up on unfamiliar parts of…
5 weeks, jeeez.
I spent around three days trying to get the 802.1x wired ethernet authentication to work* at one organisation and felt completely useless for that period. I'm not sure I'd have coped well not having any network access for five weeks.
*It turned out the ports I'd been directed to use hadn't even been patched in (in hindsight I should've figured this out a bit quicker from my EAPOL frames seemingly going into the void!). IT eventually figured out what was going on, seemed surprised I was surprised the port wasn't even active, and said they never patched more than 1 port per cluster of desks...
Re: Optimize Onboarding
#9I once started as a senior engineer at a company most folks here would have heard of and was told on arrival that every engineer first has to work a short period in support. The idea was to learn the product and customers.
In theory this sounds like a good idea. In practice, it was a poorly thought out system that left me frustrated with the company, disconnected from my team, and looking for a new job before I even finished the half implemented on boarding process. It felt more like a hazing ritual than a useful learning process and completely soured me on the company.
Doing support isn't something I find particularly egregious, but you should absolutely not segregate new hires away from their team for a long period of time immediately after hiring them. More generally, you need to equip new hires to do their job as soon as possible, less you risk smothering their enthusiasm for what they were hired to do.
Re: Optimize Onboarding
#10Committing code on day 2....I guess the author had never worked for a Fortune 500 company. It usually takes at least two weeks before you get a level of access that allows you to commit code.
I work for a non tech fortune 500 company and was committing code by day 2. It's really about being willing to figure out what the blocker's to access are and making sure they are taken care of before hand.