>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.
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.
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.
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.
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.
Quite so. In addition, as a manager of a new employee I make an absolute point of being a "helicopter mom" from the moment they hit the area until about week 2 or 3.
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 100 percent agree that it takes up to 6 months on average for most developers to become super productive in a code base and at least 2 months for them to be at the comfortable but still not sure on everything phase.
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.
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.
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.
There is a study that seem to show that designing a great onboarding experience can make a big difference down the road. In the book "Culture Code" one study is ascribed:
"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"
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.
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.
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.
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.
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...
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.
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.
It can be alienating. When this happens to me I try and think “this is their money, if they want to set it on fire it’s their prerogative, I get paid either way”. But yeah easier said than done.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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"
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.
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.
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.
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.
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.
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?
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.
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).
In git terminology, I'm both confused if you and the author mean "commit == push changes meant to go into production" or "commit == starting work locally (e.g. on a tutorial)".
For the first, day 2 seems plain irresponsible, but for the latter, day 2 seems ambitious, but possible.
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...
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...
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.
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.
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.