Ask the experts: Adding a new member to a dispersed team

Bringing a new member into a distributed team poses special problems. How do you introduce your team’s culture, rhythms, and practices to a new coworker when they can’t sit in the same room with you? I asked some seasoned remote-work pros for their advice. Here’s what they had to say.

David Browning of Two Guys had this to say:

• Bring them into all methods of communication.  If necessary, explain the differences between each and what they’re used for (Skype vs Campfire vs Basecamp vs whatever-tool).
• Preferably you have a standup, so having them talk and hear others talk is a good way for everyone to feel more comfortable speaking their mind and getting to know one another.
• Nudge them to speak more if they’re shy at first, once they open up you should be good to go.

Rob Dempsey at Life of the Freelancer had plenty of wisdom to share from his days running distributed software teams:

The way I handled this was having a shared set of Google Docs containing all of the pertinent company, team, and project information. Each time a new team member was hired on, we would do some type of group chat, and I would introduce him or her to the team. I would then go over all of the documents with the new person, and bring them up to speed.

Also remote pairing was very helpful, in terms of putting the new team member with someone else that was working on the project. I made sure that they scheduled some time to work together.

I also made sure that everyone was in continuous communication with each other via Campfire, Skype, and IM. I would also have bi-yearly meetings where everyone would get together in person, usually at some conference, and spring for a team dinner. This kept people feeling a part of.

Of course, the hiring process is very important. For instance, I would look for people that were very good at self-managing, wanted to work from home, and had a life outside of work. This helped to ensure that each team member could work alone when necessary, and got their fill of “people time” outside of work time, which in of itself was flexible.

George Anderson of Benevolent Code, LLC – one of my current dispersed-team collaborators – offered his thoughts:

When bringing a new member onto a team I think it’s of primary importance to explicitly dedicate one of the stronger veteran team members to shepherd him through the “onboarding” process.  It’s been my experience that the need for such hand-holding is usually severely discounted to the detriment of the teams short- and medium-term velocity.  Projects with any significant life span accrue a tremendous amount of context and institutional knowledge.  However, that context and knowledge builds up over time, and veteran members (and their managers) don’t realize the cumulative effort required to acquire it.  The veteran is the slowly boiled frog; the newbie is thrown straight into the boiling water.

…when you’re a newbie without a “shepherd” it’s overwhelming, demoralizing, and incredibly ineffective.  What the new member needs is a dedicated resources to first provide context and history, then later be a readily available resource to which the new member can turn for the inevitable questions that arise as the newbie starts doing actual work on the project.  The newbie’s knowledge is most efficiently gained when he can dictate the pace of its accrual.  Slow him down by making him wait for answers, or figure them out on his own, and the acquisition of critical knowledge becomes stifled, haphazard, and inefficient.  This means the veteran will temporarily be slowed down as she passes her knowledge to the newb, but this slowdown is short-lived .

Pairing a newbie with a veteran also serves to build relationships - throughout the team.  Why?  The relationship between new and veteran is almost a given.  Most veteran team members will find great personal rewards in shepherding someone along and watching them “get it.”  The new member feels valued, supported, and cared for.  But as the newbie increasingly “gets it” he will naturally start to interact more freely with the other team members as he feels more confident in the pertinence of his questions.  And the other longtime members of the team, having been release of the burden of “ad hoc community onboarding” of the newb, will more freely interact with the new team member because his questions now are more salient and insightful.  He’s no longer “wasting my time.”  Should the newbie discover a hole in his knowledge, he can still go back to his shepherd/mentor and ask her to fill in the gaps, outside of the main flow of team communication.

Benjamin Brinckerhoff, another experienced software team leader, gave four recommendations:

• For any team, team workflow is a balance between communication on one hand and eliminating distractions and interruptions on the other. After bringing on a new employee, adjust the team workflow to favor more communication at the expense of introduction distractions. Daily standups are the bare minimum. Use chat (IRC, Campfire) instead of status updates (Yammer, Present.ly). Consider leaving video chat on for long stretches (even when nothing is happening) to lower the barrier to communication and to quickly integrate the employee into the team culture.
• Pair program if possible, although I’m still looking for tools that enable seamless remote pairing.
• Plan to have the new employee visit an established team member within the first few weeks (not immediately, because you want the employee to be mostly ramped up before the visit to maximize the effectiveness of the trip). Have the existing and new employee work together and do some social activities. The goal is to introduce the new employee to the team culture and start a personal relationship so everyone gets over the “politeness barrier”. Within a month or so, the new employee should feel comfortable pointing out bad code/practices without anyone taking it personally.
• Be flexible! Just like the culture and processes of a company will change slightly with each employee, be extra careful to adjust the remote workflow as necessary. The new employee may have restrictions that were not present before or might have great suggestions on tools/processes that the team hasn’t considered.

Finally, Shane Pearlman of Shane & Peter had a concise but powerful insight:

We struggled with how to do it for years, but it became much easier after we put our company culture into words.

For Shane’s company, the culture boiled down to four words: “happy, helpful, curious, accountable”. Your team’s culture will have it’s own values, of course; but whatever they turn out to be, being able to enunciate them will go a long way towards helping a new member to be assimilated.

What about you? What strategies have succeeded – or failed – in bringing new team members up to speed quickly?