Mail is async by nature. Read them 2-3 times a day only (you don’t check mailbox 100 times a day :) and you get things done…

I prefer to reply to an e-mail immediately. Or never. If so than archive it or delete it.

If you don’t answer immediately, you carry it as opened mind window and probability to have your mind being unable to concentrate increases over time.

Long ago, I heard this advice on some ancient management tape: "never let a piece of paper cross your desk twice". It stuck with me and I've got into the habit of immediately answering, archiving or on occasion setting a snooze timer (in GMail). If the recipient takes my promptness for granted, then I might adjust my policies for just that person. (Un)fortunately, it helps to be a manager -- then you can give feedback to people who don't read emails properly.

>This is true 100% I would even say: "Never reply on anything instantly that is not an absolute emergency, ever"

you can shorten this to "never reply instantly", because an "absolute emergency" will never be communicated by email.

I take that a step further, "absolute emergency" is rarely an "emergency".

Based on my experience, it mostly translates to whatever task the person thinks it's important for them. Sometimes people will mark the task as "urgent" just to dump it on someone else.

The other thing is, in critical emergencies, you should work slower than usual. This means muting all notifications and taking your time. Rushing to get things done can exacerbate the issue.

Best engineering managers shield the team in those situation and simply reply with: "thanks, we've been notified and investigating".

What is the problem with replying instantly? If you can give a reply immediately why wouldn’t you? If it’s low priority work that takes time, sure, but a typical yes/no, I’m available at 5, whatever, why not just send it?

If you’ve already read the email it’s less efficient to come back to it later

i'm not a strict adherent to the rule, your question would be better aimed at jillesvangurp or mhaberl.

mainly i just wanted to stress that nothing in an email inbox is an "absolute emergency".

it encourages back and forth.

it trains people to expect things.

boundaries.

Also, email delivery in general can be delayed for hours. It’s not common, but there are no delivery guarantees around email. You could reply immediately, and it could arrive in their inbox much later.

This doesn’t happen enough to me that I consider it.

I once built an IdP that vended access one time codes via email. We had to switch to other means because there were a small (but significantly high) fraction of customers who didn’t receive their OTPs before they expired (TTL was 15 minutes). Also even if they came in before the TTL, a user experience that involved waiting that long to get logged in was not tenable.

When someones only contact with you is email, then that's how you'll get news of the emergency.

i can't think of a situation where both the following are true:

1) someone having an emergency needs to contact me specifically.

2) that someone only has my email, and no other possible way of contacting me (or someone else that can contact me).

> Then I guess you didn't deal with much of the empty-headed-managment type much.

I worked in a big multinational at the time ;-). So, yes. Mostly my direct managers were alright. Some were excellent even. But organizational politics and learning to read between the lines is part of working inside of big organizations.

> You get a short reply that is a reply on a 1 sentence you wrote, twisted upside down ignoring completly the point that you had.

Usually a clear sign that you are not communicating effectively. If it's important to you, you might want to figure out how to fix it. Talking is usually a good way.

> Usually a clear sign that you are not communicating effectively

Agreed. I learned that in emails, a multi-paragraph, multi-item text means the recipient will randomly reply to only one of the points (often the least important one). So an effective email will make a single point, in as brief a manner as possible.

This defines "communicating effectively" in a way that it can't possibly cover a complex topic. Sometimes you need to communicate complex topics, so this definition is a failure. The problem remains that people refuse to do the reading required for their job.

> This defines "communicating effectively" in a way that it can't possibly cover a complex topic [...] so this definition is a failure.

Indeed, I don't think email can be reliably used to convey complex topics.

> The problem remains that people refuse to do the reading required for their job.

Communicating effectively means accepting common flaws of people who are unlikely to change, and delivering your message in the most effective way. Whether people are right or wrong or should be fired (as another comment says) is not truly relevant.

I often fail, by the way. I'm not saying I have this all figured out.

I don't think these people read the official documents either, though.

Adjusting communication to the audience is a good guiding principle, but not an absolute. There comes a point where no attempt at communication works for a given audience. If the communication must happen nevertheless, then the audience must change, whether through training or replacement.

I wish this were simply a fireable offense and we were expected to read. These kind of people who act like reading 3 paragraphs is being asked to swallow glass make me blindingly mad. They should be unemployed.

I’m usually very tolerant of others’ varying capacities, but 100% this. High-school level reading and comprehension shouldn’t be a hard ask for professionals.

Sending a wall of text in an email is, IME, ~never^1 the right thing to do. If more than a fraction of colleagues fall into that bad habit, soon all anyone will be doing is email. Let alone if you try to respond to one of the too many points in an overlong message, or loop someone else into the conversation(s) which are now hopelessly fragmented. It's akin to a self-inflicted DoS attack.

1. Exceptions do exist (eg if the message is intended solely for and addressed to a single recipient, and includes a disclaimer / request / reminder about general email hygiene), but they're vanishingly rare.

If it's an emergency, you should call 911, or your country's equivalent. If that is not appropriate, then it's not an emergency.

> Hello 911, our auth service is down following a malformed config deployment.

"Emergency" is not the same as "emergency services".

You're making my point exactly. Auth service being down is not an emergency.

as i've gotten older, i've realized that an auth service being down does not fit my definition of emergency.

which is the point the parent commenter was making, if im not mistaken.

Hard disagree back. Email has multiple contexts when I would say that short form is ideal and should be the default but at times a thoroughly long form email is needed. Or, honestly, you just need to create a document at this point. It could be a slide deck or word/markdown/excel/etc (depends on context) and this should be in the email. But email is key.

