Hacker News Reader

I don't see how working remotely can ever replace the human interaction of working in one place.

For things that require physical presence, like IT, sure. Most people don't work on stuff like that. For those people, video meetings, slack, etc., can be fine for keeping in touch and having the entire team feel connected.

And, yes, having a working internet is the single point of failure for remote work. It's reasonable for the office to have redundant connections, but not for people. For the 16 years I've lived in my current place, I've probably not had a connection for no more than 24-48 hours.

And during those outages, the telephone generally works.

Everyone running to a conference room -- feels very Michael Scott to me -- and almost always just as unnecessary.

I wonder about those who claim face-to-face is best explain how Github and Basecamp seem to do just fine. Others point to how Yahoo eliminated remote as some kind of argument supporting same, yet I'd hardly consider Yahoo to be a good example of anything. If "good enough for Yahoo" is an argument, then count me out.

Unless you physically have to touch something, remote can always work (and even be better.) It's a question of establishing processes that work. The 'genre' of remote isn't the problem -- it's always the implementation.

> How long would this take if we were spread across timezones with different hours and variable lag time between communication?

Most of us work in Europe, but our ops team has been created specially to be distributed across timezones. They have rotating pager duty, as you do.

If I am fixing our staging setup, which is not customer can access data with 99.85 uptime required but still can halt team of 50 devs to a halt especially during release-testing, it is ~5 mins to get somebody to help \w slack/irc/e-mail.

> If the internet is down is there any backup?

Internet? No. But we do have several VPNs. Getting someplace where there is internet was reasonably simple so far.

> How much would it cost to give every single employee a backup method of communicating?

Hey, if there is real trouble, I can always call my manager.

> How does an employee separate a desperate please for help from the endless stream of BS emails and messages that aren't terribly important?

We are split into sub-teams, where the 3-8 people you are closely working with would definitely read your message.

>Take for example a few jobs ago when our servers went down because of a local internet outage.

having an option of your servers going down because of a local internet outage is a luxury your company had. As you correctly point out, a company with remote employees spread across timezones just wouldn't be able to allow themselves such a luxury, and to me it sounds like a good thing. It makes people and company think and work in a distributed fault tolerant way.

Great point -- and that's something that never occurred to me :)

I've found that working all in one place can lead to "over-meeting". What I mean by this is the tendency to have meetings for the sake of meetings and people not having time to get stuff done because they are stuck in meetings all day that are dubiously productive. It takes the same discipline that remote working takes to cut down those interactions to only what is important.

> Take for example a few jobs ago when our servers went down because of a local internet outage.

That's not a great example, because that's a problem that's already caused by over-centralizing. If you used colocated servers or cloud hosting, that doesn't sound like a local Internet outage would have been a problem.

More broadly: at some point, every successful company will need to handle workflows of people who aren't in the same physical space. It's much easier to bake these habits in as a small company and grow with them than it is to retrofit them onto a company once it needs to open a second office in a different city or country.

People are used to working with others far away constantly in daily life. I don't think it's much effort to say "yeah the guy that sits across from you, from now on youll have to call him" .

Especially if most of the employees in the new office are new, I don't think it's much or any real work needed to teach people to work with remote employees.

I'm just arguing that decentralizing has a fixed cost of more difficult communication, not something you can save up for or build into your company from the start.

> I don't think it's much effort to say "yeah the guy that sits across from you, from now on youll have to call him" .

Let me start by saying that I'm not speaking hypothetically. I'm speaking from experience here, having worked for companies both remotely and not-remotely, and seeing where that's succeeded and failed.

It is actually difficult to make that adjustment, because working in the same space breeds a lot of bad communication habits which don't scale.

Working remotely from the start, you end up being forced to document work (even minimally), or to make decisions over a medium that is readily archive-able like email or Slack[0]. This is particularly true if you're working across timezones, even a small difference like east/west coast in the US (3 hours). Reading through an email thread to reconstruct history isn't the ideal form of company documentation, no, but it sure beats not having it at all because all of the discussions happened in real-life and nobody felt the need to send out an email afterwards to formalize it.

If you develop a collective habit of never making important (or irreversible) decisions without some sort of asynchronous and archiveable communication, and always having canonical internal documentation and runbooks for internal systems (because some of the the people who may need to operate them are working different hours), you don't run into the situation where your company has suddenly hit 300 people and needs to open an office in Europe, but can't break the bad habits of relying on information held in people's heads and exchanged in ephemeral, synchronous form.

[0] Lest anyone misinterpret what I'm saying: Slack is emphatically not a replacement for proper documentation. It can, however, be a helpful forcing function to bootstrap proper documentation, and it serves that role far better than meatspace interactions or even video conferencing ever do.

>I don't see how working remotely can ever replace the human interaction of working in one place.

What "ever"? It has already replaced that for thousands of companies, including some valued at billions...

>People forget, humans are not machines.

Thankfully there's this great new technology called IM, where they can ask somebody (and in an even less intrusive manner than directly disrupting their flow going to their desk to talk to them).

And yet, Linux exists.

So, in your anecdote above, what was the resolution by utilizing "all hands on deck" to restore the servers?

I would also argue that McDonald's employees require a large amount of collaboration, but this is built into the operating processes of the company, not face-to-face contact.

I love your strawman example of the "war room" meeting.

On my remote team this has happened 3 or 4 times during production outages. The situation was nearly identical, except for lack of physical server room (we use AWS). Someone wrote an @team message in Flowdock, "Things are broken, we need a war room." Within seconds, people were in a video chat room. Within minutes (or, in one terrible case, hours), the issue was resolved.

The way everyone knew it was serious is because we rarely use @team-mentions and rarely call "war rooms". Also, our automated monitoring was firing and triggering pagers in PagerDuty for the on-call engineer, the log of which was also plainly visible to everyone in our Flowdock Inbox.

So yes, your example here is a nice one, but a strawman. Remote teams know how to take outages seriously.