Saturday, December 23, 2006

The Engineer as a Communication Tool for Remote Teams

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?
Go to your manager/executive and try to convince them to allow you to replace the remote team with locals. I know that this attitude does not sound so nice. Where is the team spirit? Where is globalization embracing? Where is your tolerance for openness to other cultures? You know... My answer is: if the project fails, nobody will give you credit for having team spirit, embracing globalization or being open to other cultures. Your job and commitment are to complete the project successfully and if you think remote teams are a risk, it's your responsibility and right to try to eliminate this problematic element. Now, we all know that you don't have a lot of chance to succeed. This is usually something that is imposed on you and it's not optional. But it does not heart to try and who knows, maybe this is going to be your lucky day...

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.
I think that the benefits of this technique are veryu clear to see. I have experienced this twice in my career and was very happy with the results.

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.
Yet, my experience is that the benefits of this arrangement far exceed the disadvantages. I highly recommend this. Talk to your manager tomorrow.

Let me know what you think.
---------------------------------------------------------------
Technorati Tags: , , , ,
---------------------------------------------------------------

2 comments:

David said...

Excellent post Moshe!
Engineers acting as liaison between remote teams is indeed a very efficient tool.
You touch on a couple of challenges which I've faced dealing with teams in disparate locations:
1. cost: as you mention, the cost of rotating engineers from remote teams might be prohibitive - and as a PM you might simply not get the green light to go for it.
2. retention: bringing someone in for an extended period of time is an investment you're making in that engineer. That investment is worth making based on the assumption that this engineer will stick around for some time. Most of the offshore development shops have huge retention issues: the job market over there is sizzling hot, and engineers over there are only right to take advantage of it.

Nonetheless, the concept is very powerful, and there are a couple of variables we can play with:
. who's acting as the liaison: if engineers on our teams have been there for an extended period of time, they're probably the one we want to invest in. Granting someone on our local team the role to act as liaison will give her an opportunity to grow professionally while at the same time ensuring proper technical communication between the teams.
. what tools can be used to enable the liaison: the best one is indeed to send people in for a decent amount of time. Short of that, the alternative is just to pair up a local engineer with a remote engineer and giving them lower-cost tools to communicate (phone, instant messaging, video conferences). Both of them should act as representant of their remote peer and constantly make sure that the information flows properly between the two of them as well as between their teams.

These are just some possible variations around the key concept you've outlined - Engineers acting as Communication Tools - the core of the concept being that people and responsibilities enable efficient communication; technology is merely a medium.

Moshe said...

David,

Thank you for the good comment.

Yes, I agree with your points. When you first propose to the executives to try the liaison, you see the alarm on their face. And it's hard to convince them. But after they do it, they all agree that it was a good investment. So, the costs and risks are worth it - granted, after careful consideration and planning.

The alternative techniques you suggest are very good to. I have actually tried a 1-on-1 pairing once (interestingly in the same company that also later used a "real" liaison) and it proved itself very well. If your company is reluctant to pay for a "full" liaison, start with the 1-on-1. Hopefully, later they will be willing to "upgrade".

Again, thanks for the comment.