12 ms·

Stop trying to engineer your way out of listening to people

• buggy6257 6mo ago
  > Tonnes of frameworks around this concept, so I won't repeat what others have done decently already. Jobs To Be Done, Outcome Driven Innovation, and in the UX camp, empathy mapping. 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!
  • AdieuToLogic 6mo ago
    >> 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.
• measurablefunc 6mo ago
  I was just working on this product & now I have to scrap it: https://www.theguardian.com/technology/2026/apr/13/meta-ai-mark-zuckerberg-staff-talk-to-the-boss https://www.theguardian.com/technology/2026/apr/13/meta-ai-m...
• heyalexhsu 6mo ago
  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.
  • AdieuToLogic 6mo ago
    > 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.
    • colechristensen 6mo ago
      You've missed the point and agreed with the GP. Too much time is spent attempting to communicate and as such, communication isn't actually happening. (i.e. we all spend way too much time in useless meetings where nothing happens and few people are any more informed than they were before)
      • c0balt 6mo ago
        Maybe this is just my interpretation but OP effectively argued "too many ineffective meetings, we should have less unnecessary meetings and a clearer, independent direction". The commenter above argued that the problem was slightly different, it's not too many meetings for communication but too many that are not achieving effective communication. A meeting in itself does not create communication (of information and exchange of opinions etc.) and the commenter wanted to increase the number of meaningful meetings instead of/in addition to just cutting down meetings by numbers. The criticism of not enough time spent on communication is in the same vein, both agree on the issue of "too many unnecessary meetings".
        • colechristensen 6mo ago
          Y'all are saying the same thing over and over with slightly different words proposing that the different way of saying it has a meaningful impact on the message. It doesn't. >"too many ineffective meetings, we should have less unnecessary meetings and a clearer, independent direction". >it's not too many meetings for communication but too many that are not achieving effective communication ^^ there's no meaningful distinction between those two, discussions that devolve into such things suck all potential value out of a thread.
  • twelfthnight 6mo ago
    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.
    • atomicnumber3 6mo ago
      Critical issue is that it expects leaders to actually lead. Common yet fatal flaw in many plans.
  • chaboud 6mo ago
    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.
  • mixermachine 6mo ago
    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.
    • mechsy 6mo ago
      Yes, it helps to keep the bigger picture (pun intended) in focus and something tangible to criticise. Same for design docs. Otherwise, the conversation‘s spotlight just keeps moving around and might even follow whatever thread one of the more prolific speakers just came up with, which carries the danger of derailing the whole thing and adjourning without a decision.
    • UK-Al05 6mo ago
      I have feedback in the past that people don't like diagrams upfront, because it presents a finished solution.
  • bawolff 6mo ago
    Spending time "on" communicating is not the same thing as communicating.
• sublinear 6mo ago
  > 8. You judge people You know, I was actually hoping for a good listicle of things to watch out for in meetings. The author should take their own advice. Assuming bad faith immediately kills all productivity, so there's no point in finishing reading this. I agree with the general notion that there are often knowledge gaps getting in the way of better planning and execution. I was hoping for techniques to overcome them, but (sigh) I guess that's just more "engineering" getting in the way. I've been doing this for long enough to realize there's no substitute for experience. It's basically the opposite of all the popular advice. If you're serious about any successful long-term career, you can't avoid looking foolish and having lots of difficult discussions. There are no shortcuts. There is no "higher path" you're missing out on. If you're going to grind it out, at least save face by working at the "shitty places" with bad reviews on glassdoor where you can safely fail without damage to your ego or reputation. When you finally get hired somewhere nicer mid-career, you can just bury all that in your mind and pretend it never happened. Nobody cares anyway. If we're going to be judgy, I gotta say some of the worst people I've ever worked with never got out of that phase. It's that simple.
  • layer8 6mo ago
    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.
    • sublinear 6mo ago
      Oh the author continued by saying: "Stop assuming they are bad at their job or their lives". This was too absurd and hostile for me to continue listening. I asked myself whether I thought the author was bad at writing, and realized I fell into their trap. I asked myself how lost and angry someone has to be to write crap like this, and realized I did it again. Some people have a real knack for being so defensive and insecure that they invite their own pain. They unwittingly coerce people who meant them no harm into doing so. Everyone is a victim for trying to take this blog post seriously.
      • 6mo ago
• yownie 6mo ago
  [flagged]
