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.
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.
Yes, this is a problem and indicates that the managers at these companies don't "get it", in my opinion. I refer to this as "out of band communication" (described well here: http://www.sandywalsh.com/2012/03/out-of-band-communications...) and if your "distributed" team practices it, your collaboration environment is doomed.
One easy fix - have every remote person call in to an open mic on either someone's computer or, say, an iPad that is set up with video. Then any ad-hoc chat gets captured by all the remote folks. But, it really is continual effort to get people in the chat room. It's up to everyone on the team to constantly remind each other to "take it to chat".
Yeah, this has helped us a lot. I am one of a few remote and when I can, I skype into a big screen in the central office. The account there is set to auto answer calls from its list of contacts so I can call in whenever I want. I often leave it open all day on a spare computer.
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).
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 The Success of Open Source nails a few of the dynamics pretty well too, though with less focus on actual teams (http://books.google.com/books/about/The_Success_of_Open_Sour...).
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.
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 all 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.
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.
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.
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.
I agree with all of these, except the issue is the bigger investment firms want their teams in one location for the core component pieces anyway. Not sure if this is because it makes a company more sellable later on, or to make sure people are actually working, etc.. This is what's taking me the longest time is finding / getting the core team together. Meanwhile I just keep planning and organizing more and more for when I finally have a team - it's all I can do with the only unlimited resource I have - my mind!
Face-to-face planning and decision-making is crucial for fully distributed teams for exactly this reason. So you need to take the money you save not having an office and put it into travel and regular in-person meetings. Somewhere nice!
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 (https://github.com/zolrath/wemux) as of late.
We use Github, iChat (but have been using Google Hangout more), Campfire.
I'm a remote worker, so I have switched to tmux + console emacs (some guys prefer vim). That works much better than ScreenSharing and a typical GUI editor.
I've checked out wemux, but it didn't solve my pain-point which was the ssh setup at the remote end.
The bigger deal is not whether your team has the tools. But whether they use the tools. Co-located people may talk in campfire/irc/group chat, and some may not even log in. But remote workers depend on it.
I've worked at Automattic (a distributed company) for more than 5 years. The number one communication tool/method for most teams is IRC. We run our own internal IRC server, that logs everything in every channel. IRC is great for real time chat, when people are around at the same time.
Next most used communication method are internal P2s - http://p2theme.com/ - which is great for async communication. With people all over the world it is important to have a good async communication method.
Another reason both IRC and P2 are so important is that they have URLs for history. Anyone in the company can go back and read through the discussion.
The third communication method is Skype/Google Hangout. Many teams will have a regular (weekly is common) voice or video chat, generally less than an hour.
Jingle (the protocol behind Google Talk) works great for 1:1 calls. I'm experimenting with Mumble for group voip, though I often fall back to Skype just because everyone already has it.
But for actual coding I've found http://pair.io (using tmux) to work fantastically; I can't wait for them to come out of private alpha.
We use Pivotal, Skype, Whatsapp, Github, Zoho (CRM/Projects), Dropbox. Of all these Pivotal + Github seem to be by far the highest on the list; without those we would be dead.
We have some glue tying these together and we use some in-house development wiki's and live-editing tools for producing faster and collaborating better.
Skype when 1:1 chat/voice is needed
Campfire (and many rooms for different chat subjects) + hubot for all group-based chats
Google Docs for collaborative spec editing
Github for technical discussion (pull requests/issues)
Pivotal tracker for day-to-day "what is s/he working on?"
In my previous experience of working on a distributed team, the main things were Skype, Basecamp and Bitbucket. Well, except for the designers who used email exclusively and infuriatingly :)
In my experience it's fairly easy to convince designers to use shared Dropbox folders instead to exchange design assets. And it's a lot better way of doing it than email.
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.
The trouble is that developing most software is a group activity. The result is more than the sum of individual contributions, it is also a function of how well the team works together.
Someone might be a competent developer in their own right, but not a ninjarocksuperstar. Still, if that person can understand three conflicting ninjarocksuperstars' points of view and see how to reconcile them and build a consensus, it might be the most valuable contribution of anyone on the team that day.
One of the problems with managing something like a software project is that it's very hard to measure this effect. If you're in an office where people are interacting regularly, there's usually an easy alternative to measurement: ask everyone who helped them do their job the most lately, and the guy that 75% of your team name is the quiet one who works in the background to keep everything ticking over. If everyone is 100% distributed, that guy might not be contributing at the same level as everyone else, but that's because you're not taking advantage of his skills and your team is weaker for it, which is your mistake and not his.
(I try to be consensus guy regardless of coding skill, but I'm not sure how good I am at it. That's why appreciate when there is someone who really is good at it on the team, even if their personal coding skills are merely average.)
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.
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.
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.
My last gig was primarily co-located but a few remote. We found the best way to make it work was to treat everything as if we were remote. We all used chat rooms, IM, etc. - just like we would if remote - even though we were in the same room. Your team can do it, too. It's not that hard but it takes focus and effort.
Really, you would type in chat with someone who was next to you? A real conversation is such a great thing, that I would not give that up. Much better is what the other guy in the thread is doing, skyping into a big screen in the room as interim-big-brother. Of course, he can't walk in close to join a converstaion, but unless there is a whiteboard or something out of reach, at least the conversation can still move over to him :)
Real conversations are great, but terrible for anyone not in them. What if a co-worker is out sick? At lunch? On vacation? Without studious note-taking any ad hoc conversation is just an untracked change. Not saying they shouldn't occur but if they do, the change (if any) needs to be appropriately communicated to the rest of the group.
I've found that note-taking / decision communication happens so infrequently that it's far better in the long run to just stick to logged forms of communication.
If it's a pair programming team, of course, the documentation is in the code. But if it's something architectural or changing the direction of the product/team, it's gotta be written down.
I understand the NEED not to have real conversation, but the idea that you're typing away with someone who is next to you (when you could open your mouth and have this great conversation) is so inhuman to me, I don't think I could ever acquiesce to such a working environment.
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.
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.
Your concern about human connection is totally legitimate. I think most of the successful Fully Distributed teams out there supplement the independent work environment with periodic in-person get-togethers. For example, Github has their Github Summit (pics: http://www.flickr.com/photos/brianmario/sets/721576257683729...), Basho described their "quarterly meetups". Automattic also does retreats.
I think your comment is a recognition that the most important aspect of face-to-face time isn't actual productivity / collaboration but simply social connection and team camaraderie. This is probably the biggest challenge that Fully Distributed teams face, but it isn't insurmountable with some creativity and planning.
+1 for ROWE. We love/use ROWE, too, but building a gel'd team is greatly accelerated by face to face contact. We're experimenting with some Results that are tied to face-to-face contact (show up for team dinner, lunch 2x a week, etc.) that requires folks to show up. But, that feels pretty forced. I'd love to hear other experiences with ROWE and actually having face-to-face contact.
In my experience ROWE has been a pretty great success. It's really beneficial for people who are problem-solvers, not time-clock monkeys. One of the most important aspects of successfully implementing ROWE is accountability and awareness. First, you have to have some metric to know if results are actually being produced. Second, your team needs to know what the metric is, so that they properly manage their time. Also, having some times where people are in the office together is really helpful for that face-to-face aspect. Company meetings, beer Friday, etc. all work well. Some people may prefer to have a minimum amount of time you should be in the office (maybe 25%). I would not suggest having company-mandated fun time though. It's not fun time when it's required. Last thing I'll say is, if you don't have accountability and awareness, people can coast for a long time without you knowing. Regular checkups will keep everybody on the same page, and identify problems quickly.
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).
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.
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.
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.
So far, I haven't seen a tool that was quite up to the task of keeping the team cohesive as one unified team.
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.
We recently switched to TeamLab, which is pretty awesome given all the features,but it's still not right...
I wish I could just extend trello, add some wiki/blogging functionality to it and drastically improve the search.
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.
(BTW, our team's not specifically developers, we range from business types to designers, writers and Coders)
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.
It isn't a project management tool (lots of good ones already exist), but it is a great discussion tool. Our remote team is closer together because of it.
If you try it out, we'd love to hear your thoughts, feedback@gingerhq.com.
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.
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
Since when is body language involved with getting stuff done? Or do you mean office politics and those greatly productive meeting hours?
bandwidth of communication
The lower bandwidth is more than compensated by the better signal/noise ratio.
I've found communication in remote teams to be radically more efficient than the usual office chitchat. You just don't waste time in poorly focussed meetings, adhoc exchanges that all participants have forgotten a minute later, or the infamous daily standups that give everyone the blurry feeling of being on the same page - without knowing which page that would be.
Chat is the primary communication channel in the teams that I'm participating in and the sole act of typing something out instead of saying it makes technical discussions tremendously more focussed.
It also enables a culture of meta-discussion that simply doesn't happen in old fashioned meeting-driven companies. I have many dozens of Chat-threads going on in parallel, some of which reach back months, often with long pauses. These threads contain pretty much the entire thinking that went into any given subject. Nothing is buried on funny colored post-it notes or blurry memories of long forgotten meetings.
Feel free to compare that to your "knowledge-base", "Wiki", or what have you?
certainly not viable now.
Says who?
I've been "the remote guy" exclusively for the past 5 years. For different companies, some fully distributed, some with a central office. If you want to maximize productivity of a mature team then that is your modus operandi.
I might just have to file this under "holy fuck, allistic people are so weird", but...seriously?! I have to spend two hours on/walking to a train every day so that the precise way you twitch your eyebrows can properly guide my software development? Really?
Given that many open source projects are developed by a distributed team, it seems to me that there are plenty of examples where this has worked well.
While face-to-face communication is perhaps the best mechanism of communication at the moment, a centralised team has a far, far smaller pool of potential hires to draw from. It's effectively a tradeoff of communication vs. talent.
My own opinion is that communication between fully distributed teams isn't that bad, and is getting better all the time. The small advantage of having a centralised team doesn't seem worth reducing your talent pool by several orders of magnitude.
But there's already existence proofs of good software being developed by fully distributed teams. OK, I wouldn't want to make hiring decisions without an in-person interview, but I can't imagine how body language helps make technical decisions. In fact, I'm suspicious of people who make these types of arguments, because irrational influences like personal charisma have far more influence in person than rational influences, which are more naturally suited to written (not even spoken!) language.
Bingo! That's why we created Sococo Teamspace, to make strides in capturing social signalling (expression, presence, 'over the cube wall' communication). We use it ourselves to develop Teamspace with a team distributed in 4 states, with great results.
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
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.