Email Is Async | Hacker News Reader

Email Is Async

patkua.com

117 pointsmooreds82 comments

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.

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?

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.

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

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

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.

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

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

Email is generally a better async tool than slack/messaging because it has a generally longer response time expectation.

Further when composing an email you have a big open canvas, and an implied workflow of writing, editing, and then finishing before you hit send.

The workflow in slack tends to be ad-hoc, stream-of-thought, off the top of head burst-of-questions. As a recipient this can be incredibly disruptive. As an introvert it often strikes me that even the sender doesn't quite know what they are getting at until midway through.

Obviously email can be used just as poorly, but the built-in workflow bias of the two makes this anti-pattern the default on messaging platforms.

Further on the recipient end, it his harder to setup rules to triage important senders/content away from the noise in slack than it is in email.

Lastly, slack especially gives the sender too many tools to disrupt & cause mayhem. You really only need 1 malicious user in your slack org to make it extremely noisy.

On the email side, someone who is trying to get attention generally sends 1 email with "everyone & their mother" cc'd. On slack, they instead tend to drop into multiple different channels & DMs to try and get attention. Each of these messages to different channels/DMs may set off different threads of noise on the recipient side as people are unaware of other channels/DM recipients trying to address the question. Plus the ability to force more attention with @user/@here/@channel, and force notifications through even if recipient has them paused.

Technical users will have no problem, but for non-technical users email it is easier to do permanent record keeping and documented CYA. Non-technical users puzzle over how to document a text message in writing or how to permanently store and document a slack/irc type chat. Screenshots that are printed out on paper and scanned into a .pdf? I've seen things like that.

For a lot of situations the benefit of electronic communications is CYA and permanent record keeping, not speed or ability to notify 24/7 around the world.

"As you can see by the forwarded email chain below, I emailed ops about the backup process being broken a month ago, then reminded them two weeks later, then escalated the ticket after a month, and still have not heard anything back, as you know SOX compliance requires that we actually keep that data, so given the complete lack of communication over the last month, I'm curious if you know of an ETA to repair the backup process or if we should implement a local non-IT supported solution for backups of SOX compliance data, and if so how would that local process interoperate with existing documented security policies such as PCI-DSS and related requirements?" At least if it comes to a court case I won't be the one blamed, LOL. This is how business gets done at large companies, if someone can't get blamed individually, it ain't getting done.

There's some painful truth in this comment.

Not to mention - email is very easy to branch in order to more safely secure that record. If IT owns the email server, and IT is fucking up... very easy to BCC/Forward a copy of the whole chain to my personal email for my own records.

I don't know much about that Email and legal stuff, but here in Germany I pay a couple of Euros every month to a well-known and respected company whose server is set up in such a way that my emails can be used in court without any issue (like claims that I altered the emails after receiving them). At least they claim that and I do believe them. I do not (yet) have a business, but I use it nevertheless. Just in case.

> but here in Germany I pay a couple of Euros every month to a well-known and respected company whose server is set up in such a way that my emails can be used in court without any issue (like claims that I altered the emails after receiving them)

That's already cryptographically built into email with DKIM. An email message is signed with a private key, and can be verified as authentic by the receiver using the public key in the sender's DNS records.

Click on "Show Original" in a Gmail mail to see the meta data.

https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

While this is technically true, it's not a correct use of DKIM: DKIM is meant to provide authenticity for the receiving mail server (by verifying the message against a key associated with the sending server), not nonrepudiation for the sending user.

Many email providers historically used short keys (RSA <512, and later 1024) for DKIM, meaning that lots of emails circa 2012 and older appear to be nonrepudiable but in fact are.

Long-term authenticity of emails is very difficult and is arguably an anti-feature; Matt Green correctly observes[1] that Google should be rotating and publishing its DKIM keys regularly to prevent people from falsely concluding that a DKIM signature is "proof" of a message's authenticity.

[1]: https://blog.cryptographyengineering.com/2020/11/16/ok-googl...

I belive that emails can be used in court without any specific setup within most EU jurisdictions or EU overall.

Google started deleting old emails, big companies seems to see record keeping as a liability so it is important for them to control this infrastructure so that no inconvenient messages remains in the system when the inevitable lawsuits comes.

Most big companies started retaining email indefinitely after the Monica Lewinsky scandal, and then started automatically deleting it after the Sony hack. I would expect the balance of whether to retain or delete email to continue to change every decade or so based on what's the least cheapest given the current security threat landscape and legal situation. (The exception being financial firms and other companies in highly regulated industries, which are still required to retain all communication.)

