There is one very simple rule to make distributed projects work – or fail:
Do what you say, say what you do.

 

Many people claim that distributed projects can’t work or are so inefficient that they are usually not worth doing .  One  of the key reasons usually quoted is communications, especially: trust.

People in distributed projects are from different cultures, have different social norms and so on – how is this supposed to work?

The answer is surprisingly simple:

Do what you say, say what you do.

The reason why this is so powerful is simple: yes, you come from different cultures, yes, you have different social norms and so on. In a distributed project, you can’t depend on such things. The obvious point of shared experience is: what you say and what you do.

There is a very simple rule about trust underlying that:

Trust grows where you experience consistency between words and actions.

If you are in the same location, you usually see so much consistency between words and actions that trust grows “magically” with the people you meet a lot. (That is related to the “propinquity effect”, more about that elsewhere)

However in a distributed project, you see 70% of what a person does and hear 70% of what that person says – so you experience only an overlap of 49%. And actually, 70% feels really optimistic. If you spend four hours on meetings every week and maybe another four hours on chat and email communications, you are closer to 20% – and exact numbers don’t matter as long as the essence comes across:

You need to be much more professional in a distrubuted team

So much more professional that many people don’t reach that level, even if they want to.

What to do

Once you realize you can’t live up to “do what you say, say what you do”, it’s time to look at the levers to improve.

The simple lever is to stop making commitments you can’t hold.

Be careful what you promise

Even if people on the other end of the world are not explicitly holding you accountable, their trust develops subconsciously accoring to your behaviour. And smart people don’t judge you for what you promise but for what you deliver, anyways.

If something goes wrong?

Last but not least: the world is full of surprises. We are human, thus we are not perfect. What should we do when things go wrong? There are plenty of reasons (good and bad) for delays. But:

There is no excuse for not communicationg.

For all your partners know, you could be dead. Hit by a bus. Abducted by aliens. Or, more realistic: distracted by some other (local) project.

Which is a natural thing to happen. But it is precisely what the remote people do not want to happen. It is the horror vision of your partners. It is so much easier for local people to build pressure, so the distributed project de facto becomes manoevering mass that it is the logical assumption that this is what is happening in a distributed environment: We, the remote people, have been down-prioritized, explicitly or implicitly.

Therefore: there is no excuse for not communicating. Even “my key customer is keeping me busy” is better (because it is honest, and words and actions coincide) than a communication breakdown.

This is the other qualification for distributed teams: be patient. If you receive “bad” news, stay constructive. The relationship is still intact, communication is still flowing.

Don’t punish bad news, instead reward transparency.

Closing thoughts

I like distributed projects because they help me grow.

• Do what you say, say what you do
• No excuse for not communicating
• Reward transparency

… are really hard to put into practice. So the fact that distributed projects are like an unfailing mirror that point me at where I don’t live up to my own standards, they help me grow.

My standards are high, and I WANT to be better today than yesterday and tomorrow better than today, so such a sensor for missing my standards is useful. But I understand everybody who prefers not to look in the mirror.

It’s human, and distributed projects are not for the faint of heart.