Managing Long Distance Remote Teams

The idea of people meeting daily from locations thousands of miles away is most curious in it's ubiquity. Fifty years ago a long distance conference call could be hundreds of dollars. I even found this old ad for Bell:

Imagine having an hour-long video call where long distance attendees are paying in the neighborhood of $300.00. Today, virtual channels of communication like video chat come at an incredibly small price compared to the value provided. Similarly, the amount of productivity that can be fostered from the careful use of long distance remote teams is very high and fits easily into a budget.

Nevertheless, I see companies struggling to make the most of their remote dev teams. Here are three things I've learned over the years that has made my working with these teams successful.

Treat Remote Teams With Respect

Treating all of your colleagues with respect seems obvious and yet I've seen many managers segment their hybrid teams into first and second class citizens based on location. There is a tendency for managers to assume that it's unnecessary to involve offshore teams to the fullest extent possible. Teams are at their most efficient when they feel encouraged and supported by each other, regardless of where they're located. I always organize an online game with remote teams and the domestic teams they'll be working closely with during onboarding and then at least once a quarter after that. Once we even played Call of Duty together.

Even if a project is being done on a timeline of a month or two, a little goes a long way to build a spirit of camaraderie amongst every walk of team member. Maybe that two month project turns into four months or perhaps another project comes down the chute that needs some extra hands. It costs very little to extend the same respect to remote workers as domestic ones and the rewards are great.

Know the Limitations

Not every task within a company is tailor made for a remotely managed team. Detecting where the helpfulness of having a remote worker ends is important to making the most of their time. As an easy example, a project that involves a lot of meetings during US working hours isn't well suited for someone eight timezones away. I have found a few recurring indicators that certain tasks may not be suitable for remote teams:

• Requires meeting attendance outside working hours in the country where the remote team is located - one thing I'll add here, because this seems like another no-brainer, is that it's important on the outset of a project to think about when meetings are likely to happen before the calendar fills up and it's too late. For instance, will this project require a lot of communication with key people who are strictly on US working hours?
• If the remote team is working on a contract basis, projects where other contracting companies are already involved - generally coordination between teams that hail from different contracting companies is difficult (although not impossible).
• Project has fluid/unknown scope - remote teams that work off-hours are best employed on projects that have tight scope (domestic teams too, but the reality is that scope cannot always be nailed down). Fluid scope basically translates to a higher rate of ongoing decision making between stakeholders which is usually difficult for remote workers to manage

Don't Let The Line Go Stale

A misconception when managing remote teams is that once given a high level directive, the team will be able to execute on it without ongoing communication between them and their domestic counterparts. Compounding the problem is a natural tendency for domestic and remote teams to silo themselves if left to their own devices. More than once I've seen remote and domestic teams begin building duplicate services or even products because they haven't been encouraged to frequently check in with the teams they're working with.

Additionally, the feedback that comes from remote teams is always useful, but too often gets ignored. This gap usually stems from mistrust. Both sides might begin to mistrust the feedback they are getting if not enough time is spent understanding it fully. For instance someone working remotely might send an email highlighting an important bug in code ready to go to production, but unless the people in the recipients list have a rapport with the sender, they might assume that it's not worth the time to take seriously. Maintaining a healthy state of communication between teams will build trust and beget mutual benefit.

Conclusion

Ultimately, augmenting domestic employees with remote staff, whether contracted or full time, can be extremely valuable. Oftentimes you may find high quality developers, QA engineers, project managers and more without sacrificing budget or flexibility. Nevertheless, a poorly managed remote team will only get you so far; to truly see them flourish requires a concentrated effort.