Fun Yet Effective Meetings | Hacker News Reader

Fun Yet Effective Meetings

blog.pwkf.org

81 pointsthesnide43 comments

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.

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.

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

Just invoke accessibility as an implicit benefit of the multitude of email usage possibilities and slack etc should be almost taboo.

which companies that care so much about accessibility is it that you've been working at?

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.

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.

You point newcomers at the list archive (mailman or whatever)?

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.

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

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

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.

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.

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

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

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

You can "tag" people with email. Lots of people use this highly effective pattern:

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]

Don't forget that at least three threads have forked from this because some nimrod clicked Reply instead of Reply All

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

Anyone talking to Legal gets privilege. Not only Legal.

The first thing that Legal says is "You don't communicate privileged information by email. Call me."

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.

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

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.

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.

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)

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.

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.

This is a great template! I have a personal theory about extending what you wrote above:

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

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.

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.

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

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.

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

[1] https://www.amazon.com/dp/0190689218

[2] https://youtu.be/8rDuumUtfAM

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.

0 https://blog.doist.com/asynchronous-communication/

> slack

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

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com