My experience is that people search subject lines, conversations, dates, and generally traverse historical conversations much better in email than in chat or a fully external application. They won’t search Slack, or try but can’t find the conversation. They won’t remember it’s on a wiki, you’ll constantly be redirecting them to the url. If the file is attached to an email, sometimes they’ll resurface it from a year+ ago. I find that’s way more common than someone referring to a chat from even a month ago. Chats are semi ephemeral. I’ve used both Teams and Slack and feel neither has really changed the game in terms of how the entire user base of an org use the system, enabling the historical reference points and moving it out of a ephemeral state, so email remains a stalwart for archival purposes and helps provide maximum context after the fact (people tend to elaborate on their choices more when writing an email).

I’ve found that a two-prong approach works best.

Detail in the email, expect people to read it or fail. And include a reference to a wiki or some more detailed version that can be collaborated on and extended.

So the email isn’t the primary source, the wiki is (really some markdown in git). But the email is the thing that people organize and find over time.

This probably differs a bit by your exact profession and circumstances. I could see devs and technical people (most of HN readers) to prefer and have success with this when operating with like minded peers. It doesn’t scale much outside that. If you work with people outside of tech/dev minded people, those who are not used to RTFM type info seeking, it’s going to be an uphill battle.

I think you may be right. Fortunately, I work with like 10k collaborators who are all science/tech oriented and it works quite well.

I wouldn’t want to work in an org where people can’t read email and want to talk to everyone instead.

I'm envious, although I think my experience is the rule and your's more of an exception. It might be more common on HN given the demo, but IRL, people mostly want to talk. Or even if they read email, they can't be bothered to search for things themselves. Makes me think of another long standing habit I have, I just ignore people. If they ask me something that has been answered and I know it's in an email somewhere, I ignore the question. If it's something they really need, they will go find it. Obviously this is very YMMV and I was able to start doing this after I reached a higher position/role, I've been a CFO for some time now and I still have certain people and audiences I will promptly answer any question even if I know it's been answered/documented.

>anything longer belongs somewhere better than email (Slack, wiki / knowledgebase, docs site)

wiki/kb or docs site, sure, depending what the topic is. but... slack? for your long-form communications?

please email me your long stuff, don't slack it to me. email is perfectly fine for longer text when longer text is required. (opinion also shaped over a long time in various roles at companies of various size)

Oddly, I find the search in Slack, Teams, and Discord to be so horrible I don’t create any “knowledge there.” It’s like trying to write a paper on the telephone.

Anyone putting long form stuff into an IM system is taking the way of pain.

(Replying to parent and GP)

I wasn't suggesting an IM system should be the source of truth for long-form documentation. But searching Slack works better than searching email you weren't cc'd on. Virtually anything is better than email for many essential aspects of collaboration.

Want to add someone to the mailing list and loop them in? How many prior emails will you forward to them?

Someone replies to one of several points in an email, someone else wants to address a different point, and there are a mix of habits and patterns for whether / how much / where to quote or include the previous messages in a response....

vs adding someone to a channel where they can review the conversation history, and some combination of threads and links to additional channels or external resources can adequately support whatever direction(s) the conversation takes.

In any case, it's the wrong tool for the job in so many ways, so much of the time. Hence my recommendation to keep emails to 5 sentences, and to prefer communication tools that properly support multiuser collaboration.

we have polar opposite opinions on email and slack/teams/discord! im not sure i am even understanding the issues you brought up about email correctly.

may i ask what age bracket or generation you are? only if you're comfortable sharing, of course.

im in my 60s. and im curious if our difference of opinion here is a product of what technologies were/are available during the start & prime of our careers. i very well might be in stubborn old man mode subconciously.

Thanks for considering possible reasons for disagreement. I'd like to understand it, too. FWIW, I'm about to turn 52. Been working in tech since the late 1990s. Remote more than not. Email is great for certain specific things. But for multiuser async collaboration in the workplace, surely you've encountered problems like I have, no? Email conversations -- especially if they're long and/or include a lengthy recipient list -- are inherently prone to critical failure, completely decohering as _both_ the recipient list(s) _and_ the topic(s) under discussion can fragment from the very first of N replies, making it impossible to resolve anything conclusively or to know what's been communicated to whom.

I use a git-generated static site that has good search, so if people want to find stuff before asking that’s the go-to.

Otherwise, I can search email quite effectively. And oddly, its one of the few things Office Copilot is goos at.

I don’t email is a collaboration tool. It’s an information sharing tool and maybe workflow. Just today I had to email out to like 20 people a data call with a couple paragraphs of instruction. It’s much better than Slack for this. And I can search and find my email and their responses for all of eternity (I’ve got every email going back 20+ years instantly searchable in outlook, good luck finding a slack message from a month ago much less a decade).

> "I don’t email is a collaboration tool"

That's almost the entirety of my point. Sure, email works well for simple, unidirectional / broadcast comms. But for async collaboration involving multiple recipients and any kind of back and forth, it's inherently problematic.

So far, searching email has been more effective than searching anything else (Wiki, Slack, etc).

How do you search emails you weren't cc'd on?

If it has to be information stored in depth, then sure a KB/wiki is better.

IME, the majority of long emails should not be persisted in such places, because they contain a fair amount of errors. One could say that any long email thread should be eventually synthesized in the KB/wiki after the conversation has wound down.

And Slack/Teams? No way. If I need to write something long in response to a Slack IM, and email is verboten, then I'll insist on setting up a meeting.

I think we're on roughly the same page. Long emails are problematic. Realtime meetings or (possibly but not necessarily near-realtime) chats in a dedicated channel can and do solve email's problems.