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.
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.
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.
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.
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.
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.
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.
You'll need to paste this snippet into the JS console in your browser (or make a bookmarklet out of it and click it in order to reveal the article) because something on nytimes.com has caused it to break at some point in the last 8 years:
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?
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.
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.
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.
My comment was about Retr0id's, for which I cannot find any interpretation that isn't describing the purpose as being a test of attention. If you have a different view, can you elaborate?
"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
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".
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.
Right on. It's a fine strategy. An alternative one is to pick your second best guess (usually in an upward inflecting question-voice; semi incredulously), to see if this thing you think isn't the right idea gets approval. Then, you can ask your first best guess because now just asking will highlight the distinction, which may make the missing piece more apparent to both parties.
Really no wrong answer, so long as all parties are earnestly working towards the solution. The nice part about this strategy is it lets your 'most correct' answer actually be multiple answers that you whittle down, rather than making the judgement calls, yourself, on what the other person most probably means to what they least probably mean. You remove an assumption and lead with your biggest concern, even if that seems like a crazy suggestion. Once you confirm that it is crazy, you're closer to the target. And if the 'crazy' thing was right, then you get to skip a lot of the steps between your initial best understanding and the correct understanding.
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.
I might not have been clear, but this was my manager, who was not spending time pair coding with us and things like that. His job was to deal with things at a much higher level, and this was the type of thing he would do in meetings where we were writing design documents for complex new features or entire new systems; at the abstraction where he was involved, the discussion wouldn't be about the "how" but the "what" and the "why. Building off of your example, let's say one of his engineers wrote a design document about a new piece of data called Foo that was getting added to our database, and the document mentioned that the new piece of data would be considered optional rather than required because we'd only have access to it in the newest version of the client software, and the EOL for the last version not to provide it was two years away. He might mention that customer Bar just upgraded to the latest version of our client and expressed interest in using the Foo data, and ask why they wouldn't be able to get the Foo data from their client, with the idea that he'd be corrected and told that the customer would be able to get the Foo data because they had just upgraded and the latest client had access to it.
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?"
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.
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.
> 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.
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
> 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.
this is just idealistic and doesn't acknowledge the power dynamics in any organization, nor does it factor in peoples' individual personality traits.
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.
I definitely see how it might seem like it would come across this way, but this was all within the context of a manager who went out of his way to establish himself with his team as someone who did _not_ consider him a technical expert compared to the engineers on the team (to the point where I think he honestly didn't recognize the full extent of his skills). It wasn't uncommon for him to tell people that the reason he switched from being an engineer to a manager was that he didn't think he was good enough at the engineering side of things to be successful at it. He viewed his job as doing whatever he could to make the people working for him successful, and that included setting the expectations that ideas should be judged on their own merits and not based on who they came from. This is obviously not something that just can happen because someone says it should, and I'm not really sure there's any amount of evidence I can offer to be convincing enough that he did try to maintain an environment of trust and lack of judgment, but I can at least say that I genuinely felt like that was the case, and that I only ever experienced and saw encouragement for us to consider any technical question, doubt, or feedback from one member of the team to another in good faith, regardless of the relative tenure or title of the people involved.
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.
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.
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.
I only do it when important. And in person/phone - not over IM/email.
If it's a bunch of tasks for the other person, I say "Just so that we're on the same page, can you tell me what you're going to do?" Or even "So, after this long ramble of mine, do you know what needs to be done?" - this often triggers them to rattle off a list.
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.
> 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.
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
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.
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.
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 :)
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).
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.
>> * 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.
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.
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.
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".
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.
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.
71 comments
[ 3.3 ms ] story [ 160 ms ] threadPutting 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.
The quote is "a briefing is a passive activity for everyone except the briefer."
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
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.
Of course, there is this counterpoint...
https://www.youtube.com/watch?v=cY_o4A1wzsg
You'll need to paste this snippet into the JS console in your browser (or make a bookmarklet out of it and click it in order to reveal the article) because something on nytimes.com has caused it to break at some point in the last 8 years:
HN comments: <https://news.ycombinator.com/item?id=9818310>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.
It's a bit like writing unit tests that fail, before you implement the change that'll make them pass.
"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
Really no wrong answer, so long as all parties are earnestly working towards the solution. The nice part about this strategy is it lets your 'most correct' answer actually be multiple answers that you whittle down, rather than making the judgement calls, yourself, on what the other person most probably means to what they least probably mean. You remove an assumption and lead with your biggest concern, even if that seems like a crazy suggestion. Once you confirm that it is crazy, you're closer to the target. And if the 'crazy' thing was right, then you get to skip a lot of the steps between your initial best understanding and the correct understanding.
Great teams are the ones where no one has to preface questions with this sort of throat-clearing remark (and so they don't).
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.
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
this is just idealistic and doesn't acknowledge the power dynamics in any organization, nor does it factor in peoples' individual personality traits.
- 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.
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.
https://news.ycombinator.com/item?id=27409357
https://news.ycombinator.com/item?id=23440902
https://news.ycombinator.com/item?id=16977911
https://news.ycombinator.com/item?id=22760420
Sounds like a great strategy, but:
> Can you repeat back what I said?
Seems like it'd sound superior or arrogant. Betting you have better strategies than this?
If it's a bunch of tasks for the other person, I say "Just so that we're on the same page, can you tell me what you're going to do?" Or even "So, after this long ramble of mine, do you know what needs to be done?" - this often triggers them to rattle off a list.
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.
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
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.
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).
* 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.
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.
• 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).
Greyhound is a nice example. And it was a very noisy environment
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".
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.