Full Distributed Teams: are they viable?

IMO Fully Distributed Teams are only viable when the team is fully distributed. When i was working remotely for a startup which had a central office, i commonly found that decisions regarding development were being made which i had little to no knowledge of, despite there being a chat room and task manager which was meant to keep everyone on track.<p>My guess is that everyone in the office was discussing bits and pieces outside the chat room and neglecting to keep me in the loop, perhaps unknowingly. Later on they decided to have formal weekly meetings, but this didn't really improve the situation.

There's no mention of Free Software projects.<p>There are numerous instances, including very large projects with multiple developers (Apache, Linux kernel, Debian project) in which this works quite well, and arguably several in which it doesn't (I suspect some of the desktop fails of GNOME and KDE have a lot to do with an insular psychology emerging among the development communities).<p>There've even been academic studies of the groups, including those by Biella Coleman (University of Chicago / Columbia), Siobhan O'Mahoney (Stanford/HBS). Steve Weber's <i>The Success of Open Source</i> nails a few of the dynamics pretty well too, though with less focus on actual teams (<a href="http://books.google.com/books/about/The_Success_of_Open_Source.html?id=ELieXMxR1h4C" rel="nofollow">http://books.google.com/books/about/The_Success_of_Open_Sour...</a>).<p>That said: many FS projects are highly modularized, an in particular, kernel development happens in large part by professionals paid to work at a given company on some aspect of kernel development. So the model is very mixed.<p>My own experience: maturity, individual dedication, group dynamics, and the absence of a "mothership" (and concomitant us-vs-the-world mentalities), as well as a dedicated effort to keep <i>all</i> communications on the group channel (as opposed to meatspace) is critical to success.

I've been working in a fully distributed team for nearly four years now as part of the chain of startup 'pivots' I've worked on: DotSpots, gri.pe and chee.rs.<p>It's a mixed bag. You really lose a lot not having physical interaction with your teammates (except the once or twice a year you happen to fly everyone to the same place). It's a lot easier to get on each other's nerves when you're not face-to-face. Management of people becomes a lot more difficult because of the disconnect of discussion over Skype or chat.<p>On the other hand, you can handle a lot more stress and workload by not having to worry about the commute and office hours. Sleep is easy to catch up on, even in the busy times. It's a lot easier to do things like taking a walk or grabbing a coffee down the street to clear your head - far less social pressure against taking a needed break than you'd see at the office. It's also a lot easier to thread in events in your life.<p>Ease of hiring is probably the big benefit with fully distributed teams. You have access to talent all across North America, and if you don't mind the timezone differences you can pick up people anywhere worldwide.

For those of you on distributed tech teams, what tools are you using? Some "core" ones I have seen frequently used are: Yammer, Pivotal, Github, Google Hangout, Skype, and real-time chat of some sort (e.g. Grove.io, CampFire, IRC server). Any others that have worked really well for people? I've been a little curious about wemux (<a href="https://github.com/zolrath/wemux" rel="nofollow">https://github.com/zolrath/wemux</a>) as of late.

i have worked like this more often than not. in my experience it has an amplifying effect: good people get better; trying to manage poor people remotely fails miserably.<p>i love it. now back to work :o)

I suspect most companies with remote workers don't fall in Choice 2 or 3. I believe most companies fall into a new class which is: employees are co-located, and a minority are remote.<p>Speaking from experience on both sides of that coin (currently the remote-side). It stinks. Communication incentives are out of wack. Remote people feel isolated and missing out on conversations, whether needed for a project or just missing out on camaraderie. Co-located people feel the distance of the remote people, and they either make conscious inefficient communication choices to include them or continue with the confortable in-person efficient choices.<p>It's hard work to have a minority of your workforce remote. I believe that if the balance tips the other way, remote communication and coordination gets easier and more streamlined. Even if it's not fully remote or separate co-located teams.

