Writing lessons from Jeff

It's been almost 2 years(!) since I started working here, and if there's one thing I've learned it is the art of writing a convincing narrative. I wouldn't go as far as to say that I've mastered it, but I've gotten good at it to a point where I no longer have to rewrite entire drafts.

As with any good company, the culture of writing narratives flows from the top down. And the practice of writing narratives as opposed to doing bullet point presentations has been around since the beginning. 

Jeff is a compelling writer.  You can see how much thought goes into writing each year's shareholders letter. You can find an archive of them here. The 2018 shareholders letter (pdf) is a lesson on writing clear narratives. It is data driven, speaks to the point, free of drivel, and stands true to the fact that a good document should tell you a story; a story, when read from beginning to end, lays down everything that you need to know, including the conclusions that were drawn, so you can form your own understanding of the conclusions. This is important as opposed to an open-ended document—especially those as critical as an investor letter—which leaves the conclusions to be drawn to the reader's imagination. That's the job of an op-ed, not a narrative that's trying to lay down facts and statistics.

At Amazon, instead of making presentations or giving talks with jotted down notes, we write what are six-page memos. It's not just leadership, even on the engineering side, design documents are six pagers. These memos are very effective for both parties—the writer and the reader. Your first reaction to this is probably that writing a narrative instead of making slides is a more taxing and a process that takes longer. That's true. Writing narratives as opposed to making slides take longer, but that's not inherently a bad thing. Writing a narrative helps me articulate my design well. If I cannot communicate my design via a narrative, it means there are gaps in my understanding/formulation of the same. For the readers, it gives them a coherent understanding of the problem, approach, pros and cons, along with an appendix of material. This helps them to attack the problem with almost as good an understanding of it as the writer—sometimes better, because they come in with some prior knowledge.  In an hour-long meeting, the first fifteen-twenty minutes are spent reading the narrative, and the rest of the time is spent by the stakeholders of the document/design going over the narrative section by section recording feedback/disagreements/changes. This, according to me, is the best way to deconstruct any proposal that one is interested in getting the stakeholders to be thrilled about.

If you ever did a project or had to write a thesis back when you were in school, you likely had to give a talk besides writing a report on the same. Go back to the few days/hours before the talk, when you were making the slides, and compare it with the time it took you to write the actual report. The former would likely seem like a trivial amount of time compared to the latter. This is because writing coherent narratives is hard. Not—only—because there's a lot more to write, but because it inherently puts you in a place where you cannot omit details or be vague about things. This is important because you need to present a complete picture to the reader. Your slideshow could omit details or be purposefully vague about things because you're going to be present to use the slideshow as a talking point. However, when someone is reading your narrative/report/thesis—which is going to live long after you've left the room—they do not expect you to stand around adding context to each unclear assertion or defending each claim. Your document should be doing that. Once your document is complete, it should become independent of the writer.

This is what a six-page narrative accomplishes and forces you to get right. There are certain valuable lessons you learn over time, mainly as a result of writing enough of these narratives and getting feedback on the writing besides feedback on the content itself. I think I've learned a few good lessons while there's plenty more to learn. But the delta between a bad document and a decent document is huge, while what makes a decent document a great document is intricate and the delta is small. To communicate well, you simply have to be a good writer, not a great one. Your design document need not be the next bestseller, but it should not be abysmal. This is because the time the stakeholders spend reading your document is the only chance you have to present a complete picture of what you're proposing. The rest of the meeting as I'd mentioned would revolve around what's been presented rather than what's missing. In other words, your narrative sets the agenda for the meeting. 

Some of the lessons apply generally—not just in engineering or management—and would help you have better conversations even in your personal life. I say so because it has helped me communicate better outside of work as well.

• Have a data-driven discussion. Every single detail or claim you present in your narrative should be backed by data. You cannot simply say a design or a product or a process would achieve something without providing context on how you arrive at that claim. Being data-driven cuts down the time it takes for your stakeholders to arrive at a point where they trust your claims. For instance, if you say caching the results of an API call would help improve the latencies in your overall system, layout metrics and graphs that show that the uncached API call is actually a bottleneck.
• As an extension, data-driven thinking helps you avoid the X-Y problem. If your proposal shows—with the help of data—that what you're proposing solves something meaningful, you can then easily convince the stakeholders that you're not solving the wrong problem. In a fast-paced industry, solving the wrong problem at the wrong could prove to be expensive. 
• As with writing code, while writing documents, do not repeat yourself. It is easy to do so while making a slideshow because nobody's keeping track of what you're speaking. There's no way for your audience to rewind in real time to verify whether you made the same claim—or worse, a contradictory claim—a few minutes back. If you provide your audience with a narrative, this is no longer a problem as your reader can verify whether you're repeating or presenting contradictory views by simply going back to a previous section in the document. It also helps you reaffirm your claims, and avoid making a fool of yourself.
• Avoid weasel words. Weasel words are in direct contention with a data-driven discussion. An example of such a statement would be "This solution X greatly improves the performance of the system compared to this other solution Y." Great, you've given me no meaningful information. Is the improvement 10% or 10x? Did you purposefully present a terrible solution in Y so you can make X look that much more efficient? What is greatly improves for one stakeholder could be slightly more efficient to another. Give the readers a common ground. Your readers are going to be on different planes when it comes to understanding things. It is your job as the writer to ensure that the planes have as much overlap as possible. Otherwise, the meeting is going to be spent getting your audience on the same page, which should be the job of your narrative. If that happens even after you presented a narrative, it signifies your failure as a writer.
• Diagrams are important. A picture really does speak a thousand words. Especially while describing a workflow, or a new system, it helps to paint a picture so the reader does not have to imagine it. It is especially important to ensure that you don't let the wide spectrum of imagination across your audience derails your discussion. Feed everything to your audience so they aren't shifting to different planes unless they are actively trying to.
• Provide an appendix and use it generously. After you've added a passage or a metric or an argument, ask yourself whether it needs to be in the document. I say after because it is hard for you to gauge beforehand whether or not something belongs in a document without actually trying to fit it in the document. This is in line with my previous point. Do not imagine something if you don't have to. Put the passage or the metric or the reference in the document, then decide whether or not it needs to be there.

The writing exercise takes a few months to get good at, but once you're comfortable writing narratives, you retain that skill forever. I often say that this practice is something that'll make me stick with my company for a long time, and I don't say it without reason.