Answer the question

Answer the question that you were asked, failing to do so wastes time in meetings¹. It is challenging being put to a question in a business setting that you do not know, do not want to answer, or cannot answer. In the case of “cannot answer”, for legal or compliance reasons, it’s fairly straight forward: you say so and the conversation progresses or it does not.

The vast majority of circumstances fall into the categories of “do not know” or “do not want to answer”. “Do not know” happens, we are not omniscient. The classic way to handle this is honesty: “I need to check on that, I will get back to you with an answer by $DATE”.

“Do not want to answer” is common, particularly for technical people (engineers) or technical people managers. This results in a few defense mechanisms:

• Flat refusal to answer: Seen often with technical project estimation. “I can’t say when this project will be delivered, because we haven’t (pointed every card|done three months of prototyping|built it before).”
• Techno-babble: “Well in order for our kubernetes deploy to achieve 99.9999% up time during the solar equinox we will have to get a new flux capacitor for our ansible dashboard’s high availability cluster. I have DORA metrics that will explain all of this in a confluence document about increasing stakeholder’s value.” The hope here is that a non-technical person will be too afraid of looking ignorant to push you for an answer. It might work. It won’t with a sharp executive.
• Dumping out your toy box: Rather than giving your best answer, you lay out every piece of context and information related to the query. I don’t want to give you an answer, but here’s everything I know, maybe you can make sense of it? Perniciously, sometimes people give an answer, but they lay out their toy box first as a hedge against being wrong. This isn’t much better because often people will miss your answer/assessment.

When you are asked a question that makes you squeamish, ask yourself later why you did not want to answer the question.

• Was it fear of being wrong?
• Was it fear of looking like you do not know what your are doing / your area/ etc?
• Do you truly not have the information (if so see above)? Will you ever have enough information? This point is key because it hinges on how much effort is expended to give you “enough” and what “enough” even is.

What can you do instead?

• Just answer: Unless the question is high-stakes, you are likely better off giving your professional estimate than a mealy mouthed hedge that confuses your audience.
• Provide your answer and then provide your context: This gets close to dumping out your toy box, but at least your answer is up front and the other party can know where you are starting from. “We will likely ship on $DATE but I’m concerned about $X, $Y, $Z. That could effect our ship date and therefore recommend we don’t communicate that date externally until $EARLIER_DATE”.
• Provide levels of confidence: “I’m 70% confident we will ship by $DATE”. This would be my preference from a report in a 1:1. There is always a level of uncertainty in any endeavor, and I as your manager would like to know whether we need to dig into that uncertainty or whether it is tolerable.
• Provide error bars: “We will ship on $DATE plus or minus 5 working days”.

1. Kellogg, D. The One Key to Dealing with Senior Executives: Answer the Question! https://kellblog.com/2012/01/17/the-one-key-to-dealing-with-senior-executives-answer-the-question/ (2012).