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