First off, I am a big proponent of ROWE. Still, I don't like fully-distributed teams. The human factor is just too big for me. Go work from where-ever you want, come in whenever you want, work whenever you want, that's fine (as long as you get your work done)... I would still love to see your pretty face in person from time to time. I feel (bad word, I know) that distributed teams loose something in personal connection. Maybe it's just my own personality, but person-to-person interaction is huge for me.<p>This is actually a big issue for us right now. Being a small startup in Nashville, there isn't exactly a lot of easily accessible space for us. We have to leave where we are at right now, and are trying to figure out what our plan off attack is going to be for the next few months.

I've been playing around with this for a little while now. I've tried all three approaches so far. The first two failed miserably (I take the blame for most of it, transitioning from a programmer to a leader/manager isn't as trivial as I initially thought).<p>The distributed model seems to be working the best. We are a truly distributed company. I felt kind'o self conscious when someone would ask where our offices are. But now, I realize, we get stuff done! The team just works, and works far more efficiently than any team I've been part of before.<p>Granted, 10 out of 12 of us are introverts. I think there's something even better at work. Everyone shows up and does what needs to be done when it's convenient for them, we don't really have "politics" since nobody spends a significant amount of time chitchatting by the proverbial "watercooler" etc.<p>It's really a very unique culture. We're far apart, but we know each other thru our work and we take quite a bit of pride in our work. There are several serious shortcomings though.<p>So far, I haven't seen a tool that was quite up to the task of keeping the team cohesive as one unified team.<p>We started out using Trello (which I still think is amazing), but as we grew to past 5 people and multiple projects, trello quickly became a mess (maybe due to how we're using it). We do rely heavily on skype and dropbox.<p>We recently switched to TeamLab, which is pretty awesome given all the features,but it's still not right...<p>I wish I could just extend trello, add some wiki/blogging functionality to it and drastically improve the search.<p>So, I'm contending that there probably isn't any tool out there specifically directed at a distributed teams. If there's one out there that works well for you, please share... At this point we've decided to roll our own given the time and collective energy we're already spent trying to learn and implement some of the existing tools.<p>(BTW, our team's not specifically developers, we range from business types to designers, writers and Coders)<p>To be honest being out of band isn't too bad, we've always got someone working around the clock, so it feels like we're always moving along.

People who argue for this can't just remove body language, a huge component in how we communicate, and expect that the loss can be recovered with a better project management app. There may be short-term benefits to working remotely, but there are very few examples long-term where it has worked well. This has nothing to do with the quality of the people working together, but with the bandwidth of communication being employed. Maybe that will somehow change in the future (for everybody's benefit), but it is certainly not viable now.

Mozilla's Release Engineering team shares their experiences with a distributed team in a slide presentation called <i>We Are All "Remoties"</i>:<p><a href="http://oduinn.com/blog/2012/04/04/we-are-all-remoties/" rel="nofollow">http://oduinn.com/blog/2012/04/04/we-are-all-remoties/</a><p>IRC and video chat are two critical components for Mozilla's teams.

A big part of a successful "full" distributed team are the tools and processes that are developed and implemented. When you work in a shared office space with the rest of your team, a lack of structure and organization is much more tolerable than when you're on a fully distributed team.

After 5 years working remotely, my .02 cents on the topic is that it works very well as long as you are with a team of mature developers. If any politic or personality conflicts get in to the mix you will fail miserably

In my experience, if you abide by the important rule of "work with excellent people," distributed teams work well.<p>I currently work on a team of 12, in three countries and at least seven cities.

Don't Github, Automattic, and 37Signals all have offices?

Are we sure about Basho being fully distributed? Their "careers" page lists positions in particular cities and gives a few office addresses.

MySQL is a good example of distributed teams working in the real world

All things being equal a collocated team will always beat distributed ones -soory to be brutal but thats how it is.<p>Anyone who says otherwise is a sales man trying to flog video conferenceing gear or deluding themselves.<p>This is based on many years experience and the common factor for good projects was a team that meshed well and was in the same office.