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.
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.
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).
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."
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.
If you took 35 startups that span continents and are no more than 2 years old I think the results would be significantly different.
I've worked in close proximity and remotely - you can't beat a small team of motivated developers working where they are most comfortable - collaborating through Campfire, Google Docs and Github.
... as in, most often-cited papers are older (taking some time to amass the citations), and effective collaboration tools only became available much later?
Also, the progress that has been made on remote collaboration (say, Skype and DVCSs versus telephone and CVS) is significant. I won't say that there is no advantage to meeting in person, regularly, but the alternative "Researchers keep high-impact work within their own lab" does sound very credible.
It has been my experience that if all other things are equal, working together beats working remotely.
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.
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.
There's a lot to be said about working in the same location. I never bought into the 37Signals school of thought that location doesn't matter, and can hamper productivity by way of interruptions.
"Star employee" is a term with plenty of history and a meaning most people grasp. "Rock star" is another thing entirely, and not what I think of when hiring programmers. I also don't think of hires as prestidigitators or thaumaturges, even when using the term "magic" to describe technology.
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.
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.
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.
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.
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.
1. The OP's study and the MS study were studying people in different fields.
2. The OP's study and the MS study are studying two different things. The OP's study measured how many citations published papers got, while the MS study measured a lack of bugs. So you might be able to say that collocated workers produce better quality work but don't make significantly more mistakes.
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:
* Do the personalities of the workers have an effect? I would imagine that introverts could handle remote collaboration better than extraverts.
* 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.
* 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.
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.
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 your team and your job.
>> * 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.
>> * 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.
Nitpicking, but I think the 3rd question is invalidating the way the 2nd is phrased. Comparing investment bankers and programmers is difficult to put as apples to apples. Easier to compare investment bankers to architects or analysts to programmers at a detailed level (although admittedly many investment bankers would be their own analysts, just as many programmers would be their own architects). Perhaps the 2nd question would be better phrased as "Does the type of industry matter", rather than "Does the type of job matter".
I think you're on to something with the extroverts, particularly that extroverts would be more likely to work closer together and for this study be more likely to talk up their paper to a large number of people.
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.
I'm always surprised how scientists do such bad social science even though they perceive social science as very bad science.
The same study found that collaboration inter-city is more productive than collaboration intra-city. That would not be expected by your "two Harvard professors" theory.
In any case it shouldn't be hard to reproduce with a larger sample of universities.
> That would not be expected by your "two Harvard professors" theory.
Maybe, maybe not; consider that the other college "intra-city" is MIT, and presumably they also included Northeastern and BU and BC on the list. Just knowing that a professor teaches at a school in the Boston metro area raises the prior of them being at a top school.
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.
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).
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.
The last line regarding having people brainstorm separately is particularly interesting though:
"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".
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).
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.
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.
A lot of effort has been put into new management techniques for remote teams and, nowadays, within a corporate project you will often find virtual teams working as efficiently as (or even better than) co-located equivalent.
I've worked remotely for 10 years. 5 different startups.
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
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.
The article mentions Skype etc. We're way beyond that. Any conclusions may be stale.
You bet! I spent 3 years of my life consulting with these folks, helping with architecture, coding the network and voice components, recruiting for the UI and server-side.
It started being useful two years ago. We were our first users. Our productivity climbed, and our travel bill halved immediately.
Its nothing like Skype. No "phone call" model at all. You're instantly connected, can see everybody in your group at all times, you can tell who they're talking to, when they're done.
The map feature is more useful than it might seem. You can tell what your team members are doing, who they're talking to, whether the staff meeting has started, if Bob is in today etc.
I didn't call out my involvement this post, I've done that on half a dozen posts before, sorry.
Everything that has voice is not 'just skype'. Sococo is betting that the 'phone call' model will become obsolete, like email is giving way to chat and twitter.
Try it, its free. And only about 6Mb download (most of that graphics) because the app is essentially a 'dumb terminal' - the meat is on the server.
The research is probably best applied to what it studied, producing 'influential' research papers.
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.
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.
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.
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).
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.