Hacker News Reader

Comment by jackjeff | Hacker News Reader

Async communication is suitable to resolve some kind of issues. But it has two drawbacks: participants need to be competent at writing and reading prose (it’s harder than it sounds) and even with the best of care your ideas can easily be misinterpreted resulting in the loss of an async cycle.

For problems which are not well defined, and where a lot of decisions need to be taken, especially when they verge toward the arbitrary, it’s a lot easier to have people in a room and hash it out. A remote meeting can work too.

The problem with meetings are those which are not well prepared. There shall be an agenda and proper minutes should be produced.

For most complicated matters actions/investigations are supposed to be followed up. In a way that’s how you mix async with sync communication.

View on HN

Recently, I was so frustrated with some folks poor reading comprehension that I was thinking about an imaginary communication system that would allow for decision making where there were some rules:

- No responding from mobile devices. The poor response rate is just too high.

- The reader is quizzed on the the contents of the communication before they can respond (randomly generated quizzes might be amusing).

- The reader has to retype the original communication themselves before they can respond....

- Timeout value, if no responses that pass the above tests in a given time frame, whomever asked gets to complete the task with no input and nobody can change the outcome for ... a week or so and everyone has to live with it.

- Anyone who wants to change it after the timeout value better explain why they didn't ask before hand... no idea how this would work, yeah we're getting into the weeds here.

Of course, these are all unworkable in a modern business environment but man ... I can dream that some folks would who make demands or provide input at least put a minimum amount of effort into things before they throw their given wrench into the works.

Bullets 2 and 3 combined are actually recommended for spoken communications as well. As the listener, before responding, it's a good habit to say "This is what I understand about your proposal" and proceed to summarize and give the original speaker an opportunity to correct you.

Probably over half of the communications problems I've seen at work are because people don't follow this basic practice. They respond based on what they understood, not based on what the speaker was saying.

As one book I read put it: You should be able to reflect their world view back to them as if you yourself are advocating for it (even if you completely disagree). When you do this, they'll believe you understand them. For many people, only then will they listen to your critiques.

There's also a subtlety where if you focus too much on what someone said, you might lose why he said it and how it pertains to the situation. I've gotten through some communication problems by focusing on how I understood the person's position, instead of what the arguments he brought forth. When you do that you get this funny situation where it almost seems like each person is participating in different conversations, but at the same time the discussion is progressing effortlessly. I think of it as letting yourself be free to frame and reframe the issue at hand however you like.

> As the listener, before responding, it's a good habit to say "This is what I understand about your proposal" and proceed to summarize and give the original speaker an opportunity to correct you.

I find a practice like this is also helpful for following up after a meeting. For meetings that warrant my taking notes, I like to type them up immediately afterwards, send them out to the other attendees, and solicit corrections or confirmations while the meeting is still fresh on everyone's mind.

It was a bit scary when I first started doing that since I'd fear that I might have misunderstood something and would be revealing my ignorance. But to the contrary, I've found that it tends to encourage others to share their notes for comparison and elicit further discussion. (If there's something I've misunderstood from a meeting, usually someone else was confused too.)

I've been doing the same for the past 10+ years.

