As someone with a great deal of personal experience working in virtual teams and having managed a collaboration technologies research team for several years, I am very familiar with the obvious as well as subtle problems with the collaboration tools available today. As I am sure you know, there are just way too many tools from which to choose. For this post, I’ll touch on my recent experience with just a few examples of those that provide communications (auditory, visual and data).
Let me start by sharing with you a mental model I have for helping me understand how the many communications technologies available today can be used to optimize project team dynamics:
This model shows the various classes of technologies in decreasing order of the richness of the connection between people. By “richness” I mean the relative amount of information conveyed in the form of auditory, visual, data, and body language cues.
The gold standard for communications is, of course, face-to-face. This is the form we should all use when we must exchange information in the richest and most efficient way possible. While we are face-to-face, we can all easily and intuitively collaborate on documents, draw on a whiteboard or paper, share photos, and use our hands, face and voice to describe and emphasize our ideas. This is also the mode most desirable when sensitive subjects are being discussed (e.g., performance reviews).
Moving down the table, I list technologies that provide facsimiles of the face-to-face visual and auditory experience to a decreasing degree until we reach the bottom with instant and text messaging where no audio or video is used and where the data (text) exchanged is greatly limited. To achieve optimal team performance, everyone on the team must be careful in the selection of the technology used for a given information exchange. For example, it would be insensitive to send a text message to lay someone off. Likewise, you should not call a face-to-face meeting to answer a simple question like, “Did you send that invoice?” A very fast “Yes” sent in an instant message is much better for that.
There is one interesting aspect of these technologies that deserves more discussion: the time element. All of the technologies listed in the table that are marked as “Y” in the real-time column require everyones’ full-time attention for the duration of the connection. Those marked “N” allow each party to respond at a time more convenient to them. One of the biggest killers of team productivity is unnecessary interruptions. Studies have shown that it can take 15-30 minutes for a programmer to get his mind wrapped around his work after an interruption, so limiting them is important. It is at least partially due to the inherent interruption control afforded by the non- “real-time” technologies that make them so useful.
So, now, let’s pick a technology from the table that I’ve been quite pleased with the progress made so far: PC-to-PC voice over IP (VOIP). In particular, Skype. I have recently been helping a colleague on a Web service he is building. We have met a few times face-to-face to whiteboard some ideas, but for the most part, we have used Skype to chat. After a quick check over instant messaging to be sure we are both ready to commit to a real-time connection, we open a voice channel nearly instantly. Then, using the built-in array microphone in my laptop display (a recent addition in laptops). I enjoy a very nearly “being-there” audio experience. No headset, very low delay, and pretty close to full-duplex exchange. I can finally say the audio quality has finally exceeded the old POTS telephone and is way better than a cell phone connection. But, what really impresses me most is that we can have a three-way (or more) conference call with another of our contributors without paying a cent for a conference bridge! In addition, we don’t have to waste time setting up the bridge, dialing a phone, and going through a mess of menu selections to get connected. Fantastic! The only problem we have had with it so far is that my colleague is unable to run Skype on his Linux laptop, because his version of Linux does not support the audio hardware in his computer. So he must chat with me from his backup Windows system. (As an aside, Linux compatibility for most collaborative technologies has been an ongoing issue for as long as I can remember. Most new desktop technologies are developed for Windows first — a much larger market –and much later, if ever, will show up on Linux with a greatly reduced feature set.)
Next time: my latest experiences with desktop sharing.
(Disclaimer: I don’t own any stock nor do I work for Skype. I used this tool as an example of the state-of-the art. It is possible that other manufacturers have similar capabilities).