I went snowboarding for the first and only time when I was in College. I spent my day on the easy slopes, and over the course of the morning, got to the point where I would only fall down two or three times between the top of the lift and the base. Just before lunch, a friend passed me on the way from high on the mountain to the lodge and seeing my lack of technique and timid style, suggested that I “don’t lean back so much, lean forward.” The next day we sorted out the confusion: when she said to lean forward, she meant for me to put weight on my leading foot. Being uncoordinated in general, and unfamiliar with snow sports specifically, I understood the instruction to mean leaning more towards my toes.
If you’re familiar with snowboarding, you know what happened next. Putting too much weight on one side of a snowboard is a recipe for what those in the know call “Catching an edge”. Your board digs into the snow and stops moving while the rest of your body continues forward, compliments of Newton’s first law – a face plant is nearly inevitable. From the moment I got that tip until I hung up my board at the end of the day I spent most of my time sliding down the mountain on my face. I’ve since learned to ski.
From a communication perspective, our odds should have been good. We both spoke the same language natively, we both came from similar backgrounds and shared many of the same idioms. In theory, words would mean the same thing to both of us, but due to the ambiguity of the word “forward” I missed the point entirely, and took to heart exactly the wrong message.
Miscommunication happens all of the time in engineering and as a manager, this is my first assumption when I hear of or see someone not responding to feedback well. Additionally, debugging miscommunication is one of the easiest first steps you can take, so it’s a great first thing to dig into anytime something seems amiss. Fixing broken communication is also one of the most satisfying things to accomplish as a manager – it is one of the things that you can do as a manager that has immediate positive impact, and most times, and honest misinterpretation is nobody’s fault, so you don’t need to be the bad guy.
My first step in checking if what I said was well received is to ask the other party to paraphrase it back to me. Once, I was working with an engineer who had a tendency to be very negative in team retrospectives. The feedback they brought was generally on point and helpful, but the way they phrased it didn’t make the feedback any better, and the negativity in team meetings was hurting morale. I brought it up in a 1:1 and they took the feedback graciously, but when I asked for them to echo it back in their own words, they had taken my feedback as a suggestion to not speak up as much, and keep their feedback to themselves. This would have been a huge loss both to that engineer and their team! I was able to clarify and give some suggestions (in this case, focusing on the impact of bad practices, rather than speculating on their motivation) to make sure the feedback wasn’t taken the wrong way.
Just repeating things back can frequently solve a lot of issues, but there are other tools I’ve found helpful as well. One is to ask, either in the moment or in a follow-up, what they plan to change or do differently as a result of the feedback given. This can be very helpful in understanding if the interpretation is correct – not just the exchanged words. It can also be a chance to check if my feedback is going to lead to unexpected or undesired consequences.
The last technique I often use is a follow-up in writing. This isn’t without its own risk, because the formality of written communication might spook the person you’re working with, depending on what your normal working relationship is. That can be mitigated with an explicit conversation about why you are following up in writing. The huge advantage with written communication is the lack of immediacy. There are a lot of things that can be distracting when you are talking with someone one on one, that might make it hard for someone to be present in the conversation. By following up in writing, the other person in the conversation can take their time to read and process the information, several times if needed. If someone does not speak the same native language as yourself, it removes a potential barrier in getting the message. It also gives you something concrete to refer back to later if there was a miscommunication. It’s hard for me to remember word for word what I said in person, but with a written record, I can clearly tell if my communication was unclear, and adjust accordingly, or if I said what I meant and it was simply misunderstood.
It’s also worth noting that all of these techniques are great for any conversation you might have at work, not just if you are talking to a direct report. If you are an engineer working with a peer, it can resolve so many potential issues just to clarify that you are understanding each other. If you are talking to a manager, it’s even more valuable to get what they are telling you in writing – in my experience managers tend to be less adverse to written communication, and if there is ever a disagreement about instructions, it’s great to have something written down. You also don’t need to be the one giving feedback to apply any of these. If you are receiving feedback, it can be super useful to check your understanding, especially if you have concerns or don’t immediately agree.
This might not sound like incredibly profound advice, but I’m sometimes shocked how often I’ve encountered gaps in understanding, either in my own communication, or when I’m helping someone else debug a tricky conversation. It’s such an easy first step and can solve so many problems, there’s no reason not to clarify the message if you ever detect the possibility of confusion.


Leave a Reply