For non-trivial coordination, meetings might be better than email

As a freelancer, I maintain an "email-only" policy for new clients. It says so very clearly on the contact form: I don't do phone consultations for new clients.

Even so, every once in a while I get people who use the contact form and demand that I call them back. I politely respond, obviously by email, that I don't do phone consultations for new clients. I rarely hear back from them. Good riddance; I've learned from experience that people who demand synchronous communication from the start tend to be the worst clients. They always want other people to cater to their needs right now, like an obnoxious boss. People who are comfortable with email, on the other hand, are at least a little accustomed to waiting a few minutes for a reply.

Email is one of the few communication technologies we use these days that wasn’t a mistake.

The article mentions Scrum, and its synchronous daily meetings. It fails to mention that Scrum is also largely supported by asynchronous communication, like code commits, review requests, reviews and documentation.

The effect in my experience is that the purpose of the Scrum meeting is to offer a birds eye view of the asynchronous systems that make up the bulk of the development process, to enable participation and further comment. "The idea that a quarter of an hour of structured synchrony is enough time to enable a full day of work might sound preposterous" because it is. It's just there to kickstart the day and to give everyone a general idea of what's going on.

For anyone doubting this, I suggest skipping a scrum meeting to see how much it actually impedes your work. Then, if you dare, try to avoid using the asynchronous communication that supports the development process for a day. Compare the results.

Overall I just think that people should consider more carefully whether a topic is more suited for email, phone call or a meeting.

Unlike machines that can always respond to a request for synchronous communication, people are often having meetings, doing other work that cannot be interrupted, or in different time zones. All of which necessitates asynchronous communication -- even if the delay is only a few minutes at a time. You can't just take research about distributed computer systems and apply the conclusion to humans.

I'd say e-mail was not. The features that gave it a bad rap are CC and Reply To All. My 0.02$ on the subject: https://www.linkedin.com/pulse/cc-reply-all-perfect-match-ma...

With in-person communication, you can tell if someone has allocated attention to focus on understanding you.

With async communication, you can't. This is a source of impatience on the sender side and overwhelm on the receiver end. There isn't a way to respond to an email with "429 - too many requests" or "503 - service unavailable".

I was looking at a Kanbanize board right before reading this post. I asked to my customer on Slack if I should complete a subtask of a card or start a small new one, because I think I won't be able to complete both of them before the end of the day. This is asynchronous and I didn't get an answer yet. I can make it synchronous by calling him but I won't travel the 3-4 km to their office every day I'm working for them only to be able to meet face to face. We did it during the design phases and it's OK. Probably the best way to build a grand design of the system. But email, IM and boards like Kanbanize, Trello, etc are OK for everything else. And Slack or Meet for calls and screen sharing.

I got the answer now, back to work.

Interesting to read, but maybe to simplistic? I mean, asynchronous communication and synchronous communication each have advantages depending on the work. If I have to code something completely new, i want to be able to work alone with no distraction (and email is still king of asynchronous communication). If i'm debuging or if i'm doing ops stuff, having other devops around me help, whether its by my side or with a shared screen + audio. Human are not robot, and i think/feel that foc creative/innovative tasks, async is the way to go.

It depends on the situation. Email should be accompanied by a messaging system that a) lets you know if the other person is available to chat, and b) provides real-time interaction.

The combination is more efficient than phone or video conferences, and much more efficient than in-person conferences, especially those requiring a plane trip. These more often involve social banter and often include participants who are only marginal contributors or time wasters.

Let me save you the read. No. The federated standardized asynchronous instantaneous digital communication protocol was not a mistake.

Certainly email lists as a discussion medium were always doomed. ;-)

I remember taking part in the first mailing list (1973?) on the ARPAnet, which was, appropriately enough, about mailing lists, hosted by BBN. Flame wars sprung up day and night, even with only a few dozen people.

Email is just a reflection of the humans that use it, so, sure it's a disaster, but still quite useful.

Email was a good killer app for what was an incipient technology at a time (especially with most of the participants being non-adversarial)

It is certainly not for everything and today it is only usable with a thick layer of verifications and anti-maliciousness on top, but it still has its purpose.

Does anyone know what algorithm theory is?

Such a clickbaity title. E-mail was meant as a replacement for the paper letter, and in this it succeeded tremendously well. It is quick, distributed, open, cheap and efficient (almost to a fault). It has been with us for decades and will still be with us after the current behemoths of the internet have sunk into their tarpits.

Trouble arises when you start using e-mail for different purposes. E-mail is not chat. E-mail is not a todo-list. E-mail is not a tool for massive collaboration. Running a business using just e-mail is as absurd a proposition as running a business using only paper correspondence.

This SMBC Comic comes to mind:

https://www.smbc-comics.com/comic/2010-11-26

> Was email a mistaken?

No.

> E-mail was supposed to make our work lives easier and more efficient

Email was supposed to allow us to send textual messages, e.g. letters, notices etc., through computer networks and in a computer-viewable, computer-editable format. And it has done that.

> but the mathematics of distributed systems suggests that meetings might be better.

Huh? that makes absolutely no sense. Very little of my email is even theoretically replaceable with a "meeting" (not the least of which - automatic notifications.) As for the rest of my email - if I had to hold 10-20 meetings a day I'd go nuts.

> They became convinced that synchrony was superior and that spreading communication out over time hindered work rather than enabling it.

No they didn't. Author is probably ridiculously over-generalizing some finding on a certain specific setting and a certain irrelevant metric.

> A major implication of research into distributed systems is that, without synchrony, such systems are just too hard for the average programmer to tame.

Yup, just like I thought. Totally irrelevant. How is reading email a programmatic taming of a system? It isn't. and so on, and so fort.

What a trollish article.

> But coördinating telephone conversations

As a non-native speaker, I wonder: is this a typo or intentional?

Yet another useless essay.

Emails in the workplace are only sent for two reasons.

1. To show your boss that it is someone else's fault - delays etc

2. To show that it is not your fault there is going to be a delay as a deadline approaches.