Let me repeat that back to you
roughlywritten.substack.com
roughlywritten.substack.com
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.
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...
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:
document.querySelector(".g-result.g-noText").style.display = "block"
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
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 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.
The quote is "a briefing is a passive activity for everyone except the briefer."
• 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
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 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
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".
* 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.
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.
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).