9 ms·

Optimize Onboarding

142 points by tekdude 6y ago

interrupt_ 6y ago
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 6y ago
  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 6y ago
    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.
    - bigfoot675 6y ago
      I'm interested in why you stuck "avoid on-call" in there. I'm about to start my first on-call rotation next month
      - bregma 6y ago
        Nice. You're about to learn why to avoid on-call in the most practical way possible.
        ornornor 6y ago
        Haha, that’s the best response I think.
tekdude 6y ago
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!
- walshemj 6y ago
  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 6y ago
  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...
  - AmericanChopper 6y ago
    Having contracted at many big corps, I know this situation very well. The worst issues are the fact that nobody really knows what you're supposed to be requesting, the systems you have to use for requesting them are a complete maze, and a lot of the time, you have to request one thing before you can request the next thing (waiting for those tickets to be serviced sequentially, with their multi-day SLAs). But don't stress over it. Your manager definitely knows how bad their onboarding is, and isn't expecting you to be able to do anything about it.
oxfordmale 6y ago
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 6y ago
  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.
  - phist_mcgee 6y ago
    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 happening, when they may not even yet full understand the product yet?
    - lmm 6y ago
      If you're working at these big companies then working in a codebase you don't fully understand will just be a fact of life. I worked at a Fortune 500 company for 4 years, but of course I didn't understand even half of the million-line Scala codebase I was working on by the time I left. The way you make people productive in that environment is you have, and enforce, good coding and design standards so that code will do what you expect and you can rely on parts of the codebase that you don't necessarily understand the internals of. Frankly, having to consider "nuances, and deliberate details, and designs, and prioritize and a million other things" is not a good use of people's mental capacity, and you should aim not to have a codebase where people have to do that. Write your codebase like a tower of libraries/DSLs, where each layer presents a solid abstraction to the layer above it, and the topmost layer is just the business logic written in the language of the domain; then it's easy to make a simple change to that business logic because you just have to make the same simple change to your code.
deleted 6y ago
[deleted]
pathseeker 6y ago
>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 6y ago
  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.
  - slykar 6y ago
    From my experience onboarding means showing you where the bathroom is, giving you credentials for your new emial account, pointing you to a company wiki and introducing you to your new team and then you are at the mercy of your team to "get you up to speed". Stories of some fun activities sound like some sort of novelty to me.
    - tachyonbeam 6y ago
      I've switched employer and been through the "fun activities" recently. All remote though, because COVID. Two weeks of online lectures and "icebreaker" activities. It was a weird experience, and I think the actual, useful information could have been condensed in a single day, instead of two weeks. The actual, useful onboarding, was mostly me asking my colleagues where to find the things I needed to find. I can program, I can learn what I need to learn, I just need some good pointers and for my teammates to be patient, supportive and understanding.
seneca 6y ago
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.
- doteka 6y ago
  An old employer did this, but instead of just at the beginning this was a monthly rotation thing (3 days each month or so). Being forced to do support definitely was a major factor in my quitting. I don’t even mind support so much, used to do it for a job in university. But you don’t hire a highly educated professional and stick them in an entry tier role part of each month, not if you respect them.
stevenjohns 6y ago
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.
deleted 6y ago
[deleted]
blululu 6y ago
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 6y ago
  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.
