Hacker News Reader

Comment by closeparen | Hacker News Reader

Have you ever tried working on a difficult bug or vague and ill-defined new problem space with a combination of local and remote coworkers?

Can it happen online? Probably. But proximity vastly decreases friction and increases the chances of success. Even between offices with enterprise-grade fibre and high-end videoconferencing-integrated conference rooms, telepresence isn't that good yet. There's no substitute for unscheduled hallway conversations and impromptu whiteboarding. These things might be unnecessary distractions if your job is to churn out code that fulfills well-defined specifications, but if you're doing something new and innovative and not fully understood yet, or something complex enough to require deep interactions with your coworkers (beyond task assignment and status updates), they are a major boon.

View on HN

> Have you ever tried working on a difficult bug or vague and ill-defined new problem space with a combination of local and remote coworkers?

Yes. It works if you agree that "local" doesn't exist anymore. If one person is remote, everybody is "remote". As long as that's the agreed medium, many issues go away - it actually gets better sometimes, because that private water-cooler conversation which would be interesting to other parties is sometimes available for copy-paste.

The point is to compare the experience of collaborating deeply with someone who is physically present vs. someone who isn't, not the organizational dynamics of a partial-remote team. I don't think it's terribly controversial that collaborating in person is much, much easier. It might be rational to make a conscious tradeoff to optimize for labor and real estate costs vs. collaboration efficiency, especially if you only need to coordinate your separate tasks vs. genuinely work together on the same design and problem-solving activities. But it's entirely unsurprising to me that innovation is more likely to come from collocated teams.

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

> a sizable percentage of engineers are not comfortable in social collaboration

There's some upper limit on what you can accomplish as a sequestered lone-wolf genius. I don't deny that people with such working styles have made impressive contributions, but the bar for "innovation" is rapidly climbing and will soon surpass what anyone can do in isolation. That's a pretty normal thing to happen as a field matures.

The detached, contractor-like model where you only need to communicate to receive well-defined tasks and deliver well-defined output has substantial benefits for fulfilling many business needs. If I worked on a software assembly line, there would be no need for communication outside the ticketing system. But when you're doing something new, not yet understood, and bigger than one person, you're going to need to talk about it. (Obviously you can still do that with phone/videoconferencing, but the friction it imposes on conversation is real).

> There's some upper limit on what you can accomplish as a sequestered lone-wolf genius. I don't deny that people with such working styles have made impressive contributions, but the bar for "innovation" is rapidly climbing and will soon surpass what anyone can do in isolation. That's a pretty normal thing to happen as a field matures.

I don't think this part is up for debate. It's more about how that social collaboration is handled in the best manner for everyone involved that would be up for debate.

Just because social collaboration is needed, doesn't mean everyone has to go out for drinks together or live together in a small apartment. That part is obvious, right? But just because social collaboration is needed doesn't mean people have to be together in the same physical space either.

I think the main point is that the type of social collaboration that is inducive for creative innovation fall within the realm of close physical proximity and whatever benefits that entails.

I don't know if this is substantive but I think that's the argument.

This answer does not jive with my experience working remotely nor my experience working in an office while working with a majority remote co-workers. The problems a remote team faces when it comes to producing good technology are not solved that simply IMO.

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? I guess if your intention is to prove a point, but the cost in overhead and diminished output from those who are local seems a bit excessive for my taste.

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.

For "effectively", substitute "as effectively", perhaps? The gradient is there, for the most cases.

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

I've found that, in broad strokes, communication doesn't happen as often as it should, even when all developers are collocated in the same office. It's easier to keep plugging away at something than ask for help, and many would rather develop their own ideas solo than solicit input early on and give up that control.

It's been my experience across three different jobs and many more teams that these problems all get much worse when developers are no longer collocated.

And I know there's always someone like yourself popping up in the comments saying that it can work well, but I've never personally experienced this.

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?

>and my typing is probably faster than I can talk

The average rate of speech for English speakers is 150 wpm: http://www.ncvs.org/ncvs/tutorials/voiceprod/tutorial/qualit...

Yeah, I work in an open space environment but we get to work at home from time to time when the need arises. I'd say I'm at least twice as productive at home than in the office.

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.

I'm about twice as productive at home too, when I have a concrete solo task. But early in a project, when we're not sure what it is yet, collaboration matters.

Nothing beats a white board early on, but there's no reason (and somewhat counterproductive) for everybody to be co-located 8 hours, 5 days a week.

Sure, it's great to have a 1+ days/week to work from home, but to do that you're still living in the same city.

I’d agree with this. In environments that are partially remote the people in the office often leave the remotes out of conversations they should be involved in. On remote focused teams, the problem goes away because the communication medium is the same for everybody.

Time zones and work schedule discrepancies are a bigger hindrance for remote teams in my experience.

Time differences also play a big part in effective remote collaboration. I'm not just talking about the obvious 12 hour-ish time differences between something like California and Hyderabad. Even the 3 hour difference between east coast and west coast can have a big impact.

For instance, after my second cup of coffee I'm ready to really start cranking through some ideas, troubleshooting, solutioning, etc. But my colleague in New York has just finished a big lunch and is settling in to spend the rest of his afternoon focusing on the problem he researched that morning. He is understandably annoyed at having to deal with my caffeine fueled mania.

Sure. Practically every open-source project with more than a single contributor does it all the time. In commercial projects, decisions about location aren't made by developers.

Large open source projects are often created by, and receive the bulk of their contributions from, tech company offices where real-time face-to-face communication is happening behind the scenes. Just last week, a few people on my team in San Francisco working on something related to a Google open source project drove down to Mountian View for lunch to discuss it with the authors.

When you don’t have that luxury, it takes so much longer to get patches upstreamed precisely because the design controversies have to be hammered out in asynchronous text. Even then, it’s often down to a benevolent dictator for the project or the topic area to approve or deny, there’s nothing like the genuine collaboration of two employees in the same building working towards consensus.

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.

Agree! In my experience successful remote work is associated with 2 things:

1. extremely well defined problem domains

2. incrementalism

For lots of engineers, those 2 points describe their job. Lots of (incremental) value is created that way.

But I'd argue that the larger gains accrue to those companies -- or those cities -- where work is being done in non-well-defined problem domains. And not incrementally, but by big leaps, experiments, and messy failures.

In fact, you could go farther and argue that in a competitive landscape, companies will quickly match each other in their performance in well-defined problem spaces, and the only way to actually compete at the margins is in problem areas that are, by definition, newer and not well defined.

Reply on news.ycombinator.com