The problem that I found with it, is that a recurring receiver (let's say a client) will eventually start trusting your minutes so much that they don't even bother to read them and just answer with 'Looks good' and basically you lose the power of minutes.

To counter this, recently I've been trying to insert one wrong bullet point from the beginning, making the receiver pay more attention down the line. I don't have yet enough data points to see if this approach works.

That last point is pretty hilarious!

I find writing up the minutes during the meeting and distilling to “are these the most important points?” works to grab folks’ attention.

I had managers -do-this- (repeat what they understood as the key element) in meetings and thought of it as a very annoying waste of time. With five people in the room, assuming you do, on average, two rounds per agenda item, there are nine repetitions.

Many people -- everyone? -- repeat what was said? Not sure I follow

You are right, the extreme value where everyone everytime repeats what was said before, to ensure common understanding, is an unlikely example. My point is that repeating information already present lowers information density. The "good habit of repeating what you understood" can quickly become very annoying.

Ok. Maybe it's enough that the one who is "the most responsible" for getting the things done, repeats

> They respond based on what they understood, not based on what the speaker was saying.

Lets say there are three main steps in responding to communication: 1. Comprehension of the original communication. 2. Mapping that communication onto the reader's priors. 3. Crafting a response that communicates the results of that mapping.

The problem seems to be that the first two steps are typically left implicit indefinitely. As a result, there can be discontinuities lurking hidden in or between any of those three steps and it's a hell of a lot of work to pry those discontinuities up to the surface.

Well, the whole point of repeating back their world view is to prevent implicitness and reduce hidden misunderstandings.

It's really not hard to do. You'll never get there 100%, but getting to 80%? It's easy.

FWIW, it doesn't have to be a "new communication channel", you just documented some best practices for email.

> No responding from mobile devices. The poor response rate is just too high.

If something was left implicit or de facto re-ask for it to be explicit or de jure.

> The reader is quizzed on the the contents of the communication before they can respond (randomly generated quizzes might be amusing). > The reader has to retype the original communication themselves before they can respond....

A simple "What's you're rationale?" or if you're less confident "Sorry, I understand the action items and can execute them but I didn't follow the motivation. So I can do an even better job (or so I can make this decision without you next time), could you walk me through your thought process?"

> Timeout value, if no responses that pass the above tests in a given time frame, whomever asked gets to complete the task with no input and nobody can change the outcome for ... a week or so and everyone has to live with it. > Anyone who wants to change it after the timeout value better explain why they didn't ask before hand... no idea how this would work, yeah we're getting into the weeds here.

This is the most important email best practice that trips up junior workers. Make the default of your email your desired outcome.

Instead of: "Does everyone approve?" then if people respond asking "Ok, when should I do it? Thursday?".

Try it like this: "I'll make the change on Thursday. Please let me know if there are any concerns.".

1. Make the default response (i.e. no response) in your benefit.

2. Ensure there is a timeout value attached.

None of this is difficult or theoretical, its just a set of best practices you can get your self and others used to.

So, don't end the email with "Does everyone approve?"

Start with "Unless you disagree, I'll ..." Instead :)

Maybe a nit, but I think it’s very valuable:

“I’ll ..., unless anyone disagrees”

2 changes:

- Starting the sentence with a doubt can highlight doubts so I’d avoid that.

- “Anyone” distributes responsibility, because https://en.m.wikipedia.org/wiki/Diffusion_of_responsibility

Thanks! Those are good points. I've read about diffusion of responsibility before but didn't think about it now

Oh man, I hear you. The amount of sad encounters (especially lately) that I've had as a result of people not understanding what I'm saying because they don't actually read what I wrote are enraging. I almost quit one client over it because their IT guy is the worst. He will decide ahead of time what your email probably says, and that's what he reads into it even if I wrote the opposite.

I try to blame myself first for poor communication, but I asked some mostly independent people to help mediate and they basically came back and told him to read better and review past messages if he couldn't properly remember the context.

I'm just starting to dip my toes back into the freelance web development world, after deciding indie game development wasn't for me.

My main problem with clients has always been 1) They don't really know what they want, beyond "a website", and 2) The reading comprehension of pretty much everyone I interact with is surprisingly low. I've mostly dealt with small-business owners, whose personalities seem to veer towards the eccentric.

With my current client, I'll send out emails requesting clarification for certain features that need to be implemented on the site. If I'm lucky, I'll get an email back with at least one of the issues having been addressed. There's been emails where the response was in no way relevant. At one point I even got a photo of someone's backyard sent to me as a response.

I've learned to only send him a single line of text if it requires a response, to increase my chances of getting something I can act on.

I really like making web sites, and programming in general... It's just the frustration of poor communication that makes the job so frustrating. I think if I were more of a salesman/people-person, I would probably be better about figuring out what they really need, and offering solutions to them... rather then just getting upset that they don't what they want.

I've seen people like this doing day to day business: it's absolutely awful. They attend meetings starting with software and ending up with elephants.They can't sit for more than two minutes and there's always phone, email, whatever. To expect for such a personal to produce a written piece on what they want,while they can't even do it verbally,is impossible. These are usually somewhat successful in some sort of a niche but would drown in any other environment.

I see similar issues with support emails. One thing I learnt is to never ask more than one question in an email as only the first question gets answered.

I’m sure it has been getting worse over time. I’m at the stage where I am surprised when I receive a coherent request.

Probably the most common question is “I tried you software, it don’t work”.

"I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant."

Can be shortened to “Hey! Listen!”

Not without loss of several significant subtextual channels: respect, clarity, and intent to name a few. Communication is a discipline; verbal shorthands like these are analogous to copy/paste laziness over thoughtful, intentional code.

