Our friends at Socialtext have posted a rebuttal to my last article, "5 reasons Distributed Teams Suck".  I frequently see this type of comment from people frustrated by their situations.  "I tried all those other diets and they didn't work."  But now is not the time to give up. It's not hard to make these teams work, and work well. Perhaps the Socialtext organization has, up to now, lacked the necessary confidence or finesse to solve the management challenges raised by distributed teams. But, figuring out the solutions is not optional, because your teams are ALREADY DISTRIBUTED.

I rarely see a software project that is not spread out over two locations, doesn't have someone who works at home, etc.  In the case of Socialtext, they haven't fully cracked the management code, so they apparently wish that brainstorming and problem solving would go more smoothly, they warp local schedules, and they spend extra money on travel.

To find the solutions you need, you have to go back to the original home of distributed Internet teams: Open source projects.  Open source projects take the distributed concept to an extreme.  Team members rarely meet each other.  They rarely travel.  They are scattered randomly across time zones.  They never set hours.  Furthermore, it's a worst case for management, because, even if the team members are paid for their work, you generally aren't the one paying them.  If this situation sucks, then why does it work so well for them?  Shouldn't you try to make it work equally well for you?

So, it's necessary, and it's possible.  We have a few tips and tricks we can pick up from those open source guys.  Let's do it.