In my courses, one or more of the participants almost always raise a question like this:

How do you set up a team across many sites?

Almost always when digging deeper I find out that they are currently working in a setting with many sites involved. Almost always they have a project organization set up with single-skill specialists involved. These single-skill specialists are almost always working on at least three different projects at the same time. In the better cases, the remote team members are spread across a single timezone. In the worst cases I have seen so far, it had been a timezone difference of ten hours.

I will leave how to deal with such a setting for a later blog entry. Today, I want to focus on some tips and tricks for working with remote team members and remote colleagues.

Tripit reported that I was on the road in 2012 for 304 days. I hardly believe that since I stayed at home for our newborn son Nico the whole June back then. (I think they have had a bug there.) But it was close. I have worked with remote team members and remote project teams in distributed companies since 2006. I hope I have some nuggets worth sharing.

Remote comes with a price

When it comes to distributed working, remoteness comes with a price. The hard thing most managers don’t realize does not stem from the difference in wage. In fact most companies I have seen merely out-source to far distant locations only because they take the wage savings into account – but not the social loss alongside.

The social loss is what happens when team members don’t know each other since they didn’t meet for a single time in person.

What happens with social loss?

Richard Hackman provides a some insights in his book Leading Teams. According to Hackman, teams are subject to several gains and losses over the course of their lifetime together. There are gains and losses on the subject of effort, performance strategy, and knowledge and skill.

When it comes to effort, social loafing by team members may stand in the way of the development of high shared commitment to the team and its work. For performance strategy, mindless reliance on habitual routines can become an obstacle to the invention of innovative, task-appropriate work procedures. For knowledge and skill, inappropriate weighting of member contributions can become a drag against sharing of knowledge and development of member skills.

All these three losses – social loafing, mindless reliance on habitual routines, and inappropriate weighting of member contributions – are more likely when team members are separated from each other. If they don’t know each other, they can’t make good decisions about distributing the work since people don’t know each other well enough to do so. They also are less likely to have a shared understanding of the organization’s context. They won’t know how to come up with better work procedures for the task at hand. And finally, the knowledge will be less likely shared among team members. It’s so hard to do when you have only two hours of common office hours between sites.

Besides the wage differences, these factors are hard to price. Thus, so it’s even harder to compare the costs of the decision to work in remote sites. You can make these costs a bit more transparent if you raise the question what it would cost to bring the whole team together every other week. That’s unlikely? That’s hard to do? That’s expensive? Well, how expensive is it in the first place to not do that? A couple of years ago I worked with a client that flew in their team from Prague every second week. They were aware of the social costs attached. And they were up to pay the price for it.

Though, that’s not a guarantee that it will work. But it makes the failure of teams less likely.

But what if you don’t want to pay that price? Well, there’s always the option to create teams local to one site. When you do that, make sure that you make the coordination effort between teams as less awkward as possible.

Video conferencing to the rescue

A couple of years ago, I found myself on a project team with some people set up in Germany and others in Malaysia. That’s a six hours timezone difference.

We were doing telephone conferences every other work day. And we were noticing problems in our communication. The phone went silent when one side had made an inquiry. Usually, that was an awkward silence. And more often than not – we found out later – that silence led to some undone tasks. (Did I mention the project was under stress?)

At one point, I was able to convince the project manager at my side of the table to talk to his pendant in the other location. They set up video conferencing. We coupled that with a phone call, still, but at least we could see each other. From that day on we had a different meeting. Now, we were able to see the faces of the others. We were able to see their facial expressions. We were able to see if they were not able to understand something that was said on the other end. And we were able to repeat the message or paraphrase it to get the point across. Certainly, the same happened for the other side. That’s what changed the whole meetings for us.

So, if you decide to set up remote team members, then also make sure they have the technology necessary to communicate and coordinate well enough between the different locations. One prospective client that I visited once had taken over a whole meeting room. The room was no longer bookable by persons in the organization. They had set up the various boards of all the teams in that meeting room. They also had a video projector and a 360° camera installed there. The whole set up was targeted to make it easy to have cross-site communication available. I can only urge you to invest in such technology. Your meetings will become more effective in the long run.

Transparency creates trust

Seeing each other during meetings is a specialization of a more general concept. Transparency related to work- and task-oriented data creates trust. I have seen work teams mourning over each other just because they stopped to know what “the other” team was doing. The trust also turns into distrust when there is a lack of transparency in certain regards, and the transparency you get just confuses.

Unfortunately, creating transparency also takes effort in most cases. You have to provide the numbers that others want to see like percentage of code covered by unit tests or net profit values of new features. In software, you will be providing those numbers maybe by another program. In non-software teams, you may need to find other ways to provide such information. Still, it will take effort.

Is that effort well spent? If my claim is correct, that transparency creates trust (lots of, actually), you should aim for the sweet spot between creating enough trust and effort spent on providing the necessary transparency. In other words, ask yourself the question, is the effort I spend on creating transparency well spent for the trust that we gain as a group?

A couple of years ago, Kent Beck raised another point in this regard. He said that he always tried to be transparent in every regard. Because hiding information takes effort. When you are completely transparent, you can save those efforts that go into hiding information and use it to provide value. I like that attitude.

One final thought: if creating transparency is indeed too effortful for you, remember there is always the option to work in a non-distributed setting. When you have chosen to work for a distributed company, the extra trust through transparency should be the price that you want to pay.