My post last week spurred some very interesting conversations in the comments, on the Enterprise Irregulars mailing list, and (gasp!) in person.
As Atlassian CEO Jeffrey Walker pointed out, "Humans create wonderful things as physically connected teams. Things that are very hard to do virtually. ... I welcome competitors who think otherwise." I appreciate the sentiment, and agree that interpersonal bonds between team members can have a big influence on their output, but I'd argue that it's possible to create and maintain those bonds at a distance, and that doing so is increasingly easy with tools like Twitter, FriendFeed, and Facebook.
As someone on the EI list put it so well, "We may be distant. We may have never met face to face. We may be simply using a strange new medium to connect. But it all works, and the humans behind the bits are what matters."
Others pointed out that some job functions lend themselves to remote work better than others, which is surely true. Customer-facing roles are probably the easiest to single out as appropriate for online work, at least in the case where that's where the customers are.
For instance, as a developer I like to get my information online. I may actually get on a plane to attend a conference once every now and then, but for for the most part I prefer the higher bandwidth (and higher signal-to-noise ratio) of online resources. If you want to connect with me, you better be prepared to do it online.
Finally, I had a great conversation with Clay Spinuzzi, an associate professor at UT who's writing a book on modern working arrangements. We talked about the awkward dynamic of a team comprised mostly of people working in the same physical space but with one or two members working remotely. We agreed that such an arrangement is problematic, and that the remote workers would no doubt become marginalized. But then it struck me: maybe the fact that a team can't support remote members effectively is an indication of a problem with the design of the team.
In the same way that an on-premise system that uses proprietary protocols and can't connect to cloud-based systems is severely limited, so is a team that relies on in-person communications among its members.
The good news here is that technologies (dare I call them "social"?) like Twitter and its more business-oriented knockoffs make it possible to translate much of the casual, interpersonal communication that has traditionally happened over the cubicle walls in an office to online, asynchronous, geographically-distributed teams. In other words, Twitter is the new water cooler—which comes as absolutely no surprise to anyone who uses it.
When two machines sit next to each other in a server room it doesn't really matter what networking technology they use to communicate: AppleTalk, NetBIOS, and Banyan VINES will all get the job done. In fact, so will a serial cable—and one might argue that this is in fact the best solution since it requires the least overhead. But TCP/IP will work too, and with the added benefit that if you move one of the machines across the world it will still "just work" thanks to the vast infrastructure of the Internet. I suggest that the same is true for intra-team communications.
Teams built to rely on electronic, and more specifically Internet-based, communication channels can include remote members transparently, and can therefore be comprised of not only the best people in town but the best people period.
Great post. Having worked with entire times located remotely in India and Cypress as well as a situation where 1 person was remote and the rest of the team were all in the same office I've found a few things to be true. 1) The people make the remoteness work 2) everyone local or otherwise needs to be committed to the using the same toolset for sharing information 3) everyone must be accountable for their work product 4) if something happens outside the tools 1 person needs to be responsible for bringing the non-included folks up to speed.
One of the other key learnings I've had is that documentation and process can only bridge so much. If you're not speaking the same language about the product (not your relative level of english comprehension, though this can be an issue) what you're building you'll spend the majority of your time either trying to document around the language issue or arguing about who said what and how that didn't make it into the product. The times when I've had the most success with remote teams are when we've been 'on the same page' about what we've been building, we're speaking the same language about the product.
Also remember that tools, social or otherwise are just that tools and how you choose to wield them is what's important. I've seen many companies spend 10s of thousands of dollars on HD video conferencing equipment only to have it sit dusty in the corner while their remote teams struggle to understand why their project is running in to the ground.
Posted by: dbdukes | March 09, 2009 at 11:06 AM