Why does everyone have a response, but no one is giving me a useful answer?

This month I would like to tackle a topic which comes up in every single conversation I have with people. I have hinted at it in every article I have written so far, but I have never dedicated a single article just to this theme. The topic is: listening to understand versus listening to respond, and how listening to respond is an unconscious thing we do which is damaging to our ability to communicate with others in a productive way.

Imagine you just suggested to your Team and your Team Lead that you should start using Kubernetes (or any other tool) for your project and their responses sound like this:

· It’s not going to work because of X

· We don’t use Kubernetes in this company

· No, I don’t think it’s a good tool

· You are wrong, Kubernetes won’t be that useful for this project

· I would not use Kubernetes

· How about we do X (something else) instead?

· Doing it in the way you suggest would be a disaster for our project

· I completely disagree with your proposal/idea/suggested way of doing things

· It won’t work in X situation

· Have you considered doing X, Y, Z instead?

· It’s not important, it’s not a priority

· We were already planning to do something to solve the same problem so I don’t think we should look at Kubernetes now (assuming their solution will be betterthan yours)

· Did you consider XYZ disadvantages?

· I don’t think we need Kubernetes, it’s fine as it is

· I just don’t think it will work

Does this sound familiar?

All these questions indicate that the people in the room were listening only so they can respond, not so they can understand.

I believe listening to respond is a behaviour we learnt in school and academia, where we were expected to come up with answers. At work, however, we need to listen to understand, and this is where most people are stuck. People behave at work (and in life in general) as if they were back at school, having to listen to respond.

Why do I say this? Let’s look at it objectively. In school you listened to respond: when your teacher had a question, there was always a “right answer”. If you didn’t know the “right answer” you were told to sit down. Maybe you were even told off by the teacher in front of everyone (this is a big problem for the limbic system, the emotional part of the brain, which is hardwired to feel threatened because it loses status when criticised in front of others). Worse, maybe the other kids laughed at you when you gave the “wrong answer” or if you did not know the answer. (At school you could never say: “I don’t know the answer”, you would at least try to guess.)

No wonder that, as adults, we keep talking to people like we always have to have an answer; saying “I don’t know, but I can find out” is seen as a failure by our limbic system (the emotional map of our brain), which is used to always having the “right answer” because otherwise it will be ridiculed.

What would responses that show me they listened to understand look like in the same situation?

If someone is listening to understand, their first few questions would be something like this:

· When you say “With Kubernetes we would be able to do X”, can you explain an example of X and how Kubernetes would do this in our team, on this project?

· What made you want to choose Kubernetes over other similar tools?

· My understanding of what you said about Kubernetes is that it can do X and Y when now we are struggling with these and we should implement it in ABC way. Is that what you are proposing? Or what parts have I misunderstood about your proposal?

· I liked XY about your proposal and I can see how these could work. What I am concerned about is Z problem — how much do we know about how it would resolve this situation?

· I understand it can do ABC and I can see how this could help DEF, but how would it resolve XYZ?

The questions above are constructive and they try to understand your position before standing against it.

If we translate the “listening to respond” questions into “listening to understand” questions, this is how they would look:

· Instead of “It’s not going to work because of X”, they say “What would it be able to do in X situation?” or “My concern is that in X situation it would do Y, and I won’t be able to get Z. How much we do know about its capability to resolve X problem?”

· Instead of “We don’t use Kubernetes”, they say “We’ve never used this before, so we’ll have to find out a lot about it before we start using it, but that doesn’t mean we can’t do it. Can you break down the potential implementation into the smallest steps for us, so we can see how it would work?”

· Instead of “No, I don’t think it’s a good tool”, they say “What made you want to choose this tool?” or “My concerns about this tool are XYZ because you said it can’t do ABC; how would we go about addressing these limitations that Kubernetes has?”

· Instead of “You are wrong, Kubernetes won’t be that useful for this project”, they say “What is it about Kubernetes that convinced you it’s a useful tool for this project?” or “What key aspects of what Kubernetes can do made you think it would be a useful tool for this project?”

· Instead of “I would not use Kubernetes”, they say “I am reluctant to use Kubernetes because of XYZ; what can you tell me about its capability to deal with these situations that might help alleviate some of these concerns?”

· Instead of “How about we do X (something else) instead?”, they say “When you mentioned Kubernetes, my mind went straight to X solution because of YZ aspects. How would Kubernetes be able to resolve YZ?”

· Instead of “Doing it in the way you suggest would be a disaster for our project”,they say “I hear it would resolve ABC, but I am concerned about XYZ; can you help us understand how it would resolve XYZ?”

· Instead of “I completely disagree with your proposal/idea/suggested way of doing things”, they say “My concerns about this tool are XYZ because you said it can’t do ABC; how would we go about addressing these limitations that Kubernetes has?”

· Instead of “It won’t work in X situation”, they say “My concerns about this tool are XYZ because you said it can’t do ABC; how would we go about addressing these limitations that Kubernetes has?”

