I've written documents for Jeff, and IMO, the six-page narrative memo is a key part of Amazon's success. It's so easy to fool both yourself and your audience with an oral presentation or powerpoint slides. With narrative text that has to stand on its own, there is no place for poor reasoning to hide. Amazon's leadership makes better decisions than their competitors in part because they are routinely supplied with better arguments than their competitors.
"Writing is nature's way of letting you know how sloppy your thinking is." -Dick Guindon, via Leslie Lamport
> "Writing is nature's way of letting you know how sloppy your thinking is."
Indeed!
Every so often, I have a coding question and I have an urge to ask that question on StackExchange.
Before I actually post the question, I write a draft question. I usually revise my draft a few times to make it as clear as possible. About 50% of the time, the process of revising my draft makes me realize an obvious solution to my own problem that I had overlooked.
A former colleague of mine had a teddy bear on his desk, before you could ask for his advice you had to take the teddy and explain your problem out loud to it. Easily 80% of the time you'd return the teddy and go back to your desk with the solution.
I found when I quit smoking my ability to solve complex problems took a dip, because I wasn't taking the cognitive break to step back and reflect on problems. Once I replaced my smoke break with a walk around the building my work went back to it's usual level.
> A former colleague of mine had a teddy bear on his desk, before you could ask for his advice you had to take the teddy and explain your problem out loud to it.
Somebody at work ordered 50 rubber duckies on ali express, apparently that was cheaper than buying a few or something, so everybody who wanted one got a debug duck.
Turns out you also have to use them for it to have any benefit, and most people don't.
This is why I talk to myself sometimes, explaining the problem as if I'm showing it to someone else. That forces me to order the disparate bits of information around the problem into a coherent order (rather than bouncing between points as my though processes often do) which can reveal the presence of a missing link that give me an obvious clue to the solution (or at least the next steps towards one). Some might call the jumping mind a problem to be reorganised, bit it often enough leads to random useful "ooh, that's a good idea..." moments that it is a pattern I feel worth not fighting against more generally than when I have a specific problem it is not helping with.
This is exactly what I do. It took me quite some time during my undergrad years to realize that repeating information out loud can be an effective study strategy. It was especially perfect when studying for subjects like biochemistry, physiology, immunology, etc. In these kinds of subjects, there are so many little details/exceptions to know in addition to the large pathways/cycles/concepts that it can very quickly become overwhelming if you are unable to piece all the information together, in order, and think through it logically. Forcing myself to describe everything out loud is the best way for me to identify where my gaps in understanding of the material are and also helps me retain the material better.
The internet needs more of you. Thinking about your problem and a question to solve it leads to introspection, which is sorely lacking in most StackExchange questions. Most posters just let their stream of consciousness out, post it, and curse the lack of answers.
In the 90s it had that, mostly because there was a negative feedback mechanism for poorly thought-out questions. If you posted a question on usenet or IRC that obviously demonstrated you hadn't bothered to invest any effort into reading or trying to solve the problem yourself first, you were flamed.
Over time, as a more general populace joined the Internet, the ethos changed to act more as a support system rather than the more demanding expectations of the past. Presumably that was due to a recognition that newbs did not have the exposure to computing or tech that the prior generations of users had and so the intent was to be more educative so that these new users could learn to solve things for themselves. Alas, that optimism was misplaced as the majority of people are not interested in thinking for themselves but instead just looking to follow a checklist with no understanding.
Yeah, as someone who has to deal with bugs from systems layer to userspace, a non-trivial chunk of reports (not from customers per se) are: "crap blows up, please figure out".
FWIW, some four years ago I wrote this for this "bug filing recommendations"[1] guide for the OpenStack community when triaging lots of bugs.
In my experience, the most and informative and delightful bug reports I've ever come across are from Japanese customers. And obviously, I prioritize those bugs that are competently written.
I did this too! Sometimes I use the fact that stackoverflow allows you to post an answer at the same time as the question, and sometimes I just close the tab.
The best part is running into the same problem years later and finding your old answer when searching.
It depends on the culture of the place, but stackexchange (like stackoverflow, superuser, etc.) sites allow users to post a question, post an answer to that question, and accept that answer as the best one (the same person doing all these). In these cases, the questions and answers act like one piece of an FAQ or a best practice to educate others. Since stackexchange sites are also inherently wikis, allowing all questions and answers to be edited by anyone (with sufficient reputation scores and reviews by others), it could help improve the quality of the content for such pieces.
Oh, I know. That just makes me fume. And mostly because it reveals the very selfish nature of the poster. As if everyone on this public forum is just waiting to serve you and you don't have the time to make any useful contribution whatsoever.
That actually makes me wonder. Suppose you input your first draft question into a program: is there way to create a simple AI that could "debug" the question itself. I'm thinking of the first five to ten minutes of when someone sits down to pair with you and tries to grok the problem / nature of the ask. Maybe a sentence that doesn't look right based on the usage of nouns and other parts of speech compared to good questions?
My cofounder/CEO used to work for Jeff Bezos as a GM and the most valuable lesson he imparted to us is the six pager. Before a high-level meeting begins, everyone grabs a red pen and reads/annotates the six-pager for 20 minutes. The discussion that follows is between informed participants, and has more structure. It is a highly effective technique for decision making, and a practice I would certainly carry forth to whatever I work on in the future.
It seems all practitioners print out all of these memos to paper. Has anyone successfully converted this tradition to a digital medium or does that invoke the spectre of PowerPoint too strongly to survive?
In my daily routine, the thought of printing anything for work seems peculiar.
Thinking about documents is one area in which paper is still king. I've got two 27" monitors on my desk, but when I want really think about a document I'm reading, I print it out and grab a pen. Reading things on a screen feels like having a straight jacket on. I can't put several pages next to each other. I can't put my finger on a page so I can flip back to it later. Marking anything up is an ordeal of UI getting in the way. Tablets aren't any better. Writing on glass feels wrong and the lack of friction makes it hard to write small text legibly. And their small size compounds the problem of not being able to refer to more than one page at once.
> Reading things on a screen feels like having a straight jacket on
I feel the same, but at some point I started to do everything work-related digitally because people would often comment on this. The craziest one was someone pointing out this would lead to ideas that are too complicated.
Someone will forget their laptop, or won't have wifi, or the power will die, or the link doesn't work or won't have the right pdf/doc reader, or will respond to that notification they just got distracting everyone with their clickity clack, etc.
Making the presenter bring everything needed to have a distraction free conversation is a feature, not a bug.
I work at Amazon. We've tried digital on my team. It's way worse. People make more nitpicky changes and the inline-edits/auto-suggest thing makes it easy to rat-hole. Stick to paper, imo.
I think it varies by team. On my team, we don't use hard copies, comments are written electronically, and we have the usual post-reading-time discussion.
I work at Twitch, a Subsidary. We do the 6 pager process a lot (esp when working w/ amazon). We do it with shared collab doc editors though. It's an interesting twist.
Digitally has 2 big benefits:
- You can see when someone is commenting on a thing and skip down so not everyone dog piles on the same thing.
- In lower level meetings you are very unlikely to have a note taker, so in digital form everyones notes are in one spot. In the paper form of the meeting you either collect / decipher everyone's notes, or you have argue/defend/explain your doc while also taking notes.
Paper is better for:
- Keeping everyone focused. You don't pop that laptop until you're done marking up the doc, people often don't even bring laptops to paper doc meetings.
- keeping comment arguments from forming in the margin in the digital document.
Some parts of amazon are trying to do it digitally, esp those that are remote.
Which tool do you use and how do you run the meeting ? For example is it everyone speaking and writing simultaneously..or is it people writing during the 30 minute study time, etc ?
Amazon standards is you show up and dedicate at least 30 minutes to reading. You wait till everyone is done reading, and try not to pressure people to hurry.
The reason you do it in the meeting is that for more senior people, you have to block them off time to think about the document. Asking people to schedule another block of time to give feedback on YOUR problem is rude. As you get more senior you end up in way more meetings. It's hard for more junior people or ICs to understand in a lot of cases. If timing is hard, have them schedule you in a different slot.
You can tell in say google docs where everyone is reading wise. You can also see all the comments so you can also judge progress.
Ask questions in negative every 5-10 minutes "Does anyone need more time".
Once everyone is ready, start the meeting by going through comments from top to bottom.
After that it runs like a normal N-Pager meeting, or tech review or whatever.
I will say that with say google docs you can use suggestions and other things or say "I'll work on that". And just move on. It's rarely important to rabbit hole on the english, esp on engineering docs. If you're writing a actual PR or marketing doc, sure.
The tool is inconsequential, pick whatever works for you and that has enough adoption that you aren't spending 15 minutes getting everyone accounts at the beginning of the meeting.
The features I find useful are:
- Cursor Position of readers (minor)
- Comments
- Suggestions (like google docs), helps with minor edits
The rest don't matter. Hell you don't even need suggestions. Comments are really about all you actually need.
The latter. The first half of the meeting is "quiet time" where the reading is done and reviewers take notes. The second half is where discussion occurs.
If I have a particulary gnarly function I didn't write that has no comments (it happens more than I like) I'll print it out and use colored pens.
It's a once/twice a week thing but nothing is as effective (I tried using my 2018 ipad/pencil but I just don't really like writing on it, the lack of surface resistance is wrong).
Random question -- how do you print code? Do you copy the file into a text editor? I've looked a few times and it seems like Sublime and VSCode both don't have a print feature...
I mean, just save the file as .txt and open it in Notepad, TextEdit, or whatever is the default editor in your desktop environment of choice. Should have a print function.
Otherwise you could stick it in <pre> / <code> tags in an html file, open it in a browser, and print from there.
Have you tried an ereader? I have one that's 8", has a frontlight, and runs full on Android, I use it after my no-tech nighttime threshold and during meetings. But I especially use it for any long form reading I have to do.
I was about to include this in my original question and decided against it, but I don't like marking up the original document. I would much rather have a separate set of notes.
I have (a cheap Kobo something or other), but it was completely useless for handling most pdf documents and slow enough when navigating a document to get really annoying. It also didn't have any support for annotating or making comments. I've kind of had my eye on this: remarkable.com, but I can't quite bring myself to spend that much. What do you have/recommend?
Still not the perfect device, you can see some criticisms in the review above, but it's my favorite I've seen so far. Forgot to mention it has an SD card slot in additon to 16GB internal storage, compared to, say, the Kindle Voyage which has 2GB and that's it.
Still waiting on the dream of color eink monitors, but in the meantime this will do.
EDIT: It also has a togglable faster refresh mode, which doesn't clear the screen as well but is much easier to use for scrolling/panning around.
A lot of folks still do printed narratives, but some teams (mine) are digital now. This has become over more prevalent as our teams get more distributed.
Six pages seems a lot for discussion. I prefer two page briefs, in part because it takes less of the participants' time but mainly because it requires more refinement and focus by the author.
In my experience at Amazon, we never wrote a 6-pager if a 2-pager would do, for exactly the reasons that you indicated (and also, we found that breaking complex things into smaller chunks was more effective in many cases.)
Is not this how the case based learning happens in all of the world's top MBA schools such as Harvard, Stanford etc? The class participants were given a case study in the previous class which they'd need to discuss in current class. I also know that Amazon hires probably more MBAs than other top Tech companies and maybe there's a correlation between these MBA hires and narrative style discussions at Amazon meetings.
It's notionally similar in that at b-school you read the case and then discuss in class, but in practice it's a very different activity. Real doc reviews at Amazon are far more rigorous.
This is now one of the things I screen for at any new job. At my current company, we've banned PowerPoint for any internal communication, and use text for just about everything.
I completely agree. I've been at jobs where I would be asked to explain a product or initiative and would go with documentation, only to be told that I "write too much" and to condense into slides. This was almost always due to managerial laziness in vetting decisions on the basis of "saving time", instead of doing the hard work of understanding a problem or opportunity as thoroughly as possible.
Then, when problems arise that were highlighted or predicted in the documentation, you can't just tell people "I told you so". But getting people to understand the flimsiness of slide presentations compared to documentation can be a slog.
There are companies with heavy non-native English speaking populations, for whom it be a greater cognitive load to constrain themselves to prose, whereas they might be good at explaining things pictorially interpersed with terse text.
Sometimes distillation and condensation can lead to more precise thinking too.
Western civilization has a bias toward the written, which has helped us produce analytical thinkers ("Reading maketh a full man, conference a ready man, and writing an exact man." - Francis Bacon). We tend to value precision in verbal expression and argumentation (disputation) as means of arriving at knowledge.
But I think we need to recognize that other cultures have other preferences that may be just as effective. From what I've observed, Japanese culture has a preference for the pictorial (Kanban is one such example) and it's amazing how much much they've achieved along those lines. I've worked with Japanese folks and their docs and slides tend to be diagram heavy (often beautifully so). Japanese product manuals also reflect their visual culture.
"There are companies with heavy non-native English speaking populations, for whom it be a greater cognitive load to constrain themselves to prose, whereas they might be good at explaining things pictorially interpersed with terse text."
I don't think giving a full, narrative structured presentation beyond the capacity of a non-native speaker given effort. While certainly other communication-approaches exist in other cultures - as well as in our own, I don't think one can really say full narrative structure is Western specific.
Moreover, I'd say the intent of asking for a narrative argument is to require a significant cognitive load from anyone putting out an idea. You definitely don't get a "brainstorming" effect, where lots of idea appear at once, from requiring a full narrative description.
"Sometimes distillation and condensation can lead to more precise thinking too."
Indeed. But the principle is a well written long-form narrative consists of a sequence of precise, condensed statements and not merely blathering on.
It might seem unfair to ask non-native speaker to reach a level of long and precise utterances. But currently, American education is poor enough that writing a coherent narrative document would be quite hard for a fair portion of Americans.
This is a really good, interesting point. You're probably right that it's deeply rooted in culture. In America, pictures and diagrams are just as often, if not more so, used to obfuscate than provide clarity. But I don't disagree with other cultures being able to teach from a young age how "a picture can be worth 1,000 words" and how to execute that meaningfully.
That's a really interesting point. You could argue that the problem is the low standard of PowerPoints in most companies, not the presentation medium itself. I've certainly seen the occasional great presentation.
To put it another way, my view is that
good visuals >> good writing > average writing >> average visuals
So I could certainly imagine a culture where the average visual presentation was good enough to make that the best choice.
Amazon also has a heavy non native English speaking population. Both of my team's managers and over half of my team are second language English speakers. People can still write docs.
Writing narratives doesn't preclude pictures, graphs, metrics, visualizations, diagrams etc. It was common to see these included inline or as an appendix in Amazon docs.
From what I have seen, in the west PPT are done quick and dirty, as a way to avoid doing the hard work of writing.
But a well designed graphic can require as much work as a well written paragraph, and if the Japanese put all the care needed, then the end result will be very high quality.
The point is, it is not the nature of the media, but the mentality of the worker what guarantees results.
There has to be a balance though. The last place I worked some guy would write literally 30-40 pages explaining a service he was going to write. No one was going to read that, nor should they. It could have been explained in 1-2 pages, easy.
Yes, definitely. I wrote (or contributed significantly to) dozens of docs for Jeff Bezos and his senior team. It was important to understand whether you were writing a 2-pager or a 6-pager (depended on a number of factors, mostly relating to complexity of the issues involved, the size of risks, and the variances in expected outcomes.)
Two examples:
(1) An acquisition memo justifying a functional/technical area (and specific target company) that we wanted to be able to move into due diligence with.
(2) A recommendation related to whether "Alexa" (the service) and "Echo" (the device) should have the same or different names.
In case you're wondering, the former was a 2-page and the latter, a 6-pager. In each case, the recommendation that we presented was accepted, the second after much more vigorous debate than the first. Jeff was initially strongly opposed to having two different names.
No one would read a 40-page document, but there were a few times when we ended up with 6-pagers that contained 20+ pages of detailed appendices.
I also believe that the culture of the document is a key success factor for Amazon (but that it can't just be cargo-culted into other organizations without a lot of buy-in).
Could you talk a bit more about the "rules of thumb" for these documents. is it used in all meetings ? what should you NOT DO in these memo ? are they paragraph prose or bullet points ? etc
I've been trying to find info about this practice (to use in my startup), but didnt find any.
This is super helpful ! Is there a format that you can create/share ? Like - is it like a spec (with "goal", "stakeholders", stuff like that). I'm betting it's not ...and that's makes this a little hard to get started on.
You guys had the benefit of looking at your peers' work - what would be a good two pager that we can learn from ?
It's less a spec and more of, choose the tool that fits the job. A lot of these documents fit the overall structure of "high-level situation & recommendation; industry / product / customer context; more depth on recommendations considered; FAQ"
I don't have any examples, anymore (I left Amazon some years ago), but here are a couple of links that have reasonable takes on the structure and guidelines:
Bottom line: the purpose of the document is to drive a high-quality decision, so include what will help, and leave out anything extraneous. (I know, that's not very actionable.)
No, sorry, didn't mean to imply that. In the case of the acquisition memo, there was no prior (we'd had no previous conversation about the area at all). It was simply something that we thought was clear enough to distill the reasoning down to a very short document. Also, we were looking for a decision on something that was what Jeff likes to call a "two-way door" - we were asking to engage and to conduct diligence, not for a final approval of the acquisition.
The other document, while seemingly a simple issue, had a lot of ramifications and would be hard to reverse once we made the decision. When he finished reading the doc, he initially disagreed that there should be two different names, thinking that it would be simpler from a branding and customer point of view to have only one. our position was that, although that would be true at launch, we needed to plan for success when Alexa, the service, would be available on many different types of hardware, even ones that were not made by Amazon, so we needed to do the work involved in keeping them separate. This type of decision was much more of a "one-way door" in Jeff's parlance.
FWIW, I do think that more and more "two-way door" decisions are being determined at Amazon using the narrative process, which can be very, very expensive.
At the start-up that I am at now, we are moving much more quickly by being using the narrative format thoughtfully.
Hence the importance of the other half of Amazon's policy. Not just "written form", but "written and of easily digestible length X". You want there to be nowhere for bad reasoning to hide. Neither in the disconnection that comes naturally with slide shows, or in a forest of spurious verbiage that long writing encourages.
As Dijkstra famously commented about writing, "You cannot sharpen a pencil with a blunt axe. Nor will 10 blunt axes suffice."
Agreed, the level of "paperwork" varies depending on what you're actually trying to get done. Proposing a new product? 2-3 pages like the Amazon Press Release technique should probably be the max. Product and engineering manager scoping the implementation? Could total 10 pages, but split into 20 different tickets that go across 5 devs and a designer. Context definitely matters.
6 pages is not mandatory. It’s up to 6. A lot of decision meetings are a a page or two when it’s a very clear decision which doesn’t require too much framing.
I wish my company did that. Even if you write a document usually they ask for Powerpoint so after a while everything regresses to bullet points on slides.
So, so many people hate reading and writing. They abhor it. Black and white text on a page looks like history class homework. You could strap them to a chair and hold their eyes open and they wouldn't be able to make it through two double-spaced pages.
In my experience, one of the most common agendas for a meeting is "here is a document that the author is going to read to you."
Reminds me of the time it was my turn to lead the weekly staff meeting. Why? Cause our manger was lazy I guess. I handed out copies of Brooks No Silver Bullet essay. Did not go over well at all.
At least one major (like, major) management consulting firm turns basically all their communication into a PowerPoint, sooner or later (usually sooner). I gather they've found they can't consistently get C-level folks to pay attention to any other format, but it also ends up being their own internal format-of-record for almost everything. It's bananas.
A lot of companies I have worked at use PowerPoints as the ONLY means of documentation. Presenters have slides that cram so much information that they become unstructured glob of textual-visual noise with jpegs, flow charts, long paragraphs and drawing snippets, etc.
People have forgotten to write structured documents that logically layout your thoughts.
Bullet points aren't always bad. Done properly they convey the essence of the message without the baggage of conversational language.
If you can understand a Powerpoint just from the graphics + bullets then it's done correctly. If it needs supplementary notes then send it back for rework.
We use Powerpoint internally for short discussions especially when media is relevant (we do a lot with video, so it's necessary to have some way to communicate that), but we are heavily-biased towards text as well. Printed, if at all possible.
That’s a really interesting point (and quote). I write legal briefs for a living, and routinely an argument I thought was very compelling when I jotted down the bullet points completely falls apart when I go to write it out and am forced to actually conntect the dots.
i've always liked the challenge of, and gravitated towards, being the synthesizer on group projects, because while it meant extra work for me, it also imparted deeper understanding.
you literally get smarter from having to consider disparate perspectives. this is a lesson that's always stuck with me.
and it seems to uncover a gap elided in your conclusion:
> "Amazon's leadership makes better decisions than their competitors in part because they are routinely supplied with better arguments than their competitors."
i suspect better argument came not only from (an initial) concise writing by the narrator but the revision process incorporating other people's perspectives?
Is there a way of tracking the impact of these memos at Amazon - for example a "decision log" such as "because of memo X it was decided to fit speed limiters on all delivery vans - All speed limiter costs will be under Cost Code XXX"
Then you can trace costs (and presumably savings) back as a dimension through the P&L?
I completely agree with this. In the recent past, I have been moving from ppt to writing articles. The clarity you get while you write it demonstrates how much you know. It is like thinking about a picture and then drawing it, you have to focus on a lot of details to get it right. When we think the mind doesn't focus on those
I had an episode of cognitive dissonance while working at a Big4 consultancy and studying my MBA. I could consistently score High Distinctions (85%+) on my essays and reports at uni, but Partner's ripped my powerpoints to shreds for lacking narrative and consistency.
I am only just coming to understand what they were seeing and why a long form essay would have been a much better way to get my information across. Now to convince my customers that a 6 page essay/report is much better than 60+ pages of graphs and filler.
Doesn't, eg, Walmart have higher generally revenue and margins than Amazon, especially if AWS is ignored? It is very early in the game to declare that Amazon's leadership are making significantly better decisions than their competitors.
I mean, they might be making better decisions, but they might just be making average decisions and riding the wave of technology due to having an online presence without brick-and-mortar stores to worry about.
This also works as a mechanims for two other benefits besides conveying quality information. The written narative benefits the writer as an excellent way to shape ideas in to coherent arguments and conclusions. Its useful to the team for forcing explicit consideration and decisions. Implicit or accidental effects are a much higher risk than an intentional, but suboptimal, decision.
Can you share a general template of the 6-page memo? What are the key areas to be covered that ensure heightened understanding of the topic being discussed?
Also, how do you disabuse folks who get their writing skills from Creative Fiction in college, and therefore write in a style more suited for dramatic effect than succinct communication? ie, how do you force actual "memo" writing?
I would say that there is no single general template; it depends on the purpose of the specific document. I just wrote a medium post covering some do's and don'ts of these documents:
> Also, how do you disabuse folks who get their writing skills from Creative Fiction in college, and therefore write in a style more suited for dramatic effect than succinct communication? ie, how do you force actual "memo" writing?
This is easier. If you are their manager, you hand them a couple of example documents that you believe to have been high-quality and effective, right when they join the team. Then, you read the first document that they write and return it to them marked up (edited) to meet your standards. They'll figure it out pretty quickly (or they won't, and then, to be honest, you've got a problem, because they'll have a hard time being successful at Amazon if they can't.)
The magic is that the writing typically doesn't take that long. It's the digging in, researching, learning, hypothesis building, validation, etc., that may take quite a while. But that's why the documents are so powerful; once you've gone through all that (which is easier to skip, fake, or shortchange in a PowerPoint), the level of preparation and discussion is so much higher. And you likely know the answers to almost all the questions that will come up in the exec review meeting, which reduces the need for and endless series of meetings on the same topic.
So, for me, writing a 2-pager usually took 1-2 hours. After 1 week - 2 months of work getting to the point that I was ready to write. ;)
He suggests that a great memo takes a week or more. In my experience that's roughly right, though you'll often have been mulling over the problem for weeks before you actually start writing.
Do you have any suggestions for how to improve my written thinking? Word can (mostly) fix my grammatical errors, but I am no longer in university so I don't have the ability to have a teacher look at them.
there's not a lot of information around the best practices of such a thing.
Could you talk a bit more - is it used in all meetings ? what should you NOT DO in these memo ? are they paragraph prose or bullet points ?
etc
Article starts out well and then veers off into strange and scattershot coverage of unrelated Amazon factoids.
It doesn't fully cover the communication principles of the 6-pager. The missing parts are:
- 6 pages is the upper limit; the memo can be shorter
- The format is designed to drive the meeting structure by requiring attendees to read the memo in the first 10 minutes of a meeting, followed by discussion
- You can push extra information into the appendix if needed to convince those looking for more evidence
- The memo is self-sufficient as a unit of information, unlike a Powerpoint that relies on the presenter (or a video of them) to contextualize and connect the information
The basic thrust is to bring the discipline of scientific style article writing into office communications (and avoid Powerpoint anti-patterns in the process).
A better word would be "essay". It's simply a written document proposing and explaining some idea. The essay will be read by its reviewers quietly, so the document needs to be clear and self-sufficient in presenting that idea.
The essay will be discussed verbally too, but only after the reviewers have a chance to fully read the document and ruminate over it, typically for 30 minutes or more. The verbal discussion can elaborate on points made in the essay but isn't a substitute for them. This means that the quality of the writing needs to be high, and the hope is that high-quality writing facilitates high-quality thinking and presentation of ideas.
> Alexa was not developed internally at Amazon - it was bought in, on the cheap
That's a flat-out lie itself.
A knowledge graph was acquired. Alexa - which, at this point, represents many thousands of years of engineering effort, was most certainly developed in-house.
Source: I wrote the 2-pager recommending the acquisition of said knowledge graph company.
Out of curiosity, is it a requirement to read the memo during the meeting itself? Just wondering if it wouldn't save some time for people to have read the memo before the meeting?
Practically, many people wouldn't read it ("no time") or just skim it ("got the gist of it") and having a meaningful discussion becomes impossible.
The meeting then dissolves into a impromptu brainstorming session by all the people who haven't read it.
A decision is made to implement one of the newly brainstormed hare-brained ideas without taking the carefully thought out arguments and counterpoints in the memo into account.
In the end people congratulate each other on a "productive" meeting and the memo wanders into the trash, unread.
The memo idea is a brilliant idea when Jeff Bezos and his team use it. Unfortunately it has been bastardized by inept middle managers. I saw this firsthand at Amazon. People spending hours debating about spelling errors and sentence phrasing; talking about how a paragraph is going to confuse a hypothetical person who would in reality never read it. Instead of using the memo for what it is meant for...to communicate about your project in a clear way. I saw people spend 45 min on a paper about a product and then 5 min on demoing the actual product. I think the paper applies more in high level strategic meeting and is not a universal panacea for every project you do. But people are not that subtle and its either all papers or nothing.
Of course your last sentence is true. Just hypothesizing, but I imagine the ensuing discussion is the point. Perhaps the discussion took place because:
- There's disagreement... in which case, this is a needed conversation. It probably should happen before the meeting, but it's way better to have now than to kick down the road because sentence phrasing seemed beneath us.
- There's politics/personality issues... in which case, maybe the conversation isn't enjoyable, but that clash is going to happen at some point. If not this meeting, then the next.
One of the larger points going on in this thread is that articulating things forces reality checks—between you and your idea, between your idea and others' ideas, between the team's ideas and reality, etc.
Good points but nowhere close to why this happens most of the time. I can't see how sentence phrasing can cause a whole project to go in a direction it was not intended for.
Often times the people most active in these white paper discussions are non-technical people who don't do any actual work rather than running from meeting to meeting who are trying to get in their two cents to show how valuable they are.
At the end of the day - this creates an atmosphere for the PM to shine and the Engineer to take a backseat.
Maybe it's different in more technical parts of the company but this is the dynamic in Finance/Legal/HR.
This just gave me a lot of respect for Bezos. Leader type personalities usually can't (be bothered to) write well and often seem to be more doers than thinkers. Bezos has a very clear and pleasant writing style and obviously understands the usefulness and practicalities of deep thinking.
I think he's right in general about capturing the detail. You must be able to write down succinctly what you're selling before you talk about it to an audience. It's analogous to writing down your design for software before you actually code it. If you can't then something doesn't add up.
If you want to produce a bullet point powerpoint from the document then it should be possible to do it in a few hours. But the reverse isn't true.
I realized I want to read all of these shareholder letters from 'Day 1'. Luckily some guy has already compiled them all into one PDF that I just sent to my [Amazon] Kindle. Reading about Amazon on an Amazon device lol. Hope this helps you too:
I've seen a couple companies try to adopt the Amazon-style narrative, and they both failed. I think the only way it can happen is if leadership demands it and is absolutely unrelenting. People will resist at first, but in time (years) they will come around. Some people may have to exit the organization and be replaced for this change to work. Amazon's organization circa 2004 was large and resilient enough to support this kind of change. A random startup might not be able to.
There are important norms in Amazon's culture that support this method. Time is always set aside at the beginning of the meeting for people to read the paper. They know that no one will read it before-hand, so they make time in the schedule. Also, the main document is at most six pages, but you can supply an endless number of appendices. This gives people a place to put supporting information that feels too important to cut entirely.
" I think the only way it can happen is if leadership demands it and is absolutely unrelenting. "
I should add that the leadership should do it themselves and lead by example. When we introduced Agile the developers were the only ones who went to training while management continued as usual so our Agile quickly devolved into micromanagement. Same for code reviews. It's very important that the more experienced devs closely follow agreed-on coding styles.
I agree completely. It's also important that the audience can actually tell the difference between good writing and poor writing and give useful feedback. You can't just ask people to write and hope for the best.
> They know that no one will read it before-hand, so they make time in the schedule.
That's an attitude of acceptance (is that the right word?) that I find inspiring.
I've felt that meetings would be more productive if the person presenting had to prepare some written material, and we all had to read it ahead of time. That way we have some shared base level of knowledge and the discussion can be done at a higher level.
Inevitably, some people don't read the doc. Some of them are honest and the presenter is nice and catches them up quickly. (If all of this information can be transferred in 1 minute, then why did I get a 5 page doc?). Or worse, people pretend they read it and didn't.
You could try to build some culture around "making it a requirement" (shaming them if they don't?) but, more often than not, the person who didn't read the materials is the biggest boss in the room, and enforcing requirements up a corporate org chart is a fool's errand.
So, someone at Amazon was like "fuck it", realizing that half the point of a meeting is just forcing people to work on something by putting them in a room together. And rather than complaining that that's kinda dumb (which it is) they just decided to increase the quality of work that happens in those meetings by setting aside 10 minute for reading.
typically startups work on chunks of work/product/features that have a radically shorter half-life than something that an Amazon works on. Do you think that could be a reason ?
Is this a method that brings agility only to large orgs ? If you had to do a startup, would you use the narrative method to develop a new feature/UI,etc ? Maybe you make it two pages rather than six...but still.
Amazon sent me to a Tufte seminar. I had no problem applying what I learned at work. In fact my manager required me to give a presentation on what I learned. Guess how I did it.
I highly recommend making writing part of the interview process if it will be important for the job. Some people sound brilliant when talking, but as others have noted, having to write out the details forces you to organize your thoughts.
And some people are better at it than others. I just watched three to five commits scroll by with subject lines of "updates" and no body … which tells me nothing about why the code is changing, or why this is the right change.
I work for Amazon. Charts, graphs, and other supporting data are permitted in the appendix, which can be of any length. They are forbidden in the narrative itself, however.
Typically you'd make a succinct verbal statement in the narrative like "customers tell us ____" or "___% of ______ do ______", and show the survey or other relevant data that supports the statement in the appendix.
I'm not sure about Amazon, but we do the memo thing at Jeff's other company, Blue Origin, as well. Charts are fair game and I've used them a few times. I've noticed others at the company use them too, but sparingly.
The emphasis on the word "narrative" is a little odd to me. In the book "The Everything Store", Brad Stone, the author, describes an awkward encounter with Bezos: one of the first questions Bezos asked Stone was "with this book, how are you going to avoid the narrative fallacy." The narrative fallacy basically means crafting stories where there should be none (e.g. interpreting data with a neat reason that seems plausible, while the reason may be completely wrong and is not proven by the data). See Nassim Taleb for more on the narrative fallacy.
The part about actually sitting down and writing out a proposal and finding the challenges with it hits home with me. Over the past year or so I've become (I think!) a little more cautious about things that I claim, whether it's online or in person, especially in a technical context or when carrying out an argument. And I've often found that actually questioning my own claims and then having to go and research them and figuring out whether I can actually make a claim, gives me a better overall understanding of the arguments.
I think corporations are going to have to learn a lot from Open Source practises - Agile is probably the first in road that "code" is making into the corporate world despite its mutated appearance
One of them is discussion over email (ie persuasive long form writing, combined with data driven evidence)
I'm curious to how much time is allocated for writing these six pagers? Both total leadtime and actual writing time. Anyone with experience have any insight?
Bezos discusses how long they take to write in the 2018 Amazon Shareholder Letter [1]:
"... they mistakenly believe a high-standards, six-page memo can be written in one or two days or even a few hours, when really it might take a week or more!"
love the (intentional?) irony that the first 20 something paragraphs say absolutely nothing besides "bezos like longform narrative, and he wrote it in a very short email once".
I suggest what might be happening has less to do with writing rather than the structured approach required to do such writing.
Obviously all of this works for Amazon so that's great, I wouldn't see any reason to change it, but it's probably worth thinking about a little.
I do not believe PowerPoint is inherently a bad format, nor do I believe that written is better, moreover, I think a lot can be lost in prose.
The reason I believe this is due to some military experience with SMEAC NATO orders format [1]. This format can be used by Corporals on up to Generals, by all NATO forces such that a Polish recruit could sit in on a US General's Orders and effectively understand what is going on.
Aspects of SMEAC exist to enable tired and sleep deprived commanders and soldiers to create coherent and complete plans, and to ingest them as well.
Little things like: " You must always repeat the mission twice so that any squadies not paying attention have a chance to catch what it is they are meant to be doing."
At all levels, the Mission Objective (which is a specific format) is repeated twice. Always. The impetus is twofold: if well trained staff understand the mission objectives, then the rest is 'details' meaning, even if everything falls apart, training and skills can take over so the mission could be achieved. The 'say it twice' is essentially a double affirmation of the objective.
Once everyone is on this same wavelength, it's interesting to see how people can become operationally synchronized.
My feeling is that a SMEAC-like format for meetings would likely be ideal; something that requires a specific approach, with checklists that force product/technical etc. to contemplate various issues.
If this were to be done well, then it could be abbreviated into another format.
Another reason I'm just a little skeptical, is that every big movement has a series of behaviours and attitudes that help embolden the koolaid. Amazon started as a book selling company, so in a way, it kinds of makes sense for them to value the 'literary' in some way, and this odd behaviour (which actually does work) helps them differentiate their 'movement' in a material way and reinforce ostensible 'culture'.
It's probably worth some further analysis, and maybe some data points as well, because there are many things that make growing companies unique, I wonder if we should just assume those unique things are drivers or just arbitrarily correlated aspects.
What part is Jeff trying to draw attention away from? If anything he's been incredibly open and forthright about the entire "drama", which seems to be the exact opposite of what the blackmailing parties want.
While dense writing makes it harder for the presenter to gloss over details, it makes it that much harder for the audience to grasp the idea. PowerPoint is designed for the audience.
Maybe a presentation for a live audience, and a dense paper for offline consumption is the optimal setting. The audience can remain engaged, and if an idea seems worthy, a deeper dive into the dense paper format occurs
To the contrary, clear writing make it much easier for the audience to assemble complex ideas.
Poor writing definitely makes it harder, and it turns out that the vast majority of people are poor writers, mainly because they don't practice. You might not have experienced high-quality business writing because it's so rare.
Powerpoint does have its uses; I've written and delivered lots of talks using powerpoint. But informing an audience about to make a high-stakes decision is not among them.
About a year ago, I decided to start writing about my home hobby projects on a blog. It's a nice plus when others read it (but I have no idea because there are no trackers) but the two biggest advantages are:
1. I'm now much more inclined to finish a project.
2. Writing about it forces me to truly understand the subject. There have been many times where things became clear only because I had to explain it to myself in words.
And you're right: the more I do it, the easier it becomes.
I think the mix up between enlightenment/information vs decision making is the key here. You see presentations at Re:Invent all the time, because they are the former.
Leadership decision making definitely requires the nuance a standalone document can provide. Amazon takes it a step ahead by imposing a condense requirement: now you need to write well too.
RE other comments about fluffing / buzzwords, you probably are highly misjudging the level of intelligence of this particular audience. IOW I would love to try and see someone try to push such a doc with Jeff et al :)
Because of its audience and goals it's necessarily less technical and more essay-like than a typical s-team memo. For obvious reasons, I can't link to any of those.
An example that's close and is in the public domain is Jacobsen's TCP slow start paper: https://ee.lbl.gov/papers/congavoid.pdf. He's advocating a specific change in the TCP protocol and marshalls evidence beautifully to make his argument.
There's a lot of padding and ambling in that memo. For example the entire first paragraph would have been more parsable as a list of achievements. And then there is this:
"may be because customers have such easy access to more information than ever before – in only a few seconds and with a couple taps on their phones, customers can read reviews, compare prices from multiple retailers, see whether something’s in stock, find out how fast it will ship or be available for pick-up, and more."
Everything after the clause "... then ever before" is superfluous. Shareholders know what sort of information customers can obtain, and how. He implies that with the weak "and more" at the end. But too late, he has already wasted the reader's time.
I'm not particularly impressed by that writing style, it reminds me of 16 year olds trying to impress me with their verbose history essays.
The idea of business writing is to COMMUNICATE. If the reader reads an entire paragraph and hasn't learned anything new then the author has failed. If the reader needs to use a highlighter to pick-out pertinent information from a sea of words, the author has failed.
Based on a lot of meetings I attend I suspect that the people who don't read or understand the 6 page format shouldn't maybe be at the meeting. A lot of meetings spend a lot of time with catching up unprepared people and almost nothing of substance gets achieved.
In the Amazon format, meetings begin with dedicated reading time. The presenter hands out copies of the memo, and everyone spends 20 minutes or so reading silently. Then they discuss the memo as a group. People aren't expected to read it beforehand.
The entire point is that presentations are easier to game than a narrative. If the audience can’t be bothered to read the paper it’s time for the audience to be replaced.
I feel like your message implies that the PowerPoint should come first. Why should I allow you to convince me of something that I do not understand? No, I should read the text first, to understand (which hopefully will simultaneously convince me!) and then the PowerPoint is no longer needed.
"Writing is nature's way of letting you know how sloppy your thinking is." -Dick Guindon, via Leslie Lamport