[HN Gopher] Optimize Onboarding
___________________________________________________________________
Optimize Onboarding
Author : tekdude
Score : 42 points
Date : 2020-09-07 20:18 UTC (2 hours ago)
(HTM) web link (staysaasy.com)
(TXT) w3m dump (staysaasy.com)
| tekdude wrote:
| 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 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!
| jeffbee wrote:
| I recently started working at a huge financial concern and it
| was 12 weeks before I got my laptop in the mail.
| walshemj wrote:
| 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)
| lol768 wrote:
| 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...
| user5994461 wrote:
| Pretty good, you had a desk the first day ;)
| oxfordmale wrote:
| Committing 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.
| jrott wrote:
| 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.
| blululu wrote:
| This article rings true, but I can't tell if it's a chicken or
| the egg problem. Are firms with long on boarding processes less
| effective because bad habits are setup and normalized at the
| start, or are they dysfunctional from the get go and
| dysfunctional teams setup poorly thought out onboarding
| processes. At a previous job at a large tech company I was given
| a period of ~6 weeks of onboarding. This was rather excessive,
| but the organization did not have a clear sense of what needed to
| be accomplished in the first place. I doubt that things would
| have been more effective if the onboarding simply a day or two of
| setup.
| PragmaticPulp wrote:
| I had the same thought. At some point, loading employees up
| with structured activities and obligations that aren't entirely
| related to doing their job becomes counterproductive. It can be
| a sign that the company has lost focus.
|
| My favorite onboarding process was to simply give the person's
| team a budget to do whatever they wanted with the new hire for
| a day or two, then get to work. Managers would write up a
| document with all account info, login info, key communication
| info, and then let the teams fill the new person in on the day-
| to-day details while they went out to lunches or went go-
| karting or whatever they wanted.
|
| The more HR tries to structure things, the less effective it
| becomes at onboarding people. Let the teams handle it and make
| them responsible for getting the person up to speed quickly.
| They're closest to the work, and therefore they know best what
| the person actually needs.
| [deleted]
| pathseeker wrote:
| >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.
| PragmaticPulp wrote:
| Agreed. The over-engineered onboarding process can become
| frustrating if it starts to diverge too much from real day-to-
| day life at the company.
|
| It can also be disappointing to go through a multi-week
| onboarding full of outings and lunches and fun activities, only
| to discover that the real job is nothing like the onboarding.
| Then you have to learn how to actually do the job after the
| onboarding.
|
| IMO, the best onboarding strategies give the current employees
| and the new hire some room to get to know each other naturally,
| without forcing it into overly structured activities. For
| example, giving the whole team a budget to go out to a long
| lunch with the hire 3 days per week on the first 2 weeks.
|
| Unless you have a team of lone-wolf type or antisocial
| developers, usually the person's peers have a better idea of
| how to onboard a person than a manager several steps removed.
| Or worse, a person in HR trying to imagine what a good
| onboarding activity looks like for engineers.
| seneca wrote:
| I 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.
| 01100011 wrote:
| Obviously it depends on the role and the seniority of the new
| hire to some degree.
|
| I think, as a senior embedded software engineer, the first couple
| weeks (months?) should be spent with the last new hire figuring
| out tools, processes, and keeping internal documentation up to
| date as you go. Questions should be escalated as necessary, but
| generally this should not involve much interaction with more
| senior engineers so their work is not interrupted. New hires
| should start out with big fixing tasks and not be expected to
| participate in architecture or feature creation yet. If they
| display the ability, fine, but set the bar low.
|
| Some companies I've worked at have such complicated development
| workflows that it regularly takes 3 months for an engineer to
| become independently productive.
| stevenjohns wrote:
| This isn't great advice for technical hires. Maybe for seniors
| experienced with the stack, but for anyone else you'd get a lot
| more mileage out of the on-boarding process by having them do
| stack-related tutorials, explaining things like the deployment
| process and setting the standard for collaboration/communication
| within the team.
|
| Ultimately what it comes down to is that lazy engineers will be
| lazy and that motivated engineers won't lose their spark just
| because they spent a week meeting the team. The author seems to
| think that the opposite is what takes place both counts. I don't
| agree with that.
| interrupt_ wrote:
| I 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.
| laurent92 wrote:
| But this is still something we should teach youngsters. Interns
| this summer started again they second-day standup with
| "Yesterday I installed my computer, and today I'll finish bug
| 1". Which is good until you notice that he intends to stay all
| night long and do more than expected, to exceed expectations.
|
| And that is how you burn out. In fact, exceeding expectations
| takes a lot of talent, because you need to exceed in the
| correct directions. And often, you burn out because of the lack
| of recognition. It's a real talent that takes years to learn,
| not the kind of heroic behavior that someone should strive for
| in year 1. In year 1, just learn 3 frameworks at home and
| change jobs often ;)
|
| About the intern: By the middle of the second month he settled
| down to developing the minimum features that satisfy a maximum
| of users, but polishing the bugs and buffing out the UX (first
| impression, etc) and that was awesome, by the third month he
| was productive at this and came back to school. Damn I didn't
| notice he'd learnt so much, but totally outside of programming.
| I guess the lesson is programming is long if done correctly,
| don't expect to do everything by tomorrow or you'll risk
| lowering the quality.
| PragmaticPulp wrote:
| It's important to teach juniors the importance of avoiding
| burnout. As a manager, it's not very difficult to gauge
| burnout by keeping an eye on time spent in the company Slack,
| when e-mails are spent, timestamps on commit messages, and so
| on. More importantly, building a genuine relationship with
| the employee is important for keeping the conversations open.
|
| Having someone try to stay all night to get work done on day
| 1 isn't reasonable, obviously, but I wouldn't go so far as to
| discourage people from trying to exceed expectations. I'd
| always love to tell young people that they should relax,
| never work more than 40 hours per week, never stay late under
| any circumstances, avoid on-call, and so on, but then I
| remember that much of my early career success came from
| exceeding expectations when the situation called for it. That
| doesn't mean everyone should be crushing it 100% of the time
| or sacrificing themselves for the company, obviously, but in
| the real world it often requires going above and beyond if
| you want to move up and get ahead.
|
| Many interns have no baseline, so they're constantly in fear
| of getting fired. I think it's most important to set clear
| expectations and to provide constant, honest feedback. Once
| they get over the irrational fear of getting fired, they can
| start deciding how much, if any, additional effort they want
| to put in to the job. I'd be lying if I told the interns
| they're all guaranteed return offers, so I can't honestly
| tell them that they don't need to do better work than their
| intern peers. It's best to explain the situation as clearly
| as possible and let them make their own decisions.
| [deleted]
| [deleted]
___________________________________________________________________
(page generated 2020-09-07 23:00 UTC)