> they don't actually read what I wrote

How long are those texts?

What about trying a maybe reverse text order? Start with: "do this, that, that. Because ..."? The actions first? I'm guessing

> I was thinking about an imaginary communication system that would allow for decision making where there were some rules:

> [...]

> - The reader has to retype the original communication themselves before they can respond....

In email (not following Outlook/conversation style) and newsgroups, people would trim the original quoted material down to what they were responding to and then type their responses inline. While that would, in a way, meet that requirement, it could still lead to people responding to selected parts of your message while missing other parts. But, that would allow you to reiterate the points they didn't address in your subsequent response.

Yeah, it's really unfortunate that inline replying effectively died out, replaced by top-posting. I think inline replies, while lending themselves to the selective quotation problem you mention, nevertheless force more careful consideration of the original text.

I'm not even sure selective quotation is really a problem. Selective replying happens regardless of whether they are quoting or not, but is just more explicit when they are documenting which parts they reply to.

I agree. I still do this. But nowadays lot of people feedback that they do not understand my way of replying. Compared to many of my early digital acquaintances I was socialized quite late on the internet starting in 97. Compared to my colleagues I often feel old and out of sync with my style of long form written communication.

> nowadays lot of people feedback that they do not understand my way of replying.

Some clients, like Outlook, will actually collapse the original email and only show the top-posted reply. An inline reply would appears as an empty email in their client.

I have this same problem and would describe it similarly.

> - No responding from mobile devices. The poor response rate is just too high.

For me, the tendency of slack to let users write very short sentences/phrases is the issue. Etiquette for slack allows very IM like messages, whereas Emails are generally required to be more verbose.

It's probably a question of personality, custom and habit, but I tend to write like I speak (some would say "no, you speak like you write" :-) in any forum, including Slack, sometimes in defiance of the cultural norms of the audience.

It leads to something of a reputation for verbosity, but never the accusation of ambiguity or excessive terseness. I don't think anyone's ever said to me, "What did you mean by that two-word reply?"

It can be quite useful when replying to each point though, you can quote each one independently since they're not merged into one big blob of text.

Not saying it's impossible otherwise of course, just slightly more convenient.

I hope I never have to go back to using email for work.

Long messages for tickets, slack for near real time chat.

Email for transactional spam and emailing old friend once a year.

You could only have such a system in an environment with a huge power imbalance between the sender and recipient, like Tim Cook sending a message to an Apple IC engineer. But with that kind of power imbalance all of these things happen anyways -- if an individual engineer gets an email from Tim Cook he definitely isn't firing off a poorly-thought-out reply from a mobile device.

I sort of see what you're saying. When a person with Great Authority says that Something Needs Doing, I need to think through what I'm going to say about what I'm going to do. But the single best response is to spend those fifteen minutes seeing if there's an obvious solution. If there is, you can be quite terse and just say: "done". Do that five times and even Tim Cook has your attention.

No, actually the opposite is true. The whole idea of any policy is to give artificial "power" to one side to straighten out the situations where the balance of power is unclear.

An exec (the remote-only version of Tim Cook if you like) can use their leverage to change the existing email flows between all managers and all engineers. Because it's more scalable than micromanaging one engineer.

In other words, some people are good at organizing through setting policies (the better sort of politics) and it's a good place to discuss such ideas.

Parent's formulation doesn't look convincing though :)

This is why Amazon takes the first 20 minutes as time for reading their written communication before big decisions.

I hate this approach (even more so when I was involved in writing the written communication) because it usually turns into idly waiting for others to finish reading, while I get distracted, bored and just plain could be doing something more productive.

I understand the concept and some people must find it useful and valuable, but I’ve personally never got anything of value out of it other than making sure everyone has read the content before the meeting proper starts. Personally, I find asking somebody to attend a meeting, where 20 minutes is just silently reading, rather disrespectful of their time.

What about everyone reading the material before the meeting, and a computer aided individual quiz to find out if they did?

Unless (all for the meeting really important ppl did), meeting cancelled

That would be great!

Hi! I recently opened my quiz generation service to public. Would you try out the quiz AI assistant at https://QuizRecall.com and let me know what would you need to be added to make useful also for your use case?

Give the quizzes at the end of the blog posts a shot:

- https://vaclavkosar.com/ml/starspace-embedding

- https://quizrecall.com/rack/Cynefin-Framework--Making-The-Be...