01100011 6y ago
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.
deleted 6y ago
[deleted]
dougdonohoe 6y ago
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, the HR system, etc) were auto-created prior to the start date. We reduced, as much as possible, the need to manually create or request access to needed systems. Instead, based on your job function, we already knew what you would need access to and automatically made those requisitions. I realize this is easier to do when you are starting from scratch, but it demonstrates that it is feasible. It’s simply a matter of will and valuing the importance of a smooth onboarding experience. After all, you spent a ton of time and money finding this candidate - why not get them productive as fast as possible? Setting up the development environment was also scripted. We had scripts for setting up and installing the tools needed for frontend and backend development. Common aliases and scripts were shared via a shared “dot files”. In most cases, it was possible to checkout the relevant repos, run unit tests, commit code and deploy to production on the first or second day. There is no reason one can’t have all you need ready to go on day one. Certainly things get out of date as time passes, but the expectation of every new hire was to improve the documentation and fix any flaws. This “onboarding as code” mentality also made it easier when an experienced engineer needed to set up a new laptop. Documentation is like a garden - it needs to be constantly weeded and pruned. Finally, there’s the matter of learning the tech stack, code base and current toolset. Again, this needs to be a deliberate, well thought out experience rather than an ad-hoc, thrown into the deep-end of the pool, sink-or-swim challenge. A manager needs to make it their top priority to figure out how to get new employees (or internal transfers) up to speed and confident as quickly as possible. This requires special skills in writing good documentation and figuring out the various learning styles of engineers. I agree - if you onboard, and struggle getting code to compile, can’t find the right documentation about how things work - then it sours your experience with the company. In some cases it feels like onboarding is a struggle and it’s a badge of honor to have survived. That you “made it through” and “paid your dues.” This may work with certain engineers, but I don’t think it is healthy or wise.
- hinkley 6y ago
hashkb 6y ago
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?
- wink 6y ago
  My experience is more that there's always a bunch of tickets/bugs that are a) not critical b) not 5-minute fixes and c) tend to be "we should really..." - those are optimal, because they wouldn't get done otherwise anyway.
  - hashkb 6y ago
    That's a serious problem. Whether work gets done should be independent of whether or not you have new hires around. And what lesson are you teaching if that's how you complete that kind of work? Onboarding is "hey do this thing nobody else will ever do, so we can say engineers ship on day one"
    - wink 6y ago
      I disagree, it's a much more helpful way to let them explore the code base than "here, write a test for some feature you also don't understand". Where I was it was never a stated goal to have them ship asap, the goal was a) to let them learn quickly and b) let them not hate their new job. Incidentally, everyone except one person liked this approach. Hands-on, have the genuine feeling to do something sensible (maybe not important, but hey, it's your first week) and NOT spend 2w just reading docs.
      - hashkb 6y ago
        I think that's a false dichotomy. For example, have new hires pair with someone who is making good progress on something medium sized and medium impact. Share in a nearly guaranteed success, learn, and no need to hoard one-pointers.
