Working with Remote Team Members

Working remotely is on the rise, even within game development. As you put your ideal team together, you may find someone who is a perfect fit who, for one reason or another, is unable to physically be in the office with the team. You may also find yourself working with off-site freelancers, and while they are not full-time employees of the team, they should still be treated as members. There are pros and cons to working with remote team members.

One advantage of this is that the pool of available talent is larger. You have more people to choose from, and since they don't have to relocate, they have more choices as well. You may find someone in a different country who has the right set of skills for what is needed. People who work remotely are often more productive since they don't have to deal with the small interruptions that happen when working in an office. Remote workers have more autonomy over their schedule and work-life balance. All of these things make working remotely attractive.

Disadvantages revolve around relationships and communication with the team at large. As a remote worker, it can be hard to build relationships and trust with on-site team members, which, in turn, can impact the quality and speed of work. Communication can be fragmented since the remote workers won't have the benefit of face-to-face communication or people dropping by their desk to see what they are working on. There can also be some confusion in terms of tasks and responsibilities, especially if these things are not defined clearly from the outset. If people are located in different time zones, scheduling meetings can be difficult (especially if their working hours are opposite). Language could also be a barrier if working with people from different countries.

If you have remote team members, here are a few ways in which you can improve the working relationship and integrate them as fully as possible into the team:

  • Introduce them to team (in person is best): When remote people start on the team, try to fly them to the office and have a kickoff meeting with them and the team. Ideally, they can stay the week, hang out with their teammates, learn how the pipeline is set up, ask questions about their work, and so on. The team will get to know this person, and it will be easier for them to establish a working relationship.
  • Establish multiple lines of communication: Be sure the remote people are included in the appropriate mailing lists and meeting invites. They should also have access to any group chat areas (like Slack or Google Hangouts) and have theability todo video conferencing. If they are integrated into the day-to-day communication outlets for the team, it is less likely that they will miss key information.
  • Have a "water cooler" area: One of the biggest drawbacks of working remotely is that it is hard to establish camaraderie with the team. It's nice to create some type of virtual "water cooler" where people can ask questions, be social, and feel like they are part of a team. It takes a bit more effort from both the remote and off-site workers to maintain this, but the results are worth the effort.
  • Schedule regular meetings: Consistency is also important in creating a sense of camaraderie with off-site and on-site team members. If you have regular stand-ups, have them at the same time every day and be sure to dial in so remote team members can join. Make sure remote team members are also included in team-wide or company-wide meetings, if applicable.
  • Clearly define their work: When people work off-site, make sure what they are working on is clearly defined. They will be working for several hours or days at a time on something without the benefit of immediate feedback from other team members. If they have clearly defined work and know who they should talk to with any questions, it helps improve the quality and flow of the work.
  • Integrate their workflow with your teams: Make sure remote workers have their source control, email systems, calendars, and anything else integrated with those of your team. They should be checking their work into the same source control as the rest of the team, and they should also be part of the same approval workflows.
  • Check in frequently: The person who is directly managing the offsite worker should check in with them frequently, at least once a day. Checking in during a stand-up is fine as well. The goal is to have daily contact to ensure that the off-site person hasn't run into things that are blocking their work, and they don't have anything else to discuss.
  • Have some working hours overlap: It's nice if the working hours of the remote and on-sight employees can overlap. If the time zones are too far apart, this may be difficult. At a minimum, try to schedule the daily stand-up at a time when everyone can be present either in person or on the phone.
  • Give them a tech support contact: When people are working remotely, they may run into issues that require tech support. For example, they might be blocked from checking things in, or they may not be receiving emails. A lot of time can be spent trying to troubleshoot, and I've found that it is much easier to make sure they have a reliable person in the company's IT department that can help alleviate any technical issues.



It's going to sound super obvious, but regular, structured communication with the team is the biggest force multiplier. I worked with a team of senior engineers that didn't set up any kind of meetings or daily stand-ups, and it was a train wreck—people would go off into their own corners and work on something, and when we started integrating, everything would fall apart. I remember there was a feature I wrote when I started that job that someone would break literally every 3 days.

Peer review becomes more important for distributed teams; it's easier for an isolated developer to stray when they're not involved in the regular day-to-day conversations that happen in an office. This has the caveat that peer review done poorly can significantly hamper productivity.

My best peer-review experience was when a single tech lead had ownership of the reviews and gave feedback in a one-on-one conversation after changes had been made. We were never blocked on reviews and could properly prioritize review feedback.

Conversely, my worst peer-review experience was when anyone could review work, the conversations about the review happened out-of-band in a forum, and the review was required before changes could go in. The undefined review ownership coupled with the elongated discussions meant that features could sit in the queue for days (or frequently weeks) before getting into the game. This pushed back integration and testing, and increased the likelihood of developers stepping on each other.


Time spent defining roles and responsibilities and picking the right leads for your team is worth the investment. A team organization chart is also useful for further clarifying people's roles and who is responsible for what. Now that you have an idea of how to organize the team, think about ways to manage it. Chapter 12 discusses things to keep in mind when trying to build an effective team that works well together.


< Prev   CONTENTS   Source   Next >