> 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!
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.
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.
> 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.
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.
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.
>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.
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.
yes. I have to keep telling my colleagues "about what?" for about 4-5 times in a row, at least twice daily, until they finally realize they have to tell me which client, feature, product or whatever else they are referring to.
Even if i know exactly what yhey are talking about.
> This is why it's important to write things down in details and as-unambiguous-as-you-can forms.
While that might be a prerequisite for a deep shared understanding, I have made the experience in the last few years that the number of people really reading more than the starting sentence of any message/ticket/email is consistently decreasing. I often have to feed them the information in very small and easy to digest portions. I so dislike that.
There is a very weird and a very awesome soviet-era movie Kin-dza-dza. At one point one of the characters tells this about the other: "he says things what he does not think, and he thinks things what he does not think."
This is kind of the exact thing the article is about though. They're not "failing to understand" costs - they just have different context. Your job is to help them make informed tradeoffs, not to expect them to already know what things cost before asking.
In these situations, the non-technical people don’t understand the costs, the technical people don’t understand the benefits. The communication from both sides is needed to find a good cost-to-benefit tradeoff
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.
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 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
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.
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."
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?
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.
55 comments
[ 2.7 ms ] story [ 54.9 ms ] threadTotally 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!
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.
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.
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.
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.
If that were true, there'd be something about it in the Bible.
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.
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.
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.
What management hears: We can sell this to the customer for acceptance testing.
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.
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.
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.
> We cannot do everything if we need to launch a reliable product.
Agreed, otherwise it would be Turing complete Excel/Email clone.
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'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.
A good article about the costs of not listening to your customers would be useful.
(Procrastination, Red Dwarf reference)
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.
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."
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.
That's what the 400k/yr is for.
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.