> I don't think it's terribly controversial that collaborating in person is much, much easier.

It's fairly controversial, especially among engineers. Not all engineers, but a sizable percentage of engineers are not comfortable in social collaboration - especially forced social collaboration stretching over multiple hours for difficult tasks.

As far as 'easier' goes, 'easier' isn't always 'better'. While that online collaboration across a slack channel may have higher friction, it would also have many benefits as well. Other people can follow the entire process, so continuous status updates aren't required. The chat can be stored so if the issue happens again, it's easy to reference back to what was done.

> But it's entirely unsurprising to me that innovation is more likely to come from collocated teams.

I don't think this is proven anywhere, and may be one of those things where you think it is correct, but it really isn't. Fully integrated remote work as we have today is a very new phenomenon and there hasn't been much research into it. Further, many quick growing startups that are looking very promising are taking the 'remote first' approach and seem to be benefiting from it from an outsider's perspective.

I'd suggest that if you've made up your mind that distributed teams are not going to work together effectively, you probably shouldn't have distributed teams. Not that best practices are always followed, but it's pretty standard practice that distributed teams should try to avoid things like offline decision-making by co-located workers as much as possible.

> So for the sake of pretending that the remote team members are able to contribute as much as the local ones you hobble those who are local?

Even when everyone is local, I have found the best communication occurs when forcing everyone to pretend they are remote. So many times person A talks to B and they make some incorrect decision or assumption that person C would have been able to head off if they were involved.

Having the same conversation in group chat or group email does two things. First, it lets others engage if they need to without being actively interrupted. In my example above person C could have stepped in when noticing the conversation in group chat.

Second, the conversation is now perfectly documented. "What was that decision we made 2 weeks ago? Oh yeah, it's in chat/email." I also find that writing really makes people think. Bezos is famous for forcing people to write their ideas down in memos before meetings[1].

The missing person scenario above can be worked around if everyone is in the same office, but people hate sharing open spaces today. It also does not solve the documentation issue.

[1] http://www.qcommservices.com/blog/jeff-bezos-writing-memo-im...

That's really the crux of it. Remote work is a cultural problem, not technical...

I've worked on very remote-friendly teams, the tendency to work in isolation was a constant problem. But properly using tools like email/slack/wikies was sufficient once we addressed the cultural aspect.

I have to wonder if we can’t learn something from newer social media platforms and apply it to productivity ecosystems. The fact it’s almost tough to not share any activity may be important. There’s so much effort we have to expend to construct thoughts professionally but in office situations besides personal connections that are only possible offline (sports and other non-digital recreation) we tend to have a lot of half-baked ideas and easily overhear conversations from others against our normal flow of thought (why open floor plans are oftentimes highly criticized). When we’re heads down coding we’ll miss all this even if people are physically colocated.

Among higher level folks that don’t code or design or other technical work perhaps it’s more important for the ad hoc communication styles.

Maybe it’s even just rate of communication though? I type easily over 100 wpm and my typing is probably faster than I can talk. But when typing it’s synchronous versus conversations are streamed protocols with chances for interruption and such to reclarify meaning that is much slower when you have to buffer everything first in one payload and wait for ack. Maybe someone that’s studied communication can actually give some concrete data on my hunch?

The time working remotely worked best for me, I spent three to three and a half days a week interacting with coworkers, meeting, troubleshooting and identifying problems. Then on fridays I sat in a coffee shop coding like mad to address one or more of the things I learned by talking to people.

My code (central library six products used to interchange data) was good because I saw it reflected in the experiences of my coworkers.

To experience that I had to train people to interact with me when they got stuck. I needed to be absent one day a week so that I had an opportunity to do something about what I learned. To execute the plan I had built up all week. Almost half of the code I wrote all week was done on fridays. But it was often the most useful.

Do that for a couple of yours and then get back to us.

I saw an interesting quote recently: “Alone we go faster but together we get farther”.

I would say I'm about twice as productive too.

Open office is the complete disaster result of an unholy alliance of management trying to skate by on the cheap and agile consultants pimping their latest slogans.

Even without open office, there is so much chit-chat, gossip, politics, posturing (how about a meeting to discuss the upcoming meeting), and other crap that gets swept under the rug as collaboration.

Don't forget that certain personality types just can't handle working from home or in a quiet environment. They'll just go bonkers, so they run around telling everybody else that you can't be creative and collaborate without chatting someone up in the urinal next to you.

The top comment spin is so humorous that you would almost think it's a troll, but probably not.

Even for Google — when I was on the Chrome team a few years ago (to pick a nice open example, in case anyone wants to stalk my commit history) my most important collaborators were three and twelve time zones away.

What many projects don't discover until too late is that the practices that let you work effectively across ∆x are the same ones you need to work effectively across ∆t, and no airline can fly the new hires to last year's face-to-face.