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.
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.
What a privilige it must be to be able to have a job where you can stand up and leave when your psyche can't handle it. Ever done tech support for ten hours a day? :)
"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. :)
Without effort there is rarely a big effort. You have to listen to achieve better results. If you don't listen, your results will be misaligned. Unfortunately no one can guarantee that you won't be abused. You have to ask yourself if the risk of being abused is worth the result (typical result: bigger money for a better program).
Id guess by your smile there is an element of humor in your response, so this isn't a rebuttal, but rather i identified a lot with your point, and I was thinking that this is such a human response to vulnerability.
If it was guaranteed that it will not be abused or that I would regret it, it would not _be_ vulnerable. Just like its not bravery if I am not afraid or I am assured of my safety. Such a paradox. Being vulnerable for me is acknowledging that it might have an increased probability of a more negative outcome, but still trying to be vulnerable because of the huge connection unlocks that (often) occur in my experience.
On balance intellectually i am coming to see the expected value from being vulnerable in communications is high, but my little lizard brain keeps saying to me "what if you get hurt though" and being closed off haha. its an exercise to shut it up.
I've had the privilege to have been more than half a century on this planet and my experience has not been super great regarding being vulnerable. It takes great skill to not have it mentally affect you. Even if you get ten thousand positive results, a mere two bad results will affect you even more. Nevertheless i agreee it is always better to start with empathy.
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 .
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.
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.
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.
It is! If I contort a little, the Tower of Babel is the communication problem in reverse. But original sin means we're born sinners so towards effective communication is toward God. But that's not the point of life, the point is serving God as a sinner for salvation (bible stuff, not my point).
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.
Yes, all said, developers likely are the worst communicators because they over index on their self-ascribed strengths: logic (and logic bullying). Not so much because they aren't smart or capable.
But singling out specific archetypes is an obvious contradiction of the article, which is weird. Author is in the UX design space so likely has particular lived experience with specifically eng orgs.
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.
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).
> 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.
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.
If there is a tech-person problem it is this one. I constantly have to interrupt collegues when they try to explain a thing as their explaination attempts are usually way too low level or even bordering on being self-referential. So they explain the concept by using other concepts the listener won't understand either.
In my opinion it all boils down to a lack of ability to remember how one felt before understanding a certain concept. If you did you would have an empathic understanding of how word-salady a lot of the explainations are.
The first thing you need to tell a uninitiated person is simply where to generally put it and how they already know it. If you explain DNS for example you explain it via the domains they know and how it is like a contacts list for webservers so your browser knows where to look when looking for google.com.
Whenever you explain anything you might want to ask yourself why the other side should even begin to care and how it connects to their life and existing knowledge. What problem did it originally intend to solve?
When I taught I often thought of it as explaining in a spiral: first I must go around the concept, before I can dive in to the concept. Going around gives boundary and definition to what I'm talking about, allowing people to place it in the proper spot in their mental framework and to relate it with other nearby things. It also gives some motivation for what this thing is and why they should care. Then when that is done (and it does not take long), the details can be discussed, and they're easier to communicate because people are primed to receive them.
> 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.
Nobody reads the docs, tickets, or comments under a task, nobody really checks the code they are reviewing, and nowadays thanks to AI, some people don’t even read the code they “write”.
People love to ask for documentation, as long as it doesn’t exist. It lets them off the hook, “oh I would have known what to do, I wish we had this documented”. Then you point it out that you have it documented with video walkthrough, asked the team to read it and give feedback multiple times, and nobody gave a f.
Managers ask detailed questions about the IC’s tasks and priorities, only to forget it half an hour later and ask again and again.
I don’t see the point of fighting this, I’m sure I do the same to some degree. You just need to assume nobody reads anything and nobody listens or remembers anything, so be patient and explain everything every time… at least I don’t have a better strategy.
I’ve been at it 18 years for different organisations and my experience and strategy is the same as yours.
No one bothers to read/understand anything until the very last minute, then they realise “oh shit this won’t work in this scenario, and it’s always a showstopper”…
But what about my impression that it is getting worse? When I (as a developer) was trying to help customers with the product 20 years ago, about 50% (my guesstimate) of the people were actually reading what I wrote, at least to a good degree. These days I am lucky if it is 20% who are reading answers to their problems more than in a completely superficial way. I blame social media and smartphones.
I think the quality of comms is definitely getting worse, I work for myself now and I am very selective of clients now. So I don’t butt heads against it as much, but it still happens despite best efforts, especially when people move on or even go on vacation.
Literacy skills have been falling and it shows up in testing of a lot of different countries, and it basically lines up with the arrival of iPhone/Android(or real smart phones).
> Managers ask detailed questions about the IC’s tasks and priorities
I've told the various teams that I wouldn't have to phone anyone if they updated the ticket. When I see a ticket that has not been updated for 2 months, there's no way I'm not phoning the assigned person.
Problem is that, even when I was a f/time IC, we hardly ever update the ticket unless we feel we have made progress. An update saying "Chased bug with no success $TODAY, requested $SENIOR to consult with me on this" feels like a worthless ticket update, but from the client's PoV, this is valuable info - it means that it hasn't dropped off our radar, we haven't forgotten about it, etc.
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.
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".
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.
The distinction is explicit in the statements you quoted. One is advocating for lessening the number of meetings. One is saying that won't help, and instead advocating for increasing the quality of meetings.
* Acknowledging that too many meetings are ineffective
* Suggesting reducing the number of inneffective meetings
* Saying there needs to be clearer, independent direction
The second is:
* Stating that there are not too many meetings in general (the first says nothing about this)
* Acknowledging that too many meetings are ineffective (same as bullet 1 of the first sentence)
* Not suggesting how to address either problem
I agree with GP. There is no meaningful distinction between the 2, but the first suggests 2 ways to solve the problem of ineffective meetings whereas the second simply acknowledges the existing of problems.
I don't think "attempting to communicate" - or especially not "attempting to LISTEN" as in the title here - would be the stated reason for many meetings. "Pitching people on your shit" or "making sure shit gets done the way management wants it to" is much more accurate for most corporate dev and B2B/B2C sales/product meetings.
For the typical "agile" process for software:
- standup: this fits, attempting to communicate status and request help with blockers
- backlog grooming: attempting to figure out what to do with artifacts of generally-async communication (tickets from a backlog, either created by you in the past or by others). attempting to fit them into the process best. Communication is often seen as a necessary evil, and this process often goes faster with fewer people. if people bring up questions, there may be some attempts to communicate in explanations.
- sprint planning: work assignment and time management/estimations. similar to above, questions could spark attempts to communicate, but it's not the primary purpose.
- sprint retro: improve the team dynamics and the flow of the process. communication is usually assumed here, but in practice it's "people saying things, they get written down, then the next sprint happens same as the last." there often isn't effective communication to the people who could change things
I think if the goal of meetings was more specifically "we are going to communicate until our mental pictures are exactly the same" you'd end up with faster/better actual work from everyone on the team.
But in big orgs that's usually not even what's wanted. If the plan sucks, but it's a VP's pet project, it's not good for various whole teams in that org to all effectively communicate with each other to realize it sucks but not have the political skills or pull to change the VP's mind...
> Too much time is spent attempting to communicate and as such, communication isn't actually happening.
This is where I think we have a different definition of communication.
> (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)
Hence my clarification of:
Most meetings are not about communication. They are usually
prescriptive in form and dictatorial in nature.
For example, if a project kick-off meeting consists of the highest ranking managers talking and everyone else having no contribution, listen to what they are saying; their "vision" is all that matters.
Another example is when product and/or engineer managers use "stand-ups" to ask each engineer the status of their deliverables. Listen to what they are saying; we micromanage and do not trust the team.
Listening is a skill, one which is can be perfected if practiced.
> Standard philosophical problem, you're disagreeing about the definition of a word instead of the content of the message.
Perhaps I should have said we have a different understanding or expectation of communication, instead of "definition." For this confusion I introduced, I apologize.
> Clearly you agree with OP about how time is wasted but you're insisting on using different language to express the same idea.
I do not.
Again, as I previously self-quoted:
Most meetings are not about communication. They are usually
prescriptive in form and dictatorial in nature.
OP postulated:
Or maybe we're spending too much time on communicating.
To which I disagreed. OP then opined:
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.
Which is an indirect reference to meetings, not communication.
Finally, OP concluded with:
Cut all the unnecessary meetings and only allocate the
minimum viable time to communicate. Then everyone will be
listening.
Which erroneously correlates meetings with listening. Your original response included:
... we all spend way too much time in useless meetings where
nothing happens ...
Thus reinforcing said erroneous correlation. I blame myself for insufficiently expressing my thoughts on the difference between listening, which is implicit in communication and the topic of the article, and meetings, which are an assembly of people requiring only physical presence.
That's certainly one way of looking at daily stand-up. The other way is that humans aren't perfectly spherical communicators so sometimes daily stand-up really does manage to bring up blockers for the manager to actually resolve.
> This is a phenomena I have yet to experience in the wild.
I have totally seen infinite meetings where nothing is achieved, nothing is really said, but someone socially isolate just talks and talks and talks because it is his only chance to interact.
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.
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.
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.
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.
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.
>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>
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.
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.
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."
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.
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.
The people involved in commissioning and funding nuclear power plants don't understand nuclear physics either.
The customer doesn't need to understand how the solution works, as long as they can understand that it would solve their problem (in the case of the power plant: producing "clean" energy) and any potential drawbacks or limitations (in the case of the power plant: the waste byproduct).
The point here is that as a "tech person", it's your job to help the customer understand the cost of what they're asking, and come up with a satisfactory solution based on your understanding of their needs.
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
> 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!
>> 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.
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
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?
> 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.
> 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 ...
The thing is, neither the software engineers nor the users know wtf should be done completely. Communication across domains is hard.
Let's try a physical items example: have you ever ordered a piece of furniture or other home improvement thing, got exactly what you asked for, professionally done... and then later found out there were better ways to do it (at similar cost) that you hadn't even imagined?
Was it because you didn't know what to ask for? Was it because the experts in home improvement didn't volunteer that there are other options? Was it because they sell one thing and didn't even know there are other options? Did you even ask what options you have or did you just order the thing?
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.
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
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.
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.
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.
> 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.
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.
> 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.
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.
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.
What a privilige it must be to be able to have a job where you can stand up and leave when your psyche can't handle it. Ever done tech support for ten hours a day? :)
"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)
I don't worry about such things, because I have never been in error yet.
"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. :)
Without effort there is rarely a big effort. You have to listen to achieve better results. If you don't listen, your results will be misaligned. Unfortunately no one can guarantee that you won't be abused. You have to ask yourself if the risk of being abused is worth the result (typical result: bigger money for a better program).
Kinda depends on what your position and circle of influence is.
I will admit that sometimes the circle of influence seems bigger than expected though.
Id guess by your smile there is an element of humor in your response, so this isn't a rebuttal, but rather i identified a lot with your point, and I was thinking that this is such a human response to vulnerability.
If it was guaranteed that it will not be abused or that I would regret it, it would not _be_ vulnerable. Just like its not bravery if I am not afraid or I am assured of my safety. Such a paradox. Being vulnerable for me is acknowledging that it might have an increased probability of a more negative outcome, but still trying to be vulnerable because of the huge connection unlocks that (often) occur in my experience.
On balance intellectually i am coming to see the expected value from being vulnerable in communications is high, but my little lizard brain keeps saying to me "what if you get hurt though" and being closed off haha. its an exercise to shut it up.
I've had the privilege to have been more than half a century on this planet and my experience has not been super great regarding being vulnerable. It takes great skill to not have it mentally affect you. Even if you get ten thousand positive results, a mere two bad results will affect you even more. Nevertheless i agreee it is always better to start with empathy.
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 .
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.
Yeah. It's just some random self-help piece. But slightly worse, as at least self-help books would provide some examples.
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.
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.
> Communicating effectively is the central problem of all humanity!
If that were true, there'd be something about it in the Bible.
It is! If I contort a little, the Tower of Babel is the communication problem in reverse. But original sin means we're born sinners so towards effective communication is toward God. But that's not the point of life, the point is serving God as a sinner for salvation (bible stuff, not my point).
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.
Yes, all said, developers likely are the worst communicators because they over index on their self-ascribed strengths: logic (and logic bullying). Not so much because they aren't smart or capable.
But singling out specific archetypes is an obvious contradiction of the article, which is weird. Author is in the UX design space so likely has particular lived experience with specifically eng orgs.
> logic bullying
Wow, you've just described my communication style when I'm angry. So consice yet captures the problem so well
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.
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).
> 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.
What I say: This is not ready for production.
What management hears: We can sell this to the customer for acceptance testing.
What you say: I don’t want to take responsibility.
What management hears: I want someone else to take responsibility for me.
What I say: I want a pay rise.
What management hears: We want more pizza parties.
Nah. Our CEO just fires everyone who asks for a raise because they're a liability now.
FWIW, this is in a country that supposedly hsa really strong unions and worker protections.
> 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.
If there is a tech-person problem it is this one. I constantly have to interrupt collegues when they try to explain a thing as their explaination attempts are usually way too low level or even bordering on being self-referential. So they explain the concept by using other concepts the listener won't understand either.
In my opinion it all boils down to a lack of ability to remember how one felt before understanding a certain concept. If you did you would have an empathic understanding of how word-salady a lot of the explainations are.
The first thing you need to tell a uninitiated person is simply where to generally put it and how they already know it. If you explain DNS for example you explain it via the domains they know and how it is like a contacts list for webservers so your browser knows where to look when looking for google.com.
Whenever you explain anything you might want to ask yourself why the other side should even begin to care and how it connects to their life and existing knowledge. What problem did it originally intend to solve?
Many tech people may start in a different
When I taught I often thought of it as explaining in a spiral: first I must go around the concept, before I can dive in to the concept. Going around gives boundary and definition to what I'm talking about, allowing people to place it in the proper spot in their mental framework and to relate it with other nearby things. It also gives some motivation for what this thing is and why they should care. Then when that is done (and it does not take long), the details can be discussed, and they're easier to communicate because people are primed to receive them.
> 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.
Nobody reads the docs, tickets, or comments under a task, nobody really checks the code they are reviewing, and nowadays thanks to AI, some people don’t even read the code they “write”.
People love to ask for documentation, as long as it doesn’t exist. It lets them off the hook, “oh I would have known what to do, I wish we had this documented”. Then you point it out that you have it documented with video walkthrough, asked the team to read it and give feedback multiple times, and nobody gave a f.
Managers ask detailed questions about the IC’s tasks and priorities, only to forget it half an hour later and ask again and again.
I don’t see the point of fighting this, I’m sure I do the same to some degree. You just need to assume nobody reads anything and nobody listens or remembers anything, so be patient and explain everything every time… at least I don’t have a better strategy.
I’ve been at it 18 years for different organisations and my experience and strategy is the same as yours.
No one bothers to read/understand anything until the very last minute, then they realise “oh shit this won’t work in this scenario, and it’s always a showstopper”…
But what about my impression that it is getting worse? When I (as a developer) was trying to help customers with the product 20 years ago, about 50% (my guesstimate) of the people were actually reading what I wrote, at least to a good degree. These days I am lucky if it is 20% who are reading answers to their problems more than in a completely superficial way. I blame social media and smartphones.
I think the quality of comms is definitely getting worse, I work for myself now and I am very selective of clients now. So I don’t butt heads against it as much, but it still happens despite best efforts, especially when people move on or even go on vacation.
Literacy skills have been falling and it shows up in testing of a lot of different countries, and it basically lines up with the arrival of iPhone/Android(or real smart phones).
> Managers ask detailed questions about the IC’s tasks and priorities
I've told the various teams that I wouldn't have to phone anyone if they updated the ticket. When I see a ticket that has not been updated for 2 months, there's no way I'm not phoning the assigned person.
Problem is that, even when I was a f/time IC, we hardly ever update the ticket unless we feel we have made progress. An update saying "Chased bug with no success $TODAY, requested $SENIOR to consult with me on this" feels like a worthless ticket update, but from the client's PoV, this is valuable info - it means that it hasn't dropped off our radar, we haven't forgotten about it, etc.
People often don't, but AI always does. As we rely on AI more and more, having strong docs will become even more important.
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.
> 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.
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)
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".
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.
The distinction is explicit in the statements you quoted. One is advocating for lessening the number of meetings. One is saying that won't help, and instead advocating for increasing the quality of meetings.
Actually, it isn't.
The first is:
* Acknowledging that too many meetings are ineffective
* Suggesting reducing the number of inneffective meetings
* Saying there needs to be clearer, independent direction
The second is:
* Stating that there are not too many meetings in general (the first says nothing about this)
* Acknowledging that too many meetings are ineffective (same as bullet 1 of the first sentence)
* Not suggesting how to address either problem
I agree with GP. There is no meaningful distinction between the 2, but the first suggests 2 ways to solve the problem of ineffective meetings whereas the second simply acknowledges the existing of problems.
I don't think "attempting to communicate" - or especially not "attempting to LISTEN" as in the title here - would be the stated reason for many meetings. "Pitching people on your shit" or "making sure shit gets done the way management wants it to" is much more accurate for most corporate dev and B2B/B2C sales/product meetings.
For the typical "agile" process for software:
- standup: this fits, attempting to communicate status and request help with blockers
- backlog grooming: attempting to figure out what to do with artifacts of generally-async communication (tickets from a backlog, either created by you in the past or by others). attempting to fit them into the process best. Communication is often seen as a necessary evil, and this process often goes faster with fewer people. if people bring up questions, there may be some attempts to communicate in explanations.
- sprint planning: work assignment and time management/estimations. similar to above, questions could spark attempts to communicate, but it's not the primary purpose.
- sprint retro: improve the team dynamics and the flow of the process. communication is usually assumed here, but in practice it's "people saying things, they get written down, then the next sprint happens same as the last." there often isn't effective communication to the people who could change things
I think if the goal of meetings was more specifically "we are going to communicate until our mental pictures are exactly the same" you'd end up with faster/better actual work from everyone on the team.
But in big orgs that's usually not even what's wanted. If the plan sucks, but it's a VP's pet project, it's not good for various whole teams in that org to all effectively communicate with each other to realize it sucks but not have the political skills or pull to change the VP's mind...
> Too much time is spent attempting to communicate and as such, communication isn't actually happening.
This is where I think we have a different definition of communication.
> (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)
Hence my clarification of:
For example, if a project kick-off meeting consists of the highest ranking managers talking and everyone else having no contribution, listen to what they are saying; their "vision" is all that matters.
Another example is when product and/or engineer managers use "stand-ups" to ask each engineer the status of their deliverables. Listen to what they are saying; we micromanage and do not trust the team.
Standard philosophical problem, you're disagreeing about the definition of a word instead of the content of the message.
Step back and think if a dispute over the usage of the word is necessary or helpful in this context.
Amusingly this is where a lot of communication goes to die, loss of the big picture and discussion of how to use particular words.
Clearly you agree with OP about how time is wasted but you're insisting on using different language to express the same idea.
> Standard philosophical problem, you're disagreeing about the definition of a word instead of the content of the message.
Perhaps I should have said we have a different understanding or expectation of communication, instead of "definition." For this confusion I introduced, I apologize.
> Clearly you agree with OP about how time is wasted but you're insisting on using different language to express the same idea.
I do not.
Again, as I previously self-quoted:
OP postulated:
To which I disagreed. OP then opined:
Which is an indirect reference to meetings, not communication.
Finally, OP concluded with:
Which erroneously correlates meetings with listening. Your original response included:
Thus reinforcing said erroneous correlation. I blame myself for insufficiently expressing my thoughts on the difference between listening, which is implicit in communication and the topic of the article, and meetings, which are an assembly of people requiring only physical presence.
That's certainly one way of looking at daily stand-up. The other way is that humans aren't perfectly spherical communicators so sometimes daily stand-up really does manage to bring up blockers for the manager to actually resolve.
You can spend too much time communicating and not communicate enough at the same time. Effectiveness is the key here.
> Listening is a skill, one which is can be perfected if practiced
communicating is also a skill
learning to communicate effectively can be perfected too
> This is a phenomena I have yet to experience in the wild.
I have totally seen infinite meetings where nothing is achieved, nothing is really said, but someone socially isolate just talks and talks and talks because it is his only chance to interact.
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.
Critical issue is that it expects leaders to actually lead. Common yet fatal flaw in many plans.
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.
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.
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.
I have feedback in the past that people don't like diagrams upfront, because it presents a finished solution.
Spending time "on" communicating is not the same thing as communicating.
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.
>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>
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.
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.
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."
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.
That cost has now gone way down, with AI doing that code thing. Love it or hate it, that is the reality.
i've all AI subscription, cost is definitely down but risks aren't. You can still break things, you can make mistakes.
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.
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.
it's not possible to make everyone understand nuclear physics, there is certain threshold of cognitive skills/motivation required for that.
The people involved in commissioning and funding nuclear power plants don't understand nuclear physics either.
The customer doesn't need to understand how the solution works, as long as they can understand that it would solve their problem (in the case of the power plant: producing "clean" energy) and any potential drawbacks or limitations (in the case of the power plant: the waste byproduct).
The point here is that as a "tech person", it's your job to help the customer understand the cost of what they're asking, and come up with a satisfactory solution based on your understanding of their needs.
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
> 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!
>> 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:
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
Related, I think, and I found TFA a very interesting read: https://news.ycombinator.com/item?id=23617188
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.
> 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.
> 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 ...
The thing is, neither the software engineers nor the users know wtf should be done completely. Communication across domains is hard.
Let's try a physical items example: have you ever ordered a piece of furniture or other home improvement thing, got exactly what you asked for, professionally done... and then later found out there were better ways to do it (at similar cost) that you hadn't even imagined?
Was it because you didn't know what to ask for? Was it because the experts in home improvement didn't volunteer that there are other options? Was it because they sell one thing and didn't even know there are other options? Did you even ask what options you have or did you just order the thing?
Communication is damn hard, again.
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.
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
> 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.
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.
You you you you. A rant article
Strangely, even more annoying than the "I I I I" articles that reeks of narcissism.
Anyone else catch Rimmer's study timetable?
(Procrastination, Red Dwarf reference)
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
I was just working on this product & now I have to scrap it: https://www.theguardian.com/technology/2026/apr/13/meta-ai-m...
> 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.
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.
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.
> 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.