I've been working with one of my fellow travellers on the software bus for 20 years now.  He works really hard to keep his identity protected so I won't "out" him but I'll refer to him by his secret identity of "Krow".  Krow and I first met when I put a 3 line advertisement in the Monterey Herald in 1987 looking for a programmer to work for my fledgling Pacific Grove, California company Intuitive Technologies which I founded in 1984 after my 3 year stint as Director of Research and Development at Digital Research, Inc., the developers of the CP/M operating system and the GEM graphical environment which was at the heart of the Atari ST.  At Intuitive Techologies, we built Mac, Atari and PC software and consulted to the likes of Apple, IBM, Informix, etc. until 1994.  One of the first things Krow and I found out is that we can communicate "at-a-distance" via common abstractions and make it work.  Tor Nørretrander's book, The User Illusion, claims, and I believe it's true, that communcation using human language is the process of the speaker stimulating in the listener a similar tree of abstractions to the one in the mind of the speaker.

The folks at MIT's Sloan school of management publish a review and in a recent post their 10 rules for making virtual team work:

1. Invest in an online resource where members can learn quickly about one another.
2. Choose a few team members who already know each other.
3. Identify "boundary spanners" and ensure that they make up at least 15% of the team.
4. Cultivate boundary spanners as a regular part of companywide practices and processes.
5. Break the team's work up into modules so that progress in one location is not overly dependent on progress in another.
6. Create an online site where a team can collaborate, exchange ideas and inspire one another.
7. Encourage frequent communication. But don't try to force social gatherings.
8. Assign only tasks that are challenging and interesting.
9. Ensure the task is meaningful to the team and the company.
10. When building a virtual team, solicit volunteers as much as possible.

Having done this, as I said, for more than 20 years now, my experience shows #5 and #7 are the key factors.  Decouple, decouple and did I mention, decouple?  That's the key.  Allow team members to work and innovate independently!

Your thoughts?  I'd love to hear your sucess and horror stories and share them!  Leave a comment on the blog or use the email link and drop me a line!
Final note:  Krow and I are still doing working virtually 20 years later.  Last year, we built www.projectglidepath.net and only met in-person once for two days at the beginning of the project.