I use the service for personal training, but it is opened for others now as well.

This sounds like a typical engineers approach to solving a social problem. Just hire better staff and pay them what they are worth.

>For problems which are not well defined, and where a lot of decisions need to be taken, especially when they verge toward the arbitrary, it’s a lot easier to have people in a room and hash it out

Easier in what way? I think it makes people less frustrated by having to think hard about a hard problem, and feels "better" when everyone is saying what they think without any barriers, but I would guess it's much worse at arriving at good solutions to challenging business problems. Especially in the case you describe, with many decision points. I cannot fathom how a group of people chatting can efficiently work through many decisions at once, without laying it all out on paper anyway, whether it's before or after the fact. None of the meeting conversation matters unless you have someone taking good notes and summarizing decisions. Which makes me think, why not just start with the writing part? How is one person's notes about what a bunch of people said during a real-time conversation going to be even remotely on the same level as the people themselves composing their thoughts in writing? The in person meeting just seems like a space to share emotions and make shows of power in front of others.

I think async writing is much better (obviously nothing's perfect) for removing emotions from the discussion and forcing people to spend time thinking through their thoughts. The act of composing a written email, or composing a one-page spec document can do wonders for people ironing out their own thoughts and ideas.

And CC (+BCC) is, imo, the greatest business tool being dropped nowadays in favor of synchronous comms. CC keeps people informed without wasting time or disrupting schedules. It also allows the bosses to keep a much better handle on the comms culture of the company, since they obviously cannot sit in on or observe every meeting.

In person meetings have plenty of specific use cases, but I don't really understand the drive to make critical decisions synchronously in the moment during a meeting. Meetings are great for presentations, Q&A, gathering feedback, etc.

> and feels "better" when everyone is saying what they think without any barriers

Except there are barriers: People can tell you immediately that they don't understand you before you go off and speak for too long. Whereas with asynchronous, you could write a large amount and people won't be able to comprehend it because you made a mistake early on.

> I think async writing is much better (obviously nothing's perfect) for removing emotions from the discussion and forcing people to spend time thinking through their thoughts.

I agree on the latter, and disagree on the former. Rarely have I seen an important decision being discussed async that is devoid of emotion. With async, emotions are harder to gauge. This does not lead to people giving others the benefit of the doubt. It more often leads to people misreading emotions.

> And CC (+BCC) is, imo, the greatest business tool being dropped nowadays in favor of synchronous comms. CC keeps people informed without wasting time or disrupting schedules. It also allows the bosses to keep a much better handle on the comms culture of the company, since they obviously cannot sit in on or observe every meeting.

"You know how many emails I get every day? Do you think I have time to read every email I get?" spoken by every manager/senior engineer in my company.

(Although I'll admit, I prefer email to all other async comms I've seen. Pseudo-IM stuff is the worst).

There are, for sure, problems with both forms of communications. Conducting good "live" discussions in a room is a skill, and most of the participants have to be proficient at it. The same will go for async communications.

I think if there are serious, technical/tough issues to discuss, it is best to have it written up, with proper "counter" documents, and then get into a room to make the final decision, with everyone already well informed. It's a rare workplace where that will happen. People will respond to something well written with a one line objection on one minor aspect of the proposal, etc.

1.) Taking notes and summarizing conclusions is massively faster then having that whole discussion in writing.

2.) Most people are not gifted writers and speakers. They have hard time to express themselves properly. The spoken communication is faster and pretty often someone else can help to rephrase it couple of times or ask series of clarifying questions until it makes sense. This process is looong or does not happen in writing.

3.) Quick turn on simple clarifying questions.

4.) Honorable mention:

> The in person meeting just seems like a space to share emotions and make shows of power in front of others.

Emotions and politics are part of being humans. Humans typically need to share emotions and react to other peoples emotions. Someone refusing the idea for emotional reasons is not something exceptional - and typically harder to deal with in writing. It is harder to recognize in writing and harder to respond to in writing.

And I guarantee you that shows of power are crap in writing as much as they are in person. It does not disappear.

> even with the best of care your ideas can easily be misinterpreted resulting in the loss of an async cycle

This is not unique to async communication at all -- it is just becomes more apparent.

I have experienced a lot of sync communication, in which people only seemingly agreed and, when prompted later or as apparent by their resulting actions, quite clearly understood very different things.