• apsurd 6mo ago
  Agree with the problem but this list reads like a vent. Communicating effectively is the central problem of all humanity! This vent criticizes developers for not knowing how to listen. that's why it comes off condescending. The root problem is that people don't know what they don't know. The best communicators are translators. People listen because the message becomes self evident in their understanding. It's hardly a breakdown because everyone is acting like a toddler with their fingers in their ears. This is ironically why we reach for systems and engineering. The system can build in gap detection and frameworks for translation. It's not perfect and creates its own problems but scolding each unit human to listen better does nothing for the collective environment: the team, the company… the system.
  • raincole 6mo ago
    Yeah. It's just some random self-help piece. But slightly worse, as at least self-help books would provide some examples.
  • huswepcc 6mo ago
    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.
    • apsurd 6mo ago
      Sounds like innovator's dilemma + a quote i saw recently: Former UK Prime Minister Margaret Thatcher: “Consensus ... is the process of avoiding the very issues that have to be solved.” I buy that inevitably the system becomes it's own constraint and local optimum. But working together is a practical reality too. Worth making the best of.
  • 6mo ago
• nlawalker 6mo ago
  >And if you're wondering why this happens, it's normally because: 1. people aren't talking to people 2. people aren't listening I don't think this is right; I think the reason is - to use the metaphor from the cartoon image at the top - that what most of the people involved in the not talking and/or not listening were looking to get out of the situation in the first place was the ribbon cutting, not the road, and they got it.
• HumbleBot 6mo ago
  [dead]
• onion2k 6mo ago
  You assume what they say is the same as what they are thinking The converse is also true. People saying something assume that people listening are understanding and thinking about the same thing. This is why it's important to write things down in details and as-unambiguous-as-you-can forms. If you're in a meeting and someone puts up a slide deck with a 6 word bullet point that 'explains' what they want, that is a signal that literally no one understands the goal. If they put in a meeting without writing a one page doc about it, they don't understand it well enough to explain it. And if your progression hangs off delivering that thing, you should by demanding that you get a clearer picture.
  • nomel 6mo ago
    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).
    • lelanthran 6mo ago
      > 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. I've had a lot of success by shortcutting the refinement/request sessions with clients by simply asking "What is it you need to do?". Due to an esclation from a client, I joined a meeting with a dev and a client to try and figure out why a single report is taking over a month to deliver. Dev reported (privately) to me that the client keeps changing their mind about what needs to be in the final report. When I finally asked the client my magic question, it turns out they may not even need that specific report anyway - they're just not sure what can be retrieved, so they wanted one single report for every single thing they may want to do, now and in the future, attempting to squish hierarchical data and tabular data from SQL queries into a single gigantic report. There's no way the dev was ever going to have a finished report for them. I broke it down into several simpler reports, some of which already exist, which turned a very frustrated client into, well, not exactly happy, but at least they are less frustrated now. They have some of the data generated daily now, and we can do the other stuff as and when they see a need for those reports.
• faangguyindia 6mo ago
  Most of the problem is that talking to non technical people is frustrating, they often start like 1. Can u add X 2. Can u change Y Without understanding cost of doing all this. Yes, i can do all and everything you ask for, but each action has a cost, which you fail to understand. We cannot do everything if we need to launch a reliable product.
  • fragmede 6mo ago
    That cost has now gone way down, with AI doing that code thing. Love it or hate it, that is the reality.
    • faangguyindia 6mo ago
      i've all AI subscription, cost is definitely down but risks aren't. You can still break things, you can make mistakes.
    • mavamaarten 6mo ago
      Has it, though? There's still features that bring large user value and require 10 lines of code, and features that bring a small user value and require AI to burn tokens on huge refactors and babying to make sure it doesn't break anything.
  • ethan_smith 6mo ago
    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.
    • faangguyindia 6mo ago
      it's not possible to make everyone understand nuclear physics, there is certain threshold of cognitive skills/motivation required for that.
      • 6mo ago
• hyfgfh 6mo ago
  Get ready for the not reading, between people asking for AI and the slop everyone is writing Today communication will only get worst. Talking to a 'yes and autocomplete' that will agree with everything you say and praise it as a "Great idea!" will make everything terrible
• yogigan 6mo ago
  The point about "specialism effect" is underrated. I've caught myself frustrated at users for not understanding something I've spent years internalizing. The problem is: they've spent those same years internalizing something else entirely. Their knowledge isn't absent, it's just elsewhere.
• deleted 6mo ago
  [deleted]
• lordkrandel 6mo ago
  You you you you. A rant article
  • hnfong 6mo ago
    Strangely, even more annoying than the "I I I I" articles that reeks of narcissism.
