Optimize Onboarding

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.

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.

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

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.