Photo by rawpixel
“Words have meaning.”
This is an often-used phrase to try and push for clarity. The problem is that words have lots of meanings. What does it mean for something “to be in the cloud”? What are microservices? What is Agile? Our industry is full of buzzwords which rather than clarifying things only serve to obscure conversations, especially when you take into account product vendors wanting to latch on to the latest trend.
Even forgetting about buzzwords, we assume because we know what a word or phrase means to us that it should mean the same to everyone else. We also often feel that we don’t need to state the obvious, but I can tell you after many years in the industry there is no such thing as the obvious. What’s obvious to us as individuals is usually the result of unique chain of experiences and insights that make the obvious less so to different people.
This gets down to the notion of ambiguity and how so many of our professional conversations are riddled with ambiguity. I’ve discussed in a previous blog that most of the time when we’re in meetings where everyone nods their heads in agreement they leave with different understandings of what was discussed and that we need to take ownership to improve this situation.
So how do we take ownership and break past ambiguity?
One of my favorite tools is readback, which can be used to both validate that you’ve understood others and that others have understood you.
Let’s first tackle making sure you’ve understood others as it is easier to control. The challenge for some of us is that we fear looking bad by not understanding things and asking questions. I can assure you we look a lot worse in the end if we make mistakes because we *didn’t* ask questions.
I’ll try to use a couple different techniques. The first is a simple restatement along the lines of “what I hear you saying is…” or “ok, so my understanding is…” and then rephrase what you’ve heard with your own words. This will usually create some back and forth discussion which is good! The whole idea is to keep reading back until both sides feel communication has actually happened.
Taking that further, you can structure with something like “to summarize, you want to do three things….” Quantifying what you’ve heard helps create a quick framework to the discussion. The speaker might think they told you two or four things, so even though it might sound right, there’s a distinction to be clarified.
Now we can flip that around and make sure people have understood us by asking them to repeat back what they’ve heard! Try something like “what were the 3 key reasons for choosing…” to give them a structure for reading back. Or “can you summarize next steps?” Listen closely to the results and push to make sure they really understand what you wanted them to get out of the discussion.
I’ll often close with asking “what didn’t make sense?” I used to (and sometimes still) ask “does that make sense?” The problem with the latter phrasing is that most people want to say say “yes”. If you ask what didn’t make sense, you’re taking on the burden of unsuccessful communication rather than pushing it to them. This approach makes people more likely to actually respond with details. And instead of a yes/no question you’re assuming there’s a more detailed answer which will trigger a better response.
I know some of us don’t like asking questions, that we want to appear like we get everything. However, people will appreciate that you care enough to take the time to get things right, and more importantly, you will get things right rather than just hope that you have.
Seth is the CTO at Bounteous where he sets the technical strategies for both his firm and his clients, and where he coaches technical and non-technical leaders.