• BLKNSLVR 6mo ago
  Related, I think, and I found TFA a very interesting read: https://news.ycombinator.com/item?id=23617188 https://news.ycombinator.com/item?id=23617188
• sandeepkd 6mo ago
  Its hard to make it useful. Maybe I am not the right audience for this type of content, or I was trying to find something concrete in it related to my own experience
• Animats 6mo ago
  From the title, I thought this was going to be about customer support, or non-support. A good article about the costs of not listening to your customers would be useful.
• big-chungus4 6mo ago
  I completely agree with the list but I can't lie, I did not understand how it is related to the title and first part of the article, and to "listening to people". But I'm also stupid so that could be why
• _rpf 6mo ago
  Anyone else catch Rimmer's study timetable? (Procrastination, Red Dwarf reference)
• digi59404 6mo ago
  Even here in the comments you see people who have read this article and fall victim to the very things it’s pointing out. It’s ironic. Let me add a couple to this list. 1. No amount of knowledge or discussion will make a person accept something they don’t want to accept. 2. To truly listen means to place yourself mentally and physically in a vulnerable state. Because you will likely hear things that run contrary to your experience, beliefs, and worldview. Judging people is often a self protection mechanism; which means you will almost never listen to someone. 3. Listening often means not jumping to a solution; but absorbing and processing someone’s pain. Product managers for example are quick to jump to a solution, a new feature, or they’ll push the request off as “oh, ok, we’ll make a ticket for that ” When in actuality, they should be listening to the use case, looking for the pain, and finding a way to solve the pain points. As opposed to trying to understand what feature the user wants to request.
  • ImHereToVote 6mo ago
    You must be in a position to be convinced yourself, in order to be convincing.
    • tmoertel 6mo ago
      > You must be in a position to be convinced yourself, in order to be convincing. This claim is demonstrably untrue. Do you believe that a written argument cannot be convincing? Or do you believe that when you read a written argument, your beliefs can somehow be transmitted back to the author, even if the author is long dead, and be convincing in that author’s mind?
  • jdthedisciple 6mo ago
    > 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.
    • close04 6mo ago
      More than that, sometimes one side doesn’t want to accept something because everything they know about it says it’s wrong. Then they’re faced with evidence and reason prevails. I usually have very strong opinions but try to hold on to them very loosely. It happened that I was convinced with evidence that I am right and refused to accept any alternative until new evidence slapped me in the face. At that point knowledge and discussion made me accept something I had previously thought preposterous, sometimes to the point of outright dismissing any conversation, this is how preposterous the proposition sounded at first sight. What I want to say is that if you don’t know your audience, if you don’t know for sure your attempts are fruitless, it’s always worth a shot to use your knowledge in a discussion and let the other party digest that and see if it that moves the needle.
• adilkhanovkz 6mo ago
  Interesting. That really resonates. )) I think this is especially relevant for mid level specialists who have recently learned a lot and feel the need to speak up and show off what they know =D. But it’s also relevant for highly knowledgeable people who are truly well-read and versatile. I think it's a mistake that such people often stop even listening to those who are less well-read or less experienced in a subject; they prefer to adopt the position of the 'source of truth' and the teacher. Although, it seems to me that people who are less 'biased' by extensive reading often come up with original—perhaps unpolished, but original ideas. To hear those ideas, you have to know how to listen and extract thoughts rather than suppress them."
• rrgok 6mo ago
  I have better a idea, since everybody need an engineer to build the damn thing, how about we teach non engineer people to talk to engineer people. Why is it always our burden to learn and improve. UX problem, blame the engineer. Comunication problem, blame the engineer. Documentation problem, blame the engineer. I'm so sick of it. Comunication is a tango. 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. By the way, since you all non-engineer people are so good at communicating, why are you not communicating effectively your needs? Bring on the down votes.
  • yetihehe 6mo ago
    > 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.
    • watwut 6mo ago
      > 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". That sort of decision making is not done by engineers. You are blaming engineers about product decisions made by management, product management, UIX design, analysts ...
      • rrgok 6mo ago
• tejasg910 6mo ago
  [dead]
• nialse 6mo ago
  [dead]