· Instead of “Have you considered doing X, Y, Z instead?”, they say “When you mentioned Kubernetes, my mind went straight to X solution because of YZ aspects. How would Kubernetes be able to resolve YZ?”

· Instead of “It’s not important, it’s not a priority”, they say “To my mind this would not be a priority as I thought ABC would be more important. Can you help me understand what factors you have taken into account that made you try to resolve this as a priority?”

· Instead of “We were already planning to do something to solve the same problem so I don’t think we should look at Kubernetes now (they automatically assume their solution will be better than yours)”, they say “We were thinking about the same problem and the solution we had come up with was X. The shortcomings I see with Kubernetes would be ABC. Our X solution would resolve these in Y and Z way. How would the team have to operate around the ABC shortcomings of Kubernetes?”

· Instead of “Did you consider XYZ disadvantages?”, they say “My concerns about this tool are XYZ because you said it can’t do ABC; how would we go about addressing these disadvantages that Kubernetes has?”

· Instead of “I don’t think we need Kubernetes, it’s fine as it is”, they say “To my mind this would not be a priority as I thought ABC would be more important. Can you help me understand what impact this problem has on the project that made you want to try to resolve this now?”

· Instead of “I just don’t think it will work”, they say “My concerns about this tool are XYZ because you said it can’t do ABC; how would we make it work for our team, considering these limitations that Kubernetes has?”

What can you do when people just listen to respond?

If people are negative in their responses and clearly show they are listening to respond rather than listening to understand, there are some tools you can use to help them.

Here are some responses (adjusted to this situation) you can give when people only listen to respond:

• · When you say “It won’t work”, can you give me some examples of the sorts of things that came to your mind (about using Kubernetes) that made you think it won’t work?
• · What are the top 3 features (things, reasons) of Kubernetes that make you concerned about its effectiveness for this team/project?
• · Can I check we are both on the same page; what did you understand so far that I am proposing we do with Kubernetes?
• · What I understand so far is that you are concerned about X — when you say X, can you give me some examples to help me understand specifically what it is about X that makes you feel (my proposal) Kubernetes is not right for this project?

Here are the specific ways to respond to their unhelpful reactions above. When they say:

· “It’s not going to work because of X” — you say, “Can you tell me what it is about X that concerns you and makes you say it won’t work”?

· “We don’t use Kubernetes” — you say, “What is it about Kubernetes that you feel is not suitable for us”?

· “No, I don’t think it’s a good tool” — you say, “What specifically is it about Kubernetes that makes it not a good tool in your view”?

· “You are wrong, Kubernetes won’t be that useful for this project” — you say, “What is it about Kubernetes that you feel won’t be useful for this project”?

· “I would not use Kubernetes” — you say, “What is it about Kubernetes that makes you say you wouldn’t use it”?

· “How about we do X (something else) instead?” — you say, “What is it about Kubernetes that made you suggest we do something else?”

· “Doing it in the way you suggest would be a disaster for our project” — you say, “What specifically is it about Kubernetes or my proposal that makes you think it would be a disaster for our project”?

· “I completely disagree with your proposal/idea/suggested way of doing things” — you say, “What specifically is it about Kubernetes or my proposal that makes you disagree”?

· “It won’t work in X situation” — you say, “What was it I said about Kubernetes that made you concerned it won’t work in X situation?” or“Does it need to work in X situation?”

· “Have you considered doing X, Y, Z instead?” — you say, “What is it about Kubernetes that made you suggest we do something else?” or “what made you suggest XYZ when I mentioned Kubernetes/this problem/my proposal?”

· “It’s not important (it’s not a priority)” — you say, “When you say ‘It’s not important (it’s not a priority)’, can you tell me more about what made you say that?”

· “We were already planning to do something to solve the same problem so I don’t think we should look at Kubernetes now (assuming their solution will bebetter than yours)” — you say, “What stage have you got to with finding a solution for this problem (you are trying to solve with Kubernetes)?”

· “Did you consider XYZ disadvantages?” — you say, “What made you suggest XYZ disadvantages when I mentioned Kubernetes/this problem/my proposal? How do you envisage XYZ will negatively impact the project?”

· “I don’t think we need Kubernetes, it’s fine as it is” — you say, “When you say ‘I don’t think we need Kubernetes, it’s fine as it is’, can you tell me more about what you mean by that?”

· “I just don’t think it will work” — you say, “When you say ‘I just don’t think it will work’, can you tell me more about what made you say that? What specific aspects do you think will not work?”

Listening to respond leads to unproductive meetings, uninformed decisions and unnecessary arguments. If you notice yourself saying a mental “no” to someone’s proposal, ask yourself: “If I really want to say ‘no’ to this proposal, what proposal would make me say ‘yes’?”

If someone rejects your proposal with shallow responses such as “It won’t work”; become curious about their objections and barriers to saying “yes” to your proposal and listen to understand their objections, not just to overcome them.