bfung 6y ago
The article doesn't provide good context on WHEN in a company's life to optimize EMPLOYEE onboarding. It could even be detrimental to optimize onboarding during the startup stage, when one could've been using the time and resources optimizing CUSTOMER ONBOARDING. When the company is like a 10 person startup, find people who can onboard themselves. When it's like 100 person company, then start thinking about optimizing employee onboarding. Between the 10 and 100, I'd say find that product market fit and onboard customers faster than you onboard employees for a successful company...
wnd_pn 6y ago
From a personal experience, the onboarding process should be gradual and proceeds by steps (which doesn't mean it should be slow). As others said in the comments, it depends a lot on the role the person has (junior vs. senior) but starting a new position in a new company can be stressful for anyone. That is why a business should give its new employees the time to fit in rather than creating an overwhelming environment around them. By doing so, people will give their best and the outcome will be higher at the end. An interesting article I read on the matter is the following --> https://hronboard.me/blog/employee-onboarding-best-practices/ https://hronboard.me/blog/employee-onboarding-best-practices...
- albigiu 6y ago
  i actually agree
bloopernova 6y ago
Anecdotally: The best jobs I've had were ones where I was able to contribute to the team on day 1 or 2. The worst jobs were the ones where it took me 3+ weeks before I got assigned enough permissions to make a single change. Which goes a little against the idea of slowly introducing trust, but these were sysadmin/devops jobs, not coding. YMMV. EDIT: By "best" I mean "most productive, most enjoyable, most memorable". All accusations of selective memory or bias on my part are of course accepted.

142 points by tekdude 6y ago

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 6y ago
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 6y ago
  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.
  - bigfoot675 6y ago
    I'm interested in why you stuck "avoid on-call" in there. I'm about to start my first on-call rotation next month
    - bregma 6y ago
      Nice. You're about to learn why to avoid on-call in the most practical way possible.
      - ornornor 6y ago
        Haha, that’s the best response I think.

tekdude 6y ago

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!

walshemj 6y ago
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 6y ago
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...
- AmericanChopper 6y ago
  Having contracted at many big corps, I know this situation very well. The worst issues are the fact that nobody really knows what you're supposed to be requesting, the systems you have to use for requesting them are a complete maze, and a lot of the time, you have to request one thing before you can request the next thing (waiting for those tickets to be serviced sequentially, with their multi-day SLAs). But don't stress over it. Your manager definitely knows how bad their onboarding is, and isn't expecting you to be able to do anything about it.

oxfordmale 6y ago

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 6y ago
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.
- phist_mcgee 6y ago
  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 happening, when they may not even yet full understand the product yet?
  - lmm 6y ago
    If you're working at these big companies then working in a codebase you don't fully understand will just be a fact of life. I worked at a Fortune 500 company for 4 years, but of course I didn't understand even half of the million-line Scala codebase I was working on by the time I left. The way you make people productive in that environment is you have, and enforce, good coding and design standards so that code will do what you expect and you can rely on parts of the codebase that you don't necessarily understand the internals of. Frankly, having to consider "nuances, and deliberate details, and designs, and prioritize and a million other things" is not a good use of people's mental capacity, and you should aim not to have a codebase where people have to do that. Write your codebase like a tower of libraries/DSLs, where each layer presents a solid abstraction to the layer above it, and the topmost layer is just the business logic written in the language of the domain; then it's easy to make a simple change to that business logic because you just have to make the same simple change to your code.

deleted 6y ago

[deleted]

pathseeker 6y ago

>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 6y ago
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.
- slykar 6y ago
  From my experience onboarding means showing you where the bathroom is, giving you credentials for your new emial account, pointing you to a company wiki and introducing you to your new team and then you are at the mercy of your team to "get you up to speed". Stories of some fun activities sound like some sort of novelty to me.
  - tachyonbeam 6y ago
    I've switched employer and been through the "fun activities" recently. All remote though, because COVID. Two weeks of online lectures and "icebreaker" activities. It was a weird experience, and I think the actual, useful information could have been condensed in a single day, instead of two weeks. The actual, useful onboarding, was mostly me asking my colleagues where to find the things I needed to find. I can program, I can learn what I need to learn, I just need some good pointers and for my teammates to be patient, supportive and understanding.

seneca 6y ago

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.

doteka 6y ago
An old employer did this, but instead of just at the beginning this was a monthly rotation thing (3 days each month or so). Being forced to do support definitely was a major factor in my quitting. I don’t even mind support so much, used to do it for a job in university. But you don’t hire a highly educated professional and stick them in an entry tier role part of each month, not if you respect them.

stevenjohns 6y ago

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.

deleted 6y ago

[deleted]

blululu 6y ago

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 6y ago
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.

01100011 6y ago

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.

deleted 6y ago

[deleted]

dougdonohoe 6y ago

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, the HR system, etc) were auto-created prior to the start date. We reduced, as much as possible, the need to manually create or request access to needed systems. Instead, based on your job function, we already knew what you would need access to and automatically made those requisitions. I realize this is easier to do when you are starting from scratch, but it demonstrates that it is feasible. It’s simply a matter of will and valuing the importance of a smooth onboarding experience. After all, you spent a ton of time and money finding this candidate - why not get them productive as fast as possible? Setting up the development environment was also scripted. We had scripts for setting up and installing the tools needed for frontend and backend development. Common aliases and scripts were shared via a shared “dot files”. In most cases, it was possible to checkout the relevant repos, run unit tests, commit code and deploy to production on the first or second day. There is no reason one can’t have all you need ready to go on day one. Certainly things get out of date as time passes, but the expectation of every new hire was to improve the documentation and fix any flaws. This “onboarding as code” mentality also made it easier when an experienced engineer needed to set up a new laptop. Documentation is like a garden - it needs to be constantly weeded and pruned. Finally, there’s the matter of learning the tech stack, code base and current toolset. Again, this needs to be a deliberate, well thought out experience rather than an ad-hoc, thrown into the deep-end of the pool, sink-or-swim challenge. A manager needs to make it their top priority to figure out how to get new employees (or internal transfers) up to speed and confident as quickly as possible. This requires special skills in writing good documentation and figuring out the various learning styles of engineers. I agree - if you onboard, and struggle getting code to compile, can’t find the right documentation about how things work - then it sours your experience with the company. In some cases it feels like onboarding is a struggle and it’s a badge of honor to have survived. That you “made it through” and “paid your dues.” This may work with certain engineers, but I don’t think it is healthy or wise.