• lelanthran 6mo ago
  My major role is as a customer relationship manager; the most important thing is to align the customer's expectation with reality. Once a customer's expectation is in-line with with can be done, and how long that will take, and how much it will cost, and when it can be used in production, you have one happy customer, even if they are unhappy with the projected start date, or the projected cost (generally a deal-breaker, so that's why I align that upfront with ballparks). You can listen all you want, empathise all you want, but the reality is the reality - they have to acknowledge and/or accept the realities. Having a customer relationship manager who agrees to everything the client wants is going to result in one very unhappy customer. The customer-interface person needs to listen to both the client and the internal team, to make sure what the client expects is what your team can actually deliver.
• watwut 6mo ago
  > Stop hating or dismissing people for misunderstanding the thing you documented badly. Lol on this one. I mean, yes, it is true, but also funny.
• spwa4 6mo ago
  No. This will get worse. A LOT worse. Remember all the discussion about how no human contact was a big improvement in the Waymo/Tesla/robotaxi discussions?
• interstice 6mo ago
  > "A lot of people say they say what they mean but actually aren't doing that." Funniest experience I've had with this is paraphrasing someone almost exactly in a reply to check I understood, and emphatically being told that was absolutely not what was being said.
• donatj 6mo ago
  I tend to be very exacting in my word choice. If I used a specific word, I meant it. Many people I find speak in what I would describe as tone poems. They circle around an idea using whatever word is within reach, and expect you to understand the meaning based on shared connotations. These people are tiring to interpret. When I write something, each and every word was chosen specifically and with intention. The number of times I see my words interpreted as though my choice in words had been imprecise is a near constant source of pain, particularly in the workspace. I might be on the spectrum, I am undiagnosed. About six months ago I was tasked with building a little RPC for a different division to be able to kick off a long running process and documenting it for them. The documentation was complete, correct, and relatively terse. Less than a page. I sent my manager the documentation to pass on, and for reasons I will never understand he passed it through AI before handing it over to the other department. No one informed me. Within a day I start getting feedback that makes zero sense. Seemingly no one can get the RPC to work. I had tested this extensively, the complaints made zero sense. One of the complaints includes the actual request being made and the endpoint is entirely wrong. Not a single character typo, a complete fabrication. I ask where this came from and they point me to the documentation they were sent. Every single thing was wrong. The endpoints were wrong, the required parameters were wrong, there were invented features that do not exist. I am a very easy going guy, and I have genuinely never been so furious in my entire life. I am still angry as I write this. If the job market were not what it is I would have quit there and then. I feel like people using AI to both read and interpret language is the death of rigorous language. I have genuinely been pondering for months if generative AI is the "Great Filter" preventing space faring civilizations from flourishing. Around the same time a civilization begins to enter space they invent a device that destroys their minds.
  • mjburgess 6mo ago
    Perhaps you should ask the manager why he passed it through AI. It might be that with precision, readability is lost. It's a tradeoff: the more compressed your language is, and hence the more precise, the more cognitive effort you require the reader to expend on each word. Reading is a translation from your mental model, as expressed in words, to the readers mental model. Words alone don't perform this translation, the act of reading and interpreting does so. With your concision you give no help to the reader in this process. One suspicion I have is that your one-pager was passed through AI because it was too terse to serve the job of aiding the general reader in obtaining an understanding of the topic for themselves. Writing to be read by an audience is a vastly different activity than writing notes that merely, precisely, document for the maximally informed highest-context reader (or one willing to do the work of reassembling this context during reading). When you're writing for others, especially a "generic other", you're expected to adopt their uninformed, low-context, high-difficulty reading position, and fill-out the prose in an aid to their understanding. This will involve: repetition (restatement with different words and ideas), illustration with simple examples, grounding in examples most likely to be familiar to them, explicit statement of steps/procedures/processes that breakdown topics/actions into small units which are each easy to immediately understand, possibly: some humor to break the effort of reading, some asides which engage or interest the reader, some context which makes the reading reelvant to them so they will be willing to expend the effort to read it.
• abstractdev 6mo ago
  [flagged]
• throw4847285 6mo ago
  Is there an equivalent to Betteridge's law of headlines that applies in situations like this? When the title of an article is "Don't do this" the comments are entirely people doing that.
• alvis 6mo ago
  This also apply to talking to your wife too.
• mansunyun 6mo ago
  [dead]
• theo1996 6mo ago
  I dont care what you have to say you are not worth my time in 99.99% of circumstances.
• deleted 6mo ago
  [deleted]
• hannahstrawbrry 6mo ago
  If you are a student/young engineer, this piece of advice is some of the best you can get: "...thinking of people with the binary of "technical" and "non-technical", you definitely will be missing insights and most likely, you're not listening properly." Especially for interns within large multifunctional companies- I have seen a hundred times over how some very bright engineers will start to sniff out who they have decided is or isn't technical and try to avoid the non-technical team members. You might get some kudos from other engineers but it won't compare to the praises analysts will sing when they finally get the technical attention they have needed for a year or more.