There is also the very real issue of people getting increasingly tired and more agreeable during the course of a meeting. In async, when you stumble across something that doesn't gel with you, you might default to taking some extra time to think it through. Poor communication pops out that way. In sync communication you might let the same thing go -- not because of clearer signals or because it leads to a better outcome, but because you want things to end.

Thank you for writing this out.

It's scary how many posters are missing the fact that writing is difficult Because It Makes Miscommunication Explicit

All the same misunderstandings - and more! - happen in spoken communications and discussions. The only difference is each party leaves without realizing it, and there is no record of what happened. (And if there are meeting notes, they only record the understanding of whoever wrote them)

> resulting in the loss of an async cycle.

This is great way to think about this, thanks.

Depending on the team and communication channel, the cycle time can be hours or even a day (not including weekends), and I think avoiding extra cycles has a significant impact on the way people communicate, whether they realize it or not.

> For problems which are not well defined, and where a lot of decisions need to be taken, especially when they verge toward the arbitrary, it’s a lot easier to have people in a room and hash it out. A remote meeting can work too.

If I find myself in strong disagreement with someone's statements (and maybe wanting to write an angry rebuttal), I find it's usually better to switch to a synchronous discussion. Most of the time it comes down to misinterpretation that takes 2 or 3 cycles to clear up, and in a sync conversation that can happen in a matter of minutes and with significantly shorter responses than the async equivalent requires.

When you're responding to something in async communication, most people don't want to waste a cycle by just asking "What do you mean by 'x'?" -- and so instead will respond to their interpretation of 'x', often wasting many keystrokes on a misunderstanding.

In a sync conversation starting by asking "What do you mean by 'x'?" is easy and low-effort, and in my experience results a much more constructive and positive discussion, regardless of which side the misunderstanding was on.

You might find Dialogue Mapping using IBIS another useful tool in dealing with disagreements and wicked problems. http://cognexus.org/id41.htm

> it’s a lot easier to have people in a room and hash it out

IME it isn't because they aren't an environment conducive to informed debate. It's easy to get everyone in the room to agree, but as soon as you get out and check specifics, think the problem through properly, research what's already in pace, etc, you realize the whole meeting was a waste or worse, you've just committed to something sub-optimal/impossible.

An async "meeting" allow you to look for information so it's based in reality not best guesses, it gives you time to read necessary background info and do more research. These ultimately make for better decisions. They also don't waste the time of people that don't care.

> you've just committed to something sub-optimal/impossible

What about never making decisions at meetings -- instead, let everyone think 1 week after the meeting, and make the decision asynchronously? Eg vote via email

Combining meetings and async

Then there isn't much of a point in having a meeting, is there?

Instead, send out a written proposal, require well supported written commentary on the ideas, and then then meeting is to take an actual decision.

Well, there're some benefits mentioned in other threads here, eg quickly sorting out misunderstandings

> require well supported written commentary on the ideas

That sounds good -- in that case I'd think it'd work fine both with and without meetings

> misinterpreted resulting in the loss of an async cycle.

True, but readily fixed with "Can we talk about this when you have a minute?"

Also, losing "an async cycle" is a completely alien concept to me. I've been working remotely for a decade, never heard that phrase, and not entirely sure why it matters. Does a conversation that takes 14 Slack messages make the business less efficient than one that only took 11?

Honestly, I'm not trying to just nitpick, but why would a room full of people be beneficial to decisions "when they verge toward the arbitrary"? Wouldn't that be the perfect time for everyone to send their async opinions, and let a single decision-maker just decide? Large calls/meetings work when you don't know what you don't know - to get all the information on the table, and have all the knowledge in the same place at the same time. You talk, give answers where needed, assign some action items to people, and go back to your async lives.

As far as the initial statement that you must be competent at writing and reading prose... I'd love to hear more about that than "it's harder than it sounds". I've worked remotely with people with dyslexia and reading disabilities and C-level personalities that refused to get in-depth in any single communication. And one guy who had all those traits - the CEO... and it worked fine. None of that stopped us from doing our jobs effectively. You did need to learn how your co-workers communicated, but let me assure you - we were not excellent writers, we just knew our co-workers well enough to know their communication styles.

That is what remote work comes down to, at the end of it all. Not communication frameworks and rules of when to use what communication channel - but getting to know your team well enough that you know how to work together. If you do that, you succeed, whether remote or in an office.

Well if one async cycle takes 1 day due to timezones, that 11 vs 14 cycles becomes not negligible.

