"communication" is like "engage your core" - everyone says it, you know it's good, but you don't know what it means until you know what it means.

And unfortunately there are things in life that you can't just "teach" in a linear way. You have to be curious and self driven.

One example - let's say you and Bob always miscommunicate. Like you think you agree on something but weeks later it turns out you disappointed each other. What's your reaction? "Bob's a weird asshole?" Or is it more "I am curious, why does this always happens with Bob and me? Let me ask him. Let me ask others." Then you may actually have a chance to figure it out.

Also: Talk more, in a pointed way. Ask the question: does this make sense? Is this nonsense? Am I making sense? Am I spouting complete bullshit here? You might be surprised how effective of a communicator you become if you tack some variation of that question onto every third or fourth sentence.

I wonder if people know how to talk, write, speak but not communicate.

Many people and organizations transmit in UDP. We need to communicate in TCP. Get the ack. Confirm the signal was received.

Personally, If I get or take a task, I repeat the request, confirm the deadline, and document the delivery. This way when there's a conflict I can demonstrate that someone forgot or ignored or overlooked.

It’s more complicated though. You may receive the Ack, but it gives no information about how your message was received by the recipient.

When talking to someone in person, if you say something, before they give a formal ack, their body language already tells you a lot about how they perceived the message.

If the reception was unfavorable, you have an opportunity to immediately add more to clarify if it was perceived incorrectly.

With a formal communication system such as an API, the API itself describes what messages it wants to receive and what the meaning of those messages are. But in human communication you’re not limiting yourself to messages the recipient has completely described. You’re creating new messages. New messages which the sender expects to be received ina certain way but there’s no guarantee it will be because we don’t know if the recipient is setup to handle it as you expect.

// You may receive the Ack, but it gives no information about how your message was received by the recipient.

Yup. And also, what you're getting an ack to matters.

Not helpful: you say: Project X is now priority 1. I say: I think you said, project X is now top priority, right? you say: ack!

Helpful: you say: Project X is now priority 1. I say: Just to confirm - we are going to pause project Y and Z, and move Alice and Bob to X. That probably means We are going to lose Acme as a client because they are waiting for Z. I can see how this might make sense, but just wanted to double check. you say: I didn't think about Acme. No, I didn't mean that - let's rethink.

One ack gives you no new information, one enables a really good communication. If you said "Ack" in the 2nd case, that's mean a lot!

> New messages which the sender expects to be received ina certain way but there’s no guarantee it will be because we don’t know if the recipient is setup to handle it as you expect.

I think this is one of the biggest points about communication: It requires both sides.

It doesn't matter if you have a clear and well-defined protocol for how you communicate if the other side can't, won't, or don't follow it.

It's like a web browser that only supports HTML. It may get the content your web server sends, but not the context and intent included in your CSS and JS.

And it's a lot easier to just say, "I only need the content, anyways."

Should the response time from an API affect the payload? I would suggest that body language helps the feedback loop. Body language does not change the transmission or the content.

A manager raising their voice does not change the message. Being more confident with myself, the volume, intensity, or cadence no longer impacts me in the same way as it did before. I now look forward to those moments of calm responses to the unprofessional interactions.

The way I like to think about communication is like this.

My brain is trying to relay information/emotion/experience/? to your brain. However, since it can’t be done directly, I have to translate those contents into a medium that you can understand (e.g. reading or understanding a language). My being goes further and also leaks information/emotion/? via facial expressions, body language, tone, etc.

Both the conscious and subconscious are probably lower bandwidth than the brain plus the translation machinery isn’t full fidelity.

Now the recipient has to do the same, but in reverse. This happens very rapidly but all along the way we lose fidelity and volume, so our two brains are never and can never be perfectly in sync. But we want that and so the task is to continue to hone and hone and hone. And listen and ignore the ego and establish trust and many other things that bring us closer to the almost having a single mind.

I really agree - doubly so after going independent and dealing with more non-technical counterparties.

Since my youth, I've always had a visceral, perhaps a bit maladaptive, need to be understood and have been able to parlay that into a sort of communicational hyper vigilance. The end result is that I compulsively over communicate and go out of my way to meet the receiving parties more than half way. If I can, I consider their background and reference frames and preemptively build a semantic bridge to them. Working with international teams, it's important to suppress urges for idiomatic expressions or general folkseyness, which is hard since I _LOVE_ to indulge in mixed metaphors and intentional malapropism.

The end result of emails with those constraints tends to be a wall of text, but the upside is that it tends to get copied around as a contextual 'checkpoint' of the problem under discussion.

In the end, effective communication is empathy.. And empathy can often be difficult work.

I do agree effective ommunication is challenging. For async remote communication, the one thing I found that personally helps is "Be explicit, don't assume". This can sometimes mean contextualizing and more explaining but it's definitely helped in terms of managing remote communication. Another aspect is brevity, it may come off rude at first as I've heard yet I explained why I do use it so much, in many cases but especially asynchronously it pays to be concise and very specific. I hardly deal with miscommunication and being unreliable. It might be context-dependent since I'm now in a more senior/leaderhihp like role and being somewhat a middlemen between mid/junior and management this is more valuable.

One thing I noticed is that a lot of people are trying to reuse/apply contexts and context clues that would work in synchronous cases and non-remote communication cased in asynchronous cases and remote communication casess. Obviously, a lot of people aren't adjusted yet so there's some lagging indicator like this. Overcommunication is one short term negative but long term positive action I've seen work. At first it may seem detrimental but it actually helps with adapting to the person/people/subject. Eventually people adjust the scale of communication where overcommunication is not present anymore.