How To Understand Your Team Type: Collocated, Satellite, Cluster, Nebula

I've been hearing people talk about “hybrid” remote teams. So far, every person I've talked to means something different.

When Mark Kilby and I wrote From Chaos to Successful Distributed Agile Teams, we differentiated between these types of teams:

  • Collocated, as all the people are within 8-16 m of each other. (See the Allen Curve above.)
  • Satellite, where most of the people are in one location (inside 8-16 m) and a couple of people are outside that location.
  • Cluster, where you might have pairs or triads in several locations.
  • Nebula, which is totally dispersed.

In the interest of clarity, let me start with the Allen Curve, which describes the potential frequency of communication.

How Often Do People Talk with Each Other?

You've experienced this while you've worked apart from each other: How often do you talk with other people?

If you mob, pair, swarm with others, probably often. However, if you don't? Distance, and especially, hours of overlap, make those conversations hard to conduct.

In Developing Products in Half the Time, Smith and Reinertsen used the Allen Curve (in the above image) to decide whether a team was collocated or not.

That image doesn't say that collocated teams always speak with each other. Note that the frequency of communication appears to top out at 30%. I'm sure there are good reasons for that.

And, realize that 16 meters is only about 20 steps. Which, even if we double the distance, is 32 m, about 40+ steps, which takes most people just 30 seconds or so.

What the Allen Curve says is this:

We rarely spend more than about 15-20 seconds walking to talk to another person. In fact, most of the time, we don't walk to talk to another person.

That's why so few of us actually work in collocated teams when we are in physical proximity to each other. And when we are more than 32 meters apart? The likelihood of us talking is much lower.

That might explain why some teams have told me they collaborate more now that they are all dispersed (what Mark and I call nebula). The cost to ask a question is quite low.

For the rest of this post, since we're talking about agile teams, let's assume each team has one manager. That manager leads and serves that team. Even if people are matrixed into the team, the team has one overarching goal. The people don't have to manage the stresses of competing managers with competing goals.

Let's start with collocated teams.

Collocated Teams Can See Each Other and Collaborate

When Mark and I talk about collocated agile teams, we mean this kind of cross-functional team. Everyone sits within 30 m or so of each other. Everyone can see each other.

The cost to ask a question is low, because we're all physically together.

Very few of us have worked this way since the pandemic started. Instead, many of us have created nebula teams, where everyone's dispersed.

Nebula Teams: All Dispersed

In Nebula teams, each person sits in their own location. Physical distance doesn't matter.

Instead, the team needs collaboration time, those sufficient hours of overlap, to collaborate. If you have sufficient overlap, and sufficient tooling, the cost and time to ask a question is low. And if you have a persistent text backchannel, your team can define its own collaboration time.

You're not bound by space for collaboration. You do have time bounds for collaboration.

Now, we come to the two types of hybrid teams: satellite and cluster.

Satellite Teams

You know you have a satellite team when some people are within 30 m (collocated) space and a couple of people are in different locations, farther away.

For example, in this 6-person team, four people come to the office, Location 1. One person works from their home, in Location 2. And another person works from their home, Location 3.

Back when we were all in the office, your Location 1 might have been on the same campus, but a different building. Location 3 might have been on another floor in the same building.

Satellites teams have the bulk of the team in one location and other people outside that location, often by themselves.

However, that's not the only kind of hybrid team. Clusters are also hybrid teams.

Cluster Teams

Cluster teams have several groupings of people who are collocated. For example, one of my clients has office space in downtown Boston (Location 1), Waltham, a suburb (Location 2), and Nashua NH, Location 3.

Another client of mine has developers in Georgia, product managers in New York, and testers in Vermont. Their teams all work within a single time zone (Eastern), and the teams have learned how to create hours of overlap.

When the teams are in their offices, the developers are collocated with each other. So are the product managers. So are the testers. Each function is separate from the other functions.

They have enough space at each location that people can be sufficiently distanced and still be collocated. That's how a Cluster team can work.

What Kind of Team Do You or Will You Have?

As people think about going “back” to work, think about the circumstances you have.

If everyone can sit within 30 m or so, you have a collocated team. Your team will have to think about when to stand up and walk to another person to ask questions.

If most people work in one location, and a couple of people work from home, you have a satellite team.

(Future post teaser: Some of my clients plan on having half the team in the office M, W, F and the other half T, TH. They rotate the satellite. IMNHO, this might be the worst of all possibilities. So far, they're not back in the office at all, so we'll see if that plan survives first contact.)

The cluster teams have several sets of collocated people, but each set of people is separate from all the other people.

That's it. Once you understand your kind of team (collocated, satellite, cluster, nebula), you can determine how to make it work.

For much more information, please see From Chaos to Successful Distributed Agile Teams.

2 thoughts on “How To Understand Your Team Type: Collocated, Satellite, Cluster, Nebula”

  1. I love this summary of team structures. Thank you! I have seen another structure that breaks the idea of “team” though. I sometimes call them Gateway teams. They are like Cluster teams where functions are in different locations and time zones, but you may not know specifically WHO will be performing that function at that location.

    For example, let’s say you have a Test Lead located in India, who participates with the Cluster team to understand the work needed (ok). However, the Lead is the coordinator at her location in India to select whatever testers are available at that date and time to perform the necessary work. So the Lead is the Gateway/Proxy to team members you don’t know and may change over time.

    A challenge I have with this structure is that the people making up the team (and doing the work) change over time so it’s hard to build the relationships that lead to trust and high performance. These gateway team members follow a fixed process so that they may be interchangeable (to a degree) – which also makes it difficult to change/adapt the team processes and flow over time.

    Have you encountered this type of team structure? Do you have any suggestions or strategies on how to help teams like these to grow together and improve their effectiveness over time?

    1. Paul, you already know the answer. What you describe is not a team. You’re talking about “shared services,” which precludes teams. You even said it yourself: “it’s hard to build the relationships that lead to trust and high performance.”

      That’s why I don’t recommend an agile approach if the organization demands shared services.

      However, you have options, assuming the organization will listen to you. In the book, we talk about copilots and ambassadors. A copilot will work with a colleague in a far-away time zone to coordinate the work.

      1. Ask the team lead to be a copilot instead of a directive manager.
      2. If the lead says yes, ask that lead to permanently assign people to the various projects.

      If the lead agrees, you can now use an agile approach. But if they don’t agree? Don’t use an agile approach.

      Even if the lead agrees, here’s the really hard part. That lead will have to say No to more work. That lead has to manage the capacity of the functional group the lead “has.” Very few leads can do this.

      I use Katzenbach’s definition of a team in all my books and writing about teams. Teams are relatively small, and the members commit to a common purpose or goal. They have complementary skills and an agreed-upon approach to the work. They have interdependent goals and they commit to each other about their work. Shared services people don’t fit the definition of a team.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: