Onboarding, for those unfamiliar with the term, is the stretch of time after an employee is hired. It's often used by development teams to describe setting up a new person and getting them fully engaged with the workflow - everything from signing paperwork to installing hardware and software to learning coding standards to adding rich contributions to the team. In short, turning the new guy into the guy who can be depended upon.
How long is the process? One company I worked at defined (part of) the process as a three-hour lecture, where one unlucky coworker would sit down with the new employee and read pages and pages of documentation. This lecture was both ineffective and terribly narrow compared to the breadth of knowledge a developer needs to began contributing. While it varies a lot depending on the person and the company I'd say that most of the heavy lifting for onboarding is completed within the first two weeks and other areas may drag on for about six months.
For an effective onboard there needs to be a strong effort from the company and involved managers.
A few years ago, as a manager of a small technical team, I made a mistake (one of many). Like any good manager I was juggling several priorities and when a new hire showed up I had nothing ready for him. We spent the first day scrambling, with impromptu meetings to discuss 'a typical day' and using the lunch break to drive down to Best Buy and pick out a computer. While the new employee was nice enough not to say anything I could tell that he was not impressed by our bumbling around.
Searching and accepting a job is a stressful time period. There are too many unknowns when one is juggling job interviews and their current job (maybe), all while trying to decide how they want their career to proceed (more money? more responsibility? new directions?). Accepting a job and showing up should be the solid rock at the end of a stormy ride. A manager needs to be reassuring, certain, and, above all, be prepared for that new hire.
Define the Rules
While spending three hours reading documentation is not a great way to define the rules for a new employee it is important to pass that information on. There are so many little questions that new hires (should) have. Is PTO accrued or available based on calendar year? If something breaks in production is everyone expected to jump on the network to fix it immediately? Should I wear t-shirts or button-up shirts to the office? Spaces or tabs for code indentation? This is an obvious part of onboarding, one that the human resource department should be heavily involved in, and one that I've yet to seen done well.
Define the Real Rules
The rules of employment are important, sure, but there is a whole new level that developers (and most nerds) will need to define at their new job. These are the rules that will help them win at being an employee, that will help them fit in with the group and insure a productive work environment. Some of these rules will be picked up in small talk, some during reviews, and some by accidental violations. During onboarding this is what an employee will probably be the most focused and it should be the manager's interest to define as many of these as possible before violations occur.
Some of these 'real rules' are based on the culture that the team has built up over time. Do people eat at their desk during lunch or does everyone leave the office? What is the flavor of humor in the group chats? Other rules run deeper than culture and can have a large impact on an employee's longevity in. Are there items in the codebase that are untouchable? Will a passive-aggressive commit/tweet about a coworker will it spark a long and bloody feud? Understanding and playing effectively by the 'real rules' make all the difference between the new guy(s) and the rest of the team.
The end goal for any onboard process is… well, to have the developer on board with the team. To transform the new guy into an individual who is contributing to the code base, the cultural, and the overall direction of the team/company. It is not to have them ask less (obvious) questions, though that may be a side effect, nor is it to just get them to sign a piece of HR paperwork agreeing to certain terms of employment.
I've heard of some companies that try to get their new hires to commit a feature on their first week, or even first day (my current job was 'first week'). This is a good way to help out with part of the onboard, to push the new employee forward, yet I feel that it is important to note that this is only part of the entire process. If someone has full access to the code base, has access and understand how to proceed with tasks, and can deploy code to the main base they may still lack some of the fundamental background needed to be an engaged member of the team.
Onboarding is a complex process, one that is rarely smooth, yet there are some basic areas that can help make them effective. By being prepared, fully defining all the rules and expectations up front, and keeping a focus on the end goals, new employees can be caught up and start making meaningful contributions relatively quickly. Of course, this is all assuming that the new employee is fully engaged in the process, but that's a whole other issue.