Notes source: [LEADERSHIP LAB: The Craft of Writing Effectively - YouTube](https://www.youtube.com/watch?v=vtIzMaLkCaM) # Stop thinking about rules, start thinking about readers As an engineer, your goal is to write about a subject where you have expert knowledge. The writing needs to be **valuable**. Readers don't care about the inside of your head. It is not sharing your ideas. Your readers need to be persuaded, rather than explained. You need to show the value. You must know your readers. This goes back to my philosophy that [[everything can be viewed as a people problem]]. The start and end of your piece is very important. You need to show the reader why it’s worth continuing, and leave them with what you promised. It is a good exercise to read articles from your field and highlight which words add value. These are examples from technology papers I've read: - Community Related - Widely - Accepted - Reported - Flow - Nonetheless - However - Although - Creating Instability - Anomaly - Inconsistent WRITE CONFIDENTLY. # Structure of Writing Typical: - Background, definition, thesis - 'Martini Glass' writing What you should do: - Problem - related to a specific set of readers - Two main characteristic - Shows instability - Cost and benefit - show the instability imposes a cost; or if it is fixed, it posts a benefit - Literature Review - use it to enhance the problem - Solution # AWS Writing Rules - Use less than 30 words per sentence - Replace adjectives with data - We made the performance faster -> Re reduced server-side latency from 10ms to 1ms - Eliminate weasel words - nearly all customers -> 87% of all Prime members - significantly better -> +25 basis points - would help - might bring - should result - Avoid jargon and acronyms as they exclude non-experts and newcomers