Speaking about Speaking, Part 5 — Taking Questions
This is the fifth in my series of posts on giving technical conference talks. We have discussed preparing yourself, organizing the content, preparing the stage, and giving the talk itself. You’re now done with the talk, and people want to ask you questions — probably lots of questions. This could take the form of some extra time at the end of the talk slot, or it could be people coming up to you afterward during the conference. Either way, you surely said a lot of interesting things, and almost certainly people who watched you speak will want to continue the discussion.
The Goal is to Learn
I find that it’s not helpful to come at questions as if they are a form of attack (rarely they are, though — see below). Instead, I like to have the attitude that we are all trying to figure this stuff out together.
Even if the questioner asks their question awkwardly, they are — for the most part — just trying to learn more. Often, a questioner will suggest to me something I hadn’t considered, or point out a technology I didn’t know much about, or propose an even better metaphor to illustrate a point. This is great — now I’ve learned something too.
I’ll say this about questions — if no one has any questions, it’s far more likely that I did not say anything interesting than I said everything perfectly! If I don’t get any questions, I question myself! :-)
Restate the Question
Take the opportunity to briefly restate or reform the question, especially if we are being recorded. It gives me a few more beats to think about a good answer, but trying to summarize it back can also help to clarify what is being asked.
The same is true of questions — if you can restate it simply and clearly, you’re halfway to answering it. And sometimes the restatement helps the questioner see that they already know the answer! See Active Listening as another use of this technique.
“Good Point”
Having empathy for the questioner, who probably thought a lot about their question, is a nice thing to do. In that moment, they are almost as exposed as you are, so you probably know how they feel. I like to acknowledge most questions with “That’s an excellent point”, or “Good question”, or “You’re raising a subtle point here”. (I only do this if I actually believe it, but when I believe it — which is most of the time — I try to acknowledge it explicitly)
Even if you’ve heard the same question a million times before, it’s the first time the questioner is asking it. You can even make that a good thing: “Yeah, I get that question a lot …”.
“I Don’t Know”
A legitimate answer to a question is that you don’t know the answer. The answer may be context-dependent (the interesting ones are; see below), or you may simply not have had any experience that helps you answer it. Honesty here is the best policy. You’re not doing yourself or anyone else any favors by pretending you know something you don’t.
“I Don’t Have an Opinion on That”
There are a lot of areas in technology where I simply don’t have an opinion. Not being very familiar with front-end technology, for example, I will openly say that I have no opinion about which Javascript framework to choose.
Many things in technology I do have an opinion about — maybe even a strong one — but maybe it’s inappropriate for me to offer that opinion in that moment. Maybe it would come across as rude or insulting, or maybe it would publicly reveal something proprietary, etc. Either way, I just acknowledge that I can’t express an opinion on that topic.
Of course, if I do have an opinion, I express it, as people who work with me know :-).
The Unpleasant Questions
Some types of questions are less fun to answer. Here are a few.
Unpleasant Question #1: The Dissertation
This is typically less a question than it is a statement, and sometimes begins with that dreaded preamble “Are you familiar with …” or “Are you aware that …”. It often goes on for a while, and ends with a period instead of a question mark.
Let’s be honest — the questioner is not really interested in your thoughts or opinion, but is instead using the opportunity to demonstrate their own knowledge and look smart in public. Fortunately, I rarely see this in industry conferences, but it is rampant in academia.
I usually respond with “Thanks, that’s a great point.” And I leave it at that. No one in the audience missed what the questioner was doing, and they have already been rolling their eyes. Take the high road.
Unpleasant Question #2: The Huge Context-Dependent Question
This is where they are asking something like “Should I choose Google or AWS?” (which I got recently), or “Which event system is better — RabbitMQ or Kafka?”. The answer, as with all interesting questions, is “It depends”.
I usually point out that I would need to know a lot more about their situation to make an informed recommendation. Sometimes I might try to outline some criteria which they could use to help them make that decision, or I say “I’m not sure about your situation, but we chose X for Y reasons”.
The other form this takes is some conditional that presupposes a bunch of context, like “Given that wedon’t have any time in the schedule for testing in my organization, how can weimprove quality?”. Uhhh, you probably can’t? We are going to need to play the Five Whys to figure out what is really going on, and in this particular example, there are clearly more fundamental problems at work. But most of the audience would not get a lot of benefit from that Socratic back-and-forth, so I often offer that if they find me later in the conference, I’d be happy to spend a few minutes learning more and offering some thoughts: “I would need a lot more context about your situation to give you a satisfying answer, so maybe you could find me later and we can talk more about it.”
In no circumstances do I pretend that I can diagnose and solve their complex problem(s) in the moment.
Unpleasant Question #3: Huh?
I’ve had a few experiences where I simply can’t understand what the questioner is asking. I’ll unabashedly ask them to repeat it once, and if I get it the second time around, great. But that does not always work.
It’s OK to ask for clarification or say that you don’t understand what is being asked. Chances are the audience does not understand it either.
Sometimes if I think I can interpret part of the question, I acknowledge that with “Well, I don’t think I fully get all the nuances of your question, but here are my thoughts on X”.
Unpleasant Question #4: The Multi-parter
Sometimes someone will ask two or three or four questions in one, and I find it hard to keep track of all of them. So I’ll just start with one of them, usually the first or the last (whichever one I can remember), and answer that. If I can remember the other one(s), great, but I don’t mind at all asking the questioner to repeat it.
Unpleasant Question #5: The Gotcha
Sometimes an engineer can’t resist pointing out some inconsistency in the wording or a diagram. I find it best to thank them and move on.
Unpleasant Question #6: The Troll
Some questions are more about generating controversy than about finding the truth or clarity. Just as with confrontational comments on blog posts, or adversarial @-mentions on twitter, I try not to feed the trolls.
Be Generous With References
I’m not as diligent as I should be about putting explicit references in my talks (that extra effort sadly always seems to get dropped). But often the answer to a question is that the questioner really should go read a particular book or watch a particular recorded talk. It takes nothing away from me to offer a quick thought, and then suggest that they do further reading from the expert in that area.
Recently I’ve been talking about Managing Data in Microservices, and introduce (all too briefly) the idea of using the Saga pattern to coordinate “transactional” work across several microservices. In almost every answer to a question about more detail here, for example, I refer people to Caitie McCaffrey’s excellent talk on exactly that subject, which goes into far more detail than I do.
Be Careful with the Sarcasm
As people who know me know, I am a very sarcastic person. And sarcasm has a place in communication to help illustrate a point. But this is best done in a self-deprecating way, and under no circumstances should a speaker use sarcasm against the questioner. That’s just rude and hurtful.
If you absolutely can’t resist the pithy response (as I often cannot), then one technique to blunt its effect might be something like “Well, my flip answer would be …”, followed by a kinder and wordier restatement of the same idea.
Set Your Own Boundaries
I know a few (excellent) speakers who don’t take questions at all. They have undoubtedly had bad experiences with particularly confrontational questioners, and are well within their rights to set whatever boundaries they like. They are the speaker, after all.
I know others who make it clear at the end of their talk that they are open to taking questions on some topics and not others. This is also completely within their rights.
Concluding Thoughts
Every question is an opportunity for improvement. In the last installment of this series, we will discuss some post-talk retrospectivey things we can do to help us be better next time. As one obvious foreshadowed example, I’ll note that one of the very best ways to improve a talk is to use audience questions as the jumping off point — I often ask myself how could I change the presentation so that they did not need to ask that question?
Thanks for reading this far. As I hope you are seeing, questions are a great opportunity to continue and enrich the conversation, and you might learn something yourself in the process.
