
Full Distributed Teams: are they viable? - sak84
http://www.pixelmonkey.org/2012/05/14/distributed-teams
======
jamesu
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.

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

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

~~~
GFischer
Startups with money to burn could buy one of those remote robots for
telepresence :) like the Anybots QB

[http://spectrum.ieee.org/automaton/robotics/industrial-
robot...](http://spectrum.ieee.org/automaton/robotics/industrial-
robots/051810-anybots-qb-new-telepresence-robot)

or the texai

[http://spectrum.ieee.org/automaton/robotics/robotics-
softwar...](http://spectrum.ieee.org/automaton/robotics/robotics-
software/052710-how-i-became-a-texai-robot-and-went-partying)

Maybe one day this will become commonplace (when they become an order of
magnitude cheaper, I suspect). Meanwhile, Skype is a good idea.

~~~
DeepDuh
"Startups with money to burn"

What is that sorcery you are speaking of? ;)

------
dredmorbius
There's no mention of Free Software projects.

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...](http://books.google.com/books/about/The_Success_of_Open_Source.html?id=ELieXMxR1h4C)).

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.

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

~~~
loceng
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!

~~~
mmastrac
Yeah, I should have noted that. It's much harder to be "acquirable" if you're
all over the place.

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

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

~~~
SkyMarshal
Which IRC server and logging do you use?

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

i love it. now back to work :o)

~~~
sak84
Perhaps then, it acts as a good filtering mechanism. You're able to figure out
if individuals are value add or not quicker.

~~~
Silhouette
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.)

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

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

~~~
its_so_on
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 :)

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

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

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

~~~
MattRogish
+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.

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

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

~~~
ipmb
We felt the same pain and it's why we built Ginger (<https://gingerhq.com>).

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.

~~~
Killah911
Thanks! I'll sign up for it and try it out.

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

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

------
cpeterso
Mozilla's Release Engineering team shares their experiences with a distributed
team in a slide presentation called _We Are All "Remoties"_ :

<http://oduinn.com/blog/2012/04/04/we-are-all-remoties/>

IRC and video chat are two critical components for Mozilla's teams.

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

------
clueless123
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

------
scoates
In my experience, if you abide by the important rule of "work with excellent
people," distributed teams work well.

I currently work on a team of 12, in three countries and at least seven
cities.

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

~~~
TazeTSchnitzel
At least in GitHub's case, they have a physical office but I don't think
employees really communicate much face-to-face.

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

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

------
mjwalshe
All things being equal a collocated team will always beat distributed ones
-soory to be brutal but thats how it is.

Anyone who says otherwise is a sales man trying to flog video conferenceing
gear or deluding themselves.

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.

