[Product manager]: Is the backend down?

[Engineer]: We changed our database configuration on Tuesday, so that’s seeming really weird that this is showing up now.

[Product manager]: What’s happening?

[Engineer]: We’re seeing requests taking 10 seconds or longer to process. Customers have a 1 second timeout.

Engineers, take note: every single “non-technical” person (product managers, people managers) reading these lines is groaning and cursing our profession. That poor product manager still isn’t sure if the backend is down.

Not answering questions clearly limits careers. As you grow in seniority, managers and leadership need to like working with you. If conversations with you frustrate them, you’ll have a hard time advancing. On the other hand, clear responses build trust and signal competence. This makes it easier for your manager to advocate for your advancement.

If you ever work in ops – if you’re on an oncall rotation or involved in incident responses – answering questions clearly reduces communication misses and cuts down your mean time to recovery (MTTR).

Compare that initial example with the following:

[Product manager]: Is the backend down?

[Engineer]: Yes, customers can’t use it. They have client-side timeouts of 1 second, and we’re seeing all requests take 10 seconds or longer to process. I think this might be related to a database config change we made on Tuesday, but the timing seems weird. We’ll know more in 30 minutes.

The framework

Answering questions clearly is a learnable skill, and one that few of us are ever taught. This is a method that I picked up at Amazon for answering questions that’s become engraved in my brain. There are three steps: answer, explain, and (optionally) educate. Like all communication frameworks1, the intent here isn’t to parrot exact wording, but rather to internalize useful patterns of communication.

Underlying theme: have empathy for the questioner

How can we minimize the thinking our questioner has to do? What do they know? What do they care about?

Each step of this framework is to minimize thinking for the questioner and to tailor your response to their knowledge and interests.

Step 1: Answer

When answering a question, the first words out of one’s mouth should be a direct answer to the question2. Notably, providing context is not a direct answer to a question.

Where’s the butter?

The store only had salted butter, so we need to try Star Market.

That is pure context. And is not an answer. Acceptable answers are: “In the fridge”, “On the counter”, or “There is no butter”.

Answering a question means making a judgement call. This can be difficult! It’s very easy to word vomit, providing unthinking context. Doing so produces extremely poor signal to noise and confuses the questioner. Directly responding with an answer, however, frames the response, giving the questioner a bearing. Rather than searching for “where is this going?”, they understand “okay, weird, the butter is in the fridge in the basement” and are now ready to hear your explanations.

Step 2: Explain

Next up is the explanation: an anticipation of the questioner’s follow-up questions.

This is a chance to put ourselves in the questioner’s shoes and understand what information they’d ask about if we stopped the response then and there. Sometimes this can be nothing!

Will you be there at four?

Yes.

That might be all the questioner cares about! In which case, you’re done3! Hooray4!

For “Is the backend down?”, however, a simple “Yes” will not satiate the questioner’s curiosity.

The engineer can foresee the follow-ups of “What’s happening?”, “Why?”, “When can we fix it?”, which leads to the explanation of: “Customers have client-side timeouts of 1 second, and we’re seeing all requests take 10 seconds or longer to process. I think this might be related to a database config change we made on Tuesday, but the timing seems weird. We’ll know more in 30 minutes.”

Step 3: (Optional) educate

Here’s the risky one: educating. Educating means providing information that the questioner would not ask for that we think would be useful for them to know. Again, this is not heedlessly sharing context, but is targeted to information we really think they could use. This is risky because it’s akin to offering unasked for feedback. We could make the questioner defensive or – more likely – make them bored by giving information they don’t care about.

We might really care about the mechanisms by which database config changes get applied, but our product manager there probably doesn’t care in the heat of the moment.

Educate lightly.

Will you be skiing Sunday?

Yes. We’ll be at Loon from noon till six. I’ve been really nervous about getting back on skis, but it’s going well so far.

Unclear questions

There are questions which are hard to answer because, frankly, we aren’t sure what’s being asked. The principle to fall back on: empathy for the questioner and trying to tailor answers to their knowledge and interests.

Uncertainty about what a question means comes in shades. Do you have a good guess? Call out the uncertainty and answer what you think the questioner is curious about. Inferring what the questioner is after saves both of you a back and forth.

I think what you’re asking is [XYZ] in which case, yes!

Are there just two possible interpretations? Answer both! It’s quicker and less work for your questioner.

If you’re asking [ABC] then yes, but if it’s [XYZ], then no because that’s not yet possible due to funding constraints.

If you have no idea, then say so, and in doing so help your questioner understand your confusion.

I’m not quite sure what information you’re after. It seems like maybe you’re interested in [XYZ]?

Closing

Answering questions clearly is a skill. It takes practice. It takes awareness. Both can be built over time with attention. I recommend looking for extended back and forths (e.g., the example at the top) as a signal that a question could have been more clearly answered. It’s an opportunity to ask how the initial response could have been more focused and aligned with the questioner’s knowledge and interests.

Done repeatedly, this becomes a habit, a habit that unlocks career progression, efficient ops, and less frustration in day to day conversations.

  1. e.g., the rightfully ubiquitous “When $STRICTLY_FACTUAL_ACTION happened, I felt $EMOTION because I needed $HUMAN_NEED. Would you $CONCRETE_REQUEST?” ↩︎

  2. This was drilled into me in pre-AP classes under the form of the mantra “Answer the Question Asked” (ATQA). ↩︎

  3. Yes, I too am thinking, “Why waste time, say lot word, when few word do trick?”. ↩︎

  4. And yes, you might not be comfortable letting a naked “yes” dangle out there. In low-stress situations, padding out responses with niceties can feel more natural: “Yes, I’ll be there!” or “Yes, see you soon!”. In high-stress situations, however, terseness is often more appropriate – keeping the incident call chatter down and allowing extreme focus on the matter at hand. ↩︎