Hmm... I think the idea with synchronous communication is very much the same as it is with with synchronous method calls. Synchronous communication lets you break your thoughts down into smaller chunks and thus make them easier to understand. Synchronous methods do very much the same (at least how I write them).

I like what you say about needing to "learn how your co-workers communicate[d]". Maybe that's the abstraction layer that makes async everything possible. Still a leaky abstraction and I'd prefer not to have it. But it might actually have worked for me over the last couple of months.

The problem with meetings is when they are the default. I find them much more productive when there has been written communication ahead of time. Writing forces everyone to put their thoughts in order and hopefully come into the meeting with a baseline understanding.

Writing works so well in thought organization that part of my own meeting preparation is to write down my thoughts on the topic, even if just for myself.

I can't say enough how much I love the Amazon style of disttill your thoughts into a doc (doesn't have to be long) then schedule a meeting where everyone gets time to read it first and comment inline, then discuss. As you scale out your influence this helps even more. Even friendly readers should take a bit of a grader/devil's advocate approach and call out anything that can improve. Any qq they ask a later person, less in the loop or more skeptical because they have their own ideas person will definitely ask. So fix those sections and your doc and your written communication skills will greatly improved through iteration.

Also you get bit the distilled document that can be reused later (big win of written) and the high rate communication of a live meeting. And focus.

> participants need to be competent at writing and reading prose (it’s harder than it sounds) and even with the best of care your ideas can easily be misinterpreted resulting in the loss of an async cycle.

I get what you're saying here, but can't we replace writing and reading with speaking and listening, and claim somewhat the same thing for synchronous communications?

To me, if you have employees who can't write or read effectively, that's as bad as employees who can't speak or listen effectively. If you have those kinds of people, you have hired sub-standard people.

Sure, but at least at my company and with our customers, there's a large number of people who can speak and listen just fine, but are terrible at written communication.

> If you have those kinds of people, you have hired sub-standard people.

I used to think so as well, but from my work experience I'm leaning towards being good at written communication is not the norm.

I think that what it ultimately comes down to is empathy. What determines how smooth and effective a line of communication is.

Why most people tend to feel 'exhausted' when communicating synchronously online is that it's usually not very synced at all (interruptions both online and off are constant). So makes empathy more difficult to cultivate.

Async communication does seem to have more of an advantage here, as it is by definition a more thoughtful style of correspondence (writing a tutorial for example). And ironically, is a more synced style of communication, when the information passed on is actually being consumed.

I touched on this, and the ways in which async communications can be made to be even more effective in a recent post on my blog: "Why Most Programming Tutorials Are So Hard To Understand – (And A Solution To This Problem)" - https://fromtoschool.com/why-most-programming-tutorials-are-....

Yes, totally agree with you here. Synchronising to make the decision, then writing it down for async later reference and to inform those who weren't included in the synchronous bit for whatever reason is the best mix.

(which is exactly what agenda and minutes are for - they are the asynchronous preparation and followup)

AKA when random I/O is needed, minimizing latency is the key.

Brainstorming can be a chatroom; this is a better meeting because note-taking is automated.

However that should generate a list of items to follow-up on, and there need to be chances for validating, correcting, and following up on that process.

We have real time text chat for decades but most people, after remote work become the norm thanks to the COVID-19, still prefer video chat rather than the efficient text chat. It's because most people are lacking the literacy. Even though they look like understanding the text, the reality is, they simply recognize a few seemingly important keywords and pretend they understand the text as a whole.

Kudos for the eloquent put! I will quote your post next time this is brought up at my office.

How can you trust someone's spoken words if they can't write?

And what's the problem in your opinion with written iterations?

I usually attend meetings, hours a day, when I have to repeat the same concepts over and over, multiple times, to the same people, because they just forget what we established hours before.

There are people at my job setting up meetings just to "recap", which is a poor excuse for "we didn't take notes and/or we weren't listening and just said yes"

At least emails are searchable...

It is my problem with meetings & calls; I have no issue with effective meetings, however, a lot of people I work with (but ofcourse not all), treat meetings and voice calls just as a reminder/recap. They basically do not remember most of anything and don’t read/write anything either. So the people who take notes, read the minutes and read the docs have to sit through hours or rehash per week.

I cannot imagine how much time/money is lost by this in the world.

I wonder what type of organization / company is that? Eg fortune 500 or a government agency or a small tech startup?

(What do you think about their recruitment process?)

Reply on news.ycombinator.com