The Pond
randsinrepose.com
randsinrepose.com
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).
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.
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.
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.
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.
Thanks!
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.