[HN Gopher] Email Is Async
___________________________________________________________________
Email Is Async
Author : mooreds
Score : 102 points
Date : 2022-08-15 11:41 UTC (11 hours ago)
(HTM) web link (www.patkua.com)
(TXT) w3m dump (www.patkua.com)
| axg11 wrote:
| 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.
| ryukafalz wrote:
| > 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.
| dheera wrote:
| What sucks is when "quick chat" is a 2 hour meeting about how
| to do something that's impossible.
| hammyhavoc wrote:
| 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.
| Telemakhos wrote:
| 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.
| AndrewKemendo wrote:
| 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.
| DiggyJohnson wrote:
| $*.final.02.FINAL.docx
|
| vibes for sure.
| yitchelle wrote:
| 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?
| mbesto wrote:
| > 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.
| VLM wrote:
| 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.
| Jensson wrote:
| 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.
| Alex3917 wrote:
| 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.)
| twobitshifter wrote:
| 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.
| VLM wrote:
| Its not just employee vs employer but at large enough
| corporations most effort is spent on infighting between
| departments.
| Wohlf wrote:
| Employers don't need CYA as much, they can afford lawyers and
| write the internal policies.
| ajross wrote:
| > 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.
| pkulak wrote:
| That sounds perfectly async to me.
| sorokod wrote:
| 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.
| [deleted]
| skrebbel wrote:
| Apparently CYA is short for "Cover Your Ass".
| horsawlarway wrote:
| 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.
| k0k0r0 wrote:
| 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.
| devmunchies wrote:
| > 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
| woodruffw wrote:
| 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...
| mytailorisrich wrote:
| I belive that emails can be used in court without any
| specific setup within most EU jurisdictions or EU overall.
| belfalas wrote:
| Willie Brown, once the mayor of San Francisco, had this to say
| about e-mail: the 'e' is for "evidence."
| v1l wrote:
| 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.
| lolsal wrote:
| > 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.
| lisper wrote:
| 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.
| ptero wrote:
| 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.
| fleddr wrote:
| 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 :)
| steveBK123 wrote:
| 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.
| mxuribe wrote:
| Hi @steveBK123 , would you kindly define briefly what the
| "BLUF form of email" is? I don't think I have ever heard of
| that.
| teddyh wrote:
| https://en.wikipedia.org/wiki/BLUF_(communication)
| steveBK123 wrote:
| 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.
| fleddr wrote:
| 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.
| steveBK123 wrote:
| 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.
| D13Fd wrote:
| 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
| mjevans wrote:
| 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
| em-bee wrote:
| 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.
| sharmin123 wrote:
| turnsout wrote:
| 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.
| kubatyszko wrote:
| Oh joy of large corporations where a coworker would walk up 3
| seconds after sending an email asking "have you seen my email?"
| wildrhythms wrote:
| 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.
| hammyhavoc wrote:
| Just seems like a puff-piece for their Time Management course.
| Few on-brand graphics, Captain Obvious statements, and of course
| a CTA.
| kurupt213 wrote:
| I think this applies to regular staff as well, not just leaders.
| Email is not a conversation tool
| silksowed wrote:
| 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
| deknos wrote:
| 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!
| marcosdumay wrote:
| > 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.
| deknos wrote:
| 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.
| p4bl0 wrote:
| Who on earth could rationally expect emails to be synchronous
| communication?
| steveBK123 wrote:
| 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.
| tluyben2 wrote:
| 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.
| jerrre wrote:
| 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.
| subbz wrote:
| 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".
| lcnPylGDnU4H9OF wrote:
| 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.
| ghaff wrote:
| 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.
| Double_a_92 wrote:
| 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.
| uberchet wrote:
| 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.
| ralphael wrote:
| Its called "Instant Messaging" :-) So I think the expectation
| is built into the name, even if you don't agree.
| evandale wrote:
| I would have to disagree. To me "Instant Messaging" !=
| "Instant Answering". It's only a guarantee that the message
| is delivered instantly.
| ninju wrote:
| And unfortunately there is an implicit expectation that
| the reply is to be sent immediately as well.
| nottorp wrote:
| Start with disabling auto away :)
| ghaff wrote:
| 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.
| em-bee wrote:
| 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.
| 71bw wrote:
| 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...
| Gigachad wrote:
| 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.
| fleddr wrote:
| A bullet dodged, I guess. But yes, norms are changing, not
| for the better.
| insightcheck wrote:
| 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.
| fleddr wrote:
| 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.
| hammyhavoc wrote:
| Ah yes, the inevitable "???" after 30 seconds. Fuck my life.
| kyrra wrote:
| "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.
| xbar wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-15 23:02 UTC)