Optimize Onboarding
staysaasy.com
staysaasy.com
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.
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.
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.
I run a fully remote team and am always looking for ways to make a new member feel comfortable, and the existing team comfortable with the new person... or at least less-awkward.
Also, anything to specifically avoid?
Payment at the hotel will foul up. I want overcharges and idiocies on my card and not on my employee's.
Access cards and tokens will foul up. I need to meet the new employee the first day on the morning and probably for lunch.
Network account provisioning will foul up. I need to see what the problem is and go escort the process through.
Lots of people will blow them off for asking beginner questions. I need to be around so that people answer the question properly.
The presence of a manager means that everybody who normally just fluffs off onboarding will pay fscking attention.
As for timelines, it takes about three months for a new employee or intern to no longer be actively hazardous. It takes another three months until they become a positive force for productivity.
Yes, during that time they're doing something useful otherwise they won't learn, but they're generally a productivity drag until about 6-8 months in.
I also agree with the helicopter aspect as well, that’s a key insight on your part and I bet your team likes your mangement style (mostly :)
I dislike when employers don’t structure their expectations accordingly. I once worked somewhere where we almost lost one of our most talented developers (in terms of productivity and quality and insight, a real rock star) because initially failed to understand this. Thankfully our director stepped in and made it right.
Great lesson to have learned early in my career
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.
"A group of new trainees got an additional hour of on-boarding focused not on the company but on the employee. They were asked questions like: What is unique about you that leads to your happiest times and best performances at work? They were asked to imagine they were lost at sea and to consider what special skills they might bring to the situation. At the end, they were given a sweatshirt with their name. Trainees in the latter group were much more likely to stay longer in he company than trainees that went through normal on-boarding"
https://hbr.org/2015/11/the-powerful-way-onboarding-can-enco...
This could be a whole forum. In the most important sense (the moral sense), we are not. It's a bad road to go down, thinking of other people this way.
OTOH, we are very much like dogs... a lot moreso than we usually think. It's very useful to remember this and "train" yourself. We tend to assume that we are rationally driven, and sometimes we are. More often, we (me, certainly) are impulse driven and rationalize ex post. The neurochemistry of learning, habit forming and such is something we're better working with rather than against.
Re: onboarding...
I agree with the author that this is important, and usually badly done. I disagree on the particulars.
First, HR and boilerplate management stuff tends to do a pretty bad job onboarding.
"Endless HR videos, slow security processes, a mountain of fragile technology setup"
This stuff sets the tone for culture, and it should be a lot better. Considering how many people these days are explicitly responsible for this stuff in a modern company, it should not suck like this.
I disagree about the "social, light hearted, get-to-know-you stuff." We need more, not less of this. People need to know who they're working with and have as little barrier to asking a wide range of people a wide range of questions.
I do agree that the initial period needs to be taken advantage of. One reason is the "dog training" aspect. Habit forming and such. Good advice in general, not just for work. Build your habits intentionally, especially if you (like me) struggle with bad habits. More specifically for work, use this very limited grace period to ask dumb questions, sit in on stuff and such.
If you (as a manager) put newbies onto boilerplate stuff for 3 weeks, you are wasting the opportunity (of the newbie) to encounter real problems while that grace period is in effect. It's a lot easier to ask "where do I see bugs" on day 8 than day 80. These inevitably come up once real work starts.
This was at a top5 website company.
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.
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.
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!
I was told to learn FORTRAN IV from McCracken (A Guide to Fortran Programming)
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...
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.
I spent the whole time watching compliance training videos, no joke.
The probably unintended double meaning works great
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.
It was a 6 month contract and at the end of it they still had not gotten me badge access to the area I worked in.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
For the first, day 2 seems plain irresponsible, but for the latter, day 2 seems ambitious, but possible.
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...
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.
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.