Stop trying to engineer your way out of listening to people

The points in # 2 are profound. I plan on sending this to someone who is dear to me. Maybe he will "listen" to it, too.

Thank you.

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

> Listening often means not jumping to a solution; but absorbing and processing someone’s pain

> When in actuality, they should [...] finding a way to solve the pain points

Honest question, how do I 'absorb someones pain'? And how do I transition from that into eventually formulating the feature/ticket?

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

You must be in a position to be convinced yourself, in order to be convincing.

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

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

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

ive listened my fair share . sometimes ppl get stuck in cogitation . especially around their pain points . having someone throw them off by implementing a solution helps reframe their thoughts . we discuss the solution instead . on the other hand, my empathy may come off as lacking .

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

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.

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.

> Communicating effectively is the central problem of all humanity!

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

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

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

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

What I say: This is not ready for production.

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

There is a very weird and a very awesome soviet-era movie Kin-dza-dza. At one point one of the characters tells this about the other: "he says things what he does not think, and he thinks things what he does not think."

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

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.

So you estimate costs in months and dollars, and give that in response to each. Very solvable issue.

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.

> If you - who need the product and are ready to pay for it - don't take your damn time to effectively articulate what are your needs then you should go to school again and learn it.

Instead they will go and buy a product that was made by engineers who asked them "what they actually need" and "how can we make it easier for you".

It's not about "why should I always care, I have enough". It's about "who will make better product and earn more money".

> By the way, since you all non-engineer people are so good at communicating, why are you not communicating effectively your needs?

They are good at socialising, blurting out words at each other and they think it's good communicating (it's emotional reassurance of eachother, not a technical facts exchange, but it's still their valid need), but when you say that to them, they are upset and don't want to buy a product from you. Don't tell that to their faces. Of course, if you want to do something and don't want people to buy it, do follow on what you wrote.

That's what I started doing in my company, encouraging the use of AI to polish prototypes and communication before handing it to the tech team smooths out alot of issues while exloring the solution space.

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.

> Assuming bad faith immediately kills all productivity, so there's no point in finishing reading this.

First, the author is not assuming bad faith. They are saying that judging people is common pitfall. And the "hating or dismissing people for misunderstanding the thing you documented badly" is something I have seen done so many times, that yep, it exists.

But second unrelated thing is, sometimes there is a bad faith. Refusing to accept that bad faith situation can happen just makes it massively harder to solve the issue. It empowers the person acting in bad faith.