Hacker News new | past | comments | ask | show | jobs | submit login

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."


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.

If only everyone did that.

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.

Did many people refuse to ask them questions because of that?

He was the most experienced engineer on the team, if he wasn't judicious with his time he would never get his own work done.

Working as intended.

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.

If you've ever had to deal with customer problem reports, you'll know that isn't just people using SO and related sites.

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.

[1] https://wiki.openstack.org/wiki/BugFilingRecommendations

My most common from end users is, "it won't let me..."

It won't let me login. It won't let me change my profile. It won't let me go to the page I want.

Such a waste of time. Two seconds of thought should allow anyone to realize that is not enough data for me to even begin troubleshooting your problem.

This is how I found I was importing the wrong file after 1 week of working on it...

I was using Welcome.js instead of Home.js

I was happy, kinda. But also, wondering if I solved the issue earlier in the week.

Was anything else happening during the course of that week?

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.

I hope you still post those well written questions. They do add value. If you’re having that issue someone else may too.

Question to HN: In that case is it good practice to post then answer your own question?

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.

I know I hate when I search for something and I find my question on a forum and then the poster responds "Nevermind, figured it out."

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?

Do you post your solution regardless?

If not, it’s almost like an incognito version of the dreaded “never mind, I found a fix”-follow up post.

Nearly relevant XKCD: https://xkcd.com/979/

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.

And the two 27" displays are filled with enticing distractions.

> 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.

People just drive-by comment on all our quip docs all the time... it's lowered the value of docs.

could you explain what do you mean by this ? why would a Google Doc not work as well?

Any other rules of thumb for people who are trying to adopt this ?

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.

In my daily routine, the thought of printing anything for work seems peculiar.

Anything I have to read that's more than 2-3 pages always gets printed. Especially if it's non-trivial.

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.

Lots of options...

I paste the function into geany (I’m on Linux) and print from there.

Usually I have IntelliJ open and it can print quite nicely.

Not trying to fix what isn't broken, just asking:

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.

Marking up documents with your notes and questions is a critical part of the process. It's ultimately why I end up preferring paper.

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.

Have you tried an ereader?

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.

which ereader is that?

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.

Sadly, no. Many B-schools focus more on analysis than on communicating the results via longform written documents.

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.

I’ve been in Japan for 6 years now, and I have yet to be favourably impressed by any presentation I’ve seen.

Often the presentations involve dumping literally all their graphs and text on the slide, and then literally reading from the slide.

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.

Visual presentations are fine, if they provide a thorough analysis, and not just clip art.

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.

Sure - something I've been wanting to do for a while. I just wrote a Medium post, as I think it's a longer topic than HN comments are optimized for.

Please take a read and let me know whether it's helpful.


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.)

So the length of the document is determined by whether you need to change Jeff's mind or merely justify his prior preference?

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.

Hope this makes sense.

Makes perfect sense to me, given I was there...

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."

I have told people "we don't need a meeting where you read the slides to me. Just send the doc and I will read it" :-). Didn't go over too well....

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.

You shouldn't just dump a document with only black text. Don't be afraid to use colors and illustrations (which are nearly always enhanced by colors).

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.

More than one.

Basically any global consultancy targeting c-suite ‘strategy’ advisement.

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.

> "Writing is nature's way of letting you know how sloppy your thinking is." -Dick Guindon, via Leslie Lamport

This makes so much sense in context to Facebook and YouTube comments...

Addendum: coding is Nature's way of letting you know how sloppy your writing is.

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 would add "Teaching is nature's way of letting you know how incomplete your understanding is."

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.)

I realize it's probably difficult to give a simple answer to this question, but roughly how long would it take to write such a memo?

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. ;)

Jeff talks a lot about this in his recent letter to shareholders.


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.

Got any samples of great six page memos you can link to?

I constantly point to the Amazon narrative as a good thing to do. I know it helps put my thoughts in order. That quote is great, thanks for sharing.

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

Replied to your similar comment as well, but here is a Medium post that I just wrote on the topic:


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact