"To truly listen means to place yourself mentally and physically in a vulnerable state."

If you can guarantuee me this will not be abused in every situation ever and/or come back to haunt me, i will gladly always give up as much time as i can to actually listen. :)

> No amount of knowledge or discussion will make a person accept something they don’t want to accept.

Not sure it's ever good to assume this beforehand though. Most things are negotiable, if you know how to negotiate right.

I don't worry about such things, because I have never been in error yet.

"When in actuality, they should be listening to the use case, looking for the pain, and finding a way to solve the pain points."

You have now described the value of product design (no matter if the person doing this is labeled PM, UX, Product design, or whatever)

> To truly listen means to place yourself mentally and physically in a vulnerable state

if it's not two ways, stop trying, stand up and leave.

Presales discovery in a nutshell. It’s truly an art.

> about the same thing

yes. I have to keep telling my colleagues "about what?" for about 4-5 times in a row, at least twice daily, until they finally realize they have to tell me which client, feature, product or whatever else they are referring to.

Even if i know exactly what yhey are talking about.

You also need to force them to justify their requirements, since asking for something way beyond what you actually need is an easy way to hide the fact that they don't understand what they actually need.

In my experience, people like that asking for 10x the actual requirement is fairly usual. But, every once in a while you hear someone say "we should buy the best, so we don't have to worry about it in the future" (when I heard it, that was a 500x cost difference).

What I say: This is not ready for production.

What management hears: We can sell this to the customer for acceptance testing.

> This is why it's important to write things down in details and as-unambiguous-as-you-can forms.

While that might be a prerequisite for a deep shared understanding, I have made the experience in the last few years that the number of people really reading more than the starting sentence of any message/ticket/email is consistently decreasing. I often have to feed them the information in very small and easy to digest portions. I so dislike that.

Passing on what an ancient greybread told me. He said look at it as a Noisy system (signal is always lower than noise no matter what you do) with bounded chimps inside it.

Bounded meaning there are upper limits to what anyone can do. And there are upper limits to how frequently model updates of the chimp brain can happen per unit time. And the limits of a group are much lower. At the extreme end Large institutions once they settle on a model of reality can take decades to radically update it. Even if all signs say reality has totally changed.

So with those constraints in mind decide what you want to spend your energy and time on.

Yeah. It's just some random self-help piece. But slightly worse, as at least self-help books would provide some examples.

> Communicating effectively is the central problem of all humanity!

If that were true, there'd be something about it in the Bible.

I am a developer, I also have worked enough other jobs to know how important communication is and how bad developers can be at it.

A typical pattern I recognized is that many developers communicate like bad medical doctors: they do "Mhh, Ahh" and then after a way to short period they fire out a diagnosis of what you need, sometimes without you even having said everything relevant yet.

It is nothing new that people in software are at times not the best communicators. For the first part the interesting bit isn't what your clients want, it is what they need. Unless they are the usually rare customer that has a good understanding of how software could solve their problem elegantly, you will have to assume it was someone's job to come up with something and that someone has never written or thought a lot about software before. That doesn't mean their ideas are worthless, but it means the work of finding the requirements and coming up with a solution is usually not done when you arrive. And the way to get it done is communication, by observation and by having them explain the processes.

Many software developers are in fact really not listening in my experience. Not that developers are the only people that happens to, doctors or other technicians also come to mind. They are often trying to quickly come across as competent by showing off their good grasp of the subject. To them you are a clear case of some category of problem they have dealt with a hundred times. This can work for them.. Until it does not.

> Or maybe we're spending too much time on communicating.

This is a phenomena I have yet to experience in the wild.

> Cut all the unnecessary meetings and only allocate the minimum viable time to communicate.

Most meetings are not about communication. They are usually prescriptive in form and dictatorial in nature.

> Then everyone will be listening.

