Remote worker vs distributed team

No readers like this yet.
Tug of war

Opensource.com

Not all work-from-home gigs are created equal. There is a vast ocean between being a member of a distributed team and just being a remote worker.

The groups of "remote worker" and "distributed team member" are neither a super-set nor a sub-set of one another. Insead, they can be represented as a typical Venn diagram.

remote workers vs distributed team

Image credits: bob.mcwhirter.org

Remote worker

A remote worker is someone who simply isn't in the office. He's off on his own. Somewhere.

When you're a remote worker on a team, you might be the only remote worker on that team. If you've worked on a traditional team, but suddenly got moved to Montana to tend to your family's bison ranch, and your employer didn't want to let go of you, you're a remote worker.

The other 11 guys on the team are not remote workers. And you're not on a distributed team at all.

Distributed team

A distributed team simply means that you and the vast majority of people you interact with are not near each other. No mention of "at home" is included in this definition.

If your company has 20 offices scattered across the globe, and your team has a member in each, you're a distributed team. You all might be sitting in your cubicle at each office, so you're not automatically remote.

But you might as well be.

Why it matters

When I joined Twine.com, my coworkers and I were all remote, every last one of us. That forced our team to be distributed. And it worked fantastically well.

After an injection of funding, offices were opened in San Francisco, and most of the team relocated. Except me.

I was suddenly just a remote worker.

When the team is distributed, all communication happens on an equal footing for all members. You use IRC, mailing lists, bug trackers. You're forced to not rely on hallway conversations or lunch-break chatter.

Everyone can participate equally.

When you're a remote worker, on the other hand, you completely miss out on many communications channels. A dozen people are in a conference room scribbling on the whiteboard, and you're listening blind on the crappy speakerphone.

Not fun.

Adding more remote workers to a non-distributed team actually only increases problems and frustration. You simply have more people who feel alienated and isolated.

Breaking over to a majority of remote workers, though, forces the team to reformulate as a distributed team. They rework their habits, expectations and workflows. And ultimately, the team functions better for it.

Problems vs remote

Image credits: bob.mcwhirter.org

Doing distributed

Skills needed by distributed teams are the same skills developed by participants in open source projects.

Communication occurs through "permanent" and "public" means (within some scope--these may be purely internal), such as mailing lists and IRC. Using them avoids much of the point-to-point communication between individuals.

I've found IRC invaluable to my team, in that it helps form that group atmosphere, even though we're hours apart. During the workday there's technical discussion, random chatter, jokes, and other interactions that help avoid isolation.

Distributed teams also need to select tooling that not only provides a technical function, but also one that they will actively use as additional communications channels. A by-product of using a tool correctly is group memory and knowledge. For instance, notes attached to bug reports or issues in JIRA and messages in the commit logs all should contribute to institutional memory.

When a non-distributed team doesn't have to rely on these methods, substituting the water cooler instead, they actually lose this benefit in a severe way. Distributed teams end up functioning better because they must be better organized if they wish to function at all.

Another up side to distributed teams is that there's always a back channel. A team of 10 meeting their boss or another stakeholder in a conference room have to communicate through facial expressions, nods, winks, hand gestures, and dramatic sighs. Distributed teams just open another IRC channel for chatter, clarifications, objections, and contributions amongst themselves.

Bottom line

Remoteness just adds problems. But distribution solves a lot of problems, including that of being remote.

All teams could benefit from the same practices of distributed teams, but it takes work, and they're ultimately lazy and often don't reap the advantages.

Being a remote worker is not fun at all. Being a member of a distributed team is beyond awesome.

This article was originally published at bob.mcwhirter.org.

User profile image.
Bob is a JBoss Fellow (a part of Red Hat). He leads the TorqueBox project for JBoss, building an open-source Ruby application-server on top of JBoss AS. Previous to working for Red Hat, Bob was involved with the founding of The Codehaus open-source community, and is one of the creators of the Drools business-rule engine.

1 Comment

I agree that distributed teams work far more efficient, better then a team with one or more remote workers. I don't agree with your "is beyond awesome". Read the Virtual Distance from Karen Sobel Lojeski. She's 100% right. I have experienced every aspect in her book. There is no way you can replace "a real team" (not a bunch of people) by any distributed team.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.