On board is something technical people don’t seem to think about very often. Bigger companies handle this through the Human Resources department. There is probably a handbook and a series of videos explaining step by step what to do with a new person. IT builds new computers based on employee profiles so that everything is setup on the new person’s first day. The startups I have worked with didn’t have any of this. I had to get my computer setup and figure out what systems I needed access to when someone pointed me to a URL that I couldn’t log into.
I am starting the new year with a new gig, and that reminded me of some of my preferences for the first day on a new job.
The first thing I want, first thing in the morning on day 1, is access to every system — email, Continuous Integration, bug tracker(s), test and development environments, github, and so on. You need access to these systems to do your job, of course, but on the first week these help you to piece together how things are really done. I like to do this as a small list, maybe in a wiki. If IT is getting this set up, then that gives a sure fire way to get everything right (or mostly right, at least) the first time around. If a staff member is getting their own access, then this list means they don’t have to sit around waiting for replies from busy people that met only minutes or hours before. This sounds trivial, but the asking strangers questions, and then trying to wait politely can be stressful. Especially 8 hours of it.
System access is problem zero. Problem one, is what do I do now?
I like to approach that by pairing up with employees that are in a real project. Some companies will try to shuffle the new employee off to read the wiki, or bug reports, or test cases, or whatever at this point. Pairing is an authentic dive into the work, an opportunity to meet people on the team and to contribute a little. A pairing session might give me exposure to real process, different parts of the application from different points of view, and s peek into daily interaction. All of this is relatively low-stakes, too. No one will reasonably expect someone to contribute novel things to a code base on their first day. The new person can ask questions, some of which might guide code design or testing. And, they are pretty unlikely to make mistakes of any consequences.
The overarching theme here is checklists and pairing. Checklists are light weight reminders of each thing a new person might need to be productive on day 2. Pairing with other employees throughout day 1 gives deep perspective on process and practice that can not be described in a wiki or employee handbook. The small companies I have worked with didn’t have any official on boarding because they were too busy building software. Anything that didn’t lead to production was a distraction. This strategy only takes an hour or so of preparation, and saves hours of interruptions when that new person does jump into the fold.