There is an enormous amount written about distributed teams and I find most of it very frustrating. It’s not that the observations or the ideas are bad. The problem lies with the primary tool we have for exploring the principles and practices of distributed teams: the English language. Terms like “distributed”, “dispersed”, “remote” or “virtual” are insufficient for describing the situation and characteristics of these teams that may or may not be working together effectively. I appreciate how we try to use these terms, but if I have to think about what the term means each time I use it, does it really work? You may already be frustrated with this paragraph just from the terms I used.
I find that English is very good for telling rich and meaningful stories and that we all tend to learn best through stories. So allow me to offer up a few story fragments of the types of teams I have seen in distributed space. In fact, space can be a handy metaphor to use when telling the stories of these teams.
One kind of team that I often come across is the “satellite team” where there is a central and co-located group of people (and work) and one or more individuals that work remotely from the group. This remote work can be occasional or it can be a permanent arrangement. We could even refer to the occasional remote worker as an artificial satellite and the permanent one as a natural satellite. One question that might pop up is what gravitational pull exists between the core of people and the satellite worker? Is it prior work relationships? Is it the unique expertise of the satellite worker? Is it possible that this pull is weak and the satellite worker may develop a weak orbit? Will that weak orbit mean unexpected work, poor quality work, or a disconnected worker that eventually leaves orbit (and the company) to look for a more habitable work environment? You might be able to find some good stories to tell this way as you make observations here.
Another type of team that I encounter is the “cluster team” where there are different clusters of co-located workers. The people within a single cluster (or location) may or may not work together directly. For instance, you may have all of your software developers at one location and all testers in another location. Each developer may not be working on the same thing as other developers in that same location, but instead work with people in other clusters. Do you find this way of working pulls the clusters closer together or do they seem to constantly expand until it becomes difficult to tell who is working on what? Or, perhaps each cluster is itself a self-contained unit with all the right skills to complete a portion of the work. Does your cluster seem to pull together in this situation or expand out into the void? Again, there may be some good stories to tell about the different configurations of these clusters and characteristics you can observe.
Finally, a third type of team is what I refer to as a “nebula team” or “cloud team” where all of the workers are working in separate locations. Each has control over how and when they work and this freedom can be focused to have a very energetic and productive cloud of work or it can also disperse the cloud so that the work almost fades from existence. These nebula teams were once thought to be quite rare, but with the increase in network speeds, technology to collaborate in multiple ways, and the desire for more choice in how one works, these teams are not only being discovered more, but they are being written about frequently. They also should not be confused with the first two types of teams which have different characteristics and need to operate differently.
You might wonder: can anyone work in any of these three types of teams? Perhaps not since each team has unique characteristics and require some unique skills and attributes of the workers within these teams. Those who don’t consider these challenges have definitely encountered supernova-like explosions of their teams and their work.
Is this an accurate model for describing distributed teams? As George Box is often quoted, “all models are wrong but some are useful“. So I’m not worried as much about accuracy. I’m more interested to find if these descriptions are useful. Can you tell better stories about your teams this way? Let me know.
