Design Teams: Co-location Trumps Remote

Jared Spool

January 6th, 2012

We’ve been studying this for some time now and the reality is harsh: A co-located design team will have an easier time of producing great designs than a remote team.

That doesn’t mean co-located teams will always succeed – they don’t. It doesn’t mean that remote teams will always fail – they don’t either. In fact, we’ve met some awesome teams where team members are remote. (The folks at EightShapes immediately come to mind!)

Design is hard. Great design is really hard.

Teams need to rally every bit of energy they have to work together to produce great designs. They need to talk with each other. They need to see each other’s work.

We’ve observed that teams that work closely together create a common vocabulary. That vocabulary creates words and phrases that separate good design decisions from not-so-good ones. It helps the team discuss what’s on track for their design, versus what’s a distraction.

It’s also critical that teams is regularly discuss their emerging vision. This vision gives team members direction when making tough decisions. As things tiptoe up the borders of that vision, the teams needs a channel for expressing their thoughts.

Teams working remotely limit their communication channels. (This is even worse when the time zones are skewed, especially for those teams that span across oceans.) Establishing the common vocabulary and reinforcing the vision becomes increasingly difficult with remote teams. It’s not impossible, but the amount of extra effort is formidable.

We’re still collecting and analyzing our data on this, but our early results seem very clear. You’re more likely to produce a great design when you’re all in the same space, talking to each other. (War rooms are great for this, especially if you have lots of wall space to hang work-in-progress and have impromptu discussions.)

The next best thing is to have everyone be remote, but in the same (or a very close) time zone. Physically getting together at regular intervals can help quite a bit. (It’s even more helpful if your first project can be co-located.)

Teams talk about using remote conferencing tools, but they aren’t the same. The weird delays that come make simple things like telling a joke more difficult. These meetings adopt a false sense of formality because the changes in how the group interacts. It’s an expensive substitute that doesn’t really live up to its promise.

From our data, the worst case scenario seems to be when some people co-located and some remote. The remote people, not privy to the local conversations, become a type of second-class citizen. These teams seem to have the most trouble producing great results.

If you have any say in the matter, you want to aim for a co-located design team. If you can’t do that, then forcing everyone to be remote might be the next best option.

This is really hard for organizations that aren’t located where all the good talent is, or for those designers who are in places where they can’t be near the rest of their teams. Unfortunately, we’re not seeing any good options here for those folks.

It sucks, but those teams face a much harder challenge that teams that have the luxury of co-location. Great design is hard enough when we’re all in one place.

2 Responses to “Design Teams: Co-location Trumps Remote”

  1. Fast Start – Design Teams: Co-location Trumps Remote | Toby Elwin Says:

    [...] Fast start conversation:  When co-creating, teams need every bit of energy they have to work together to produce great designs.  To maintain energy, teams need to talk with each other, teams need to see each other’s work, and for design teams co-location trumps remote. [...]

  2. Mark Hart Says:

    There is an abundance of academic research to support a conclusion such as “the designs produced by co-located teams trump those produced by remote teams.” You did indicate that there were a few exceptions.

    There are several conditions in your scenario that are implied as immutable that should be examined.

    The scenario that you described seems to suggest that the two ‘teams’ are composed of the same number of individuals with the same set of unique skills and experiences and training.

    The two groups of individuals do not have be ‘the same’ in every aspect expect where they sit. Consider the following differences in the remote network:

    Challenge 1: The remote network can include individual contributors with superior skills in the designated domain. The have enhanced capabilities in this domain.

    Challenge 2: The champion (product manager, product owner, development lead,..) for the the remote group can be 10x more capable of leading a network of remote individuals that have a diverse skill set. The person recruiting the talent has a better vision of what will be required at various times during the project.

    Challenge 3: The remote group can have cooperation/collaboration supporting tools that are 5x better than the co-located group.

    Challenge 4: The nature of the project may benefit from having individuals that have been immersed in a particular culture or a variety of cultures. The geographically dispersed team may be equipped to understand the regional/global aspects of the project more quickly.

    Challenge 5: The nature of the project may benefit from testing in multiple geographic locations with representatives of the development network available for direct observation. The geographically dispersed network may be equipped to make more observations and have better skills to interpret the results.

    Challenge 6: There may not be sufficient supporting resources for a co-located team. There may be shortages of physical space or IT support. A distributed network may be able to adapt to an evolving need for specified head-counts and expertise better than mobilizing the ‘available resources’ (those that do not have obligations to other concurrent projects).

    Challenge 7: Doing something with a remote team and learning NOW may be better than procrastination because a co-located team option is not available immediately.

Add a Comment