The Wonderful World of Onboarding, or "Hey, do you remember the password for the build machine?"

You are hired new. Or, you're hiring someone new. New hires are expected to hit the ground running, which is fine as long as the have the tools for their run.

As a manager, you're job is to have those tools--at least as much as you can--ready and waiting for them for day one. As a person being hired (perhaps being hired as a manager), your job is to acquire those tools as quickly as possible without being a pain in some new co-workers tuckus while you do it.

Both cases require you to think like you are the person being onboarded, as you want to look at the experience from the perspective of the person who needs the tools (and, of course, if you are that person, all the better perspective).

1) How are you going to communicate?

This question encompasses process, technology, and knowledge that you need to acquire quickly in order to succeed: how to know who knows what and when and what is okay to ask them.

Let's start with technology:
o You'll need a working phone that allows you to dial internally, externally, and allows you to set up and access voicemail.
o You'll need email access (sending and receiving).
o Does the team use Instant Messaging to communicate? This needs to be set up for you, too.
o Is there a common share where documents, useful urls, etc. are kept? Maybe a SharePoint? Access to this share/SharePoint needs to be made available to you.
o Timekeeping systems, are they in use? Are you set up to access? Do you know how to use them?
o Tech to do your job; this varies depending on your job. Do you need bug database access? Source control access? Access to the build machine? Access to the FTP servers? Access to download the proprietary software used to to build the code? Access to the web browser software to manage project management tasks? Automated tools access?

Process:
o You need to be invited to all the regular meetings: daily, weekly, team, etc. Those have to get on your calendar somehow. It does help if you have access to your calendar.
o Reporting: is there a reporting process on progress that needs to be made verbally (say in a daily meeting or weekly 1:1) or in a written form once or twice (or more) per week? Is there a format you need to learn/have access to?
o Team processes, rules, and mores: you need to know how the team does specific things so you can do no harm when starting to do your job. So, for example, is the normal method of defining variables camel case? Do tasks get entered under user stories in the project management tool? Is the expected results and actual results section of the bug report before the body of the reproducible steps? When do you stop arguing your point of view in the group (does quitting early lose you respect but arguing too long cause you to be ignored)? Does the team wander out to lunch together every day, and you should probably go at least once a week or every other week so they know you feel like you're part of the team, or is the lunch imposed by higher ups who think its a great idea but no one ever goes?

Knowledge:
o Tech to do you work: who knows what that is, how to help get you set up, and who can troubleshoot with you when things go horribly wrong (tm)?
o Communication of social rules, mores and already-made-technical decisions: who is going to advise you on how the team writes code, what to avoid in the deli, and the team definition between a bug and a feature request?
o When those two point people--tech and communication--aren't available, who are the fall back folks?
o Who might you should get friendly with outside your team? I generally recommend making nice with admins and executive assistants, because, a) they tend to be extremely nice people or they don't last long in their jobs and b) they know EVERYTHING.

Finally, how do you communicate these meaningful pieces of information?

As the manager, when the employee comes in, write up an email with this data in it while having your first 1:1. Include who can help, and other friendly faces in the organization. Pre-load the links and usernames and passwords, where possible, so you can leave time open for answering questions about the materials and the people.

As an employee, when you first come in, see to your basics first: phone and email. Make friends with the people who sit near to you (but try not to annoy them). Schedule a meeting with your boss and set the agenda to cover these basic items. While waiting for that meeting, go visit the front desk and chat with the admin about where supplies are and ask him/her how they are doing.

Once you as an employee have the basic information, make a folder for it on your computer and one on your email, and start putting every new thing, every new url, ever new password into both places.

As a manager, work with the team to arrange for a single location that connects to all the necessary things, so that, in the future, the email you write with the employee is considerably shorter, because he or she can go to this location and delve into the depths for all the information they may wish to know.

Also, as the manager, try to arrange for a lunch with the team either the first day or sometime in the first week. Give people a chance to talk to the new guy and, if your budget allows, pay for the lunch so people will actually COME. Too many people see new folks as a potential problem or burden; while one free lunch is unlikely to undue all that potential worry, it's a good start to a soft step with a new person.

If you are new and no lunch has been set up, ask people to lunch with you. You're going to have to talk to them sometime, and doing it when you can shove food in your mouth rather than answer, immediately, an awkward question puts the odds in your favor of making a better initial impression...just as long as you aren't constantly shoveling food. Make sure to ask about other people, make occasional eye contact, and really listen; occasionally repeat back what you've heard so they know you are listening to them. The first doors of trust open if people think you are actually paying attention to them, and the good kind (not the stalker kind).

Onboarding is never an easy time--the whole team is disrupted, and of course, the new guy is, too. But it doesn't have to be very long or very bad, and it can certainly help set the stage for a new, successful team member and a stronger overall team.



What to do when bringing a new person on board/into the group. --tech --communication --team introduction --etc.