Listening is a skill, one which is can be perfected if practiced. Neither meetings nor their duration are contributory to this skill.

  Most meetings are not about communication. They are usually 
  prescriptive in form and dictatorial in nature.

  Listening is a skill, one which is can be perfected if practiced.

  Most meetings are not about communication. They are usually 
  prescriptive in form and dictatorial in nature.

  Or maybe we're spending too much time on communicating.

  If too much time is allocated then its hard to stay focused 
  and there's always the next time that can be used to 
  clarify.

  Cut all the unnecessary meetings and only allocate the 
  minimum viable time to communicate. Then everyone will be 
  listening.

  ... we all spend way too much time in useless meetings where 
  nothing happens ...

I’ve been in so many meetings where the outcome is to plan another meeting, and include even more folks. Whichever team brings the most folks steers the decision in their favor, and thus manages hire more unnecessary employees for political will (which then increases the need for even more meetings).

The way out is creating a singular vision (eg leadership) and assigning teams goals they can work independently on towards that vision. It is to remove dependences between teams (and thus the need for them to communicate as much), not to increase communication or Jira tickets or Gantt charts or RACI matrices.

In my experience in software architecture, drawing a diagram often saves you >60 minutes of discussion and potentially multiple meetings. This works even with a badly drawn but truthful one.

Use an Ai agent + Mermaid.js for a quick scribble if you are in a remote meeting. Use white boards or pen + paper in a local meeting.

Diagrams are so much clearer then words, especially if the concept or logic in question is not trivial.

Spending time "on" communicating is not the same thing as communicating.

I think this is, more often, that we are spending too much time pretending to communicate. Far too often I've found myself in a meeting that doesn't have a quorum, but people try to have the meeting anyway. Even more often than that, I've found myself in a meeting that doesn't have the sufficient pre-requisites to be useful. It will just be some AI slop document dropped in front of folks, with little to no regard for coherent thought or responsibility. It's 30 minutes of gaslighting the readers, trying to make them feel stupid for "not getting it", followed by 10 minutes of "this meeting was a waste of time" course-correction (we read our docs in the beginning of meetings).

And the problem is that the communication (or alignment) is the thing that the meeting is supposed to be about, sharing well-considered thoughts and cohesive direction, soliciting meaningful feedback against clearly-articulated assertions. Instead, we're all-to-often addressing someone's attempt to turn their job into a group project, the stone soup of the modern business world. You can lay this bare by asking "what is the aim of this meeting?" early on, to level-set that the meeting owner isn't just setting up a study group.

Birds-eye-view-only managers only see work get done in meetings, so they assume that the meeting is where the work gets done. They don't understand all of the work that went into what came before the meeting to make it a successful one. If you rush the "communication" before you've found the clarity of thought, your meeting is just noise.

There's a simple but powerful response to this sort of persistent malaise, one that strikes fear in the hearts of the secretly inept: "I don't know, but let's figure it out right now."

When it's time to slow down and walk through the problem, I hold folks to an ordering of dependency: Why, What, How, Who, When... If you don't know all of the things before (e.g., Why, What, How - if you're trying to figure out Who), you cannot proceed. I don't care if you're an intern or a VP. No short-cuts to bullshit hand-wavy answers.

Decompose the problem, do the thinking, reason through it right there, and, if the team doesn't change its behavior, find another team. In the right environment, some folks are willing and able to step up to the plate and act like grown-ups working together to craft something better. Sadly, quite a few can't (or won't) answer the call to be responsible adults.

So they call another agenda-less meeting.

This is kind of the exact thing the article is about though. They're not "failing to understand" costs - they just have different context. Your job is to help them make informed tradeoffs, not to expect them to already know what things cost before asking.

In these situations, the non-technical people don’t understand the costs, the technical people don’t understand the benefits. The communication from both sides is needed to find a good cost-to-benefit tradeoff

That cost has now gone way down, with AI doing that code thing. Love it or hate it, that is the reality.

>> Tonnes of frameworks around this concept, so I won't repeat what others have done ...

> Totally understand, but I would love if the author included links to these other things for articles/etc they thought did a good enough job not to repeat them!

I believe the author identified the primary remedy in the article:

  The problem isn't that you need a better system. The 
  problem is you're avoiding doing the work.

Strangely, even more annoying than the "I I I I" articles that reeks of narcissism.

Judging people doesn’t imply bad faith. We are all judging people all the time. It takes constant effort trying to be self-aware of it and trying to compensate for it.