Search for a command to run...
Miguel is a Principal Engineer and 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.
No comments yet. Be the first to comment.
Protect your system from vulnerabilities
How I saved my company $1 million
This YouTube video series provides quick overviews of the top 10 cybersecurity risks for serverless applications. Each video covers the risk and some recommendations on how to address it. Why is the OWASP Serverless Top 10 important? In this video, I...
![Overview of the OWASP Serverless Top 10 [videos]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1636408504092%2FBcNttK9q2.png&w=3840&q=75)
A little over one year ago, I published my first book thanks to Apress and author Nihad Hassan. I am in a cybersecurity writing group with Nihad, where he shared he had published his 4th book; this was back in 2019. I was impressed by his accomplishm...
You may have heard, “If you build it, they will come.” Have you heard, “If you build it, I will break it?” This is a skill I developed over my career to build better systems. It is a skill that took me a while to learn I had. Shortly before I graduat...
Miguel's Blog · Serverless · Security
49 posts
Miguel A. Calles is the author of the Serverless Security book, and a Cybersecurity engineer who works on serverless and cloud computing projects.
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.
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.
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.
Dear CEO,
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.
Dear CEO,
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?
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.
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).
Originally published on Patreon
Photo by Christina @ wocintechchat.com on Unsplash
