Distributed sucks. Human interaction is far better than virtual, all the more so for teams of any significant size. I have worked with successful distributed and local teams. The local teams were far superior in their ability to improve. I much prefer the lifestyle afforded by distributed teams. But that lifestyle comes at a significant cost that today’s tools cannot even begin to mitigate.
Editors note: Wide Teams is about more than just advocacy for dispersed teams. One of the reasons this site exists is to foster a robust conversation about all aspects of remote work – including the very real challenges involved. In order to get a critical perspective on distributed work, I asked my friend, former coworker, and fellow blogger Chris Strom to write this guest article. As someone who has managed both collocated and distributed teams, Chris is eminently qualified to comment on the issues involved. If you are a remote worker, I hope this post will spur you to think seriously and creatively about the difficulties Chris highlights. — Avdi
Let’s face it, conversations around distributed teams always involve attempts to digitally capture one or more facets of human interaction. A web site may be able to partially mimic whiteboard discussions. A single tool might allow you to read the body language and hear a couple of team members. But there is nothing that encourages ad-hoc whiteboard discussions with multiple team members producing highly visible, easily recorded artifacts. These real-life discussion are fertile ground for team growth.
When I inherited a team back at the beginning of 2007, we were a team of 20+ developers distributed across the US and Canada. There were questionable business reasons for the distribution, but reasons nonetheless. We were sadly dysfunctional.
Over the course of the next three years, there was an incredible amount of change in the business — much for the better, but likely more of it for the worse. The biggest change was that we closed remote offices and shrank to 4 local-only developers. During that period two things did remain constant: how we estimated the work and how much of that work got done.
Think about that.
We went from 20+ developers to 4 — four! — and the amount of work accomplished in a release stayed the same. Many of the developers that left were more talented than the ones that stayed. Many are well known and well respected (and rightly so) in the community. So how could the amount of work accomplished remain constant?
There are two reasons that I have identified allowing the few-left-behind to maintain output. First, the codebase got better. Like I said, we had extremely talented people working on the distributed team and they helped. A lot.
The other reason is that we were no longer distributed. We no longer had to lose context when the phones went wonky or Skype decided to die. We no longer had to take time out to manage off-site buildings. We no longer had to manage off-site personalities or perceived, digitally enhanced slights.
Conversations at the whiteboard were immediately absorbed by the entire team. Digital contention was replaced by analog learning. Artifacts of that learning were visible for all to build upon. Some of the departed were local and, while here, taught the few-left-behind. And the few-left-behind learned because “I think I understand” might be accepted digitally, but lack of comprehension is immediately obvious in-person.
This is not to say that I believe that distributed teams cannot work. I have worked distributed and distributed worked, to a point. The successful digital team was already strong but made little progress to improve — as a team or as individuals. Perhaps improvement was not as important. After all, we were already strong individuals and thus made for a formidable team. We did not need to improve, just execute.
Ultimately, strong individuals committed to self-improvement can make for a successful distributed team. But even they will benefit the more often they get together in-person. I still hope to work on distributed teams in the future, but only if they are small and focused on a well-defined project. Ideally, I will be able to continue working on small, local teams that I can help grow and can, in turn, encourage me to grow.
What do you think? Is is possible to find a large distributed team that institutionalizes growth of the team, the project and individuals?