
The Pond - naish
http://www.randsinrepose.com/archives/2009/04/15/the_pond.html
======
frossie
Good piece, good advice. Since OP was generally negative on remote work, I
want to put forward a counter-example of situations when remote work is an
advantage: When you can get 24 hour support without anybody working
nightshifts (by harnessing timezones) and even more, when you are shielding
valuable people from operational hassles in order to allow them development
time.

OP says: "What was a 27-second walk down the hallway to yell at Bob about his
crap code is a now 30-minutes constructing an email." My response to that is
(a) dude, pick up the phone, it won't take more than 27 seconds but more to
the point (b) Maybe Bob would write less bad code if he didn't have people
waltzing in to talk to him all the time.

I totally sympathise with the telecon complains though and I agree, it's not
for everyone. I went nuts trying to work from home during family leave, I felt
so out of the loop (sorry, Pond).

------
jmtame
This is a classic problem in start ups, and I would strongly recommend against
doing remote if you can avoid it. I only know a few people who have ever
pulled it off successfully, and they are _really_ good. Statistical outliers.

You cannot replace having an entire team in the same spot where people can
grab a white board and clearly talk about what something means. Just the
energy alone is probably enough to keep everyone active on the project. It's
difficult when you don't see others contributing to a project. You start to
think you're putting in more work than the rest.

I've worked for two start ups. The first one didn't do remote work, and while
the leadership initially was poor, the execution was actually insane. The
second start up had mostly remote workers, a few PhDs in the same city, and me
and another guy doing the front end and servers, and it was a little slow. I
tried to recruit some people who had worked at Google and YouTube (as
undergrads), and they turned the offer down simply because most of our team
was remote. A lot of people join a start up because they want to meet other
smart people, not just work on a cool product.

------
gills
Ugh...great article about the reality of workplace communications, but I think
it needs to be underlined.

From what I've seen, remote is a function of the whole team -- not just 'does
this guy depend on the Pond' but 'does the rest of the team depend on the Pond
for their interactions with him/her' and 'do I, as a manager, depend on the
Pond?'

I'll be forthright -- I don't like the Pond. To me it implies a lack of
communication discipline; dysfunctional project management; a place where
tribal knowledge and unwritten nuance rule behavior; and a place where power
is derived from mastery of this subtle channel rather than documented
performance and technical prowess. Rands' checklist for 'remoteable' workers
is filled with issues of communication discipline -- able to get a point
across in IM; cover an entire issue, eloquently, in email. I would add at
least a couple more, such as 'reviews, documents, and publishes the
[technical] decision process', and 'keeps trustworthy metrics on progress and
technical issues'.

Too often groups use colocation as an excuse for undisciplined communication,
then run into this uncertainty about remote workers as a side effect of the
monster they've built.

------
tjic
I've worked with developers who never EVER allow themselves to be interrupted.

Yes, yes, I acknowledge mental state, "flow", etc.

...but when you've got a developer who comes in, nods "hi", goes straight to
his desk, codes for 8 hours, then stands up, nods "bye" and leaves, that's
almost as disruptive to team cohesion.

"Schedule a meeting" is not an acceptable answer. There is value - big value -
to informal communication.

I suggest that all resilient systems need a bit of unscripted, unscheduled
slop.

This applies to HR policies, customer support policies, building large
physical structures ... and team interactions.

~~~
Retric
My advice for working with such people is to just use email. Require people to
respond within 4 hours and before they leave and 95% of the time that's good
enough. Interrupting flow costs between 1/2 and 4 hours of productivity, but
most people take breaks so as long as they respond in a reasonable time frame
it should be fine.

------
mcslee
Interesting article. Can't help but think about how it's no coincidence that
so many technology companies have come to exist in such close physical
proximity in Silicon Valley. This article speaks to managing a team, but the
power of the Pond metaphor goes well beyond single companies/teams.

------
dejb
Good article but it fails to mention perhaps the most important technology for
making it work - the telephone. I'm not so sold on teleconferencing - similar
issues as with videoconferencing. But one-to-one calls can and do work.

------
geoffc
The problem he is describing is the information disparity in the mixed
onsite/remote setup. In my current company all the developers (~15) are remote
and it works well as we all have to effectively use email, im and phone to get
things done. We don't have the informal office chat channel.

I have worked in all three scenarios, onsite, remote and mixed onsite/remote
and the mixed scenario is clearly the worst. The onsite vs. remote debate
comes down to the makeup of the team you have, it's a different type of person
that is successful in each setup.

------
blogimus
That is a very interesting and lucid narrative on working remotely. I've not
read his stuff before. I like it. He points out some of the obvious on office
social interaction, but in an organic way (hence, _the pond_ ). To that he
outlines points addressing his concerns, recognizing the necessity of remote
work, but driving home the social costs and identifying his metrics for the
traits someone would need to successfully work remotely.

Thanks!

------
edw519
I would take the Pond a step further. Programmer/analysts should not have
their own office space in IT. They should be sitting with their users.

If I have to listen to idle chatter all day, I don't want hear Joe bitch about
the poorly written code he has inherited or Mary complain how hard it is to
normalize her database. I want to hear Tim bitch about how hard it is to
update an invoice or Julie complain about why data has to be re-entered into a
web app from an Excel spreadsheet.

The best application software comes not from technical prowess, but from
intimate knowledge of that application. If you're not a user, you should be
suffering with them. Need office space? Knock off 2 birds with one stone and
sit with your users.

------
BobN
I've done Remote and the Pond. I like the Pond a lot better.

------
c00p3r
That is just an opinion. For me, for example, remote work is a essential idea
in this economic crisis. We can save on office, on hardware, phone bills -
everything. trac with discussion plugin and blog plugins is time-tested
solution, along with little bit of self-discipline, of course. System
administration tasks, for example, on Unix systems (which were designed for
remote work, in contrary with all those desktop virtualization crap) can be
perfectly done remotely. One week ago I did some emergency tasks on Informix
server located in arctic Russian city Murmansk from Kathmandu, Nepal via local
EDGE connection. There are many more benefits from globalization-affected
outsourcing - the cost of living, conditions, climate, people around you and
so on.