It sounds you see it as more CYA for employees than employers? That’s probably true. The companies I’ve worked at have deleted old emails rather than keep a record of all conversations, so that material doesn’t show up lawsuits. When someone leaves the company, all their emails are deleted.

Employers don't need CYA as much, they can afford lawyers and write the internal policies.

Its not just employee vs employer but at large enough corporations most effort is spent on infighting between departments.

That sounds perfectly async to me.

Apparently CYA is short for "Cover Your Ass".

> For a lot of situations the benefit of electronic communications is CYA and permanent record keeping

Note that in a lot of industries, "permanent record keeping" is a regulatory requirement, it's not just politics. The culture of general employee communications being ejectable ephemera is somewhat unique to the US tech industry.

I find it helpful to think of my emails as documentation. Imagining myself figuring something out months or even years later changes the way I write.

Willie Brown, once the mayor of San Francisco, had this to say about e-mail: the 'e' is for "evidence."

What I've done for this sort of thing is use email for an evidence trail (and searching), but ping people via chat if it is something that needs to be looked at soon.

So is text chat. Shame most people have such low attention span they actually get angry when you don’t answer within seconds, let alone longer. I have been trying to get people to accept email and chat as async for decades and for some it is natural, others throw absolute fits.

Looking at people my age it is only gonna get worse, considering how even relationships work now. Hundred years ago you would be happy to recieve a written letter every month or so, nowadays not responding to your partner within seconds could be treated as a valid reason for breaking up...

A bullet dodged, I guess. But yes, norms are changing, not for the better.

Yeah, the vast majority of people would see it as erratic to break up with someone for not responding to a text within a few seconds. It's not culture or technology that's the issue, but the personality of the anxious person who ask to break up over just that.

I think it's both the individual personality as well as growing up in an online world. I'm not an expert but I'm thinking it has the power to actively rewire a person's brain. If in your entire lifespan so far you do not know any better than for everything to be available always and instantly, that creates an entirely different creature.

But you would primarily live with the person or within walking distance. Hundreds of years ago if you ignored your partner for the whole day while living with them that would probably be grounds to break up as well.

I don't have experience with anyone actually throwing a fit for not insta-replying. But one factor is that for some people not-insta-replying == never replying.

Email and text as async communication only works if both parties actually have the processes in place to reply async.

It's a question of the topic. Some topics need to be handled synchronously. And if you don't answer in a conversation this is legitimately perceived as "rude".

If the topic of this conversation is whether or not IM should be considered synchronous, then this argument doesn't hold up. If I take one side and suppose that IM should not be synchronous, then obviously the mistake in your case is on the individual that tried to use it for a topic that needed to be synchronous. The not-responding person is not wrong in that case since they're ostensibly using the method of communication as intended.

Part of it is that, in many cases, we've normed not calling people on the phone out of the blue. And, while some may disagree, we often do need some reasonably real-time communication channel. Someone may not see a message instantly but it is reasonable to have some mechanism in a business setting to generally reach people quickly--if for example, there're supposed to be someplace.

I dunno.

I think it's a continuum, for one thing.

Phone calls are clearly sync. But IM on the desktop is, in my working life, much closer to sync than email.

I think of phone texts as attempts at unobtrusive but still mostly synchronous communication.

Yeah. A lot of it is convention of course. But where I work, Google Chat for individuals and small groups has sort of developed in general into a higher priority interrupt than email. e.g. are you joining this scheduled call?

On the other hand, the group chat for a broader team I'm in is more likely to be used for idle non-work-related chit chat.

And phone calls basically aren't used at all outside of scheduled meetings.

Its called "Instant Messaging" :-) So I think the expectation is built into the name, even if you don't agree.

I would have to disagree. To me "Instant Messaging" != "Instant Answering". It's only a guarantee that the message is delivered instantly.

And unfortunately there is an implicit expectation that the reply is to be sent immediately as well.

Start with disabling auto away :)

Because it is supposed to be faster than email. In my opinion it should almost be equivalent of asking someone in real life if they got time to talk.

Supposed to be. Email these days is also instant and I have indeed people calling right after sending emailing to ask if I got it. I never did or will use outlook , but I know many people in business settings who use the slowness of it (‘stuck in outbox’ etc) to force it to be more async. With gmail or others you don’t have any excuses; it’s as fast as chat.

