10 ms·

Let me repeat that back to you

127 points by rco8786 3y ago

sklargh 3y ago
Aviation, restaurants and emergency services have all widely adopted pieces of this technique.
jeffrallen 3y ago
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 3y ago
I try this with my young kids with mixed results. They seem to have instant amnesia.
- Zambyte 3y ago
  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.
saghm 3y ago
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 3y ago
  Smart play, but hard to do in the moment. Sounds like a sharp guy.
- avianlyric 3y ago
  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 https://youtu.be/vKA4w2O61Xo
  - jerf 3y ago
    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.
    - Spivak 3y ago
      This to me gets to the fundamental nature of testing. If errors are part of your test suite then they're happy path too. It's just as much a part of your API surface as any other return value. But if you don't have (or want) callers that depend on your specific behavior in error situations then I wouldn't bother testing them. It's my contract that I can and will change the behavior arbitrarily and you can't be mad at me for it.
  - Stratoscope 3y ago
    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 https://www.youtube.com/watch?v=cY_o4A1wzsg
debo_ 3y ago
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."
bitshiftfaced 3y ago
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 3y ago
Syn, Ack, Syn/Ack. IRL.
maroonblazer 3y ago
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 3y ago
  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 3y ago
    That sounds awfully much like something I might be doing. Do you have any specific books you would recommend?
    - BeetleB 3y ago
nuker 3y ago
Oh sweet summer child …
- rco8786 3y ago
  Yes?
pacifika 3y ago
As an expat with an unusual name after the fourth time one party just agrees to the other party
krisoft 3y ago
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 https://www.youtube.com/watch?v=D88EZJ2wJ7M
- rco8786 3y ago
  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.
Retr0id 3y ago
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 3y ago
  > 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 3y ago
    In academia this takes the form "I'm confused", which is code for "I suspect you're an idiot; please prove me wrong".
karaterobot 3y ago
> 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 3y ago
  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 3y ago
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 3y ago
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 3y ago
  >> * 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 3y ago
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 3y ago
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 3y ago
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 3y ago
  > 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 3y ago
  HELM 108
dudul 3y ago
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 3y ago
“Sounds like a subdural hematoma to me…” https://youtu.be/7-a2QBfFQeA?si=ApJLjBOf27ovN2kH https://youtu.be/7-a2QBfFQeA?si=ApJLjBOf27ovN2kH
sophyphreak 3y ago
So important. Very underused and underappreciated. Even more important for talking to people as an Autistic person and for talking to Autistic people.
da4id 3y ago
In emergency medicine we refer to this as closed loop communication.
jayeshsaita 3y ago
Nice one, liked the idea of intentionally committing a mistake to check if the other person catches it!
oooyay 3y ago
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.
btbuildem 3y ago
This is such a simple, and fantastically effective tool. I use it often at work - either as in "let me repeat this back to you just to make sure I got it" or "please tell me what you just heard" when I'm explaining something and it seems the other person is just yessiring-verygoodsiring along.
cxr 3y ago
This is called three-way communication.

127 points by rco8786 3y ago

Aviation, restaurants and emergency services have all widely adopted pieces of this technique.

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 3y ago

I try this with my young kids with mixed results. They seem to have instant amnesia.

Zambyte 3y ago
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.

saghm 3y ago

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 3y ago
Smart play, but hard to do in the moment. Sounds like a sharp guy.
avianlyric 3y ago
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 https://youtu.be/vKA4w2O61Xo
- jerf 3y ago
  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.
  - Spivak 3y ago
    This to me gets to the fundamental nature of testing. If errors are part of your test suite then they're happy path too. It's just as much a part of your API surface as any other return value. But if you don't have (or want) callers that depend on your specific behavior in error situations then I wouldn't bother testing them. It's my contract that I can and will change the behavior arbitrarily and you can't be mad at me for it.
- Stratoscope 3y ago
  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 https://www.youtube.com/watch?v=cY_o4A1wzsg

debo_ 3y ago

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."

bitshiftfaced 3y ago

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 3y ago

Syn, Ack, Syn/Ack. IRL.

maroonblazer 3y ago

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 3y ago
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 3y ago
  That sounds awfully much like something I might be doing. Do you have any specific books you would recommend?
  - BeetleB 3y ago

nuker 3y ago

Oh sweet summer child …

rco8786 3y ago
Yes?

pacifika 3y ago

As an expat with an unusual name after the fourth time one party just agrees to the other party

krisoft 3y ago

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 https://www.youtube.com/watch?v=D88EZJ2wJ7M

rco8786 3y ago
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.

Retr0id 3y ago

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 3y ago
> 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 3y ago
  In academia this takes the form "I'm confused", which is code for "I suspect you're an idiot; please prove me wrong".

karaterobot 3y ago

> 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 3y ago
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 3y ago

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 3y ago

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 3y ago
>> * 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 3y ago

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 3y ago

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 3y ago

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 3y ago
> 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 3y ago
HELM 108

dudul 3y ago

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 3y ago

“Sounds like a subdural hematoma to me…” https://youtu.be/7-a2QBfFQeA?si=ApJLjBOf27ovN2kH https://youtu.be/7-a2QBfFQeA?si=ApJLjBOf27ovN2kH

sophyphreak 3y ago

So important. Very underused and underappreciated. Even more important for talking to people as an Autistic person and for talking to Autistic people.

da4id 3y ago

In emergency medicine we refer to this as closed loop communication.

jayeshsaita 3y ago

Nice one, liked the idea of intentionally committing a mistake to check if the other person catches it!

oooyay 3y ago

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.

btbuildem 3y ago

This is such a simple, and fantastically effective tool. I use it often at work - either as in "let me repeat this back to you just to make sure I got it" or "please tell me what you just heard" when I'm explaining something and it seems the other person is just yessiring-verygoodsiring along.

cxr 3y ago

This is called three-way communication.