
Study: Teams work best when members are physically close together - sdfx
http://www.collisiondetection.net/mt/archives/2011/01/_when_i_wrote_a.php
======
unoti
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.

~~~
rwhitman
Is there an example of the sidebar you're talking about that we can look at?

------
jdp23
"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.

~~~
mtkd
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.

------
raganwald
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.

~~~
jayzee
please dont say 'star.' please.

~~~
raganwald
"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.

------
jarin
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.

------
wallflower
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.

------
luu
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,
[http://research.microsoft.com/apps/pubs/default.aspx?id=1382...](http://research.microsoft.com/apps/pubs/default.aspx?id=138224)

~~~
j_baker
Two things leap out at me:

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.

------
lukepublic
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.

------
j_baker
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.

~~~
PakG1
>> * 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".

Here's one anecdote of where it's easy enough for financial guys to have
analyst work done by non-colocated people, and still achieve success:
[http://www.businessinsider.com/pine-river-bejing-china-
beiji...](http://www.businessinsider.com/pine-river-bejing-china-beijing-
quants-math-geniuses-2011-1)

------
equark
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.

~~~
btilly
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.

~~~
blahedo
> _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.

------
AndrewDucker
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.

------
guptaneil
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."

------
rahooligan
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.

------
ErrantX
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.

But you need a good team manager to pull it off.

------
JoeAltmaier
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.

~~~
fbailey
Why do you use sococo. I just visited the site and it just looks like skype
with a weird Office UI ? Is there more to it?

~~~
Silhouette
Possibly because he works there?

<http://www.linkedin.com/pub/joe-altmaier/6/38b/996>

~~~
JoeAltmaier
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.

------
fleitz
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.

------
ergo98
To say that this study doesn't support the broad conclusion is being generous.

