I received some feedback recently. Updates to execs need to be crisp, and to the point. If more detail is needed, that can be provided later.

In the middle of a critical outage, I had to provide an update to senior leadership. It took a few tries for me to get to the right level of clarity in my message. The first version was a really long document that was about 6 pages long, with all the details. Then it became a 1 pager, with a 3 paragraph summary. The final version I sent out was one paragraph. It was well received and sufficient for the moment. A day later I was asked for more detail, and the one pager I prepared came in handy for the task.

I wish I’d gotten to this level on the first try but hey, now I know. And I’m going to work on this.

What was I missing?

I was not thinking about my audience, and thus, I likely did not give them what they were looking for. I was just writing how I knew how to write. Two of the execs I shared my answer with, gave me some feedback. They asked me to think about who the audience of my report was, what were the top three questions they’d get when they shared it with their audience, and to answer those questions in my report.

Key points

Who is the audience? I did not think about that. I was writing for myself. I did not try to find all the relevant information in this situation and then I wrote a report. I was not really writing for the General Manager of a business unit at Cisco. I was probably also not writing for the SVP of Engineering of that business unit at Cisco. Did they need all the technical details or did they need to know just what happened, how long it lasted and how we were addressing it? Probably the latter.

What is your immediate audience going to do, who are they going to explain this to? Another key bit of feedback was to think about who they were going to share this with. Was the GM going to take it to a customer, or someone internal like Sales or Customer Success? Would I change something about the report if it was going to be shared externally? And what I would I do differently if it was an internal only report? Those would have been good things to think about. If I was writing for an internal audience, I would have provided a lot more detail. Even if there was a lot of detail, I should have provided a crisp summary instead of a really long document. Just because we collected all the details, it did not mean that we should have put all that into the report.

What are the top three questions those folks are going to ask? If a regional Sales head was given my document, what would they get out of it? And what else would they ask? I think they might want to know what happened, what was the impact and how we’re going to prevent it from happening again. I should start with the answers to those, and only then provide additional detail. Any detail that did not answer these questions, was not going to be helpful and would only end up confusing the readers.

Conclusion

The lesson here is simple but easy to forget in the moment: start with your audience, not your data. When you’re deep in an incident, the instinct is to dump everything you know into a document. But the people reading your update are not looking for a full investigation. They need to know what happened, what the impact was, and what you’re doing about it. Everything else is supporting detail that can come later if asked for.

I’ve started applying this framework to every update I write. Before I start typing, I ask myself three questions: who is going to read this, what are they going to do with it, and what are the first three questions they’ll ask? If my update answers those questions in the first paragraph, I’ve done my job. The rest is appendix material.

References

https://medium.com/lessons-from-mckinsey/the-pyramid-principle-f0885dd3c5c7 https://lethain.com/pyramid-principle/