Answer, Explain, Educate. In that order.

I first learned this tip from a Distinguished Engineer at Amazon. It changed my life when it comes to dealing with managers/execs.

As an engineer, I’m not a smooth talker by any means. In my career, I have encountered moments where managers and directors have been frustrated whenever I open my mouth, especially in high stakes moments like customer emergencies. It took me years to understand why they would re-ask the same question with different words, or say “get to the point already”.

It turns out that I started by educating them, then explaining, and then if they were still with me (most of the time they were long gone or spaced out), I might finally answer their original question.

In my defense, as an engineer, details is what I’m best at. I can effectively educate you on exactly how our code works, why it was written this way with this language with this style and these standards. In fact, I can give hour long lectures on such details. And I’m quite proud of it! It means I’m connected to the juicy details.

But, when someone high up approaches me, they aren’t looking for that amount of detail. They have bigger problems, and I have some kind of key information they need in order for them to make an important decision that affects the entire organization. They want just enough input to aid them in that decision. They want answers.

So, the trick I developed over time is to say everything I normally would with my mouth closed, and only open my mouth for the very last sentence. And fast-forwarded. (Otherwise it’ll be a really long awkward silence.)

Allow me to illustrate.

Scenario: Oncall Emergency

Imagine you’re responding to a customer emergency and the room is tense. Every second of the unfixed issue leads to revenue loss, and your boss and your boss’s boss all the way up more chains than you can imagine are staring at you. Your top dog boss asks, “Give me a status report.”

The Wrong Way to Respond

Here’s what we engineers usually do on instinct:

We might respond like this:

The data ingestion pipeline is really complicated and hard to debug. Every time I go into it, I need to first need to look at the dashboard to find the right host that has the issue, grep the logs, and reference the code to see if the latest version of our code even got deployed. Assuming it got deployed, I then have to examine the logic to see where a bug might be. Assuming the bug is even in here, and that I am looking in the right place, I may need to engage the infra team, my product manager, our customer support team, and my manager.

By this point, your top dog boss would be incredibly confused.

Here is what they heard:

• detail, detail, detail. boring detail after boring detail.
• don’t care, don’t care, don’t care. definitely don’t care about that detail.
• what was the status again?
• more boring stuff. about to fall asleep.
• what was my question again?
• who’s talking again?
• why are they talking?

To be fair to you as the engineer, nothing that you said was inaccurate. You indeed take those steps in order to troubleshoot the problem when you’re oncall. Your top dog boss’s thoughts here do not reflect poorly on your technical competence.

But, you did not answer their question.

If you continue to leave their question unanswered, here what can happen, from mild to worse:

• They will ask you the same question, again.
• They will reword the same question and re-ask.
• They will start to show signs of irritation.
• They will start to show visible signs of frustration.
• They will start yelling at you.
• They may consider firing you. (hopefully not. assuming you are a competent engineer, if it gets this bad, your manager will probably intervene and cover you. but it doesn’t change the fact that you could have avoided this if you re-oriented your communication.)

The Right Way to Respond

Here’s what we should train ourselves to do:

The response will depend on whether you know or don’t know the root cause.

Unknown Root Cause

If you don’t know the root cause, here’s an example:

There’s an issue in our data ingestion pipeline. I don’t know the root cause yet, but I started investigating. I’ll keep you up-to-date with the latest.

Your management chain will hear:

• We don’t know the problem yet, but our reliable engineer is working on it. Furthermore, our engineer will update us on any news.
• I don’t need to spend any more brainpower on this issue anymore.

To be clear, you still need to actually figure out the issue and fix it. But, in the meantime, you’ve bought yourself some precious uninterrupted time to attack the issue.

Known Root Cause

If you do know the root cause, here’s an example:

A bug got introduced to our data ingestion pipeline in yesterday’s code deployment. The mitigation is to revert that code deployment to unblock customers. After the mitigation, we should fix the bug with another code deployment, but we should be careful to test it against this failure mode that we just encountered.

Your management chain will hear:

• Wow, our engineer found the issue.
• Wow, there’s already a path to mitigation so we can stop losing money.
• Wow, our engineering team knows what to do next to avoid this issue coming up again.
• Great, I don’t need to spend any more brainpower on this issue anymore.

Keep in mind that this isn’t about technical competence at all, even though your management chain’s perspective of your technical competence probably went up. It’s about communicating effectively, which means keeping communication short and sweet and to-the-point.

The main benefit here is to take the attention off your backs. That way, you as an engineer can get to doing what you’re good at.

Now, to reiterate, you still do need to actually perform the mitigation and perform the fix. But at least you can do so in peace.

In Sum

As engineers, our pride and joy is in the layer of details. In fact, we know those details better than anyone else, and our craftsmanship powers the world.

But, when we answer questions in high stakes scenarios, especially to someone who’s high up, who has little knowledge or care of the details, we should resist our natural urge for barfing details, and be brief. Do whatever it takes to get them off our backs so we as engineers can go back to actually fixing the issue.

Keep in mind that it is fair for them to ask us what went wrong. It’s not an attack on our work. The system is always complicated, and something will always eventually go wrong, even though we strive to minimize that. They need to make their best decisions up there, and we need to do our best work down here. Both are important.

But we can make things easier for both them and us if we answer first. And if they ask for it, we can explain. And if they want to know even more, only then should we educate.