I agree with the author's crusade against pointless meetings, but their attack on email doesn't sit well with me.
> Avoid email loops. Those have too much overhead, and will divide your audience pretty quickly.
The author recommends "async slack" in a cartoon, but then advises against using email -- which is IMO far superior to "async slack" in every way possible. Mailing lists are severely under valued in corporate environments. They are still a great medium for discussion.
> Create a slack channel instead of the email loop. This will retain the whole conversation in 1 central place.
So will email? With the added benefit of being self hosted, with a great collection of software which works on any and all platforms, which has been around for decades, which can easily be archived, and which will still be accessible decades from now.
chrisweekly 1305 days ago [-]
> "email -- which is IMO far superior to "async slack" in every way possible."
You're entitled to your preferences, but "far superior... in every way" is a bit hyperbolic. In practice, with email, usage patterns vary wildly (forward, reply, reply-all, cc, bcc). IME Slack channels are cleaner and provide several benefits. Not just the option for ~realtime / synchronous chat (where email doesn't work at all), but the mechanisms for tagging users and other channels; "pinning" key attachments; all its 3rd party integrations (ie, it's viable as a "hub" for communications and record-keeping thereof)... Don't get me wrong; it's far from perfect, and email -- when used properly -- has substantial strengths. But so does Slack. An open-source, self-hosted Slack clone would be my strong preference.
gregmac 1304 days ago [-]
You can "tag" people with email. Lots of people use this highly effective pattern:
Please consider the environment before printing this e-mail.
This message (including any attachments) is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error please contact the sender (by return E-Mail) immediately and delete this message. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that, for organisational reasons, the personal E-Mail address of the sender is not available for matters subject to a deadline.
[Broken image] [Broken image]
---------
[Chain of 92 emails; the important ones are #36 and #73 but you won't figure that out until at least an hour of scrolling]
dsr_ 1304 days ago [-]
Hi John --
Please remember that our corporate standard of email etiquette, as referenced in the employee handbook wiki [link], is to inline our responses while removing unrelated content. We've found that method to be very effective for the last thirty years.
Also note that the standard for internal signatures [link] is 2 lines:
NAME OR NICKNAME
DEPARTMENT
and that the standard for external signatures is a maximum of four lines [link] with the following recommendation:
NAME
DEPARTMENT / COMPANY
DEPARTMENT CONTACT URL
Finally, I don't know who told you to put all those images and disclaimers in, but Legal advises that you can't discuss confidential info in external emails, so you don't need disclaimers. You don't get privilege unless you work in Legal, either.
Yours,
dsr_
Security
brnt 1304 days ago [-]
Try working in a non IT company. Its IT itself who set up the mile long footer and people will have no idea or no authorization tot change it.
srtjstjsj 1304 days ago [-]
Anyone talking to Legal gets privilege. Not only Legal.
dsr_ 1304 days ago [-]
The first thing that Legal says is "You don't communicate privileged information by email. Call me."
CleaveIt2Beaver 1304 days ago [-]
Don't forget that at least three threads have forked from this because some nimrod clicked Reply instead of Reply All
wcarss 1304 days ago [-]
+1, I agree strongly that the "channel" is a powerful UX metaphor and enables better high-throughput communications, and that other modern ideas are expressed in chat applications in a way that's more comfortable to us than they are within email.
I also believe that there's a big gap between traditional text chat and an audio/video meeting, where casual discussion and emotion trade off against calendar space and long periods of captured focus -- so I hope we have progress to make here!
(I posted in a different thread in this submission that I believe in this so strongly that I'm making a product to try to bridge that gap, but I won't muddy things by re-linking it repeatedly.)
Jedd 1305 days ago [-]
> An open-source, self-hosted Slack clone would be my strong preference.
Are you suggesting that a non-free, expensive, SaaS, IRC/rocket/mattermost/element/etc clone is not where we should be aiming?
rich_sasha 1305 days ago [-]
+1. Also, chats imply a semi-synchronous conversation, which IMHO is the worst of both worlds. Talking to people 1:1 is disruptive, but at least very efficient. E-mails are slow, but very non-disruptive. Chats are slow, inefficient _and_ almost as disruptive as talking.
You could use them in an async manner I guess, but Slack isn't really made for that, it's clumsy as an e-mail replacement.
christophilus 1305 days ago [-]
Basecamp seems like a good alternative. I can't stand Slack for anything, really. Email is OK, but you can't easily just add someone into a group of old emails automatically. Well, I suppose you could, based on your email service, but yeah. I think this kind of thing is where Basecamp and similar tools really shine.
Stratoscope 1305 days ago [-]
The problem with an email loop is it has no visibility to newcomers.
If you create a channel for a particular topic, then when someone new joins the team, you can point them to that channel to catch up.
Jedd 1305 days ago [-]
This is the same problem that TFA glosses over.
From the article:
> Having everything searchable makes it super easy for a) newcomers that can simply scroll back, and b) old timers such as me that forget and can also simply scroll back.
The (false) implication being that in the 40 years we've had email, no one's worked out how to archive and index it.
Worse, the disingenuous use of the word 'simply' here.
For some years I've put effort into my comms to avoid the words 'simply', 'just', and similar whenever describing a task I wish upon someone else.
It devalues the time, effort, and complexity that I'm demanding of someone else, by assuming the task I'm pushing onto them is trivial.
In this case, trying to comprehend context, let alone nuance, from an instant interruption log, is a massive cognitive load. Timing / pace is completely lost when reviewing a big wall of short and sharp exchanges between multiple people.
Compare and contrast reading an email thread where people aren't battling to be first / fast - but rather, to be coherent, concise, cogent, and considerate in their correspondence.
kashyapc 1305 days ago [-]
IIUC, Elric is referring to the usage of internal mailing lists, whose archives are (internally) open for anyone.
Each discussion becomes a URL in its own right, and is blazing fast (given it is locally hosted); you can point the thread to the newcomer. I too think this is more effective than any chat "scroll-back" hosted on someone else's infrastructure—it can go down any moment.
ekianjo 1305 days ago [-]
> when when someone new joins the team
What happens is that someone new joining the team will not even bother searching thru dozens of channels, they will use the chat system to ask questions instead. Completely failure of knowledge management.
bloak 1305 days ago [-]
You point newcomers at the list archive (mailman or whatever)?
usrusr 1305 days ago [-]
One argument that I could imagine (not sure that I'm supporting it) to prefer slack over mail: usage patterns for a shared email channel are far more individual than for a branded async medium like slack. With mail, some people will do elaborate filtering, others just dump everything in a single inbox. Some will use mail very close to real-time (perhaps even do all their mail hands-off through some Siri/Alexa/whatever voice interface?), others might maximise asynchronicity even to the point of hardcopies. A branded channel will be far more predictable in terms of client UI and usage patterns.
bryanrasmussen 1305 days ago [-]
>usage patterns for a shared email channel are far more individual than for a branded async medium like slack
on the other hand this can also be argued as a strength of email (which is what I would do) because different people need different usage patterns to work optimally, by forcing people into a one size fits all solution you will ensure some people will work less well than others.
usrusr 1305 days ago [-]
Just invoke accessibility as an implicit benefit of the multitude of email usage possibilities and slack etc should be almost taboo.
bryanrasmussen 1296 days ago [-]
which companies that care so much about accessibility is it that you've been working at?
grayclhn 1305 days ago [-]
You're combining "email" and "mailing lists." I totally agree about the value of mailing lists, but well archived mailing lists don't seem to be an option in many companies. Email w/out mailing lists can be a poor experience.
6gvONxR4sf7o 1305 days ago [-]
Maybe it depends on the email habits at your office. In mine, the signal-to-noise of email is so low that it's nearly worthless. (If this were an email, it'd probably go to the whole department)
boredumb 1305 days ago [-]
I find that slack channels generally can be less pedantic and people are more likely to ask "dumb" questions they would otherwise not bother with in an email.
Archives do the job, but being able to have a dedicated channel in a tool i'm using for ongoing communication is nice and I find it nice to pin certain posts to the channel for reference or newcomers.
With that said my only arguments for a slack or "async" IM client is generally predicated on it being internal communication.
jmartinpetersen 1305 days ago [-]
I guess for the author (and most other people who hasn't participated on usenet or the like), email is understood as "person to person communication through email". As in, not something that involves listserv.
It seems like you agree on the principles but have different favourite tools for the solution?
One upside of using a chat'ty tool is that you don't need to discuss top vs bottom posting ...
tyingq 1305 days ago [-]
I have trouble with both email and/or slack or MS Teams. All are full of notifications, requests, and unintentional spam. But none has a way of identifying which is which. So I'm stuck trying to sort all that out. I can tag them, but that puts a lot of work on me.
StavrosK 1305 days ago [-]
I very much agree with you. Even without lists, I found email better because it lets you gather your thoughts and present them coherently.
Nowadays I prefer Zulip, as it's a great fusion of email/lists/IM with various very nice features and usability added.
daralthus 1305 days ago [-]
Async Google Docs > async Slack > meetings
You can setup a template with all they main points and checklists already in place, then get people to fill it out and collaborate on it.
Here's an example with the headlines, each would become it's own section:
- Problem summary
- Impact
- Measure of success
- “Why does this happen?”
- Current solutions
- Ideal scenario
- Constraints and needs
- Unknowns
- Proposed change
- Alternatives
And checklists for the writers:
- On what level, and how detailed I want to describe things?
- Did I write details into unrelated sections?
- Who is this document for? Do they really know all that stuff I assume?
- What impact would this change have on the business?
- Can we quantify it?
- How do we measure that the change solved the problem? How does winning look like? (ROI, proof of impact)
- What is the root cause? (“Why? Why? Why? Why? Why?”) Are we solving the right problem?
- Can we break up the solution into smaller chunks to reach the goal faster?
- Are we trying to solve a general problem before something specific?
- How do people solve this already?
- Did we talk to them yet?
etc.
Then you offloaded all the questions you would have asked anyway to a document.
wcarss 1304 days ago [-]
This is a great template! I have a personal theory about extending what you wrote above:
...and I'm writing an MVP for a tool to do it[1]! I hope that a lot of people will run async verbal meetings and do team-wide chats via asynchronous audio in the near future, because it's much more convenient and comfortable than long, synchronous video chats or laboriously editing text messages for technical content and tone.
In most ways, my MVP is just like IRC or slack, but it lets you also send audio, and it auto-transcribes the audio as a chat message, with a play button beside it.
I think meetings are one of the biggest use cases for a tool like this, so building some default structures like the above and publishing them out as artifacts is certainly in the milieu of ideas I'm trying out.
This piece is a collection of disjointed claims and complaints. There is little in the way of argumentation to support any of them (and nothing in the way of evidence).
The existence of a valid opposing view on each of these claims isn't even acknowledged.
Then there's that the content is disjointed from the title. Clickbait is evil.
TBH I don't get why this post floated to HN top. Especially when there are so many better pieces about this topic out there. Off the top of my head: https://basecamp.com/guides/how-we-communicate Go read that; a much better use of time.
d23 1305 days ago [-]
Perhaps people only read the title? I too found this really disjointed. The author says the whole thing is "extreme satire" in the header, but it doesn't read that way, so I found myself increasingly confused as I attempted to read.
flohofwoe 1305 days ago [-]
> Try as hard as possible to avoid meetings
Yes, but
> use textual IM instead
...please no, first try to figure out if you really need someone else's input at all to make a decision and after that if that input is needed immediately, if yes you should have requested that information a few days ago already. If no, send an email and don't expect an answer before the next workday. Otherwise you just interrupted someone else's work the same way a meeting would, and that should be reserved for emergencies.
testcase_delta 1305 days ago [-]
Any time I read threads like this one I am grateful I found Basecamp years ago. Granted, my company has a really small team (projects with 4 internal people on it), but largely due to how Basecamp is structured and my own dislike of being interrupted or time-sucking meetings, we suffer very little of the problems OP brings up. I strongly recommend Basecamp or at least checking out the philosophy behind the software.
cpeterso 1304 days ago [-]
I spend a lot of time in meetings, as both host/facilitator and guest, and work remotely 99% of the time. We spend so much time in meetings without giving them much thought to designing them.
I highly recommend the book "The Surprising Science of Meetings: How You Can Lead Your Team to Peak Performance" [1] ("One of the top business books everybody will be reading in 2019" — Business Insider) or, for a quick summary, the author's webinar "The Surprising Science of Meetings: Evidence-Based Insights Leaders Need to Gain a Competitive Advantage" [2].
While I agree with much of the OP, I think it’s all over the place.
Asynchronous Communication is they key to me and is described by some remote-first companies [0].
The medium of communication is up for debate.
Co-edited design docs for example. In its simplest form I can write a draft of an ADR as markdown and add it to source control. Ensure people know it’s there and have them edit and comment in their own time. No extra tools needed.
What you do need is a team of people able and willing to spend time working like this. Some teams consist of people that are just drifting along and you’re forced to stick everybody in a room and discuss that one issue with no distractions.
Slack to record meeting decisions? That has to be the most ridiculous proposition ever. Slack is a chat system, not supposed to become a knowledge repository or even remotely made for capturing meeting notes. Using effective tools for the job matter.
darkerside 1305 days ago [-]
I'm not sure if this satire is crude and poorly targeted, or if it's high brow to the point it's over my head.
I think it may be the latter, not because I "get it", but because it's hard to believe someone is really arguing for using Slack like a microservice over the monolith of meetings. I think author is skewering the "adopt everything" crowd that jumped all over microservices and likely the comprises the current wave of Slack adopters. Not that I'm against Slack, but pushing more there instead of into a well run meeting, particularly to make effective decisions as a team, is a laughable idea.
1305 days ago [-]
javier10e6 1304 days ago [-]
Why do we meet?
To avoid going on a picnic and while unpacking the food
someone asking: "Ok, who brought the salt?" and everybody
getting a blank look.
That its easily achieved today with online tools.
Then why we keep having meetings?
To avoid going on a picnic and while unpacking the food
find out that some people went to McDonalds because they
feel that the food and the whole idea of preparing your
food sucks.
It's group therapy.
It might help, or get on the way of getting things done.
skrebbel 1305 days ago [-]
Entirely offtopic, but I'm bothered to no end that this page appears to be using the LaTeX default font but the typesetting is shit (on my Edgium/Windows at least). Like an uncanny valley.
Apparently I've been trained to go "hey, Computer Modern! If anything this is gonna be nice on the eyes" and then when it isn't my stomach makes weird feelings.
_tk_ 1305 days ago [-]
Can someone elaborate what the satirical part of this article is? I’m not sure I understand. Or in other words: I agree with this version very much.
awofford 1305 days ago [-]
I see the note at the top of the post that it's meant to be extreme and satirical, but a lot of people actually try to substitute Slack for a meeting or quick zoom call and I think it's incredibly counter productive. The efficiency of verbal communication should be prioritized any time a Slack thread goes beyond ~10 replies. Slack is where work goes to die; not meetings.
montagg 1305 days ago [-]
Any form of communication can be helpful with norms and proper framing. I regularly use Slack for asynchronous decision-making where we’re explicitly not trying to fill each others’ calendars with more meetings, and we start with a specific question as a frame and what we want to get out of it. Threads can be long, but it also doesn’t pollute the rest of the channel, so it’s opt-in. It’s expected folks will bring the group back to the topic of discussion strays. And 80-90% of the time, we can get most or all decisions out of the way, such that if we have a meeting, we’re focusing that time just on the areas where a meeting is necessary.
Without some kind of guard rails through norms or framing, any communication, including a meeting, can get unproductive fast.
hrktb 1305 days ago [-]
It heavily depends on why the thread is getting long.
If people are talking past each other on trivial matters, sure a call should be faster.
Or if the core issue is to take a simple decision or iron internal politics.
If it’s a complex issue that needs input from a number of people, with resources and/or documentation to consult, and a need for well thought input vs. random babbling, participants should actively fight the urge to move to a call IMO.
Rendered at 04:37:59 GMT+0000 (Coordinated Universal Time) with Vercel.
> Avoid email loops. Those have too much overhead, and will divide your audience pretty quickly.
The author recommends "async slack" in a cartoon, but then advises against using email -- which is IMO far superior to "async slack" in every way possible. Mailing lists are severely under valued in corporate environments. They are still a great medium for discussion.
> Create a slack channel instead of the email loop. This will retain the whole conversation in 1 central place.
So will email? With the added benefit of being self hosted, with a great collection of software which works on any and all platforms, which has been around for decades, which can easily be archived, and which will still be accessible decades from now.
You're entitled to your preferences, but "far superior... in every way" is a bit hyperbolic. In practice, with email, usage patterns vary wildly (forward, reply, reply-all, cc, bcc). IME Slack channels are cleaner and provide several benefits. Not just the option for ~realtime / synchronous chat (where email doesn't work at all), but the mechanisms for tagging users and other channels; "pinning" key attachments; all its 3rd party integrations (ie, it's viable as a "hub" for communications and record-keeping thereof)... Don't get me wrong; it's far from perfect, and email -- when used properly -- has substantial strengths. But so does Slack. An open-source, self-hosted Slack clone would be my strong preference.
FW: Re: FW: Fw: Re: RE: Update on project
hey chrisweekly, what do you think of this?
Regards,
John Doe, MSc, CPA, CMA, TLA,
CISAOO
Big Corp
123 Fake St
Someplace, OT 90210
Phone 2025551234 x364375
Fax 2025553536
Cell 2025553788
Pager 20255522226
Check out our FacedIn page!
[Broken image] [Broken image] [Broken image] [Broken image] [Broken image]
Please consider the environment before printing this e-mail.
This message (including any attachments) is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error please contact the sender (by return E-Mail) immediately and delete this message. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that, for organisational reasons, the personal E-Mail address of the sender is not available for matters subject to a deadline.
[Broken image] [Broken image]
---------
[Chain of 92 emails; the important ones are #36 and #73 but you won't figure that out until at least an hour of scrolling]
Please remember that our corporate standard of email etiquette, as referenced in the employee handbook wiki [link], is to inline our responses while removing unrelated content. We've found that method to be very effective for the last thirty years.
Also note that the standard for internal signatures [link] is 2 lines:
NAME OR NICKNAME DEPARTMENT
and that the standard for external signatures is a maximum of four lines [link] with the following recommendation: NAME DEPARTMENT / COMPANY DEPARTMENT CONTACT URL
Finally, I don't know who told you to put all those images and disclaimers in, but Legal advises that you can't discuss confidential info in external emails, so you don't need disclaimers. You don't get privilege unless you work in Legal, either.
Yours,
dsr_ Security
I also believe that there's a big gap between traditional text chat and an audio/video meeting, where casual discussion and emotion trade off against calendar space and long periods of captured focus -- so I hope we have progress to make here!
(I posted in a different thread in this submission that I believe in this so strongly that I'm making a product to try to bridge that gap, but I won't muddy things by re-linking it repeatedly.)
Are you suggesting that a non-free, expensive, SaaS, IRC/rocket/mattermost/element/etc clone is not where we should be aiming?
You could use them in an async manner I guess, but Slack isn't really made for that, it's clumsy as an e-mail replacement.
If you create a channel for a particular topic, then when someone new joins the team, you can point them to that channel to catch up.
From the article:
> Having everything searchable makes it super easy for a) newcomers that can simply scroll back, and b) old timers such as me that forget and can also simply scroll back.
The (false) implication being that in the 40 years we've had email, no one's worked out how to archive and index it.
Worse, the disingenuous use of the word 'simply' here.
For some years I've put effort into my comms to avoid the words 'simply', 'just', and similar whenever describing a task I wish upon someone else.
It devalues the time, effort, and complexity that I'm demanding of someone else, by assuming the task I'm pushing onto them is trivial.
In this case, trying to comprehend context, let alone nuance, from an instant interruption log, is a massive cognitive load. Timing / pace is completely lost when reviewing a big wall of short and sharp exchanges between multiple people.
Compare and contrast reading an email thread where people aren't battling to be first / fast - but rather, to be coherent, concise, cogent, and considerate in their correspondence.
Each discussion becomes a URL in its own right, and is blazing fast (given it is locally hosted); you can point the thread to the newcomer. I too think this is more effective than any chat "scroll-back" hosted on someone else's infrastructure—it can go down any moment.
What happens is that someone new joining the team will not even bother searching thru dozens of channels, they will use the chat system to ask questions instead. Completely failure of knowledge management.
on the other hand this can also be argued as a strength of email (which is what I would do) because different people need different usage patterns to work optimally, by forcing people into a one size fits all solution you will ensure some people will work less well than others.
Archives do the job, but being able to have a dedicated channel in a tool i'm using for ongoing communication is nice and I find it nice to pin certain posts to the channel for reference or newcomers.
With that said my only arguments for a slack or "async" IM client is generally predicated on it being internal communication.
It seems like you agree on the principles but have different favourite tools for the solution?
One upside of using a chat'ty tool is that you don't need to discuss top vs bottom posting ...
Nowadays I prefer Zulip, as it's a great fusion of email/lists/IM with various very nice features and usability added.
You can setup a template with all they main points and checklists already in place, then get people to fill it out and collaborate on it.
Here's an example with the headlines, each would become it's own section:
And checklists for the writers: Then you offloaded all the questions you would have asked anyway to a document.Async verbal meetings > Async Google Docs > async Slack > meetings
...and I'm writing an MVP for a tool to do it[1]! I hope that a lot of people will run async verbal meetings and do team-wide chats via asynchronous audio in the near future, because it's much more convenient and comfortable than long, synchronous video chats or laboriously editing text messages for technical content and tone.
In most ways, my MVP is just like IRC or slack, but it lets you also send audio, and it auto-transcribes the audio as a chat message, with a play button beside it.
I think meetings are one of the biggest use cases for a tool like this, so building some default structures like the above and publishing them out as artifacts is certainly in the milieu of ideas I'm trying out.
1 - https://heysync.chat
The existence of a valid opposing view on each of these claims isn't even acknowledged.
Then there's that the content is disjointed from the title. Clickbait is evil.
TBH I don't get why this post floated to HN top. Especially when there are so many better pieces about this topic out there. Off the top of my head: https://basecamp.com/guides/how-we-communicate Go read that; a much better use of time.
Yes, but
> use textual IM instead
...please no, first try to figure out if you really need someone else's input at all to make a decision and after that if that input is needed immediately, if yes you should have requested that information a few days ago already. If no, send an email and don't expect an answer before the next workday. Otherwise you just interrupted someone else's work the same way a meeting would, and that should be reserved for emergencies.
I highly recommend the book "The Surprising Science of Meetings: How You Can Lead Your Team to Peak Performance" [1] ("One of the top business books everybody will be reading in 2019" — Business Insider) or, for a quick summary, the author's webinar "The Surprising Science of Meetings: Evidence-Based Insights Leaders Need to Gain a Competitive Advantage" [2].
[1] https://www.amazon.com/dp/0190689218
[2] https://youtu.be/8rDuumUtfAM
Asynchronous Communication is they key to me and is described by some remote-first companies [0].
The medium of communication is up for debate.
Co-edited design docs for example. In its simplest form I can write a draft of an ADR as markdown and add it to source control. Ensure people know it’s there and have them edit and comment in their own time. No extra tools needed.
What you do need is a team of people able and willing to spend time working like this. Some teams consist of people that are just drifting along and you’re forced to stick everybody in a room and discuss that one issue with no distractions.
0 https://blog.doist.com/asynchronous-communication/
Slack to record meeting decisions? That has to be the most ridiculous proposition ever. Slack is a chat system, not supposed to become a knowledge repository or even remotely made for capturing meeting notes. Using effective tools for the job matter.
I think it may be the latter, not because I "get it", but because it's hard to believe someone is really arguing for using Slack like a microservice over the monolith of meetings. I think author is skewering the "adopt everything" crowd that jumped all over microservices and likely the comprises the current wave of Slack adopters. Not that I'm against Slack, but pushing more there instead of into a well run meeting, particularly to make effective decisions as a team, is a laughable idea.
Apparently I've been trained to go "hey, Computer Modern! If anything this is gonna be nice on the eyes" and then when it isn't my stomach makes weird feelings.
Without some kind of guard rails through norms or framing, any communication, including a meeting, can get unproductive fast.
If people are talking past each other on trivial matters, sure a call should be faster. Or if the core issue is to take a simple decision or iron internal politics.
If it’s a complex issue that needs input from a number of people, with resources and/or documentation to consult, and a need for well thought input vs. random babbling, participants should actively fight the urge to move to a call IMO.