How to write to CXOs and supervisors
This post will teach you how to write to high-level business people.
Over ten years ago I enrolled into an MBA where I learned how to write to high-level business people. I have refining what I learned since then. I am sharing what I have learned to save you the cost of an MBA and over a decade of practice.
Leaders are busy. Get to the point.
Bosses, supervisors, directors, and CXOs are busy with many responsibilities. We should aim to take up less of their time and give them actionable information to make decisions faster.
Leaders should read your message and get all the necessary information in less than a paragraph. That is difficult to do after. With practice, it becomes easier.
Leaders should be able to respond quickly too. Your questions to them should allow them to reply with "yes," "no," "why?" or a concise sentence. A faster response will enable them to move onto the next item on their busy day.
Two requests to a leader.
We will review two requests from an engineer to a CEO. The engineer was tasked to investigate a "thing" and find the best choice to get it done. The engineer will present the best options so the CEO can make the final decision.
Here are two examples: a not-so-good one and a better one.
A not-so-good example.
I have spent the past few weeks researching this "thing." I have done multiple assessments, spoken with many vendors, and conducted various tests. I have narrowed down the final choices for the "thing."
The first choice is not as good because it requires "widget X" and will take several months to implement. But it will save us 5% per month after two years. Read the attached document for the rest of the details.
The second choice is better. It does not require any widgets, but it will still take several weeks to implement. It will only save us 4% per month after one year. Read the attached document for the rest of the details.
The third choice is the best in my opinion. It does require "widget Y," but it will only take a few days to implement. There are no cost savings, but the savings in the implementation time make up the difference. Read the attached document for the rest of the details.
Please let us know which choice you prefer.
A better example.
I have narrowed down the final choice for the "thing." I recommend the first choice because we can implement it within days and the cost is comparable to the other two choices. The other two choices take several weeks to months to implement and only save up to 5% after one or two years.
Do I have your approval to buy the first choice?
Deconstructing the two requests.
The first request is very long and lengthy. The engineer explains his task even though the CEO already knows it. This persons also brags about the amount of work invested. This person then proceeds to explain each choice in one paragraph. The leader does not learn about the best option until the end of the email.
The second request is only one paragraph. The engineer states the outcome in the first sentence and the recommended choice in the second sentence, and explains why the other two options were not as good in the third sentence. This person then asks a question that will lead to a yes/no response, or a request for additional information or a meeting.
The second request achieves in three sentences in what took four paragraphs in the first request.
What about the details?
As an engineer, I want to provide all the information and details about my analysis. Most engineers I know take pride in their work and get excited to share it. This does not mean we need to share all the details. We need to resist getting into all the details and get right to the point.
If our boss asks us to find the best widget, we return with the best one. If our boss asks us to discover why something failed, we present the most likely reasons. We share why as succinctly as possible.
Getting to the point may be a difficult thing to do at first. We can fight the urge to share all the details by writing them down in a document. That document will be available to anyone who wants to know your processes, data, and findings. When it comes to communicating with others, present the outcome in one paragraph, in 30 seconds, or on one slide (depending on which medium you choose).
Before You Go
Join my mailing list to receive updates about my writing.
About the Author
Miguel is a Principal Security Engineer and is the author of the " Serverless Security " book. He has worked on multiple serverless projects as a developer and security engineer, contributed to open-source serverless projects, and worked on large military systems in various engineering roles.
Originally published on Patreon