hinkley 6y ago

hashkb 6y ago

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?

wink 6y ago
My experience is more that there's always a bunch of tickets/bugs that are a) not critical b) not 5-minute fixes and c) tend to be "we should really..." - those are optimal, because they wouldn't get done otherwise anyway.
- hashkb 6y ago
  That's a serious problem. Whether work gets done should be independent of whether or not you have new hires around. And what lesson are you teaching if that's how you complete that kind of work? Onboarding is "hey do this thing nobody else will ever do, so we can say engineers ship on day one"
  - wink 6y ago
    I disagree, it's a much more helpful way to let them explore the code base than "here, write a test for some feature you also don't understand". Where I was it was never a stated goal to have them ship asap, the goal was a) to let them learn quickly and b) let them not hate their new job. Incidentally, everyone except one person liked this approach. Hands-on, have the genuine feeling to do something sensible (maybe not important, but hey, it's your first week) and NOT spend 2w just reading docs.
    - hashkb 6y ago
      I think that's a false dichotomy. For example, have new hires pair with someone who is making good progress on something medium sized and medium impact. Share in a nearly guaranteed success, learn, and no need to hoard one-pointers.

bfung 6y ago

The article doesn't provide good context on WHEN in a company's life to optimize EMPLOYEE onboarding. It could even be detrimental to optimize onboarding during the startup stage, when one could've been using the time and resources optimizing CUSTOMER ONBOARDING. When the company is like a 10 person startup, find people who can onboard themselves. When it's like 100 person company, then start thinking about optimizing employee onboarding. Between the 10 and 100, I'd say find that product market fit and onboard customers faster than you onboard employees for a successful company...

wnd_pn 6y ago

From a personal experience, the onboarding process should be gradual and proceeds by steps (which doesn't mean it should be slow). As others said in the comments, it depends a lot on the role the person has (junior vs. senior) but starting a new position in a new company can be stressful for anyone. That is why a business should give its new employees the time to fit in rather than creating an overwhelming environment around them. By doing so, people will give their best and the outcome will be higher at the end. An interesting article I read on the matter is the following --> https://hronboard.me/blog/employee-onboarding-best-practices/ https://hronboard.me/blog/employee-onboarding-best-practices...

albigiu 6y ago
i actually agree

bloopernova 6y ago

Anecdotally: The best jobs I've had were ones where I was able to contribute to the team on day 1 or 2. The worst jobs were the ones where it took me 3+ weeks before I got assigned enough permissions to make a single change. Which goes a little against the idea of slowly introducing trust, but these were sysadmin/devops jobs, not coding. YMMV. EDIT: By "best" I mean "most productive, most enjoyable, most memorable". All accusations of selective memory or bias on my part are of course accepted.