I firmly believe this is almost exclusively a didactic issue, ie. the person explaining does not or cannot reflect what is common knowledge and what needs to be explained in addition to the new ideas.
This comment resonated with me so much
"I’ve been on the receiving side of this before. What typically happens is the Dunning-Krueger Effect. This is typically understood as incompetent people are too incompetent to determine that they are incompetent, but its lesser-known corollary is that competent people assume everyone else is competent too, and thus they don’t have to explain themselves.
Once you understand this, the reason for poor communication becomes clear. The team doesn’t bother to explain their presumptions, falsely assuming that everyone is on the same page. They feel free to use original concepts they developed, internal team slang, unexplained acronyms, etc. Then they’re baffled why people are so stupid and can’t understand their outstanding presentation that obviously went over all the details. "
I, too, have been on the receiving end of such treatment multiple times.
I wouldn't call exclusive or inside knowledge "competence". What shocks and baffles me is exactly this phenomenon: Companies have inside knowledge, which an outsider starting fresh could not possibly know. An outsider also has a really hard time grasping and sorting the new inside information. Yet, it is common of engineers to not reflect at all about "what can this person know and understand without working here 5+ years", and prematurely jump to conclusions that outsiders are slow, and they are lazy to not aquire this information on their own.
This behavior is not competent, or smart if you ask me.
When you try to communicate the issue at hand, it might also fall on deaf ears, because reflecting about such meta levels of knowledge is a skill not everyone posesses and could easily understand.
In the end, either side, the insider and the outsider, can experience a lot of frustration, because their viewpoint is so incompatible with the other.
You have summarized my first two months at a new job.
I joined as a lead and spend a good deal of time in meetings where they discuss new features and tasks. Before the meeting, I open the company's acronym cheatsheet just to be able to keep up. Then after a long monologue from a manager that ends with "Any questions," I'm the guy who asks: "What's <product-name>?"
It sucks because I appear incompetent. But it has also helped us onboard people better. One of the first tasks I assigned to my team was to update the README.md files of all code bases they touch. It might seem obvious to the old timers what everything does, they have spend years working on it. But to the avalanche of new developers they are hiring, a code base that has code and no description is a source of confusion.
This is really doing god's work though. A lot of teams I've been on were deep into a mess of their own make due to this. You build a whole terminology around you work and not it takes twice the time to onboard anyone.
This is also an issue with people that like to pick non-descriptive name for their projects (although I might just be grumpy on that one). Don't call your pipeline workflow "Optimus Prime", it means jackshit to everyone else.
>This behavior is not competent, or smart if you ask me
One job I had, my manager decided early on that I was a complete idiot and insubordinate. Freely asking any "dumb" question that came to my mind was a no-no, and even more so was asking other people to verify what my manager told me - it was seen as undermining their authority.
A later job, my manager formed the opinion that I was really smart in the beginning, and so when I fail to understand something, they blame themselves for not being able to explain. Sometimes I feel bad they are so self-critical.
"Fish can't teach you about water"
Even if people are not consciously intending it, though, being bad at knowledge transfer is in everybody's self interest. Perfect communication would facilitate workers being interchangeable cogs.
I left out the option of doing it on purpose, conciously or unconciously, but you are right, it could be that as well.
I think in the long run it will hurt you to actively refuse to help your colleagues, because they are smart, they will pick this up and be reluctant to work with you and share information with you as well.
Not helping the people you work with has its advantages too, like more time and more focus for your own stuff, maybe even more carreer opportunities, but for me it is simply not an option anymore. I tried that, but it made me negative and miserable, so I gave it up. Now I try to be the engineer I personally would like to work with on a daily basis. If people get it, great, if not, it doesn't matter too much anyways. I do it for myself as well.
While I agree with you that it is a didactic problem, I also think it is an optimisation heuristic. When working with engineers, it is expected that they know what, for example, git/version control is, hence such jargon will be sprinkled in conversation freely. That's how we compress the communication bandwidth. It is enormously costly if we document everything in a context free manner that anyone newly into the topic can understand, and people still won't understand.
It is also why learning from/teaching to users seem futile and why adhering to common UX patterns help adoption. We basically don't know our user and our user don't know us. So users commonly assume whatever product they use is omnipotent (having all features) while we, as product owner, need our product passing the Mom Test.
One would only spend so much effort on bridging the understanding gap. On internet, not so much, hence the copious amount of flame war. In a compassionate working environment, better. In family setting, ideally infinite.
> While I agree with you that it is a didactic problem, I also think it is an optimisation heuristic. When working with engineers, it is expected that they know what, for example, git/version control is, hence such jargon will be sprinkled in conversation freely. That's how we compress the communication bandwidth. It is enormously costly if we document everything in a context free manner that anyone newly into the topic can understand, and people still won't understand.
This is exactly the reason I ask some common knowledge jargon during interviews.
I start by saying, "hey, I know this is silly but I'm going to ask you some basic questions, please explain to me what you think it means.. JSON, REST..."
You'd be shocked how many strange / ridiculous answers I get, along with a few that after 10 words I know I'm speaking with someone that has a change getting the position.
This is part of an initial 30 minute phone interview.
While poor explanation is a likely culprit in many cases, I think there is something more to this.
I think a lot people (especially males, could be linked with men lower performance in education) subconsciously don't want to listen.
This happens a lot to me, people ignore my warnings and believe giving me some long explanation will be helpful just for me to flat out ignore them and read the source material.
At least in some of these examples, the problem seems to be rooted in a lack of understanding of the audience/customer. Implicit in this essay is an expectation that the audience/customer will do the work for you. Saying :"We’ll be able to put avatars on web pages. Start thinking about what you might do with that.” Doesn't explain the value proposition or the problem solved. Why should they care? You'll always be disappointed if you expect the audience to figure this out for you. They've got 101 problems they're working on and your asking them to invest in your idea. You need to do this leg work for them.
As for the statement "why would people put documents on the web?" That seems a very valid question. If you can't nail that answer, you haven't invested enough in understanding the customers/audience for who you're trying to solve problems.
Pitching a new idea is hard. You need to iterate on it obsessively, cutting it down to the core value prop in easy to digest words for the specific audience you're talking to.
> Pitching a new idea is hard. You need to iterate on it obsessively, cutting it down to the core value prop in easy to digest words for the specific audience you're talking to.
Then, after failing to explain it 1000 times, you find a combination of working simplifications and it finally can be explained in a few sentences.... Then people say: If it was that simple someone else would have thought of it.
> As for the statement "why would people put documents on the web?" That seems a very valid question. If you can't nail that answer, you haven't invested enough in understanding the customers/audience for who you're trying to solve problems.
The answer would have to be a lie. Neither of us would understand it when told it is all to watch cat pictures and to document and manipulate peoples personality and behavior to sell products and nudge their political ideas while they exchange cooking updates with their mum.
If someone told me or you the honest factual truth that it was a sound plan for world domination we would have laughed so hard. Why would anyone use google or facebook if it's that expensive to use?
> Then people say: If it was that simple someone else would have thought of it.
That's when you go into the prior art. Give a summary (long list of things other people have done – five or six will do), then start drilling down into them, touching on what they address, genuine pros and cons wrt your approach (when relevant), and then go back to how yours is different. (“But none of these XYZ, which is useful for foo and bar.”)
Or, you know, whatever else feels right to say at the time. If you're well-calibrated, your gut instinct will be a result of “reading the room”. That comes with practice.
I think someone can certainly explain an idea if both people take enough time and have enough motivation.
The thing that stands out for me is people who have different ideas concerning where the obligation is in communicating concepts. Is it the speaker's job to put things so the listener can understand? Or is it the listener's job to spend time parsing an objectively correct explanation? In society, overall, this involves a process of negotiation. Notably, I think some people who's job involves manipulating abstract ideas don't think it's their job to put spend time putting concepts into a form appropriate for a given person - the concepts being expressed in an abstractly correct fashion is sufficient.
> Notably, I think some people who's job involves manipulating abstract ideas don't think it's their job to put spend time putting concepts into a form appropriate for a given person - the concepts being expressed in an abstractly correct fashion is sufficient.
If your job involves manipulating abstract ideas, then surely you should know that different people have different abstract representations of those abstract ideas! The more abstract the concept, the more “and this is this” “yes, I follow” handshakes you have to do before you get into the details.
I've been working on infrastructure to support a certain class of applications (medical imaging devices) that have a lot of complex functional and nonfunctional requirements. I initially developed much of the system I own alongside the first product team which made use of my systems, and together we ran into a lot of painful issues and added functionality to support these use-cases.
Working with a new team who haven't yet shipped such a system to production has been supremely frustrating, because they haven't gotten far enough in the process to understand the classes of problems that my system solves. I've gotten a lot of pushback simply because they simply didn't have enough context to understand why you'd even care about this stuff - "Why are you bothering us with these problems? I'm sure we can figure this stuff out eventually."
But now, after working with folks for a year and a half, they're starting to come to me with questions about how to resolve certain things - and that's when I say "remember that stuff you didn't care about at all last year? fortunately my system already knows how to do that for you!"
Glad to know this is a systemic problem with humans and not a personal failing on my part!
* input validation at ingestion time vs processing time
* access control via a proper IAM system with defined roles as opposed to granting access to individual users
* various multi-tenancy, multi-region, and multi-regulatory-regime concerns
* relying on standard frameworks/platforms which provide rollouts, monitoring, test harnesses, etc. as opposed to rolling your own
Some of the things were simply "we know this is important, but we have to hit this deadline so we're going to cut corners", resulting in rework later to do things properly in production
The other issue is that people are constantly telling others crap. People are constantly giving bad advice, making wrong predictions, etc. Sometimes these people are very accredited, very smart, and well-intentioned, they just happen to be wrong.
So when people receive advice, predictions, etc. they won't just accept, they use their own judgement. Which is also often wrong. But either way can be wrong, and people almost always trust themselves more than others.
The best thing you can do to convince a skeptic is show them very clearly or move on. The best thing a manager/lead can do to convince a skeptical employee of their business/design plan is show them very clearly or fire them if they don't follow the plan.
I've found that working and expressing my ideas more locally is far better than posting ideas to the world. It is also contrary to how social media, radio, and TV are modeled.
By starting locally, you build a following and don't need to worry as much about being ostracized and cancelled before a well-known credibility among people who will support and defend you is established. (Don't break the law or support negative means in the process of course).
So many people get burnt out and cancelled right when they become famous now because social media catapults people from obscurity directly into popularity, when they don't have proven and tested experience, no prior following, and no prior reputation.
I think about this from the opposite perspective all the time when I'm trying to learn a new skill or when I'm doing something out of my realm of experience, anything from server configuration to hanging a door: someone already knows the best way to do this.
Over and over again people will configure their servers wrong and hang their doors askew because of the concept described here, even though the correct way is well known. On the flip side, there are some benefits: each person figuring things out for themselves undoubtedly leads to innovation, especially in realms like the arts.
Still, I can't stop myself from daydreaming about some way to transfer door-hanging knowledge into my head matrix-like (my eyes pop open and I say: "I know how to hang a door!") similar to the useless way I sometimes find myself thinking someone should do something about that sun when I find myself driving west at sunset.
One of the things I did was travel around the country trying to evangelize the idea of hypertext. People loved it, but nobody got it. Nobody. [1]
The thing about the "you can't tell people anything" statement is, it's a good shorthand for a certain kind of situation. In this article, it's shorthand for people not understand a situation even if they're given what to you may seem a complete logical explanation. The simplest explanation, somewhat alluded to in the text, is that the people you're explaining the thing lack the context to understand even if they understand the terms used in the abstract. It's easy to see how people wouldn't "get" hypertext in a pre-Internet era. It's easy to say how people wouldn't "get" a client-server application if they'd never been exposed to the client-server architecture previously at all.
Which is to say, I think it's quite possible to tell people things - in the context of a big, difficult abstract - if you go step-by-step, verify understanding at each step, break up the explanation process if it's not working, ask questions etc.
And often, when a person fall back on "you can't tell people anything", it's because they fail to do the laborious explanation process. The bureaucratic standards don't allow it, there's no time or whatever. And some people just fall on this by reflex, they're reconciled to the situation. It's very annoying when a certain type of person gives a single explanation and then responds "you just don't get it" when questioned, etc. But it's worth being clear that, in the abstract, "you can tell people things".
[1] Worth nothing that in the reality is no one at all "got" hypertext or the Internet when to "get" involves a good grasp of the implications, in ways, we still don't get everything here. No one had the full context in 1980. The full context is still being created.
I was just thinking about this earlier today with respect to Mastodon and federated social networks. As someone who has been very actively using Mastodon for years, it is frustrating — painfully frustrating — when people criticise it in the abstract. "It will never work" then why is it working? "People won't know how to sign up" it is easier to sign up than any the average email service - blah, blah, blah - actually it's not worth anyone's time answering these questions. Just use it. _use it_ for goodness sake.
My issue with mastodon is that exploring servers means creating a bunch of accounts. That's kind of annoying. I still like and use Mastodon, but there it is.
"It will never work" can mean so much. It will never be bigger than Twitter (almost certainly true), it will never work to spread my ideas to a wide audience, that may or may not be true.
My issue with Mastodon is that it imitates Twitter a little too well. I keep finding people to block when looking for people to follow. The local and federated feeds are infested with spammers, self-righteous ideologues of all kinds, 4chan rejects, and bots. It just isn't worth the effort.
Readit News
This comment resonated with me so much
"I’ve been on the receiving side of this before. What typically happens is the Dunning-Krueger Effect. This is typically understood as incompetent people are too incompetent to determine that they are incompetent, but its lesser-known corollary is that competent people assume everyone else is competent too, and thus they don’t have to explain themselves.
Once you understand this, the reason for poor communication becomes clear. The team doesn’t bother to explain their presumptions, falsely assuming that everyone is on the same page. They feel free to use original concepts they developed, internal team slang, unexplained acronyms, etc. Then they’re baffled why people are so stupid and can’t understand their outstanding presentation that obviously went over all the details. "
I, too, have been on the receiving end of such treatment multiple times. I wouldn't call exclusive or inside knowledge "competence". What shocks and baffles me is exactly this phenomenon: Companies have inside knowledge, which an outsider starting fresh could not possibly know. An outsider also has a really hard time grasping and sorting the new inside information. Yet, it is common of engineers to not reflect at all about "what can this person know and understand without working here 5+ years", and prematurely jump to conclusions that outsiders are slow, and they are lazy to not aquire this information on their own. This behavior is not competent, or smart if you ask me.
When you try to communicate the issue at hand, it might also fall on deaf ears, because reflecting about such meta levels of knowledge is a skill not everyone posesses and could easily understand. In the end, either side, the insider and the outsider, can experience a lot of frustration, because their viewpoint is so incompatible with the other.
I joined as a lead and spend a good deal of time in meetings where they discuss new features and tasks. Before the meeting, I open the company's acronym cheatsheet just to be able to keep up. Then after a long monologue from a manager that ends with "Any questions," I'm the guy who asks: "What's <product-name>?"
It sucks because I appear incompetent. But it has also helped us onboard people better. One of the first tasks I assigned to my team was to update the README.md files of all code bases they touch. It might seem obvious to the old timers what everything does, they have spend years working on it. But to the avalanche of new developers they are hiring, a code base that has code and no description is a source of confusion.
This is also an issue with people that like to pick non-descriptive name for their projects (although I might just be grumpy on that one). Don't call your pipeline workflow "Optimus Prime", it means jackshit to everyone else.
One job I had, my manager decided early on that I was a complete idiot and insubordinate. Freely asking any "dumb" question that came to my mind was a no-no, and even more so was asking other people to verify what my manager told me - it was seen as undermining their authority.
A later job, my manager formed the opinion that I was really smart in the beginning, and so when I fail to understand something, they blame themselves for not being able to explain. Sometimes I feel bad they are so self-critical.
"Fish can't teach you about water"
Even if people are not consciously intending it, though, being bad at knowledge transfer is in everybody's self interest. Perfect communication would facilitate workers being interchangeable cogs.
I think in the long run it will hurt you to actively refuse to help your colleagues, because they are smart, they will pick this up and be reluctant to work with you and share information with you as well. Not helping the people you work with has its advantages too, like more time and more focus for your own stuff, maybe even more carreer opportunities, but for me it is simply not an option anymore. I tried that, but it made me negative and miserable, so I gave it up. Now I try to be the engineer I personally would like to work with on a daily basis. If people get it, great, if not, it doesn't matter too much anyways. I do it for myself as well.
It is also why learning from/teaching to users seem futile and why adhering to common UX patterns help adoption. We basically don't know our user and our user don't know us. So users commonly assume whatever product they use is omnipotent (having all features) while we, as product owner, need our product passing the Mom Test.
One would only spend so much effort on bridging the understanding gap. On internet, not so much, hence the copious amount of flame war. In a compassionate working environment, better. In family setting, ideally infinite.
This is exactly the reason I ask some common knowledge jargon during interviews. I start by saying, "hey, I know this is silly but I'm going to ask you some basic questions, please explain to me what you think it means.. JSON, REST..." You'd be shocked how many strange / ridiculous answers I get, along with a few that after 10 words I know I'm speaking with someone that has a change getting the position. This is part of an initial 30 minute phone interview.
Dead Comment
I think a lot people (especially males, could be linked with men lower performance in education) subconsciously don't want to listen.
This happens a lot to me, people ignore my warnings and believe giving me some long explanation will be helpful just for me to flat out ignore them and read the source material.
As for the statement "why would people put documents on the web?" That seems a very valid question. If you can't nail that answer, you haven't invested enough in understanding the customers/audience for who you're trying to solve problems.
Pitching a new idea is hard. You need to iterate on it obsessively, cutting it down to the core value prop in easy to digest words for the specific audience you're talking to.
Then, after failing to explain it 1000 times, you find a combination of working simplifications and it finally can be explained in a few sentences.... Then people say: If it was that simple someone else would have thought of it.
> As for the statement "why would people put documents on the web?" That seems a very valid question. If you can't nail that answer, you haven't invested enough in understanding the customers/audience for who you're trying to solve problems.
The answer would have to be a lie. Neither of us would understand it when told it is all to watch cat pictures and to document and manipulate peoples personality and behavior to sell products and nudge their political ideas while they exchange cooking updates with their mum.
If someone told me or you the honest factual truth that it was a sound plan for world domination we would have laughed so hard. Why would anyone use google or facebook if it's that expensive to use?
That's when you go into the prior art. Give a summary (long list of things other people have done – five or six will do), then start drilling down into them, touching on what they address, genuine pros and cons wrt your approach (when relevant), and then go back to how yours is different. (“But none of these XYZ, which is useful for foo and bar.”)
Or, you know, whatever else feels right to say at the time. If you're well-calibrated, your gut instinct will be a result of “reading the room”. That comes with practice.
The thing that stands out for me is people who have different ideas concerning where the obligation is in communicating concepts. Is it the speaker's job to put things so the listener can understand? Or is it the listener's job to spend time parsing an objectively correct explanation? In society, overall, this involves a process of negotiation. Notably, I think some people who's job involves manipulating abstract ideas don't think it's their job to put spend time putting concepts into a form appropriate for a given person - the concepts being expressed in an abstractly correct fashion is sufficient.
If your job involves manipulating abstract ideas, then surely you should know that different people have different abstract representations of those abstract ideas! The more abstract the concept, the more “and this is this” “yes, I follow” handshakes you have to do before you get into the details.
I've been there and done that at the "two people and a crazy idea" level and seen how hard it is.
Working with a new team who haven't yet shipped such a system to production has been supremely frustrating, because they haven't gotten far enough in the process to understand the classes of problems that my system solves. I've gotten a lot of pushback simply because they simply didn't have enough context to understand why you'd even care about this stuff - "Why are you bothering us with these problems? I'm sure we can figure this stuff out eventually."
But now, after working with folks for a year and a half, they're starting to come to me with questions about how to resolve certain things - and that's when I say "remember that stuff you didn't care about at all last year? fortunately my system already knows how to do that for you!"
Glad to know this is a systemic problem with humans and not a personal failing on my part!
I like this kind of "meta-problem" and would be interested in known how to get people more interested in ideas that I intuitively know are useful.
* input validation at ingestion time vs processing time
* access control via a proper IAM system with defined roles as opposed to granting access to individual users
* various multi-tenancy, multi-region, and multi-regulatory-regime concerns
* relying on standard frameworks/platforms which provide rollouts, monitoring, test harnesses, etc. as opposed to rolling your own
Some of the things were simply "we know this is important, but we have to hit this deadline so we're going to cut corners", resulting in rework later to do things properly in production
It's just how it is, take it or leave it. To get away with this you need to have sufficient authority and agency however.
So when people receive advice, predictions, etc. they won't just accept, they use their own judgement. Which is also often wrong. But either way can be wrong, and people almost always trust themselves more than others.
The best thing you can do to convince a skeptic is show them very clearly or move on. The best thing a manager/lead can do to convince a skeptical employee of their business/design plan is show them very clearly or fire them if they don't follow the plan.
By starting locally, you build a following and don't need to worry as much about being ostracized and cancelled before a well-known credibility among people who will support and defend you is established. (Don't break the law or support negative means in the process of course).
So many people get burnt out and cancelled right when they become famous now because social media catapults people from obscurity directly into popularity, when they don't have proven and tested experience, no prior following, and no prior reputation.
Pop life is a meat grinder.
What do you mean by this?
Over and over again people will configure their servers wrong and hang their doors askew because of the concept described here, even though the correct way is well known. On the flip side, there are some benefits: each person figuring things out for themselves undoubtedly leads to innovation, especially in realms like the arts.
Still, I can't stop myself from daydreaming about some way to transfer door-hanging knowledge into my head matrix-like (my eyes pop open and I say: "I know how to hang a door!") similar to the useless way I sometimes find myself thinking someone should do something about that sun when I find myself driving west at sunset.
The thing about the "you can't tell people anything" statement is, it's a good shorthand for a certain kind of situation. In this article, it's shorthand for people not understand a situation even if they're given what to you may seem a complete logical explanation. The simplest explanation, somewhat alluded to in the text, is that the people you're explaining the thing lack the context to understand even if they understand the terms used in the abstract. It's easy to see how people wouldn't "get" hypertext in a pre-Internet era. It's easy to say how people wouldn't "get" a client-server application if they'd never been exposed to the client-server architecture previously at all.
Which is to say, I think it's quite possible to tell people things - in the context of a big, difficult abstract - if you go step-by-step, verify understanding at each step, break up the explanation process if it's not working, ask questions etc.
And often, when a person fall back on "you can't tell people anything", it's because they fail to do the laborious explanation process. The bureaucratic standards don't allow it, there's no time or whatever. And some people just fall on this by reflex, they're reconciled to the situation. It's very annoying when a certain type of person gives a single explanation and then responds "you just don't get it" when questioned, etc. But it's worth being clear that, in the abstract, "you can tell people things".
[1] Worth nothing that in the reality is no one at all "got" hypertext or the Internet when to "get" involves a good grasp of the implications, in ways, we still don't get everything here. No one had the full context in 1980. The full context is still being created.
- [Because all attempts have so far failed, or no attempts have been made] <X> "is impossible".
- [Based on my personal model of reality] If you do <X>, <Y> "will happen" [therefore it's not even worth trying].
- "The" reason for <X> "is" <Y> [because this is what my model tells me].
- etc
https://mastodon.social/explore
I might misunderstand what you mean by explore.
I'm the only user on my instance so everything I see is there because I subscribed to it.