Hacker News Reader

Comment by axg11 | Hacker News Reader

I've never met a manager that has expectations for email replies on weekends or frankly <24hr replies during the working week. At all the places I've worked (startups and FAANG), emails are treated as a slow communication medium.

I think chat/Slack should be a bigger focus as it's a greater source of anxiety. The issue with messaging is that it's a mixed stream of both sync and async.

Sync: "Hey - can we have a quick chat?" - requires ~immediate response

Async: "When you get a chance can you update XYZ, not urgent" - doesn't require a response

Distinguishing messages as urgent vs. non-urgent (no notification) _could_ alleviate some of this issue, but it's ultimately a culture issue, not a tech issue. Half of the people I've worked with won't even use threads in Slack. Good luck getting people to use different message levels.

View on HN

> Distinguishing messages as urgent vs. non-urgent (no notification) _could_ alleviate some of this issue, but it's ultimately a culture issue, not a tech issue.

I think drawing a hard distinction between culture issues and tech issues is a mistake. Tech influences culture and vice-versa.

The fact that Slack saves the full message history is great for being able to refer back to previous discussions, but the fact that the history view of every joined channel is the default interface encourages this sort of asynchronous messaging.

IRC was closer to synchronous in that you could leave channels but retain permission to rejoin them. So you ended up with a sort of split in the culture because it supported two different usage patterns; some people would use a bouncer and idle in every channel (this is basically Slack), while some people would connect and join only the channels they wanted to be in at the time (unsupported by Slack). And of course there are levels in between those two.

MUDs could be considered the option that’s fully at the latter end of that spectrum. You may go AFK and idle, but you’re only ever idling in one room, and it’s often made clear if you’re AFK or not in the interface. The result is that for synchronous chat, there’s one single place to pay attention to: the room that you’re in. (Whispers are supported but they typically show up in-line as a message.) For asynchronous chat, there’s a separate mail system (which often forwards messages to your email address as well). The two are distinct in the UI.

I think MUDs got the sync/async distinction right in a way that modern chat apps don’t.

The distinguished idea is used fairly regularly, however unless executed extremely well, it doesn't take long to have it get out of hand.

A perfect example of this was back in the mid-00's in the US military. Often we would get emails with the subject:

HOT [Subject]

Which over the years turned into something like:

*HOT*TIME SENSITIVE** [Subject]

I can't even imagine what it's evolved into now.

  $*.final.02.FINAL.docx

vibes for sure.

What sucks is when "quick chat" is a 2 hour meeting about how to do something that's impossible.

Followed by "can you send me an email summarizing this meeting?" because they've taken none of it onboard, and took zero notes, nor recorded anything.

I've had such a manager. Her policy was that, during working hours, all staff should reply to managers' emails within an hour, if for no other reason than to acknowledge receipt and promise a lengthier response later. Staff would respond to external emails or colleagues' emails by the close of play; as with managers, it was acceptable to reply briefly to acknowledge receipt and return a real answer the next day. Managers, for their part, responded to the rest of staff within an hour as well. She was firm, but this worked out very well for all of us, and I continue following her policy in my new job elsewhere. My new boss loves me for it, because he knows I've at least read whatever he's requested.

So that means you need to check your emails every 20-40 mins, sort through everything and write replies when required? Sounds like a terrible way to do any sort of focused work.

Using an email client with notification support circumferes this issue.

Even better - get interrupted constantly and do zero concentrated work day to day

> I've never met a manager that has expectations for email replies on weekends or frankly <24hr replies during the working week.

You have clearly never worked at Amazon.com. That has been my experience: there for 6 years, AWS, 2008-2014. I've met SEVERAL, not just managers, but colleagues, who had these expectations. Mind you, this is a pre-Slack era. Not sure if today things are different because of corporate chatrooms.

> Async: "When you get a chance can you update XYZ, not urgent" - doesn't require a response

For common tasks this should be in a system then. Otherwise this is essentially the major pitfall of chat. IMHO anyone using Slack for async is doing it wrong.

I personally almost always use an important/unimportant and urgent/not urgent entry in my communications. Helps alleviate quite a bit of stress, IME.

In my simple understanding, Synchronous and Asynchronous messaging comes down the sequencing of sender and receiver messages, it is not a matter of timing, right?

Reply on news.ycombinator.com