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.
Hi Mark – nice post! I guess I recognize all three types of distributed teams.
Satellite Teams are in my experience less frequent for “more permanent” work. I see them during workshops where a team collocates for a week or so, and a few specialists can’t meet on site. Or during parts of projects where there’s a heavy focus on Software development and test and the team reaches out to experts at times needed.
Cluster Teams were more common (in my working world) a few years ago, when teams for the duration of projects were brought on a few dedicated sites. Often we had teams in time zones 6-8 hours apart. Overlapping 1-2 hours a day to discuss progress and tasks to continue with. If well set-up, and true collaboration exists, I find this one of the most effective ways of working (yeah, said by somebody who works most of the time remote and alone…).
The last few years I work in Cloud Teams. That may be due to being part of a large multinational. By design people grow into specific areas and teams are formed around skills, competence and knowledge regardless of where people are based. Of course sometimes we change team members, and there may be 2 people located at the same site. That, however, hasn’t led to a ‘satellite model’ so far.
Great post! Thanks Mark!
Thanks for the response Patrick. I too am finding Cloud teams becoming more common especially with the growing number of newer companies. It’s interesting that you are in a cloud team in a large multi-national. I find that Cluster and Satelite teams seem to pop more in larger organizations. Clusters tend to form around groups of expertise in specific locations and satellites sometimes form due to someone with unique experience that wishes to move to another location due to family or interests but the organization would like to continue to engage them in projects. Again, thanks for your insights.