I've been spending a fair amount of time researching how effective distributed teams work, and there are a few high-level principles that stand out.  First, a disclaimer: much of the content I've consumed is coming from companies who leverage the fact that they are distributed as a marketing strategy in some form.  And, so I'm getting a lot of the intent behind how they operate without researching and interviewing those who are performing work within it.

That said, some high-level thoughts:

  1. It starts from the top.  Like many things, if leadership isn't fully bought in, it's just not going to work.  
  2. The best systems are very clearly optimized for working asynchronously, and leverage synchronous interactions as needed.  Further, like any good product, they stick to those principles and don't introduce a muddied framework that attempts to cater to everything.
  3. They focus on defining a set of constraints and being clear about those constraints versus optimizing for control (surveillance).  The benefit here is that, if done well, it gives the employee a sense of freedom rather than feeling oppressive.
  4. They're creative at enabling different modes of self-expression. This may include adopting and constantly experimenting with the latest technologies, or playing with regular weekly prompts.  They acknowledge that they are all human.
  5. They leave little gray area by choosing good defaults, thus minimizng the need for synchronous meetings in which to clear things up. In some sense an open "meeting" is the worst interaction model and is both a waste of time as well as emotional energy.  If there's a common interaction that needs to be had, there are defined frameworks, templates, constraints, roles, which are systematized.  People know what to expect, and hence you feel comfortable moving about.
  6. They work in small pieces.  By breaking work into smaller pieces, you remove risk. You allow for more frequent checkins.  And, you are able to ship things faster.  That allows you to build trust more quickly (and effectively) vs working on larger cycles.

At a macro-level, I'm somewhat relieved to be finding that the years spent iterating on the design of the Entrepreneurial Design course, the membership rituals at Orbital, the program design of Orbital Studios, have actually been great preparation for designing how a distributed group of people can collaborate with other people under a common effort.  Many of the insights that people have shared have an analog in course design.  It's why I often suggest to interaction design educators that they should start their students off with designing in-person experiences.  Because, it's very immediately clear whether something is working or not.  And then, they can either confront it and try again, or give up.  Most will do the former, and through that they'll learn how to iterate in the field, which often requires the ability to set aside your own ego and focus on what you are seeing in front of you, which is often the hardest part of being a designer.