The Importance of Story-Telling in Software Engineering
Amazon’s Cult of the 6-pager: why narrative matters
I’m going to start by telling you the story of a little tech startup founded in 1994. Like most startups in the nineties, there was much hype, but it didn’t deliver profits for 7 years. Even then, in 2001, it only delivered a modest penny per share. Yet surprisingly investors were willing to stick around and tolerate millions and millions of dollars of operating losses. The dot com bust came and went and took most tech startups with it, and this little company hung by a thin thread. Again investors stuck around, defying logic. That company today, in 2021, has a 2 trillion dollar market cap and employs 70,000 software engineers. I’m talking about Amazon.
Why were investors willing to take a risk, over and over again, with a company that according to data and facts looked doomed?
Because Jeff Bezos was a master story-teller.
Every one of his letters to investors was a masterpiece. He elegantly and credibly painted a future that he saw, and inspired others around him. Bezos was not charismatic like Steve Jobs in his turtlenecks, dramatically unveiling the latest and greatest Apple product to a frantic crowd of adoring fans. He was kind of dorky and geeky (I can say that because I’m kind of dorky and geeky too). So he focused heavily on the narrative to make up for that. Substance over style.
The DNA of companies reflects, in so many ways, the DNA of founders. Jeff had a strong opinion about narratives, which he imprinted onto his senior leadership team, which in turn imprinted it onto front-end managers, which in turn imprinted it onto engineers. And so Jeff created a culture in which if you want to convey an idea to influence others, you write a 6-pager. With proper grammar, well-articulated sentences, and well thought-out points backed by data, that gets critiqued and improved round after round of reviews. None of this powerpoint-style presentation nonsense.
When I joined Amazon, I was so intrigued by this quirky aspect of the culture. I was a software engineer. I wrote code, in Java. Why did I also need to write narrative, in English???
Much later I learned that being able to articulate a vision, or an opinion, in precise and concise writing, is critical to influencing. If you want to grow to Staff or Principal levels, you need to develop the ability to put forth a narrative. This is to get peers to understand and buy into your way of thinking, to get leadership to fund it, or to align partners and stakeholders. Or even when you’re trying to convince others that you should be promoted. Narratives matter, even in software engineering. I can only go so far single-handedly writing code, but my words can influence the paths entire organizations take for many years to come.
Amazon’s writing culture is very strong, quirky and unique. Here’s 5 things that make it all work…in Amazon’s peculiar ways.
1. Banning PowerPoint-style presentations…
In 2004, Jeff Bezos took a bold stance, formally banning powerpoint-style presentations for Amazon’s Senior Executive team. Over time, that permeated to any communication to VPs and then Directors. In 11 years at Amazon, not once did I see a PowerPoint-style presentation given to leadership.
This may seem draconian to you at first, but it makes perfect sense to me. To this date, I have a visceral reaction when I see a powerpoint-style presentation that should have been a 6-pager.
- Flow. Presentations only have one way in which the information flows: you’re a hostage to the presenter’s choices. Documents offer you non-linear navigation, a “choose your own adventure” where you can skip sections that aren’t as important to you, and dive deeper in areas that are (for example if the author provides appendices with more background).
- Self-contained. Presentations require you to physically listen to the presenter, or if you’re lucky, the slide deck contains decent presenter’s notes. Slides don’t generally age well. Documents are stand-alone timeless artifacts. People who need just the information (but can’t participate in the meeting) can simply read the document anytime.
- Substance over style. Presentations can go well if there’s a charismatic presenter or beautiful slides. It’s a lot easier to be vague or evasive in presentations. With documents, you are forced to have crisp narrative, and it levels the playing field. A writer isn’t spending time on animation or cute pictures or pretty fonts; they are spending their time on thoughts.
- Speed. Presentations communicate at the speed that the presenter talks. Narratives communicate at the speed that the audience reads.
Writing takes longer, but the time taken to think through ideas properly is not wasted, because it saves time in the long run. If this intrigues you, google “amazon banned powerpoint” and you’ll find lots of good articles.
I personally really enjoy speaking in public and have spoken at tons of conferences both internally and externally, but there’s a time and place for them. Presenting to senior leaders isn’t that.
2. Amazon’s Cult of the 6-Pager: Less Is More
The next quirky part of Amazon’s writing culture was a strict limit of 6 pages for the main body of any doc. I sometimes tried to cheat by playing with the font, line spacing or margins, but savvy leaders would always call me on it.
Why this magic number?
I occasionally get a very large whitepaper on a subject. 20, 30, 40 pages. Reading it is daunting. It requires a significant time commitment. I find myself losing interest, keenly aware of the limits of my attention span. Extracting essential information requires significant cognitive load. The more cognitive load I dedicate to connect dots and extract critical information, the less I have left to actually think about the actual goal of the doc.
Less is more. Having a hard limit in the number of pages of your whitepaper forces you to think long and hard about real estate in your writeup, and what parts are essential. I would write a long doc on a topic, then ruthlessly edit out the superfluous.
I think the actual number of pages was not as relevant as the thought process it imposed: prioritize the points you want to make across, reduce cognitive load required to understand your viewpoints.
3. The “Sit-and-Read” Culture
Amazon combined the deep loathing of powerpoint style presentation and the cult of the 6-pager with one more quirky thing: a sit-and-read culture.
How many times have you shown up to a meeting for which you were expected to have read a document without actually having read it? Me, I have to admit quite a few times. Maybe I forgot. Maybe I was doing it but got interrupted. Sometimes I came clean and admitted it. Other times I was embarrassed and tried to wing it.
Amazon assumed statistically a percentage of people invited to a document review would show up without having read it, so it baked reading time into the meeting. The host of the meeting brought a stack of printed copies of the document and a handful of red pens. The first 20–25 minutes of a meeting consisted of everybody quietly reading the document, highlighting sentences, and writing notes in the margins. This was deeply embedded in the culture.
Towards 2020, between covid-19 forcing us to work from home, becoming a more global workforce spread over many timezones, and collaboration tools getting better (aka Quip, GoogleDocs, Office365, etc), a bit of that moved to offline, asynchronous document review, via e-comments on a shared doc. But I still believe that sit-and-read-then-discuss provides a higher quality conversation.
4. Friends don’t let friends use weasel words
Amazon leaders made a sport out of spotting and red-circling weasel words during document reviews. It is deeply ingrained into the Amazon reptilian brain.
Weasel words are words that add little to no value to a sentence. Fluff. The origins of the term are unclear, one explanation being that weasels suck bird eggs through a small hole and leave the empty shell (a weasel word is basically that shell: looks good on the surface, but has no actual value inside).
I remember back in 2011 I told my boss I thought I was ready to be promoted to Senior Engineer. He agreed, and asked me to write my justification. I sent him a first draft. It came back with every other word circled as a weasel word. I revised it and sent him a second draft. This time, it had half as many red circles as before. With every revision, the number of red circles got smaller, and after many, many iterations, he gave the doc thumbs up. The experience was frustrating, but it taught me a lot. Matter-of-fact tone, and quantifiable statements, over fluff. Objective data should replace subjective opinions whenever possible. As engineers, we should strive for precise writing.
Here’s an example. I recently saw this statement in a draft of a feature launch summary: “Many customers were happy with this new feature.” The word “many” here was meaningless. Was it ten, a hundred, a thousand, a million? What percentage was it of your customer base? “Many” is a filler word that provides no value or context. Likewise “happy” was a weasel word too. How do I know that a customer was “happy”? I pinged the individual that had written that and we worked together on improving it. As it turns out, there was raw data available. We rewrote that to: “In a survey, 4200 customers (87%) indicated a satisfaction rate higher than 4 out of 5 with this new feature.”
One more example. I recently started a pitch to apply Machine Learning to a problem here at Google with the statement “Applying ML to the problem may address it.” As I was re-reading my pitch, “may” jumped out at me as being a weasel word. Saying it “may” address the problem was weak and non-committal. I needed to be principled, opinionated and take a stance. I re-wrote the sentence: “Applying ML to the problem will address it.” Bolder, but it was still a subjective opinion. Could I replace it with data? I took a third go at it: “Applying ML to the problem will address it: we ran an experiment (see appendix) and our precision was 98% and our recall was 97%.” The appendix provided detailed methodology and raw data, for those who were interested in diving deeper, without taking up valuable real estate in my first page.
5. PRFAQ: Working backwards from the Customer
Amazon uses one document format above all others: the PRFAQ, Press Release & Frequently Asked Questions. Some good places to learn more are here, here or here.
In the “traditional” way of doing things, you’d have an idea, design it, write the code, and when you’re ready to launch, you write the customer-facing announcement. You’ve probably done this dozens of times.
Amazon flips that around by forcing you to write the customer-facing announcement *before* you write a single line of code or even give the technical design much thought.
It is a very simple yet powerful concept, and it’s not additional work (just shifting the order in which work happens) but I assert that it changes everything. Writing the announcement first shifts your thinking to work backwards from the customer experience and aligns everybody on the customer needs, to make sure you’re building a product that people actually want.
I recently had an epiphany as to another critical aspect that makes PRFAQs so powerful.
A few months ago I read the book Switch: How to Change Things When Change Is Hard (I wrote a much longer blog about that here). “Switch” puts forth a simple yet brilliant thought framework for influencing: think of a Rider, guiding an Elephant, on a Path. The Rider is the logical part of our brain: it is rational, it deliberates and analyzes, and it needs to be directed. The Elephant is our emotions: it behaves based on instinct, pain, or pleasure, and it needs to be motivated. We often fail to influence because we appeal only to the rider or only to the elephant.
One reason PRFAQs are so effective is that they appeal to both. On one hand, PRFAQs are aspirational, ambitious, they elicit emotion and excitement. That motivates the Elephant, who is excited and feeling “I want this!!!”. On the other hand, given Amazon’s deep distaste for weasel words, they must be backed up by boatloads of data and facts, appeasing the Rider, the logical part of your brain that keeps thinking “ok this is cool, but is it feasible?”
Almost nothing gets built at Amazon without a PRFAQ. And PRFAQs are equalitarian. While in other companies the process of deciding what to build and how much headcount to put behind the effort are up to managers, and can be a black box to regular engineers, at Amazon anybody can write a PRFAQ, and if the idea is solid, escalate it up the food chain to influence roadmap and funding. One of the highlights of my career was writing a PRFAQ that went to Chop, Andy Jassy’s “shark-tank,” and actually getting it approved, funded and built.
Ryan, a Principal Engineer at Amazon and good friend of mine, both jokingly and wisely said: “when I became a Principal, I went from writing in Eclipse to writing in Microsoft Word!” And he was right.
There’s a lot more I could say about Amazon’s peculiar writing culture, but this is a good introduction to peak your interest!
I’ll leave you with a quick video from Llew Mason, a VP at Amazon and one of my favorite former managers, talking about Amazon’s writing culture:
