We all have experience working with remote teams. And it's most likely not a very good experience. Remote is hard. Many experienced professionals will tell you that the shortcomings outweigh the benefits and that, therefore, companies should not allow dispersed teams. But we all know better - ain't gonna happen. The lure of cheap labor is too strong for the executives. So, remote teams are here to stay - at least for a while.
One of the most painful problems that I have experienced with remote teams is the communications issue. Mostly, the members of the remote team are very good professionals. They know their job. They have to. They have to prove themselves even more than the local team members. The problem is the difficulties in the communications. Distance also means time. They are not only far away, they are also usually asleep when we are awake and visa versa. They have a different culture (including work culture). But the most important factor (IMHO) is: Being remote means not being involved. Not that they don't want to. The time-space difference just makes it so hard. And it goes both ways. Not only are they not able to be involved with our work, we can't be involved with theirs. So we are all familiar with frustration around this disconnect. If we don't understand these dynamics we just conclude that they are just lousy professionals. Those of us who are more experienced know better: it's the communications, idiot!
Now, you are the PM and you have a local team plus a remote one (or more than one). How do you handle this communications problem? Well, the first thing you should do is probably something you haven't considered: try to see if you can avoid the remote team altogether. Yes! Remote teams are not something from God. Just from the executives. Your first reaction should be: "Do I really have to work with them?" Find the answer to the following:
- Do I need their skills in my project?
- Are there available local professionals who can do the same job?
Assuming you must work with the remote team, how do you handle the communications problem? Textbooks offer a variety of techniques (email, con calls, Video conferencing, status reports, etc.), so I'm not going to repeat that here. Textbooks can do it much better than a blog. What I'm going to recommend is one technique which is slightly more radical but has proven extremely beneficial. Not theory, real experience.
The idea is: have an engineer from the remote team come and stay with the local team and act as a liaison between the local and remote teams. The engineers from the remote team will rotate in the liaison role. Each engineer should stay for an extended period (typically one to three months) so they can get really knowledgeable about how things work locally. This person will spend a significant period of his/her time on the following:
- Talk with team members to get to know them well.
- Thoroughly learn the product (code, docs, etc.)
- Learn and understand the local team's development "culture" (tools, processes, etc.)
- Learn and understand the business aspects (time pressures, clients, executive perspectives, etc.)
- Participate in most meetings, to understand exactly what is going on with the team, product and project.
- Be the main communication "tool" with his/her "home" team. Typically, have a regular, daily (probably more like nightly) phone call with the remote team to update them on what has been going on locally and ensure that the remote team is well updated.
- Represent the remote team locally.
Needless to say that this also has disadvantages:
- Costly. You have to pay for the liaison's transportation, food, accommodations, etc.
- Complicated logistics.
- A large chunck of the liaison's time is spent on the communications part, so they contribute less to the generation of the product artifacts.
- Their time schedule is typically somewhat shifted - they work late into the night and report to work late in the morning.
Let me know what you think.