I'm going to disagree here. It's entirely possible to work effectively with others via mostly-asynchronous communication. Open source projects, as you point out, can be a pretty good example of this. I'd further argue that for some (I suspect many...) people work much better when they can have long stints of focus without fear of interruptions.

Two-minute responses on Slack absolutely is a model that can work, and perhaps it's the easiest transition for people who've been working in a "teamy"/open-plan on-site setup. But I'm also convinced that it's not the only viable setup.

Open source projects don't have deadlines, product owners, antsy investors, runways, or quarterly goals, though.

Open source projects work that way because we have to, not because we want to. Large projects have semi-regular meetups/sprints where they can all get together face to face. Small one muddle through and try to prevent the problems not meeting face to face causes.

Large open source projects may meet other members at conferences but rarely do you find a situation where everyone can be in the same location/country at the same time.

I think the main takeaway is that it all comes down to expectations. If the expectation of the team and the communication medium is rapid response (minutes vs. hours/days), and that expectation is not clearly communicated and agreed upon, you're going to have trouble.

Likewise, if everyone knows that due to people's different time zones, schedules, etc. that 24hrs is a typical response window via email, there should be no complaints if responses aren't received more immediately.

But open source projects have no other way so they need to work that way, also there is little pressure to meet deadlines and such.

> If someone slacks you, the response should be as quick as if it were verbal in the office

While this can work for some people, such "interruptible anytime" mentality may not be good for many workers. For example, when I am most productive I need to minimize, and ideally eliminate, disruptions. Such periods are short (2 hours at most for me), but I could do 90% of day's technical work in those 2 hours. If someone wants something, unless it is a blocker for a large team, I will put it away and get back to it later.

This has nothing to do with being remote or local, this is just the mode at which I am productive. I try to treat folks who work for me the same way: we can still meet daily in the morning I try to give them enough structure so I do not need to preempt them every hour. Things happen, there are failed systems that need to be fixed now and other fire drills, but I find most people in technology development more productive when on an async comm channel. I am.

Maybe I am just old and you youngsters do not need to do it this way :)

Schedule some time, maybe call it a meeting on your work-wide-visible calendar.

This is exactly what I am talking about: a set of infrequent, mandatory meetings with most/all other comms on a high latency async channel.

It takes significantly more discipline for a PM to run things this way, but the reward is often better productivity and happier, less frazzled developers.

Now if only people would stop using `@here` for every little thing, it'd be easier to separate "blue" notifications from "red" and Slack would actually be the perfect model of async communication. I could prioritize whether to pull myself from my current task to look or not.

Doesn't work when people just write "@here, making nachoes" all day.

`@here` should really be yellow. Only direct communications red. Or something other than the current system.

BTW, slack let's you supress @here and @channel notifications - I do it for almost every channel I'm in ;)

Discord has a bunch of extra filtering built-in for their equivalent.

I've had only bad experiences where a 2 minute reply time is mandatory. I found that's the case with large-amorphous projects where nobody knows anything for certain, there's piss poor planning and that's why they need to keep "chatting" all the time. You're basically reduced to a message switch.

I think you're on to one of the major points. It would be great if companies could run entirely on asynchronous communication. Companies who do this well, and job functions that jive with asynchronous communication, can more easily support remote work. At some companies and with some jobs though, it's totally impossible.

When Mr. Exec wants a status update, and he wants it RIGHT FUCKING NOW. I'm not going to E-mail you and hope that your inbox doesn't have 10,000 other unread messages, or text you and hope you respond. I have to physically hoof it over to where you sit, apologize for interrupting, and get the info Mr. Exec needs. That's hard to do remotely.

If I know in advance I need a response about some topic, sure, try async first. If the deadline's a day out, E-mail, if it's an hour out, text or IM. But, after that if you don't respond, I've got to be the bad guy, break your concentration, and call you. And, if you don't pick up, I'm headed to where you are physically.

If your company culture embraces remote work it also must embrace responsiveness and a communication style that clearly conveys when responses are needed.

You can respond quicker in a remote setting because you are always connected. Good luck finding me at the office in two minutes.

>Yes. Having managed remote teams and being a remote dev, it's all about response time. If someone slacks you, the response should be as quick as if it were verbal in the office. If it takes 2 hours to get a response out of someone - then they are not participating correctly on a remote team.

This is pretty much why I don' want to work remotely.

At the office, when busy, I can turn my email and IM off. If people need something, they are welcome to come to me and I'll engage with them. I do not want to deal with urgent issues over any kind of IM. If you are not physically present, then call me and we'll have a voice chat.

My frustration is that IM is used for both urgent requests, as well as non-urgent ones. It's used as an alternative both to phones (immediate need - synchronous) and to email (no rush - asynchronous).

My fear in working remote is that I'll get too many non-urgent interrupts using IM. I cannot see a good reason to use textual IM over a voice chat. If it's not urgent, just use email.

So while I agree that response time can be important, there should be clear policies on the medium used for it. If the team mostly had policies that match my preferences, I could do remote work. But I suspect most teams will disagree with them. Hence I get my way in the office.

Taking 2 hours for a response is often fine at the office, BTW. It all depends on the context.

>Immediate responses is a remote team. Day long responses is contract work. Week long responses is open source projects and government work.

There are very few jobs that really fit this categorization. At my work (in the office), we often respond to things the same day. On the flip side, today I plan to respond to something that had been requested a week ago. I don't work in OS or for the government.

If someone wants a quick response, they have to explain the need for it in the email. If it's open ended, it goes to the bottom of the queue. I'm willing to bet that since they haven't bugged me about it, they either no longer need the information, or it is low priority for them.

> If someone slacks you, the response should be as quick as if it were verbal in the office.

It's droll that Slack is the name of the service chaining you to notifications. I wonder if that was deliberate.

I would not consider working for a company that required a 2 minute slack response time, especially for a role that required uninterrupted focus. Different story if you are in a "put out fires" role

Is it more important to actually get stuff done or to be available for every distracting slack message that comes through?

If you need people to respond within 2 minutes to every message, that is lack of organization imo unless it is an emergency.

Good remote teams are very organized, prioritize documentation, have weekly and sometimes daily kick off meetings and then for the most part get out of the way for their team to get stuff done.