This is a topic very interesting to me, because over the years I've written a lot of call center and customer service software used by distributed teams. I also worked as a developer remotely for Linden Lab for long time, which had a highly distributed workforce, using Second Life and other things as a primary interaction platform. There are things I've observed when writing software used by distributed teams that make a huge measurable difference in productivity.<p>When working remote, it's easier to feel like it doesn't really matter if you put your nose to the grindstone, since nobody can tell. So I found it made a dramatic difference in productivity when I implemented a simple sidebar that showed what ticket each member was working on, and how long they'd been working on it. It was intended to be sort of like an office: in an office, when you see your team members working away, it's a little more emotionally difficult to take time off to surf your favorite website or something.<p>For customer service, video game mechanics help a lot: completing each ticket gets you closer to your goal. Keeping quality metrics up gives you a visible indication that you're a good person. It's not easy to implement and sell these kinds of features, but it's also not easy to keep people motivated (whether they're remote or not).<p>Scrum and frequent voice communication help a lot as well. There are downsides to distributed teams, but there are big upsides, as well. Distributed teams, while not perfect, have many benefits. The key to making it work, as with so many things, is to figure out ways to make everyone care and want to do their best. In absence of that vital culture of giving a shit, even a team that's co-located together is not going to do well. In my experience, that culture of excellence is even more important than being in the same place.
"So they gathered info on 35,000 papers in biomedical research where there was at least one Harvard author, calculated where the authors lived, and examined how influential the papers were — based on how many citations they received."<p>Hmm. The papers they looked at were from 1993 to 2003, and remote collaborative technology has improved a lot since then. Other teams may have very different dynamics that biomedical researchers and Harvard professors. Hard to know what to take away from it.
It has been my experience that <i>if all other things are equal</i>, working together beats working remotely.<p>Of course, if you are a young startup and you have a choice between an ok hire working locally and a star working remotely, all other things are not equal.<p>Some companies would always take the local guy. Some would hire stars wherever they find them. Some would hire neither and wait for a local star. I certainly can't generalize about which strategy is the best.
I've had very good results working with the owner of Set For Marriage, despite him living in Houston and me always either in San Diego or Olympia.<p>I think the reason is because we talk on the phone or over Skype throughout the day and coordinate things over Basecamp. I'm not sure if it helps that I'm the only developer on the project right now and mostly have creative control (he's down with anything as long as it sounds good), but we're hoping to get another developer on board soon so I'm curious to see how it works out.<p>It has been difficult working with some remote clients in the past where there wasn't that level of communication, and I've found that daily phone calls work much better than even chatting over instant messenger. I'd like to see how Campfire would work out, but it's difficult to get people to stay on Campfire all day unless they're completely sold on the idea.
Co-location saved a big project at a crucial point, after I had done my best to inject a wrench into the project.<p>A few years ago, I raised some concerns about the hacks we were doing at the end of a sprint review session. As part of the innocent "does anyone have anything else to say". This completely derailed everyone and the senior product management was surprised. This was about 60% into a 1.0 product. As a result, our scrum master and tech lead flew the other two members of our team who were remote in - and we had intense/design/coding sessions in a conference room for a very long week. We were able to address all of the hacks and get on the right track going forward. With my unsolicited comment, I was able to surface a lot of what was being unsaid (remember, techies at times of stress can tend to clam up). By co-locating the entire team for one week (on very short notice - travel arrangements were made the next day), our tech lead was able to address the problem straight on and bond our team stronger.<p>I can personally attest that my best coding sessions have all been pairing in person. Face to face is still the best collaboration mechanism out there. Even the best Campfire session is just a transcript of the human drama.
I wonder why MS found a different result when they studied the issue: Does Distributed Development Affect Software Quality? An Empirical Case Study of Windows Vista, <a href="http://research.microsoft.com/apps/pubs/default.aspx?id=138224" rel="nofollow">http://research.microsoft.com/apps/pubs/default.aspx?id=1382...</a>
I'm a developer who usually works remotely. I agree that people work better together when they are in the same place, but by having a distributed team you are not restricted to recruiting just people from a certain area and so the standard of the people in the team can be higher. So for teams that require a fairly specific skill set, teams that are recruited from anywhere in the world and working remotely would often outperform teams recruited from one area who work in the same place.
I think this subject is more nuanced than these studies. A few things that come to mind:<p>* Do the personalities of the workers have an effect? I would imagine that introverts could handle remote collaboration better than extraverts.<p>* Does the type of job matter? For instance, I would imagine that it might be a lot more difficult to build a remote team of investment bankers than it might be to build a remote team of programmers.<p>* Are certain phases of a job easier to handle remotely? For instance, perhaps coming up with an architecture needs to be collocated but the actual process of coding might be more productive if handled remotely. Or perhaps writing a research paper can be handled remotely, but editing it needs to be collocated.<p>I do find the third of these points the most interesting though. It might be possible that there are certain parts of a project that are bottlenecks unless collocated. Thus, it might be possible to build a remote team, but fly them in for critical parts of a job.<p>Regardless, I think this study is interesting, but I'd take it with a grain of salt. I don't doubt that this is true for the average person. But that's really not relevant. What's relevant is whether it's true for <i>your</i> team and <i>your</i> job.
How is this relationship any different from saying that if two Harvard professors publish together it receives more citations than if a Harvard and non-Harvard (remote) professor publish together. Seems pretty obvious given that the quality of authors will go up, including the their ability to promote their work.<p>I'm always surprised how scientists do such bad social science even though they perceive social science as very bad science.
The most efficient I have ever been was when we had 4 of us sat around a large desk, a coder doing UI, a coder doing back-end, a user/business expert and a data-migration expert. When I wanted to check what was going on, I just had to twist my monitor and point at it to ask if I was doing the right thing. Vastly superior to even working 30 feet from someone else.
I've always wondered about the efficacy of distributed teams. It's easy to see people all over the web that expound the virtues of not working in an office. 37signals comes to mind here, since they are always warning of how working together in an office is only distracting to productivity.<p>I've found it to be quite the opposite. When working together in a group, everybody seems to motivate each other and work gets done faster. That's why founders who share an apartment that doubles as an office seem to be most successful IMO (insert marriage joke here).<p>In the end, my guess is it just comes down to either team size or personal work style. There's no one rule that can be applied to everybody. Obviously, if you have a team of more than 20 people, being close together isn't going to make much difference since you aren't interacting with everybody anyway.<p>The last line regarding having people brainstorm separately is particularly interesting though:<p>"That’s because the problems of face-to-face dynamics go away: The “virtual” group is better."
My co-founder has been out of town for about a month now and while not substantial (yet), I see my productivity sliding. I have come up with some hacks to prevent this. But there is a kind of intensity/momentum that gets generated when the two of us are in the same room. The effects of colocation are probably different on different people but in my case at least, I need to be in close proximity to my team.
Within the, slightly mumbo jumbo, world of research into team dynamics (yes it exists, yes it is a surprisingly large field) they relate this to something called "information richness".<p>i.e. Speaking to someone face to face includes visual and tonal clues to accompany the information. Digital communications can be a lot less rich (the worst being discussion forums and similar) which causes all sorts of complexity problems - a lack of engagement, misunderstandings, offence taken at wording (we all know how tough sarcasm is to convey online I am sure).<p>Then you factor in the problems of different timezones, company and country cultures and varying tool preferences and, yes, it seems obvious that virtual teams will suffer.<p>This paper seems pretty good from a quick read through; however I think there is a big caveat - they are studying academic research papers. Which is fine, but only one data point.<p>A lot of effort has been put into new management techniques for remote teams and, nowadays, <i>within a corporate project</i> you will often find virtual teams working as efficiently as (or even better than) co-located equivalent.<p>But you need a good team manager to pull it off.
I've worked remotely for 10 years. 5 different startups.<p>Its had its ups and downs, but its working better now that ever. We're using an always-on collaborative tool that removes all the friction: Sococo.com<p>Our project has taken 3 years and involved Engineers/managers in 4 states. We've interacted daily and in a ad-hoc manner. Now we're doing Agile development to some degree, and thats working too.<p>The article mentions Skype etc. We're way beyond that. Any conclusions may be stale.
The research is probably best applied to what it studied, producing 'influential' research papers.<p>It could well be that the papers were more 'influential' because with having the team co-located it got enough notice within the network to gain popularity. What I mean by this is that with 5 people in a concentrated area talking about a paper that it got to the 'front page' of what academics in the area were working on.<p>It's like saying teams work better closer because those teams got more links to the front page of HN because they each upvoted the story enough to get it on the front page where it could gain enough votes to stay.