React to vs. Reflect on a question

There is a common anti-pattern in communication: trying to answer a question too quickly. The symptom of this anti-pattern should be quite familiar to people: in a review / meeting, someone asked a question, then one or several people jumped on to answer the question immediately. But after a few rounds of "answering", the person who asked the question, or the audience didn't really get a clear answer and might feel more confused.

I was having this anti-pattern myself a couple of years ago when leading a project. Back then, since I was running the project, I had the sense of ownership and impulse to answer any and every question regarding to the project immediately with lengthy explanations, otherwise my implicit fear is that I will be seen as incompetent. 

My boss back then pointed out to me his observation of my behavior and told me: "Carl, don't react to the question, reflect on it first!". That was when I started to have consciousness about this anti-pattern, and started to learn systematically how to reflect on a question before responding (if at all). Here are a few tips that I've learnt over the years about this anti-pattern.

Take a deep breath first

Answering the question after a few seconds delay is not only fine, but also desirable to some extent, since it will give more time for the whole audience to digest the question, before being able to absorb your answer. It also helps to ramp your adrenaline down, if you are really triggered by the question.

Ask yourself if you fully understand what is being asked

A typical failure model we've all seen is that someone asked a question, the person who is answering didn't fully understand the question, therefore either gave a wrong or irrelevant answer. The asker, being polite, did not explicitly point out that the answerer did not answer the right question, then everything turned into a downward spiral from there.

The solution is actually very simple: always assume that you didn't understand the question, repeat back to the asker "This is how I understand your question, is this what you are asking?", then ask additional clarification questions before considering to answer.

Understand what is the intent of the question

Not all questions are being asked with the intent of getting an answer. Sometimes, recommendation or disagreement are expressed as a question. Therefore to understand why the questioner is asking the question is essential to having the right answer. In order to really understand the questioner's intent, it's also useful to have a rough (if not precise) idea of what the questioner already knows. E.g. an expert asking a question about something in their domain probably means they are auditing whether you are doing the right thing instead of asking for a lecture. If you can't infer with confidence the intent of the question, it's always better to ask for clarification explicitly.

An example: 

Q: "Why is that the right thing to do?"

A: "Are you suggesting that we are doing something wrong and you have an alternative in mind already? I'd like to hear that feedback first if this is the case".

Ask yourself do you really have an answer

I've definitely stumbled on this quite a few times myself in the past, and I also write it in a different note about how a leader should not give assertive claims with false precision. Sometimes we might not have the right answer to the question being asked, and it could be because of many reasons, lack of context, lack of technical knowledge, or simply failed to consider something. Self-awareness plays a very critical role in getting this tip right, you need to be very aware of how much you actually know and how much you don't know. It would also be very beneficial to know who else in the same meeting knows more than you for this question, such that you can redirect the question to the right person. The worst scenario is that you try too hard to answer a question that you don't actually have an answer to, which can lead to no information added at best, false precision and pure BS at worst.

An example: 

Q: "How is this work done?" 

A: "I only have very high level-understanding of the work, X has much more in-depth understanding, so I'm gonna let him/her answer it."

Acknowledging that you don't have the answer is an option

After the previous step, you realize that you don't have an answer to the question, and no one in the meeting / your team has the answer, the only right thing to do is to acknowledge that you don't know the answer. Being able to acknowledge this confidently is already 100 times better than trying to provide a hand wavy abstract answer, and what can turn a situation where you might be perceived as "incapable" around is to provide concretely the next steps how and when you will be able to get this answer.

An example: 

Q:  "Why does this not work?" 

A: "Sorry, we do not know at the moment, but here is the plan, we are going to run test A which is going to tell us whether it's X failing, then we are going to run test B to determine whether it is Y's issue. We expect to have an analysis by the end of the week."

Get to the precise answer first, then provide context and explanation

Ok, given that you know the precise correct answer to the question, with all the level of details necessary, you might still fail answering the question, depending on how the answer is presented. Many TLs who had all the technical details (myself included in the past) tend to provide extensive details before actually answering a binary question. This situation also happens very often in chat threads: a question is asked, the answerer types in several long paragraphs of answers before getting to the point, then the questioner and other audience might need to hear / read through all those details that they might not even care about before getting a simple answer. Do it the reverse way, directly answer the question, then ask what level details the questioner wants to hear.

A example: 

Q: "Does method A work?" 

A: "Yes it does, Do you want more details on how it works?".