[HN Gopher] Let me repeat that back to you
___________________________________________________________________
Let me repeat that back to you
Author : rco8786
Score : 106 points
Date : 2023-12-23 12:24 UTC (10 hours ago)
(HTM) web link (roughlywritten.substack.com)
(TXT) w3m dump (roughlywritten.substack.com)
| sklargh wrote:
| Aviation, restaurants and emergency services have all widely
| adopted pieces of this technique.
| jeffrallen wrote:
| Yes, this. "Ok, what I just heard you say was X."
|
| Putting the other person in a position of security, knowing they
| were heard has another benefit: now you can ask them to consider
| another way of looking at the same issue. It might be your
| counter argument, or maybe asking them to develop some empathy
| for why some third party acted the way they did or whatever.
|
| This is a gentle and respectful way forward when tempers are
| making it difficult to have a discussion.
| drewcon wrote:
| I try this with my young kids with mixed results. They seem to
| have instant amnesia.
| Zambyte wrote:
| I was like this as a kid. Are they using a computer or doing
| something else while you talk to them? Computers (especially
| phones) are attention hogs. It's easy to forget everything when
| you're dividing you're attention like that.
| debo_ wrote:
| There's a version of this in "Turn the Ship Around" which is
| phrased as "Don't brief: certify."
|
| The quote is "a briefing is a passive activity for everyone
| except the briefer."
| saghm wrote:
| I had a boss who liked to use a similar idea, but with a twist;
| he'd sometimes repeat the idea back but intentionally get a key
| nuance wrong, with the intention of getting feedback on that
| part. If the person corrected it, he'd be much more confident in
| both his own and the other person's understanding of the idea. If
| they didn't, he'd dig in more to figure out why his original
| understanding was actually _not_ correct. The idea behind this
| was to look to _disprove_ what he thought he understood rather
| than to confirm it; he would only feel confident in his mental
| model if he couldn't disprove it after exhausting all of the ways
| he could think of. His strategy was pretty effective, from what I
| could tell; he'd often uncover subtle flaws or questionable
| assumptions in ideas or plans where he was not as knowledgeable
| in the domain as the person presenting it due to not only being
| willing to say something incorrect, but going out of this way to
| embrace it. Importantly, this was never used as a way to try to
| trick or test people; he would never criticize anyone for failing
| to correct him when he said something wrong, because the whole
| point of the technique was that he wasn't even sure whether he
| needed to be corrected or not, and he was still trying to figure
| it out.
| obeavs wrote:
| Smart play, but hard to do in the moment. Sounds like a sharp
| guy.
| avianlyric wrote:
| Veritasium has a great video[1] about people's cognitive bias
| towards using examples that prove their mental model, rather
| than using examples that disprove their mental model. But if
| you want to actually confirm you have accurate understanding of
| something, testing examples that _don 't_ fit your metal model
| is the workable methodology (i.e. use a null hypothesis).
|
| Testing examples that do match your mental model only proves
| your model partially matches the actual model, but it does very
| little to actually identify misunderstandings, or improve your
| understanding.
|
| [1] https://youtu.be/vKA4w2O61Xo
| jerf wrote:
| It's a common programming error too. I often see automated
| test cases that only test the happy path, but you ought to
| test that errors error the way you expect and desire too.
| These tests fail the first time I run them as often as the
| happy path cases do.
| Stratoscope wrote:
| So many great videos on Veritasium, and that is one of my
| favorites. Anyone who is not familiar with the channel should
| check it out.
|
| Of course, there is this counterpoint...
|
| https://www.youtube.com/watch?v=cY_o4A1wzsg
| op00to wrote:
| I was taught to use the null hypothesis in a US high school
| science lesson on the scientific method in the 90s. It never
| clicked to me "why" until your explanation. Funny how that
| stuff works.
| stavros wrote:
| Can you elaborate a bit? I don't understand how this is useful
| if, for example, someone says "we should add a nullable field
| and then create a migration" he'd say "you're saying we should
| add a non-nullable field and create a migration"? Why would
| someone _not_ correct this?
| Retr0id wrote:
| I think this approach is mainly for more complex ideas. To
| expand on your example, it might be something more like "our
| 99th percentile page loads are slow due to high widget view
| hydration latency. We can reduce the cost of hydration by
| caching greeble status in the the widget table. We should add
| a nullable field and then create a migration."
|
| To which, the reply might be roughly the same but ending with
| "We should add a nullable field to the greeble table and then
| create a migration."
|
| If the proposer is paying attention, they might say "no no,
| the new field has to go in the widget table."
|
| The goal isn't to catch someone out, but to make doubly sure
| you've reached a shared understanding.
| stavros wrote:
| Hmm, that makes more sense, but I still don't see how these
| factual errors could go uncorrected. I can see how this
| might be a measure of attention, but I don't understand the
| "disprove my assumptions" aspect of it.
| Retr0id wrote:
| If you repeat what you think is a 100% correct version of
| the information, and the other person nods along, you
| can't be very sure whether they're just passively
| agreeing because they zoned out or if you were actually
| correct.
|
| It's a bit like writing unit tests that fail, before you
| implement the change that'll make them pass.
| mitthrowaway2 wrote:
| It seems you also agree with stavros that this strategy
| seems more like a test of attention, then?
| catapart wrote:
| "okay, so you mean that the profile data is being sent,
| but something is messing up in our endpoint handle,
| right?"
|
| "No, it looks more like it's a routing issue. The
| endpoint never gets hit when the client sends data, so
| we're trying to troubleshoot where the disconnect
| happens"
|
| Not trying to be snarky; just had a real world example
| handy because my entire team uses this type of messaging.
| Usually starts with a "okay, just trying to level
| set...", or "just so I know I'm on the same page".
|
| In our experience, this type of communication has helped
| minimize instances of completely mismatching on task
| expectations
| stavros wrote:
| Hmm, I see, thanks. This sounds pretty everyday to me,
| but I guess that's probably just because we already do
| this. Things like "you're saying <x>" and "OK, summarize
| my points back to me so I know we're aligned".
| mitthrowaway2 wrote:
| Whenever I'm saying "just so I know I'm on the same
| page", I communicate my best understanding of the
| _correct_ interpretation of my colleague 's message. I
| would never deliberately introduce a misinterpretation to
| see if it gets corrected. Misinterpretations happen often
| enough naturally already, in both directions, and my goal
| is generally to minimize them.
| trealira wrote:
| It sounds more like he's trying to disprove his current
| understanding, and he feels confident in his understanding
| only if he can't disprove it. So, he probably wouldn't fake a
| trivial misunderstanding like that, but some deeper part
| where he's less confident about his understanding anyway.
| norir wrote:
| I personally prefer a direct strategy: state that you don't
| understand and what your (possibly) unenlightened concerns are.
| Or ask something like, "that sounds good, but what are we
| missing that might cause someone to be paged at 3am?"
| greenie_beans wrote:
| i like the repeat back but i would hate this. what if the
| person doesn't feel comfortable correcting them? just so many
| ways this could go wrong. not to mention it's dishonest and
| manipulative. management is already manipulative in a way, but
| this is crossing the line.
| StevePerkins wrote:
| If it's a junior developer, then they really shouldn't have
| too much responsibility without heavy supervision anyway.
|
| If it's a senior developer, then they should feel comfortable
| speaking up when there's a disconnect or misunderstanding. I
| would argue that one trait is the overwhelming majority of
| what separates a senior developer from a junior one.
| watwut wrote:
| > If it's a senior developer, then they should feel
| comfortable speaking up when there's a disconnect or
| misunderstanding. I would argue that one trait is the
| overwhelming majority of what separates a senior developer
| from a junior one.
|
| Whether seniors feel confident to correct the manager
| depends primary on how manager acts when corrected. There
| are many managers who don't get corrected by seniors and
| seniors who do learn not to do that - either becabuse it is
| useless or will be punished.
|
| Either way, juniors do talk with management fairly often,
| whether they have responsibility or not.
| TrololoTroll wrote:
| I could not agree more
|
| Seems like it'll always be the case that people will
| chuck the responsibility for X towards people with the
| lowest capacity to actually be responsible for X
|
| People feel fine with correcting managers when managers
| reward being corrected instead of punishing it. That's
| got nothing to do with seniority levels
| spaceprison wrote:
| Agreed I've seen a scenario play out with a junior engineer
| and a senior manager who does this. The junior had the right
| idea but the dialog with the inquisitive senior manger left
| the junior confused because they didn't feel like they had
| the chops to push back.
| bitshiftfaced wrote:
| I've heard that professional mediators use a similar technique.
| It goes something like: 1) repeat back what you've heard and ask
| if you've got it right, 2) if the other person says no, then have
| them explain, 3) repeat back again and again until the other
| person says that you've got it right, 4) only after that point do
| you share your own perspective.
| schneems wrote:
| Syn, Ack, Syn/Ack. IRL.
| maroonblazer wrote:
| When I was starting my career I had the good fortune of working
| with a senior consultant who shared a piece of advice when it
| comes to communication. Specifically, getting someone to take
| some specific action. In short:
|
| - Just because I said it doesn't mean you heard it.
|
| - Just because you heard it doesn't mean you understand it.
|
| - Just because you understand it doesn't mean you agree with it.
|
| - Just because you agree with it doesn't mean you'll do it.
|
| It serves as a good reminder for all the potential points of
| failure in interpersonal communications.
| BeetleB wrote:
| The first two is where most people stumble. Before I started to
| read communications books, I (as with many others) would focus
| on improving _my_ wording. How did they not understand? Let me
| be precise and concise so there is no room for confusion. That
| didn 't improve things. Let me be verbose and say the same
| thing 3 times in different ways. Nope.
|
| Coworkers would do something different from what I requested,
| and then claim I had asked them to do it. I would go to them in
| frustration, have them to pull up my email, and ask them to
| point to the line where I made the request they claimed I had
| made. I was that guy.
|
| Finally, after reading the books, I understood that you can say
| things perfectly _but should not expect the other party to
| understand!_ The only solution is to ask the other person to
| reflect back what you said. And to do likewise when they speak
| to you.
|
| Communications is lossy. At the first level they may not have
| heard (e.g. noisy environment). At the next level they may not
| have processed it (e.g. zoned out because of some personal
| problems they are dealing with). At the next level, they may
| have processed everything, but interpreted the words very
| differently from what you meant. You cannot change any of these
| things. Don't (overly) focus on how you said it. Focus on
| getting them to reflect it back to you.
| ent wrote:
| That sounds awfully much like something I might be doing. Do
| you have any specific books you would recommend?
| nuker wrote:
| Oh sweet summer child ...
| rco8786 wrote:
| Yes?
| pacifika wrote:
| As an expat with an unusual name after the fourth time one party
| just agrees to the other party
| Retr0id wrote:
| I do this sometimes. Normally I phrase it something like "So what
| you're saying is, [summary]", or "Just to make sure I got that,
| [re-explanation]" which feels more natural to me. "Just to make
| sure we're on the same page here" is another one.
|
| I also ask questions about any aspects that sound sub-optimal,
| which is useful in its own right, but it's just as likely to
| uncover gaps in my own understanding - and I have that in mind
| when formulating the question.
| msla wrote:
| > I also ask questions about any aspects that sound sub-
| optimal, which is useful in its own right, but it's just as
| likely to uncover gaps in my own understanding - and I have
| that in mind when formulating the question.
|
| And this framing is important: Even if you think you've found a
| serious problem in the proposal, treat it as if it's a gap in
| your own understanding and ask the other person to explain, as
| opposed to framing it as you fixing their faulty ideas.
|
| It's a social lubricant, in that it reduces emotional noise
| caused by people getting defensive, and it saves you
| embarrassment if you are, in fact, missing something.
| senderista wrote:
| In academia this takes the form "I'm confused", which is code
| for "I suspect you're an idiot; please prove me wrong".
| krisoft wrote:
| Interesting that they use the "My Aircraft" "Your Aircraft"
| example from aviation.
|
| While it is true and indeed used I don't think it is the best
| example for what is proposed. Because with "my aircraft/your
| aircraft" the content is always the same. It is more a start
| transaction / acknowledge transaction kind of deal. It contains
| only 1 bit of information.
|
| There is a better example in aviation: clearances and ATC
| instructions are expected to be read back by the pilot. This is
| to ensure that the information was transmitted correctly. And the
| information content is many many bytes.
|
| Here is an example where the pilot is struggling with the
| readback and the ATC is very patiently repeats it until they get
| it right: https://www.youtube.com/watch?v=D88EZJ2wJ7M
| rco8786 wrote:
| Oh awesome! Thanks for this. I agree that's an even better
| example, the pilot transfer one was just the simplest thing I
| could think of while writing this out.
| karaterobot wrote:
| > Isn't that awkward?
|
| I do this in every work conversation of any complexity. Probably
| 5-10 times a day. If it's awkward, you get over it pretty fast.
| Normally, I say "hey, can I summarize that in my own words to
| make sure I understood?" and as often as not the response is
| "Please do!" because nobody likes being misunderstood, and it
| happens all the time.
|
| One issue to work around is that, due to the turn-taking rules of
| conversation, the other person will immediately launch into their
| next thing after you've summarized their last thing, instead of
| letting you make a response, or ask a question. That is, if they
| are thoughtless or socially inept, which is not exactly a rare
| kind of person to encounter at work. So, your summary of what
| they said effectively becomes your "turn" in the conversation,
| and your role becomes essentially an amanuensis rather than a
| participant.
|
| You just need to be ready to interrupt a steamrolling colleague
| and say "--Well, before you continue, I wanted to respond to what
| you just said." That's actually more awkward to me than
| summarizing their initial monologue, but it's important because
| this method makes for frustratingly one-sided conversations if
| you don't assert yourself.
| rco8786 wrote:
| Yea this is a great point. I'm generally aware of what point I
| actually want to make after the fact so once I get an
| affirmative from the other person I can go "Thanks, so with
| that in mind blah blah blah" before anyone is able to take "my"
| turn :)
| yboris wrote:
| I like this technique for even less-complex conversations. A
| simple _checksum_ of sorts.
|
| One (somewhat related) example: after scheduling a meeting for
| "next Tuesday at 7pm" it's worth repeating back "Tuesday the
| 26th, at 7pm EST" (or something similar).
| angarg12 wrote:
| I naturally developed this as a key technique when I interview
| software engineers. Repeating back a long-winded technical
| explanation servers several purposes:
|
| * Makes sure you indeed understood what you think you did.
|
| * Gives you some time to think what to ask next.
|
| * Focuses the conversation.
|
| I think the last point is also key. Usually these kind of
| explanations take several minutes and can ramble a bit. By
| repeating something back clearly and concisely you can focus the
| conversation on the point that you want to dig in further.
|
| Of course this technique is also excellent while collaborating
| with colleagues.
| gully_boy wrote:
| >> * Gives you some time to think what to ask next.
|
| I have found this quite an important part of this strategy
| actually, especially in negotiations (eg on a termsheet or
| something like that). having some time to both a) understand
| what was just offered to you but also b) give enough time to
| ask questions/respond.
| Galxeagle wrote:
| I will often do the reverse, especially when they've repeated the
| same opposition point more than once or I'm feeling unheard -
| 'I'm worried I've miscommunicated, can you paraphrase back what
| you've heard my point is and I'll clear up any nuance?'. It does
| wonders when someone is being territorial or arguing in bad faith
| to watch their gears turn on how to respond while maintaining
| their arguments.
| Ensorceled wrote:
| This is why I'm a big fan of having developers write out a spec,
| even it only a simple one pager, to make sure they actually
| understood the requirements/design.
| dctoedt wrote:
| That's how it works on U.S. Navy ships:
|
| * Conning officer: "Right standard rudder, steady on course 090."
|
| * Helm: "Right standard rudder, steady on course 090, aye,
| [sir|ma'am]."
|
| This is especially important in background-noisy environments,
| such as engine rooms:
|
| * Propulsion plant watch officer _(over low-fidelity sound-
| powered phone):_ "Feed pumps, EOS: Light off number one main feed
| pump."
|
| * Feed-pump watchstander: "EOS, feed pumps, light off number one
| main feed pump, aye."
|
| I get a kick out of it when it's done this way in TV shows and
| movies (even Star Trek).
| skydhash wrote:
| > I get a kick out of it when it's done this way in TV shows
| and movies.
|
| Greyhound is a nice example. And it was a very noisy
| environment
| amenhotep wrote:
| HELM 108
| dudul wrote:
| As a manager I always do that.
|
| First, I want to make sure I understood what engineers were
| explaining. I'm not as much in the code anymore and it is vital
| for me to rely on their expertise to understand technical
| details.
|
| Second, I sometimes include some clarifying questions or try to
| tease out something that I feel was overlooked.
|
| Third, when I repeat back I try to make it more concise and to
| the point. It's kind of a coaching moment I guess:) some of my
| reports struggle with succinct, effective communication, so I try
| to model how I think they could have conveyed the information
| with half the amount of words/time.
|
| I absolutely don't feel that it's awkward. I just say "ok let me
| try to summarize to make sure I understand/get this right".
| mjklin wrote:
| "Sounds like a subdural hematoma to me..."
| https://youtu.be/7-a2QBfFQeA?si=ApJLjBOf27ovN2kH
| sophyphreak wrote:
| So important. Very underused and underappreciated. Even more
| important for talking to people as an Autistic person and for
| talking to Autistic people.
| da4id wrote:
| In emergency medicine we refer to this as closed loop
| communication.
| jayeshsaita wrote:
| Nice one, liked the idea of intentionally committing a mistake to
| check if the other person catches it!
| oooyay wrote:
| I like that the article specifies to do this in your own words.
| If you just repeat someone else's words you're not actually
| proving understanding. You're just parroting, which anyone can
| do.
___________________________________________________________________
(page generated 2023-12-23 23:02 UTC)