Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimize Onboarding

staysaasy.com

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Optimize Onboarding

#31

Post by jrott »

sudeepj wrote: post #29
jrott wrote: post #10

Earlier quoted context omitted.

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.

Good for you! (not being sarcastic) Culture plays a huge role as well. I have seen the environments where existing folks are un-willing to help out new guy. This could be due to lack of time, getting territorial, just-being-jerk, lots of attrition, etc. The best way to get started is to start writing tests for the team and work your way up. I find this useful for all levels of hire.

Absolutely. It's totally a cultural thing I've been in the opposite situation as well. The culture really has to be that getting someone new onboarded is the most important thing and not somebodies side project.

Re: Optimize Onboarding

#32

Post by yjftsjthsd-h »

jeffbee wrote: post #15
tekdude wrote: post #3

Personal 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…

I recently started working at a huge financial concern and it was 12 weeks before I got my laptop in the mail.

I just... What did you even do in that time? (Sincere question; if I started a job and didn't have a machine I don't think I could work, and I assume a financial place won't let you BYOD)

Re: Optimize Onboarding

#33

Post by 3np »

jeffbee wrote: post #15
tekdude wrote: post #3

Personal 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…

I recently started working at a huge financial concern and it was 12 weeks before I got my laptop in the mail.

> financial concern

The probably unintended double meaning works great

Re: Optimize Onboarding

#34

Post by jeffbee »

yjftsjthsd-h wrote: post #32
jeffbee wrote: post #15

Earlier quoted context omitted.

I recently started working at a huge financial concern and it was 12 weeks before I got my laptop in the mail.

I just... What did you even do in that time? (Sincere question; if I started a job and didn't have a machine I don't think I could work, and I assume a financial place won't let you BYOD)

That's the crazy thing actually, virtually the entire company is BYOD with Citrix access to a Windows VM hosted in a datacenter. Only software developers need a specific machine.

I spent the whole time watching compliance training videos, no joke.

Re: Optimize Onboarding

#35

Post by hashkb »

Getting engineers to commit code ASAP can become entrenched to the point that it's unhelpful; the tail wags the dog and all of a sudden you're leaving easy bugs unfixed or small UX issues or whatever to make sure you have "first day" tickets. Just so you can say "our new hires ship code on day one" or whatever your flex is.

Does it really matter? Aren't you teaching the lesson that speed is the first principle?

It's just another excuse to avoid building actual onboarding, whatever that looks like for you. Too relaxed, too aggressive... are you really doing it thoughtfully?

Re: Optimize Onboarding

#36

Post by hinkley »

pathseeker wrote: post #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…

But...

I have talked to coworkers who have left, and generally if the start of their employment was rough it comes up in a discussion of why they left. It’s not why they left, but a part of a narrative about patterns.

The output may look the same, but there is still a toll. Wear and tear is wear and tear.

Re: Optimize Onboarding

#37

Post by hinkley »

tekdude wrote: post #3

Personal 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…

Our onboarding is a hot mess but if I can’t get you at least the source code by the end of day 2, you get an apology. That’s the part I can control, a bit.

Pro tip: collect all of the accounts one needs into a Wiki page, ordered roughly by how soon you need them. This page looks like it’s for you, but really it’s for the person doing your onboarding, so they can go poke people before you even know you need the account.

Re: Optimize Onboarding

#38

Post by hinkley »

jeffbee wrote: post #15
tekdude wrote: post #3

Personal 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…

I recently started working at a huge financial concern and it was 12 weeks before I got my laptop in the mail.

We started a contract and they gave us Windows laptops with 2GB of RAM. For coding Java. I probably should have run at that point but I was new. I’m fairly sure 2GB is either an IDE or running the app. We could use our own hardware though, or the contracting company could cough up a few.

I had just upgraded my personal laptop and my old one was 16GB of RAM and 2nd Gen SSD so you’ll never guess what I did.

Re: Optimize Onboarding

#39

Post by hinkley »

dougdonohoe wrote: post #22

I agree with pretty much all the OP has to say. In my experience, onboarding is something that is usually an afterthought, if it is considered at all. Which is why, when starting from scratch as CTO at two companies, I set it as a top priority from day one. In both instances, onboarding was optimized as much as possible. In one company, we used Okta, and 90% of accounts needed to be productive (Git, Jira, Confluence,…

For me setting up my dev tools was always part of orienting myself. It’s foreshadowing of what’s to come. Oh we’re installing this tool I bet that means yada yada.

If you want to install and set up Office, Chrome, a virus scanner, backup and VPN software then more power to ya. Having dev tools automated might not save all that much time overall.

Re: Optimize Onboarding

#40

Post by MarkSweep »

phist_mcgee wrote: post #23
jrott wrote: post #10

Earlier quoted context omitted.

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.

I've heard this a few time about submitting your first PR within one or two days at a company. It's cool and all for you to get code out there, and if you've got good CD it probably won't screw anything up, but I know my stack at work. I know there are nuances, and deliberate details, and designs, and prioritize and a million other things. How can a person be expected to write a bug fix and truly understand what is h…

At my old job I maintained a list of “up for grabs” tickets. They were all very narrowly scoped, so little judgement would be needed. Things like “the text on this button is misspelled” or “add an extra button to the GUI to expose this existing functionality”. These sort of bugs are good “first week” bugs since most of what you learning is setting up the development environment and interacting with engineering systems (bug tracker, code repo, CI/CD).
Post reply on HN