[Part of a series on Managing Distributed Teams.]

Distributed teams and colocated teams are similar in some ways, and different in many others. But there is one underlying difference that is so basic it has an impact on everything else:

Rule #1 of distributed teams: Communication doesn’t just happen.

In a colocated team, there is a lot of communication that happens naturally, without anyone ever thinking about it or planning it. Some of this is really obvious. Team members go to lunch together, or grab coffee, or sometimes share drinks after work, and conversation naturally includes work topics. Employees overhear nearby conversations (and join in if they feel they have something to contribute, or want to learn more).

But there are also things you might never have considered. People notice when people are sitting together or meeting together, and from that collaboration they infer that something is happening. They see interesting information left on whiteboards. They notice reference books left on desks, thereby understanding what tools or technologies are being considered for other parts of the system. They see expressions of stress, excitement, or confidence on the faces of peers and managers. They think out loud, or ask nearby coworkers for help in working through ideas.

All of those things are passive forms of communication. People are quite good at communicating with each other and drawing conclusions from the patterns they see—so good, in fact, that it’s almost as natural to most people as breathing. That means that a lot of valuable communication happens in a colocated team implicitly, without anyone ever planning it or even thinking about it very much.

You can’t depend on that kind of thing happening on a distributed team. I mean, sure … people still communicate, and ask each other for help, and have conversations in chat rooms where people can “overhear”, and so on. But there’s more friction, more overhead, and so unless you’re deliberate and intentional about it, it won’t happen as much.

At this point, you might be thinking, “It sounds like distributed teams are inherently worse for communication.” But colocated teams have their own issues with communication, often directly related to how easy and casual it is. Think about it: you’re relying on a lot of accidental communication. It’s great that it all happens so easily, but it could actually benefit from being planned and considered a little more. People will learn important things the hard way, and then not take the time to communicate that to the rest of the team. Or an impromptu gathering will make an important decision, but forget to validate the decision with important stakeholders (or to communicate it to everyone who must follow through with implementing that decision). And background information, such as the rationale behind a decision, is frequently lost.

Those things happen in distributed teams, too. But a distributed team typically does much more of its communication in writing, and can have more opportunities to review, disseminate, index, and archive team communication. Plus, as with anything else, focusing on something and giving some thought to the best way to do it can pay important dividends: people become more conscious of how they’re communicating, and of whether the medium is the appropriate one for the kind of information involved. They are more deliberate and careful about how they communicate.

Because this is rule number one, several of the posts in this series will be about communication: the different tools, styles, and techniques that are required to make sure that the right communication is happening both within and beyond your distributed engineering team. Start paying attention to all of the kinds of communication that happen in an office, and ask two questions about it:

1. How could a distributed team get some of the same benefits?
2. How could we make this communication more valuable by taking it a little more seriously?