When first leading distributed agile teams, a key challenge that can sneak up on you is onboarding a new team member. You cannot show them around the office. You cannot take them to lunch with their new distributed team members. How can you possibly get the new person-oriented to their new organization and their new team? My secret: Get the organization and team to help you—and start onboarding before they do.
First, it begins with an interview team that assesses the candidate’s abilities and introduces them to the unique distributed work environment. Second, an onboarding team is formed with a primary mentor to guide a newly hired team member to connect with appropriate subject matter experts inside and outside their new team. These steps allow the new team member to quickly become a productive member of the distributed agile organization.
Start in the interview
When you are in a fully distributed organization, it’s important that you not only interview job candidates for their technical skills, but that you also check their ability to work in your distributed agile environment.
This means you need to do a little homework. Part of the homework is talking to different teams in your organization to see how they deal with time zones, agile ceremonies, team working agreements and collaboration tools (video, screen sharing, chat, etc.). You may find that each team in your organization handles these differently. Often the best way to represent these different perspectives on distributed work is to form an interview team, with members coming from different teams that a candidate may end up working with.
You should also understand the differences between the current teams and also note their similarities. Then you can formulate questions for team member candidates on how they handle some of these scenarios your teams face now. You may even have more than one person on your interview team dive into this particular “distributed work” topic with the candidates.
If the candidate has prior remote work experience, you may only have two members of the interview team ask questions about the candidate’s remote work style. If the candidate has little remote work experience but excels in other areas, you might have each member of the interview team ask about a certain aspect of remote work.
Keep in mind that what you are doing in an interview is trying to evaluate a future partnership with the potential candidate. So you want to provide opportunities for them to evaluate your unique distributed work environment as much as you are evaluating their fit into the organization. No one wins if you have a brilliant technical candidate come onboard but then feels isolated by the distributed work environment and then leaves after a few months.
With that in mind, I do more than ask questions when it comes time for the interview. I also explain the similarities and differences between the work of the different distributed teams. I will explain how this may change as the distributed agile teams inspect and adapt into new ways of working. This helps the candidate consider if this environment is a good fit for them. If they feel the job is still interesting, then you have already started some of their onboarding by introducing this unique aspect of your distributed work culture.
Peer mentoring over solo mentoring
When a new team member joins, there are different time periods where they need to collaborate with different people. In the book Peer Mentoring by Steve Trautman, he outlined the need for a primary mentor to oversee the onboarding process and then introduce a number of subject matter expert mentors based on particular skills a new team member needs to learn.
For distributed agile teams, it may make sense to have the agile coach or ScrumMaster serve as the primary mentor and set up an onboarding kanban board for the new team member (as shown in Figure 1). Then the primary mentor can coordinate with the new team member through updating this board, connecting with expert mentors to help them through the steps and be able to signal when they need help.
Usually, the expert mentors can be identified by specific time-based milestones. The first day on the job usually involves the typical new employee paperwork and getting them “wired” into the various communication systems and tools. Using the onboarding kanban, the new team member can quickly indicate what steps they are working on their own and which they have completed. It also helps if the new team member is given contacts from the primary mentor for other expert mentors (usually the HR and operations teams) as needed.
The first one to two weeks is then getting oriented to the work of their new team and the team itself. In this phase, the new team member is learning how the distributed agile team plans, communicates, coordinates and reviews the work products as well as the process. If the team is following a two-week iteration cycle, a new team member can observe the entire cycle quickly. I’ve found a check-in call with the primary mentor every one to two days also helps answer questions that pop up from this observation period.
Also, the new team member has the task on their onboarding backlog to set up one-to-one meetings with their team members. Through these chats, they get to know the skills and backgrounds of their different team members. Some embrace this, and others might need some “starter questions” to get the conversation going—but everyone on the team finds this time valuable. I discovered that experienced team members find this valuable to think of other areas where the new team member can contribute.
The next month is then getting them involved in the work of the team. This usually means that the new team member is given some options on good places to start for an upcoming iteration. These “starting points” may vary by team. Some teams prefer new team members to start with bugs to get comfortable with the code base. Other teams prefer the team member to start with a small user story so they feel they are directly contributing to the code base.
Regardless of the choice of starting point, it should be clear to the new team member and the rest of the team where that starting point is, how and when help is needed and how to receive feedback on the work. We do not want the new team member to struggle and become discouraged.
In some cases, a senior member of the team may volunteer to work with the new team member for a couple of days to walk through relevant parts of the code and suggest some options based on their knowledge of the rest of the code base.
Don’t forget to check in
After the first couple of weeks, the new team member typically starts to work well with their new team. However, as the primary mentor that does not mean you should take your eye off them. It’s good to occasionally check in with them, see if they have what they need, ask where they may be struggling and just give them another opportunity to ask questions. It is also an opportunity for you to get feedback from them on the onboarding process in order to help improve things for the next person joining the team, whether it’s next week, next month or next quarter.
With these approaches, I find that there is minimal disruption to the distributed agile team—and the new team member is able to contribute quickly to the work of the team.
A previous version was published on ProjectManagement.com March 8, 2017 by Mark Kilby.