[seattle_spring]

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.

[sib]

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

[sandGorgon]

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.

[sib]

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.

https://medium.com/@sib1013/writing-docs-at-amazon-e02580861...

[sandGorgon]

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 ?

[sib]

Thanks!

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:

https://www.anecdote.com/2018/05/amazons-six-page-narrative-...

https://use-cases.org/2018/01/03/the-evil-genius-of-the-amaz...

https://www.geekwire.com/2017/prepared-6-page-memo-geekwire-...

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

[hopler]

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

[sib]

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.

[jdt76]

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.

[btilly]

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

[loganfrederick]

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.

[bbgm]

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.