Stop trying to engineer your way out of listening to people
Engineers, managers, and UX practitioners wrestle here with why so many projects fail not for technical reasons but because people don’t actually listen to each other. Commenters argue over whether the real problem is too many meetings or too little meaningful communication, how judgment and defensiveness shut down understanding, and who bears responsibility for translating between technical and non-technical perspectives. Several note that AI tools and superficial documentation are amplifying misalignment, making deliberate, empathetic listening and clearer, audience-aware writing more critical than ever.
Frameworks vs. “Doing the Work”
- Some wanted links to frameworks mentioned (Jobs To Be Done, ODI, empathy mapping); others argued that chasing better systems is itself avoidance.
- A recurring theme: the real problem is reluctance to do messy human work (listening, clarifying, iterating), not lack of methodology.
Meetings, Communication, and (Not) Listening
- Many see organizations drowning in meetings that don’t communicate: prescriptive, status‑gathering, or political rather than collaborative.
- Debate: is the solution fewer meetings, or better ones? One camp stresses cutting “unnecessary” sessions; another says quantity isn’t the issue, effectiveness is.
- Diagrams and simple design docs are praised as high‑leverage tools that can replace long circular discussions.
Tone, Judgment, and Bad Faith
- Some found the article’s listicle section vent‑like, condescending, or hostile (especially around “judging people”), and stopped reading.
- Others countered that calling out judging and dismissiveness is valid and common in practice.
- There’s disagreement over how much to assume good faith vs. recognizing genuine bad‑faith actors.
Developers, Specialization, and Communication Gaps
- Several criticize developers (and other specialists) for “logic bullying,” premature diagnosis, and not listening to what users actually need.
- The “specialism effect”: users aren’t ignorant, they’re expert in something else; their mental models differ, not their intelligence.
- Some push back that communication is a shared responsibility, and engineers are unfairly blamed for UX and requirements failures.
Requirements, Costs, and Tradeoffs
- Non‑technical stakeholders often request features without understanding cost; technical people often fail to probe for actual underlying needs.
- Good practice described: ask “What do you need to do?”; align expectations on cost, timelines, and realistic scope; question over‑specified or gold‑plated requests.
Documentation, Not-Reading, and AI Distortion
- Strong frustration that people don’t read tickets, docs, or emails; documentation is demanded, then ignored.
- Some accept this as a constant: assume no one reads, be ready to re‑explain patiently.
- Multiple stories of AI‑summarized or AI‑rewritten docs introducing incorrect endpoints, features, or omissions, causing confusion and anger.
- Concern that AI “smoothing” for readability erodes precision, hides nuance, and may worsen communication overall.
Listening, Vulnerability, and Limits of Persuasion
- Listening is framed as a vulnerable act: being open to having one’s beliefs challenged.
- Some argue many people simply won’t accept truths that threaten their worldview; others insist discussion and evidence can sometimes change minds.
- Advice: recognize when persuasion is futile to avoid damaging relationships or wasting time.