Just tell me what’s next!

I was in a oncall handoff meeting. The outgoing oncall engineer had been going on for almost 5 minutes on a ticket.

“I tried x and it didn’t work. So I tried y it still didn’t work…”

Finally I asked.

“Jammy, what was the impact of this problem to customers?”

“Just occasional latency spikes at p99.9. It triggered auto cut ticket to oncall”, Jammy answered.

“So do you have a hypothesis on what could be the root cause of the spikes?” I followed.

“Not really. I thought about A then B then C …”

Jammy started again.

I almost laughed.

“But by now you must have known what can NOT be the root cause?”

“Yeah … we are pretty sure it is not A or B.” Jammy hesitated.

“So what would be your suggestion to the incoming oncall engineer?” I asked.

“Work with team X to try C to confirm if C is the root cause.” Jammy answered.

“All right. Let put this to the ticket:

We observed p99.9 latency spikes on API abc starting [timestamp 123]. We confirmed A and B are not the root cause. The next oncall should work with team X to try C to continue the investigation.”

Let’s move on!

The moral of the story: communication at work is not a detective fiction, don’t make listeners guess the ending - start with what is the problem/impact, then so what (why it matters to the listeners), then tell them what’s next.

Is less always better? It depends what your listeners need to hear and want to hear. It took me years to appreciate how to communicate for the sake of the listeners, not for myself. It is a form of empathy, or you can say “listener obsession”, working backwards from what the listeners need to hear in Amazon jargons.