If people who send a chat message are all asking me ‘if I have time to talk’, life is over if I say yes; it is always no aka async. And for most people I work with and definitely friends, that works well, just strangers usually have to be educated a bit and some never learn (and are just ignored generally).

when the first instant messengers came out (ICQ and i don't remember what else) i was arguing that they could have used SMTP as a protocol, and people got on my case that email and chat would be fundamentally different and should not be mixed.

today i am happly using deltachat, which effectively proves my point.

the primary difference between email and chat is threading. and even that can be handled.

Ah yes, the inevitable "???" after 30 seconds. Fuck my life.

It is unfortunate that the communications mode has been bound by convention to the medium. It should be bound to the message. The urgency of a message should be metadata associated with the message content regardless of the medium through with the message is transmitted and the client used to view it. How and when the content is delivered to a user should be a function of this urgency annotation and the trustworthiness of the sender. Someone who cold-calls you with an urgent communication is almost certainly a spammer.

Of course, this will never happen, but a boy can dream.

Treating email or slack or any other not explicitly sync channel as sync is often a self-inflicted wound. I think management is sometimes guilty of pushing this, but it is usually an employee who runs with some self-imposed requirement of "I must be checking email on weekends" or some such and drives himself into a "sync hell". And entrenches the misconception.

Good management has no desire to burn out their employees for some nervous and useless message checks instead of a good rest. My 2c.

I have two rules for email: normal response time is “within 24hrs” and response rate is not 100%.

I’m sure some people out there just think I’m a flake because I don’t get back to them, or don’t respond quickly enough. That’s the downside.

The upside is that my life is not controlled by email notifications. Life is short.

I disagree with lumping chat in with e-mail. The whole reason for chat is that it's closer to being synchronous.

On the spectrum:

Very asynchronous: Letter, E-mail

In between: Slack/Teams Chat, Text messages

Very synchronous: Call/video call, In-person meeting

Did forums vanish from cognition? Though I guess newsgroups also died out from common perception or get lumped with similar tech (email).

Fully asynchronous: letter, email, newsgroups

In between: forums (you're reading one now), IRC, Slack/Teams Chat, any other sort of text-chat server, (SMS/RCS/iChat) text messages

Real Time: voice / video call, conference, in-person meeting

forums are really just a webinterface for something that works like email. email. newsgroups and forums are different interfaces for the same thing.

hackernews is definitely asynchronous, because i don't even know if i get any replies unless i search for them which i don't do all the time.

Who on earth could rationally expect emails to be synchronous communication?

I just wish, people would work on open email features and fix things...

email can still be fixed, at least for semi-open systems. but noooo instead we build a myriad of other things.

Things to be fixed/extended:

* MIME * Support for SMIME/OpenPG Encryption with IMAP (like, when emails come into a imap inbox they are encrypted with a certain public key and signed with another, or when a email has to be saved, there's a standard, that emails can be saved encrypted in the inbox) * quite a few sieve extensions for more filtering/action possibilities * Publishing of Mailservers from whom they will/won't accept emails (or attachments) * better support of markdownn (markup/mime) type in emailreaders, there's even an rfc for it!

> email can still be fixed

I doubt this. Email is run by people that want it dead.

It would be better if we replace it.

Email is run by a lot more people than those who want it dead.

also: they may want it dead, but still they use it for verification... so.. even they cannot kill the infrastructure apparently.

Good luck getting anything to change without their approval.

"focus time" calendar entry works pretty well. I set that along with marking my chat status as being in focus, and then will close Gmail/chat.

While I don't do everything in this article, I definitely do many of them. Trying to treat chat and email as synchronous drove me a bit crazy, so I did these things a while ago.

Nice to see these ideas all written down in once place.

Pretty good guidance, could be extended with a step 8 and 9.

Step 8: emails that shouldn't be emails. For example, asking for a status update, whilst you have a status management system already in place. Complicated cross-department discussions being handled over email. And so on.

Step 9: optimizing the content of emails. Making sure they are relevant and actionable, indicate priority, give suitable context.

Personally, I find meeting optimization way more important though. Meetings destroy productivity. Even if you're a non-leader and have 3 or so meetings in a day, you have very little uninterrupted time, and the time blocks in between you'll probably spent on emails and chat or recovering from the meeting.

I find it puzzling how lax corporate management is in allowing every employee's calendar to fill up with meetings. Or maybe it's not that puzzling as they're often the source of the problem :)

People need to learn the BLUF form of email.

Further - management, who demands KPIs/dashboards/etc, should learn to actually use them rather than pinging people for status.

The other death loop I've gotten in with new(er) managers is that they want "a weekly status report" and are very (VERY) fussy about the content, however they 1) never show you an example "good" one (assuming they must send one to their manager.. or not?) and 2) just iterate painfully over months&months where the only feedback is re: more tweaks to the format of the report (mostly in the negative form of dislike, rather than pointing in the direction of what they want)

Usually this incentivizes me to send fewer and terser status reports & focus on delivery. If no report format is ever good enough.. why waste time on it vs just getting tasks done that will make users happy... which is ultimately what drives compensation in the mid/long term.

Hi @steveBK123 , would you kindly define briefly what the "BLUF form of email" is? I don't think I have ever heard of that.

https://en.wikipedia.org/wiki/BLUF_(communication)

Ah, thanks!

https://en.wikipedia.org/wiki/BLUF_(communication)

Bottom Line Up Front Lead with the summary (conclusions/recommendations, decision) OR statement in a single sentence what action are asking the recipient

Then you can follow with supporting details at increasing levels of granularity

It inverts the usual structure because most people feel compelled to give background, discuss options, offer costs-benefits, go into detail, etc .. all before coming to a conclusion/request about 75% down the email.

Ah ok, I'm familiar with this approach. But never knew it had an actual name. Thanks!

When you think about this more deeply, a well working status system is an existential threat to several layers of management.

If all you do is collect metrics and reports to aggregate them upwards, the value added is minimal.

Maybe there remains some value in exception management (risks, roadblocks)? Barely so in my experience. Because managers in tech have no clue what they're managing. So this is again just a report which next the team should resolve on their own.

Yes, but to be fair to managers in tech - no one else around them knows what they are doing either. Tech managers tend to have to wear too many hats filling in gaps in the product/project/program management layers and do some random assortment of people management & technical leadership.. depending on which firm/team and day of week.

For non-tech companies, you'll often see a lot of non-technical stuff happening in the technical management hierarchy.

At a high level all they care about is process, and at a low level all they care about is if a stakeholder is screaming right now. Nowhere in between do they care about what is actually being delivered.

And by process I mean things like firm-wide cookie cutter agile mandates, all-hands calls, OGSM, OKR, etc.

The last two shops I worked, the CTO spent a lots of time talking to investors about Cybersecurity/Resiliency/Cloud strategies, which are more attributes of a well engineered system, rather than a deliverable product.

You wouldn't believe how many annual/quarterly CTO hosted events I've attended where either a Navy SEAL or Astronaut was the keynote speaker, lol.

Sometimes it feels like people talk about this sync/async issue in a vacuum. But often there is a real need to get a response from the recipient in a timely manner. You can't just sit around twiddling your thumbs waiting for a response hours later because until then you might be blocked.

It isn't just the big things that could block you. A small piece of feedback, an opinion on a design decision, a review of your approach etc all require relatively quick and synchronous responses or you end up in multi-hour or multi-day long chain of async discussions. Business can't move at that speed.

> It isn't just the big things that could block you. A small piece of feedback, an opinion on a design decision, a review of your approach etc all require relatively quick and synchronous responses or you end up in multi-hour or multi-day long chain of async discussions. Business can't move at that speed.

In my experience, the folks that ask for immediate feedback on those kinds of things are the kinds of folks that don't understand they are often not small or relatively quick things. Often they aren't accounting for the cognitive cost of context switching.

Title on HN, "Email is Async" and the authors first header states the opposite. ... ask yourself, what's the author selling and move along.

Oh joy of large corporations where a coworker would walk up 3 seconds after sending an email asking "have you seen my email?"

Another facet of large corporations is people cluttering up every single email with pointless email signatures. I always wonder how much collective bandwidth, storage space, electricity has/is being wasted by sending these annoying, useless blocks of text back and forth.

Just seems like a puff-piece for their Time Management course. Few on-brand graphics, Captain Obvious statements, and of course a CTA.

e in email stands for evidence, learned that the hard way. i think email can be async if its culturally treated that way. unfortunately too many people use it as a bad way to document things. i think the wiki part of the equation needs to be expanded upon, then email can even further become async

I think this applies to regular staff as well, not just leaders. Email is not a conversation tool

0. Email is a method for putting work onto others, or for receiving work from others. Limit the amount of work you consume from email to the minimum amount necessitated by your manager.

Corollary: If your manager necessitates that you consume unbounded work from email, or that you consume work from unbounded sources outside of your manager, you have an ineffective manager.

Reply on news.ycombinator.com