Define Your Onboarding plan for New Hires to Create Personal and Team Success

Tim, a first-level manager, asked me, “Is it reasonable for someone to quit after just a week? With no notice?”

“No. What happened?”

“Sam, a new developer, started on Monday. He told me today, Friday, he's not coming back.”

“Did he say why?”

“He had a whole raft of reasons. He had too many questions: how to use his expertise to contribute to the team; who was actually on the team; and the processes we use. He decided to take another offer.” Tim paused. “If we were in the office still, I could have convinced him to stay. Or I would have seen what was happening.”

“That might be true,” I said. “But you can plan now to integrate people onto any team, collocated or distributed.”

Everyone needs to know how they will contribute to which team or product, and how. Here are my three tips to create a great onboarding experience.

Tip 1: Define the W's for Day One in Advance

When we start new jobs, we need to know:

• When and where do we work? Where do people start and when? If you have a distributed team, when do people tend to start work?
• Who will meet the person on the first day? (See the buddy idea below.)
• What does the person need to know? Is there an FAQ or some other material the new hire needs to know in advance?
• For the product or the work, what is the purpose of the work? (the Why)

Those are the Who, What, Where, When, and Why. Now, let's move to how to integrate a new hire.

Tip 2: Integrate a New Hire With a Buddy

I wrote this How2Create a Buddy Program article years ago. The principles still are correct:

• Make sure the buddy is a peer
• Ask that the buddy wants to work with the new hire.
• While I prefer that the buddies decide how to work together, consider asking them to pair on the work.

Now that we know more about mobbing/ensemble programming, consider asking the team to mob with the new hire. The more I see teams mob, the faster they all learn together. The team integrates the new hire—and the new hire can feel productive right away.

And the more your team is distributed, the more you need a buddy to integrate the person onto the team. Mark and I wrote about this extensively in From Chaos to Successful Distributed Agile Teams.

Tip 3: Use Checklists

I need checklists to make sure I remember “everything.” I offered checklists in Hiring Geeks That Fit. (See the Templates page for all the checklists.) I updated them in Checklists for Hiring Remote People. In addition, Mark and I offered more ideas in the hiring chapter in From Chaos to Successful Distributed Agile Teams.

You might need different items on your checklists.

Remember: Regardless of your approach, product development is team-based work. Involve the team from the first day, so you engage people right away and retain them. The team and the person will succeed. And so will you, as the leader.