The Document Culture of Amazon | Hacker News Reader

The Document Culture of Amazon

justingarrison.com

488 pointsecliptik210 comments

When I joined, I was perplexed by this way of operating meetings. It surprised me greatly that people wouldn't want to read the doc at ahead, give it time for thinking and researching, and then come to the table feeling prepare to contribute to the best if your ability.

Now, I understand and deeply appreciate this method. I believe it provides lots of benefits. It drives towards better docs that can be understood quickly by non-experts. When there are just a few minutes to review the doc, we don't have time to go digging for information on our own - the critical information must be provided in the material given. There will also be SMEs in the room who can clarify any shortcomings here. Because the audience of the docs is non-SMEs, it drives towards inclusion of other teams. From this, you get more diverse viewpoints, considerations, and experience. It also contributes towards cross-team awareness and education. It makes it much easier to participate as a contributor to the meeting while simultaneously less impactful when you don't. It let's us timebox our attention span - you won't accidentally spend hours rabbit-holing into a doc.

The other side I heard from someone who worked at Amazon:

The SMEs read critically and take the full time. The PMs skim it and start pitching whatever idea comes first to mind.

The PMs are often SMEs of related concerns and own stakes in the new idea being discussed

If someone is wasting time in a meeting on tangents unrelated to the goal of the meeting, the person running the meeting has every right and obligation to shut down the tangent.

This is a problem regardless of the document culture. If anything the document culture gives you an objective standard that makes it very clear whether a line of discussion is on topic.

When you begin to enforce such rules is when you know the culture is going to shit.

The act of “shutting down a tangent” will be seen as hostile and a grudge is created. Hurt parties will refuse to or be difficult to cooperate with. Your culture can survive only if there’s a shared commitment to it and people feel like they belong.

Perhaps you would want to shut down “politely” and it’s an art to do it without embarrassing the receiving party? But that means that only people with such political skill/power can take that action.

I think it's pretty easy to politely shut down tangents.

"Thanks for raising that. In this meeting I want to focus on X. Why don't you start an email thread with <whoever> or setup a time to discuss this later."

Not in my experience. I value it hen someone realizes that a discussion path left to its own will not help with the goal of the meeting and then asks to have that discussion in a different channel. This is true when I was contributing to the distraction as well as when I was wishing we could get back to the meeting's purpose

Pal, it's like meeting 101, the only people possibly get butthurt about this are those with zero work exp

Um this happens all the time, and you know what, usually the people involved in the discussion realise it is the wrong forum and it is one of them who will suggest 'taking it offline' so as to not waste everyone else's time.

Meeting is about X. If someone rolls in and only wants to talk about Y they are one or more of these things, a) clueless, b) unprofessional, c) disrespectful of others time.

But what typically happens is people get excited and have ideas. That's great, but focus is key and people need to be reminded.

TBH, I don't even see any art in shutting it down. I get excited about ideas and can head off on tangents. The meeting runner (or anyone else) should call me out, and get us back on track. And when this happens, I apologize and thank them for the reminder.

I agree 100%, I'm a product leader at Amazon, and if a meeting goes off the rails we will say "let's take that offline". I even inject things from my background and end it with "let's connect offline". I've even told leaders higher up in my management chain "Let's not solution this here, we can schedule time for that if we agree on next steps". They don't mind, we're all busy, often very excited about what we're reading, and in free-flow feedback mode.

It's easy to get excited and run off topic a bit. Brining it back in actually shows a respect for everyone in the room. Not everyone in the meeting is interested in the random off the rails thread anyway, schedule a follow up and get the meeting back on track.

> Let's not solution

Ah, corporate language :-)

Let's not solve this, solve.

When you are in a room with Solution Architects.. what do you say.. use the vernacular of your audience.

I guess they should be renamed to Solve Architects, then :-p

Former AWS SA Manager here, my team had a standing joke about dissolving the problem.

or even worse solutionise/solutionising.

Conversating

To Solution = Discuss options, tradeoffs, identify next steps, working towards a possible solution.

It's a transient state that leads to a solution eventually but not necessarily by the end of the first discussion

To Solve: To identify a definitive solution immediately.

Sure, you're not wrong, it's corporate-speak. But it does have some nuance.

I can picture this so clearly it’s painful.

To be clear, it’s very possible that both these perspectives can be true simultaneously. Big corps are one in name only, different divisions could be different companies and thus the variance in experience.

PM prerogative. Same as it ever was.

What's an SME?

Subject Matter Expert

Engineering jargon for "Subject Matter Expert".

Is this common across the industry, or mostly used at Amazon? I’ve been a professional software engineer for 20 year and read a lot of HN, but I think I haven’t seen this particular acronym around much (I think I would usually call these people “domain experts”).

Yeah - I’m nowhere near Amazon but I’ve heard it, even been called it more than once. In my experience it’s not a title, so much as a role in a particular context. Like, I could be GM of billing - and therefore in a meeting I might be one of the billing SMEs.

The term "SME" is common in engineering. It is equivalent to "domain expert".

Same here, 25 years writing software, never heard it, even working in the Bay Area.

I got a pretty large number of upvotes on the three-word post above so I think the term is common in some circles, unheard of in others. Someone should map it somehow.

Map it somehow? What do you mean? There is a Wikipedia entry on it [1] that is a start.

To your point, maybe there needs to be an HN glossary of terms or something like that.

[1] https://en.m.wikipedia.org/wiki/Subject-matter_expert

I mean map which companies use this SME acronym and which don't, similar to how "soda", "pop", and "coke" map to different regions of the USA.

My hunch is it comes from companies that use PMI project managers. Maybe that maps to older non-tech companies, but I have no proof to back any of that up.

> never heard it, even working in the Bay Area.

I think SME is would be less common in the Bay Area. I tend to associate it's usage with older, less computer tech first, companies.

This is commonly used in the Hr, accounting, finance, and logistics teams in retail companies I’ve worked at that aren’t Amazon. In my experience it’s not uniquely an engineering term.

I worked at Nielsen (TV Ratings) 3-4 years ago and we used it all the time and not for tech. At the time it was used by all he major Entertainment Studios in Los Angeles as well. Any type of office role it: Marketing, Mathematician, Software and Data Roles, ...

Never used it at small companies so it seems mostly used at larger companies or relatively new.

I miss many aspects that are the byproduct of this particular Amazon process. Namely:

- it’s also a very email heavy culture, yet I had zero anxiety about what might still be sitting in my inbox unread as I went to a meeting. If it was important pre-work that was required for the meeting we all did it together at the start of the meeting. There was no expectations to have caught up on context prior. - the format was very empowering both as an author and a consumer. As an author the constraints meant you didn’t have to worry so much about the audience or the structure and instead it was a more pure focus on content. Likewise as a reader you quickly build a muscle for how to consume it rather than second guessing if there’s going to be some grand reveal or how a story is building. - it was also nothing short of inspirational being able to observe very senior leadership coming in to a read on something. Near zero previous context about local challenges, the particular business space or problems we’re discussing, and every single time they’d gone straight in on a fundamental issue others had missed or something that seemed inconsistent across the data presented that warranted a closer look.

Agreed on every one of these points. Especially with the inspirational aspect of seeing veteraned industry leaders and principal engineers come in fresh and have questions and misunderstandings. It's given me the courage to be wrong or confused and ask questions. I've also admired a few people's ability to advocate for shared principals and express how this relates to them - especially customer obsession

Funny I literally tell people when they join my team that email is the worst way to get my attention. You have a guaranteed slice of attention from me if you schedule time. If you email me you're spinning the wheel and if what you are sending me isn't that important, I'll get to it when I can.

> I’ll get to it when I can

Sometimes that is what I want: the non-urgent attention of a relaxed person who can think more deeply about a problem.

I found printed documents to be much more helpful than using Quip (or WorkDocs).

Quip / WorkDocs means you start getting comments, highlights and other things from people -- which are then visible to everyone else at the meeting.

If there was a way for you to personally highlight your concerns during the read-through and then the presenter could display them all at once that would be great.

By not having that ability, it tends to mean the person with the "most authority" has their comment taken seriously and addressed straight away -- just like having the "loudest voice" in a meeting works against allowing everyone to contribute.

I actually prefer the online docs format as there's usually a bunch of things people jump on, and if I see someone commenting on that, I can keep reading and get further down the doc (better coverage).

When I did doc reviews on paper, I found everyone would find the same weak point in the first paragraph and would miss getting to the end of the doc.

Another major benefit, esp for junior employees, is the person who wrote the doc does not have to take as many notes, they're all in the online doc. Meetings full of senior folks tend to have TPM/PMs in the meeting who are playing notetaker. But junior folks are defending their thesis and taking down notes, it's just a lot to do. Online docs makes that a lot easier.

As I've had mentors say... if you find issues in the first part of the doc, what are they hiding at the end... Save your questions till you read the whole thing.

Understood that with printed docs multiple people may start commenting on the same points, however, the discussion happens only once still.

I personally find that many of the comments showing up with online commenting are not worth, and they don't even get acted upon. What's lost in the process are good comments amongst the sea of them.

Notetakers should be capturing the key points anyways. Large number of online comments is perhaps even worse than meeting summary notes with a raw listing who said what.

I'm with you on filtering out the key points. But I felt I had to do that in paper meetings as well. I have no real issue closing out comments after the review.

I've also started making heavy use of suggestions instead of comments for minor edits... I spend a lot of time doing grammar and phrasing stuff on early release documents. This feels more like collaborative editing.

Both paper and online docs are a lot better than sending around word docs with track changes on tho.

+1 overall.

>> I'm with you on filtering out the key points. But I felt I had to do that in paper meetings as well.

Agreed. Even for the verbal discussions after paper meetings, the law of triviality still usually applies. https://en.wikipedia.org/wiki/Law_of_triviality

Just that it has become worse with online documents.

>> I have no real issue closing out comments after the review.

+1.

>> are a lot better than sending around word docs with track changes on tho.

I agree, collating feedback from multiple Word documents is a lot harder for accommodating the smaller comments (i.e., those comments which should be handled later offline).

It would have been ideal if (online) document review tools had the following features:

(a) Allow the reviewers to mark their own comments on importance. I would find this useful even as a reviewer so that I can bring up only the important points into the verbal discussion. It would also be helpful if I can mark some comments as intended for myself only.

(b) Submitting the key comments first (using 'a' above), subsequently the remaining ones after the meeting.

With online commenting, comments show up even before they have read the whole document which partly defeats the purpose. Often the comments are already addressed later in the doc.

With printed documents, the audience naturally brings the most important comments first, and many less important ones would never come.

I personally prefer to send documents by email. Everyone has their own copy in which they may put comments, but what comes back in the meetings are only good comments.

I think you're missing one of the biggest features.

Do you really think that most L8s have time to read your doc, let alone Jeff or Andy? Their calendars are all completely booked. Asking them to read the documents before the meeting without scheduling the hour for them just means that doc is not going to be read. It's also asking them to value your document over their other obligations and their personal time. Most L8+'s and especially Andy/Jeff are just wall to wall doc reviews and decisions.

Putting the time in the meeting is the respectful thing to do for other people's time. I'm a PE (L7) and I have to ask people just to book an hour for me for docs to read otherwise it just won't happen, someone else who does use my calendar will take that time instead.

That's pretty counterintuitive - surely if I book half an hour on your calendar and ask you to take half an hour beforehand, isn't that being more respectful of your time than booking an hour on your calendar? Surely in the worst case you could achieve the same thing by blocking out the half hour immediately before my meeting yourself, but you gain some scheduling flexibility as well.

If your schedule is busy enough, you may literally not have half an hour free between now and the half hour being booked. Calendar UIs are pretty good at making it clear whether you're finding an open one-hour slot and less good at making it clear whether you're finding an open half-hour slot where there's a free half hour at some prior time. And they also won't put a hold on that half hour, so multiple people might send meeting requests that implicitly expecting the same prep window.

You can potentially build a culture where it's normal for the recipient to decline invitations if they can't find a prep time, but it's much more coordination overhead.

Also, there's an advantage in having the document fresh in your mind, instead of shuffling into a meeting with people grabbing sodas etc. and immediately hearing "So, any comments on section 1." (The article mentions this: "Some people read the document but forgot what it said because they read it days or hours before")

Maybe another way to put this: "respectful of time" does not mean allowing the recipient to cram as many things as possible into their working day; it means allowing the recipient to decide how many things they can pay full attention to. If they don't have a full hour to dedicate, the better answer might be "Let me find you someone else who can provide you feedback" (or declining some other commitment in order to prioritize your document) instead of showing up for half an hour.

Book an hour because that’s how much time you’re actually asking for. Don’t additionally give someone with a busy schedule the task of booking another appointment on their own to prep.

I think the key insight is that if you have some free time. Being able to schedule your prep is convenient. If your day is going to be packed full 110% of the time anyways then you may as well let the scheduler of the meeting schedule your prep at the same time.

But I have always thought it would be nice to be able to have calendar constraints. Some simple like "I need 1 contiguous hour for lunch between 11 and 15" to more complex "I need travel time between meetings" to automatically rescheduling meetings across people to avoid fragmentation issues. This could be a potential additional constraint. "This 30min meeting requires a preceding 30min of prep". This would be more flexible to schedule so could help busy schedules align. Then every day before I leave the tool can stabilize my schedule for the next day, any maybe I end up doing tomorrows prep today to allow things to bin-pack better.

I’m a director level person — anywhere from 60-80% of my working hours are allocated in advance, and I have a hard limit where I stop working. So time is precious.

So if your expectation is that I’m doing work to prepare for your meeting, you best be confident that it aligns with my priorities and make that expectation clear.

It’s often a rude awakening for new PMs and salespeople. Lazy people, or people who have worked for micro managers, like to push trivial decisions up for various reasons.

I don't have an hour before hand. Just book the time on my calendar and you don't even have to show up, gcal lets you do this. This is how I get most of my document reading done for people. Sometimes I find other time to do it. Sometimes I don't. But having the person show up and code on their laptop while I read makes me really feel guilty, so it guarantees I don't get pulled onto something higher priority (this happens to me a lot).

Also if the person doesn't feel it's worth their time to do me the favor of making the appointment or to get my feedback, then are they really going to listen anyway, or are they just having me review it because their manager said they had to?

I'm an Amazon product leader and I agree 100%, I'm already in back to back meetings all day long, emailing me a doc to read "in advance" puts all the stress on me. I'd rather you put time on my calendar and let me read quietly, and let me give you immediate feedback rather than me having to draft yet another email in reply to poorly explain my questions and/or my ideas.

I also block time in my own calendar, I have to write, a lot, and I have to work with my team on docs and other outputs. I block my calendar for those times, if you want me to read you know clearly when I have time to read with you, just grab a free slot on my calendar (in my timezone please lol). I am happy to provide the time, enjoy learning new things, enjoy sharing my thoughts, and often I can help find the right next person to read with you, or sponsor a leader to read with you.

Now all this said, I do find it a bit intense, to read "on the spot" and provide feedback, that said I will often provide feedback and suggest a follow-up meeting so I can noodle on the topic some. Meanwhile the author can spend time getting other input, improve the doc, and come back with a stronger story.

The best part for me: On-boarding!

When new people join I share major docs that were important to my team's plans, and some of them date back several years! I can share the doc with the new hire, ask them to block time for read + Q&A. It saves time getting them up to speed on our thinking, and we can discuss "so where are we on this journey" rather than spending time telling the full story for the 1,000th time.

When I joined Amazon I was an "Orator" style product manager, I would "tell the story" over and over, sometimes with some power point. And it was successful, however I feel like me and my teams are many times more successful with a strong doc process. And in the end decisions are memorialized, we don't have to go back and hash them over and over.

I was an entrepreneur for 25 years of my career, and CEO all those years. At Amazon I feel like I get the best of both worlds, the ability to innovate, invent, and the ability to do it at scale without pitching 100 VC's my next idea.

Interesting the way you termed docs as useful for Onboarding. I've found myself doing this a lot with our new SDE/SDM/PMs when they come to me for advice on how to propose initatives. I usually send them a top hits list and tell them which doc is appropriate for what scale / audience. Thanks for giving me a better way to phrase this!

It sounds like I would have a distinct disadvantage if I was at Amazon. I am a slow thinker, and questions and ideas often come to me a day or so after reading some document. If I had to come up with all my responses within 20 minutes, I'd be effectively cut out of the conversation. Maybe that means I'm not L8 material.

It is said in the article that documents can be provided early. So you could read the stuff twice, first the day before so you have the time to think and then at the meeting to refresh your memory. So no, you probably won't have a disadvantage because of your careful thinking.

The effective ICs that are that high level get involved in the whole doc process earlier than The Final Review anyway; people are collaborative about those before The Official Meeting, and asking to take a pass at the doc before The Review With So-And-So isn't weird.

More than anything it actually gives people time to read the document. Time doesn't come from nowhere, especially for people higher on the ladder. It's always good when its purposefully scheduled, rather than expected.

What happens if a document does not deliver the data and too many things are unclear? Like too many questions appear and the while meeting is becoming unproductive?

Typically you get that feedback, in a very clear and positive way. I've never felt like someone was putting me down when my doc was not answering the questions.

The goal of a doc is not to show how smart you are. The goal is to expose the truth as "We" know it and expose it to critical feedback to dig deeper, or decide we have enough to make a decision.

If it's an important meeting, it's expected that you've gone through previous reviews with other people who would've given you that feedback

If there are issues that have not been caught until that important meeting, you'll get feedback to come back with the concerns addressed

I’m at AWS and the doc focus meetings is my favorite cultural force of working there. I was surprised to see the article leave out the benefit to author of forcing them to clarify their thoughts and get evidence to support their claims. I am always way more prepared to discuss and defend my proposals after writing a document, even if I thought my idea was pretty clear before writing it.

A drawback, if you want to call it that, is it can be exhausting. Both on the consumption side when you have to review lots of deeply technical and nuanced things all day and be on your A game, or in having to constantly write documents. As I’ve gotten more senior it has taken the largest part of my time now. It also seems like a lazy answer from management can be “well write that up in a doc and we can review”. Feels like you can’t discuss anything without a doc sometimes. But still love it, net net.

Having witnessed this through a flood of incoming ex-Amazon folks I agree that it brings so much more content and focus on a meeting. It is amazing. The silence, the reading, the staying on topic (apart from tangents that sometimes need to be brought up, but are vulnerable to being just dismissed with the power of The Document) all helps to get the attention and feedback you need.

The thing is though, that while the article mentions briefly challenges with the writing, it does not shine light on the hours and hours or reviews, rewrites and re-reviews when preparing the document. The endless and often times pointless arguments and bad blood between people on how to write a sentence so that it would be "correct" and every word and number counts. Arguments if a given word should be "benefit" or "impact". If the word should be "system" or "solution". It does not feel productive and I am not sure if counting the hours spent would actually add up classical "hours wasted" in a typical 10 person "pointless meeting". And also when usually a piece of writing has some soul of the writer, in these documents they end up being soulless, blank format robotic texts only aiming to convincing the reader to fund your project or sell your idea over others. And that leads to quite an Amazonian culture that is a subject of many different articles.

I just felt there was something omitted by OP. So while it has benefits, it does have a cost associated.

The downsides sound a bit odd. The process as usually described seems like a single person usually writes the doc, often the person in charge of delivering the project? Why would there be much argument about the wording then? And if there is a duo or team, it sounds like the same rules as pull request / code reviews apply? Make sure it's objectively correct, then concise, and last stylish?

It varies on the attendees in the meeting and the length of the document. If it’s what is typically referred to as a “6 pager” the situation that parent outlined is certainly believable. Lots of collaboration with peers and your manager and weeks of refinement before that meeting.

Similar with the working backward process/PRFAQ. You might stop shopping it around when it’s just the answer to the 5 questions and an aspirational testimonial. By the time it’s a meeting reviewing the 1-2 page press release it’s likely been months of refinement.

That isn’t to say it’s a full time effort over that period though. These things are usually background/parallel work with whatever else you you’re doing.

An ex-Amazon PM ‘promoted’ the silent reading culture in my previous company. Definitely brought a lot of benefits:

- forced more senior / leadership members to read through and internalize the details. Reduces wasted time asking already answered questions.

- we used google docs. Question and answers were posted as comments. This formed a log of the majority of the discussion. Less note taking needed.

- allowed less assertive members to ask questions or give answers.

The only drawback - the overwhelming silence at the start that I never really got over…

I just pop on my headphones and get reading. Silence gone.

> The only drawback - the overwhelming silence at the start that I never really got over…

More the overwhelming anxiety you face being the person who has written and edited the document multiple times during the 30 minutes of silence at the beginning of the meeting.

As a dev, o boy, the silence while people read your docs was maddening. Great people watching though as they digested and marked up what you wrote. Whole process is mildly cathartic to be honest.

> The only drawback - the overwhelming silence at the start that I never really got over…

Dealing with silence is a cultural thing. In Nordic countries silence is the norm.

It seems that way to me too. In the US silence is basically a crime against humanity.

I wonder how widespread this is outside Amazon. Compare it to, say, Google: In Bay Area, the cultural influence of Google is strong both in good and bad ways. Things like OKR, monorepo, snippets, go links etc. seem to be adopted by many younger companies. I don't think it means these cultural artifacts are always superior. It'd be more about familiarity for ex-Google employees.

There must be a lot of ex-Amazon talents, but I haven't heard or read this outside the context of Amazon. If this is unique to Amazon, why?

Maybe the book "Working Backwards" [1] is changing the situation? I'm very curious, and honestly, a bit envious.

[1] https://www.amazon.com/Working-Backwards-Insights-Stories-Se...

Flexport does it.

Is all that stuff just like cargo culted from these giant companies? My company does these things and I've always kind of found it weird that so many unrelated people seem to use the same terms. Like one year we just started using okrs and seemed like everyone else was too. Silent reading was a fad for a year too. I think everyone found it be annoying though no one does the silent reading thing anymore

Yup, these are fads.

Fads come and go. If they significantly improve life, they tend to stick around until they are near-universal. If they significantly detract, they tend to go away.

What people notice are the new fads and the ones which are negatives but for some reason are still being used.

Properly run meetings with proper documentation and procedures are not a fad.

Hence the staying power of Robert's Rules of Order.

But if I insist on getting a motion, a second and a voice vote by acclaim during a monthly poker game, I'm not getting invited back.

Apollo Agriculture does it.

We've used the document-driven approach effectively at our company retreats (https://innolitics.com). We plan to use it more frequently as we grow (we have 12 engineers and are hoping to hire a couple more this month).

I have worked at both Amazon and Google. The document writing culture is 10x more serious at Google. If you didn’t write a doc for a project, it didn’t happen.

However, the review process is different. People are expected to comment on the document beforehand and use the meeting to discuss any contentions. The google doc comments accurately capture the history of why a particular decision was made.

I found the Amazon wiki and quip terrible tools for writing docs. In practice, folks spent only the first five minutes reading a doc. That is rarely sufficient so you’re expected to read the document beforehand.

I think the key here is that the pre-meeting review provides a time-efficient way to highlight gaps in the document and highlight the areas that are contentious and need more justification. The doc can then be filled in more before the meeting where the final details can be discussed.

It has far less to do with "everybody silently sit in this room and read the paper at the beginning of this meeting" and more to with forcing the driver of meeting with articulating their thinking in writing form. Few understand that the 6-pager isn't about the reader but about the writer.

That’s an interesting thought that suggests that if you’re someone holding meetings, that you can get some of the benefit by writing a brief for the meeting even if the culture isn’t to stop and read and comment on it. I say some because I’d expect you get better at composing your thoughts if others are reading and critiquing the output.

That applies to presentations as well.

"If there’s no document, we cancel the meeting."

this is a very good idea.

I tried to push a "if there's no agenda, we cancel the meeting" at a prior job. It didn't really work that well. They had a lot of standing "status update" and "one-on-one" types of meetings that were just on the calendar without any specific goals or decisions to be made at any particular meeting.

There are meetings which should not be thought of as "meetings"

Labeling them as collaboration sessions or more social one-on-ones helps though.

I love this idea.

I've tried to push people to make agendas and just generally do some legwork to make meetings run smoother.

There's only been a few times where I've had project managers who actually tried it out. It was glorious and meetings ran so smoothly, but it stopped shortly after.

I guess they found it to be to onerous to spend 5 minutes write an email. I think it's hopeless to expect them to write an entire document.

A related good idea is "Ticket or it didn't happen."

Every time a question gets answered, or something gets discussed, put in the appropriate ticket for the problem related to the meeting.

If there isn't a ticket, why not?

Actually I have often pushed a meeting with a simple "The document is not ready".

Obviously you can get push back if you do it too often, however nobody wants to join a bad doc read meeting, they'd rather you get a bit more time to work out the issues in the doc.

Often times the issues are cross team, you need to get alignment with partner teams before you join the meeting, or if you can't you write a "hotly debated topics" section with the partner team and just go for it. There is a balance, you should not spend too much time driving for alignment, but you would be better served to come to the meeting showing both sides are talking and understand the point and counter-point.

Some companies have powerpoint fetish and those are basically the exact opposite of this.

You go to a meeting and someone without presentation skills that has spent more time choosing the background picture than thinking about the content is going to give you a lot of information that nobody will document after the meeting ends. You will end up with some random notes that you won't remember after a week.

This is my company right now. Everything is in PowerPoint.

Even guides or system documentation gets put in PowerPoint in stead of a document, it's really annoying.

I've read this blog and comments with great interest.

The first time I heard of this idea was at an Edward Tufte* seminar. He researches and publishes on the design of presented information and how that impacts how it's communicated. His books, especially The Visual Display of Quantitative Information, are highly recommended.

* https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...

Tufte is required reading for everyone in my group. I actually give every team member a copy of his book.

Another nice add-on to this format within my department is that we utilize an internal retro tool for people to post their questions for discussion.

After the 20ish or minutes of silent reading, we give people ~5min to post their questions for all others to see in real-time. We then give people a set number of votes and the presenter goes through the list answering the questions in descending order of votes.

I was hesitant at first when they introduced this (since it felt like more red tape), but I've found it helps focus the discussion on the most important feedback while avoiding one person bikeshedding the discussion time right at the beginning.

We've been doing ours in quip with wfh.

Comments are added in real time as people read, and both readers and the author can respond to those questions as they go through.

Its kinda changed the switch to talking where we mostly talk overall comments, and then go to the biggest comment threads to make sure everyone is aligned

Can you share the tool name?

It's an internal tool developed at Amazon so it's not available to the general public.

That said, it's nothing super fancy. Simple collaborative sticky note app that supports Markdown and has the ability to vote once per sticky.

You can use https://retrotool.io/

What kinds of feedback have come up about this for people with reading challenges like dyslexia?

The closest comparison I have to this is reading in school where it became very obvious who the fast, skilled readers were and who had to work harder to understand the text, which caused a lot of anxiety for the slower readers (which didn't help).

I can imagine a wide variety of possible outcomes for this, from accommodations being made to people just being a lot more mature as adults, but I'm also guessing there has been some trial and error about this at Amazon and some best practices have emerged.

Does anyone here know what they are?

For my team, we take average reading speeds for the main document then add extra time for the appendices. This means that slower readers will at least get to read the main document. Also, providing documents in advance will give those who need time and technical assistance, the ability to take the steps they need prior.

Glad you asked, I have dyslexia, and I was very worried about writing, much less reading fast enough. In general we budget 4 mins per page, that said the meeting usually starts with a "here's the doc, please read until XXX and let us know if you're ready sooner". And then a "time check how are people doing?" and often you'll hear "I need N more minutes". And back to reading.

I was very worried about this part of the experience because of my challenges, I'm not the world's fastest reader, but over time I got comfortable just saying "I need 5 more minutes". Or I'll say "I'm on page N".

That said we do have some leaders who read incredibly fast, for them I always include some good appendices so they stay "in the room and on topic" rather than float off into their email.

This is off-topic but your comment reminds me of a principle I learned when I was briefly studying to be a teacher, use extra enrichment material rather than tracking (ie, having the kids go further ahead in the main material) for advanced students so that the slower students do not feel discouraged or left behind and the faster students do not get bored.

I got a book thrown at me in middle school by a teacher who thought I was lying that I'd finished the whole textbook when he told me to try working ahead if I was bored.

When I handed him a stack of all the end of chapter tests to prove it we had to schedule a meeting with the principal to figure out what I should do next. It involved having to go to another school in the morning because mine didn't have anything else to teach me, and I can't help but think you're right that enrichment would have been a better solution for everybody than that was!

I remember in junior school there where about three or four of us who the teachers let read at our own pace.

This is exactly the sort of information I was looking for! Thanks for sharing!

I just proposed this, with your suggestions to my team. We've been experiencing meeting creep and having some trouble staying focused on one meeting topic at a time, and I think this will help us a lot!

Does anyone have an example of one of these documents to share? Preferably a "6 pager". I'd love to see what a real-world example looks like.

Someone who used to work at Amazon wrote one[0] describing their game engine, as well as a description[1] of the important mechanics of the document.

0: https://docs.google.com/document/d/1LPh1LWx1z67YFo67DENYUGBa...

1: https://writingcooperative.com/the-anatomy-of-an-amazon-6-pa...

Thanks for sharing!

The tenets section is missing the traditional "These are our tenets, unless you know better ones".

We operate in the same way in the company I work for, and while it's certainly an improvement over useless presentations, the silent reading being part of the meeting drives me insane. The fact that people can't manage their calendars to allocate whatever time they need to prepare before a meeting now means that the rest of us have to sit around for 15 minutes twiddling our thumbs. Even if I purposefully ignore the material until the meeting itself, I typically finish reading in about half the time it takes the slowest reader. I almost wish meetings would have two different start times - one for people that want to do meeting prep during the meeting and one for people that do it at some other time, so that I can just join 15 minutes in when everyone is actually ready to start the meeting.

I complain, but again, overall I think it's an improvement over what came before and I wouldn't want to go back.

The author implies that going to meetings later if you've already done the reading is an option at Amazon.

> If a document is provided early and I have a conflict at the begining of the meeting I can read the document ahead of time and join the meeting 10-20 minutes late without missing anything.

> I almost wish meetings would have two different start times - one for people that want to do meeting prep during the meeting and one for people that do it at some other time, so that I can just join 15 minutes in when everyone is actually ready to start the meeting.

They do. Show up 15 minutes late, or bring your laptop and get work done while you wait.

> The fact that people can't manage their calendars to allocate whatever time they need to prepare before a meeting

If I wanted to manage my calendar in the way you suggest using my current calendar system it seems like I would manually allocate a block of "prep time" every time someone invites me to a meeting with prerequisites, correct?

If prep time is publicly blocked out then we may have to manually negotiate a suitable time because no one knows which blocks are prep and which are meetings. Alternately if prep time is not publicly visible then anyone can schedule over it then people need to start rejecting meetings after all blocks are filled by meetings or prep. In both cases everyone has to manually reshuffle prep time and potentially manually negotiate schedules which sounds like a lot of work for every new meeting.

In reality everywhere I've worked assumes that "prep time" is something that everyone handles in their own way. In practice that means some people mange to squeeze it in during normal business hours, some people do it the night before during their personal time, some people (usually the most important stakeholders) come with an apology that they haven't gotten to the material yet.

Perhaps it wouldn't be so bad if calendaring tools better supported this use case (e.g. "reserve 30m up to a week before this meeting") but until then blocking out time during a meeting for reading seems very civilized.

I think this comment comes from a place of having plenty of unscheduled time before the meeting, but the format is really oriented around solving things for people with no unscheduled time.

I am curious if Amazon follows this process for engineering design documents. I worked there a very long time ago and don't recall this. At another company I worked for, folks from Amazon introduced this for eng reviews. I found it very difficult to get or do a thorough review after reading a document for the first time at the meeting. Some things are nuanced and need time to process - I thought this style just didn't work for these cases.

Writing is followed for design reviews as well.

The recommendations to solve the challenge you mention are to (a) writing better, (b) splitting into a sequence of meetings, (c) reading the document ahead of the time.

There's no real reason why writing process should not apply to design documents as well.

I wasn't questioning the writing process - written design documents are very necessary. My experience with the Amazon-style design review meeting is that there wasn't sufficient time to read the document, process it and come to a decision. If you're reading the document ahead of time, then that isn't really following Amazon style :)

We try to go slower with such documents. E.g., the meeting may start by asking to read the first five sections and discussing them first. The meeting then may naturally be longer than an hour, usually two hours, and still may need a follow up slot.

Nothing in the Amazon style precludes reading ahead of the time, and it is recommended to send the document to the audience ahead of the time. That people often don't is another thing.

I start reading ahead of the time as I read slower (but also read more carefully and thoughtfully).

Few anecdotes from Amazon's folklore. "Why a six-pager has 6 pages?" A typical meeting at Amazon is 1 hour long -- 30 minutes reading followed by 30 minutes discussion. It is rumored that it takes Jeff Bezos 5 minutes to read and fully understand 1 page (10pt font, 1.2 line spacing). Hence 6 pages in 30 minutes. BTW, a six-pager can have an unlimited number of appendixes that do not count to the 6 pages limit. These appendixes provide extra in-depth info and often discussed during a meeting. But appendixes are not required reading. That said, quick readers oftentimes cover extra 10 pages during the silent portion of the meeting.

Does this discourage attendees from reading/thinking about the topic ahead of time?

If you’re the presenter or organizer, you’ve put all of this energy into a document. You’ve thought about it for days or weeks or months. And now meeting day is here, people sit down and read your document, and immediately, there is a discussion. Those people who literally just finished reading about the idea 2 minutes ago now have thoughts and opinions on it.

This happens regardless of the existence of documents, of course. But I wonder if waiting until the meeting to read the document encourages this sort of immediate feedback from people new to a topic.

Generally a link to the document is sent out earlier in the day. That way folks who are inclined can read ahead and comment. The slackers still get time to read the doc at the start of the meeting so they’re not completely in the dark.

Haven written many 6-pagers, PRFAQs, and other written narrative formats then centering the meeting around the written documents, the writer should write for the audience and the allotted time for reading and discussing. New people may have less to contribute in the moment, but now they can read and research it later for contributions.

Yes, it does. But I don't think that is a problem...quite the opposite. When you're preparing a document, and you know you've only got a half hour some some executives attention, it forces you to really think through the message. It forces you to ask yourself questions, and find ways to make the point more succinctly. It's an extremely refined elevator pitch devoid of the influence of charisma and showmanship.

If you expect people to read before the meeting, there are two problems: 1) nobody will read before the meeting, and 2) the documents become too verbose and poorly thought out. If you don't expect any reading at all, you get presentation-led sales pitch that favors smooth talkers and charlatans.

I absolutely hated about 99% of the culture at Amazon, but not the document-led meetings. It's an amazing bullshit filter.

Generally you will have actually reviewed the document with wider and wider groups of people, gotten feedback and updated the doc. Many of the people reviewing the doc will not be seeing it for the first time. Others will.

Generally reviewing it with your local org is called "getting alignment". By this point in a big review the document should represent your team, org, or groups view to the next layer up who needs to approve.

If you're reviewing a doc with other people for the first time in front of your VP (unless they are your manager and this is like a 1:1) you've gone seriously wrong IMHO.

I’d love to get insight into how orgs with cultures like these organize docs so they’re discoverable

Generally the docs are linked from the project wiki pages. So you can find say the docs for DynamoDB on their wiki page (I'm not sure that's true anymore but it's an example)

The docs are actually not as important as a legacy item as you would think. They're good to go back and look at for context. They're also good to hand to people as examples.

But their real purpose is for forming consensus / alignment around an idea and then choosing to pursue, iterate, or can the idea.

Thanks for sharing! This makes a lot of sense given my own experience -- my workplace is very document centered but the docs are fairly transient and disposable once the decision is made. My takeaway is that there's a high bar of institutional memory and personal processing time to engage with the history of docs, which is made higher when there isn't a curated index of some kind.

When I first heard about this, I thought it was a brilliant idea.

The alternative, perhaps the norm these days, is PowerPoint-driven meetings. I find this fraught with so many problems.

Firstly, while most people receive a lot of training/education on how to write well, the came cannot be said for putting together decks of slides. Some people are great at it, most are not.

Secondly, condensing everything onto a few slides allows for people to skate by on some sort of 'impression management.' If you put down the right buzzwords, maybe some diagrams, it may resonate with your audience but it does not guarantee that you or they have a detailed understanding of the important details, or even the same understanding of what the important details are.

And thirdly, the presentation is distributed outside the meeting as a static document, shorn of context, and more likely to be misinterpreted. Not to mention, during the presentation, people are more easily distracted as you go through the content, compared to if everyone just reads a memo in the allotted time.

Equalizing the level of preparedness for the meeting is also a great benefit, although that's a more general problem.

I'm curious how this work with people who don't read or write English, or are L2 learners. Are they kept out of the loop?

My neighbor’s first language is Spanish, but his grasp of English is very good. He went to work for Amazon corporate and said the first several months, coworkers would tear apart his documents on English issues. It worked.

He quickly learned how to write documents up to Amazon standards. Amazon was a terrible place for him anyway (work/life balance), but he certainly wasn’t kept out of the loop. He was forced into the loop.

Very good, that type of rigorous immersion is what should be done for ESL kids at all grade levels during education, otherwise they are at a varying degrees of disadvantage in all subjects

There are text-to-speech converters

I think it's easier to read a foreign language than it is to speak it (assuming you know it at all).

I found this to be true for languages that use the same alphabet, but found I could understand spoken languages with different alphabets much faster than I could read them, especially when the direction of reading was different.

Being able to stop, go back, and look stuff up is huge. Googling the common form of a phrase you want to use is huge. Assuming you have basic reading proficiency already.

I’m learning Thai: literacy is not for beginners here. But I look forward to one day googling stuff like I do when reading Hungarian legal contracts.

That’s definitely my experience. The ability to lookup anything you don’t understand and not needing to battle against strong accents and/or poor enunciation makes a big difference.

I don't think these people are recruited in the first place. This is about Amazon on the software side.

So, a sizable portion of Indians and Chinese folks? Many Indians have spoken english most of their lives, but definitely tons of Chinese (and other) devs where ESL is a very real thing.

ESL doesn't mean that you can't read or write english. Amazon requiring the devs to be able to read and write english is not really surprising, I would consider it the bare minimum.

Most of the chinese people I've met in tech have been excellent at written English because they learn it starting in primary school. They're just uncomfortable speaking it.

The written meeting format may be less disadvantageous to non-native speakers than the oral format. As the article mentions, it helps presenters sidestep accent issues. And I bet most non-native audiences appreciate being able to see the text instead of having to catch it from a single listen. It helps too that written communication isn't going to be laden with the various side comments, idioms, and in-jokes that an oral presenter always brings.

IMO, to some extent yes. Just like they'd be 'kept out of the loop' in many other cases for not having the best communication. It's not inherently fair but I don't know how to solve that problem either.

It’s striking that command of written language could be considered an “unfair” expectation in a cerebral, white-collar job.

In a not-very-distant cultural landscape that’s the baseline. Show up on time looking presentable, read, write, summarize, make deductions, discuss. All the domain specific stuff is taught on the job.

In my org at least, most of the time the doc is distributed ahead of time. It gives people a chance to spend more time on it or start adding inline comments. But we still start meetings with reading for those that don’t read ahead of time.

How common is the inability to read English at Amazon?

You are probably not an amazon knowledge worker unless you have those skills to start with.

I was always interested in this but could not yet find deep resources on it.

Sadly the post skips over the format of these docs - is there a good resource for examples/templates of the different doc types (with comments?)?

Also, how are these documents shared and made discoverable internally? Do they refer to each other?

There are lots of other articles about what's in an Amazon doc [0]. They're mostly accurate but it depends on the team quite a bit.

Comments are exactly what you'd expect from any doc comments. (what does this mean? who's the audience? does it scale? what are alternatives?) There are other links in the comments here with more examples if you're curious.

Most of the documents are shared via calendar invite. Lots of teams/products have team folders to collect docs centrally. Finding docs at Amazon has been the biggest gap IMO. There are too many places a document can exist and no way to centrally search them all.

[0]: https://writingcooperative.com/the-anatomy-of-an-amazon-6-pa...

Thank you very much for both your comment and link. This cleared things up for me.

It feels like an obvious oversight that there is not some company-wide Wiki to organize all of these docs. Since we are talking about Amazon/AWS, this has to be intentional. Can you speculate on why this gap exists?

I like the attention-focusing and emphasis on clear, concise, structured argument. I gather the idea is to get the right people together to introduce and critically assess a proposal or recommendation. I am suprised about not reading before the meeting, but reassured that one may read and reflect after.

If I want to roll this out in another organization, how does the rest of it work? - what is the process before and after the doc? What kinds of decisions or issues typically warrant a doc? Is there a process or situation that triggers the development of a doc, like a quarterly planning cycle? How does a doc review translate to someone making a decision - does a decision-focused meeting have a different grammar than a doc-centered meeting? Is there a book that covers the approach?

How does this culture work at the boundary? How does it work when meeting with people outside Amazon? I'm all for this idea but I can see it quickly breaking down for certain key roles, like product managers, who often interface with customers.

At our organization, we use doc-meetings to drive core operational meetings, core strategic questions etc. We still put together presentations for partners, our all-hands etc.

A thing that my coach told me at one point is "You can shape how your company and especially your reports communicate with you to make things work better for you" but the opposite is also true, you should proactively shape how you communicate with others to work for them.

Docs are for internal review. I've never been in a customer meeting where we reviewed a doc.

You could call this literate management :-). Not sure how this works for some purposes though, do audit / risk people make important decisions on docs they have just read?

The ritualistic sounding silence of the first half of the meeting could probably eliminated with an automated document distribution system that does not allow you to participate in a meeting unless you've scrolled through the docs for sufficient time within a few days prior (a bit like those license aggreement buttons at the end of oracle's java downloads)

Jeff has talked about this in public, "good executives will cheat, they're busy they won't take the time to pre-read".

I have found some leaders I can do "off line" with, but in general it's because their calendar and mine just don't overlap properly for a couple weeks and I want them to give me feedback earlier.

I've been at Amazon 3 years, 6 months, and 7 days (thanks phonetool). In that time I've only seen a couple pre-read meetings, and a couple "offline review" (still in your calendar). Most of the pre-read meetings are less effective, they usually happen because of calendar pressure and the need for rapid decision on a topic.

The one thing I don't like about WFH is that we sometimes "lose" people, they come to the meeting but float off into email, chat or whatever. When I first started we'd have 20 people in a room, laptops closed, reading, you could hear a pin drop. And usually I knew it was time to start the discussion because people looked up from their doc to see if others were done. I miss these meetings because the focus was amazing. To have all these people who I really respect read my doc and give me their 100% undivided attention is awesome.

The nice thing about WFH is sometimes we spawn a bit of related topic in the chat, however it can be really hard to keep the debate going while the chat runs across a different thread but related to the overall topic.

The thought occurred to me that the language development process for Rust and Python (and I’m sure others) encourage a variation of this document first process.

Many high level engineers that I’ve been impressed working with are very good at merging in a technical memo or brief, often at the start or early in the process.

Writing forces presenter to think about the idea in much more detail. This is major benefit IMO. Many times, where document culture is prevalent, people come up with vague ideas and expect others to clean it up. Definitely see a value in this approach. Thanks for the write up.

I wish I could read a document while using a step climber. I find that I get focused on the reading, and stop moving. Then I focus on moving for a bit, and lose comprehension. Then I have to read that section over, and stop moving. Rinse and repeat.

I usually have to stop while I write comments and occasionally if I start thinking about something a lot I'll stop. But overall in 20-30 minutes I still get 10-15 minutes of climbing. I don't have that many meetings so this usually only happens 2-3 times a week for me.

"Agenda" out, silent reading of document in.

Bit bizarre, but in this attention economy, I guess it's the only way to make sure participants are on the same page.

For example I put an agenda in a Google Calendar meeting and most people don't notice it.

It depends on company culture. My old job, people read meeting descriptions. New job, no.

My favorite is to try to CHANGE the culture to what I want it to be. Though I am not starting with the meeting agendas on that.

What I immediately like about this idea is it requires the meeting convener to do some prep in advance to guide the meeting.

Do you suggest a guide how to write these documents?

There are general style guidelines Amazon tries to foster. Here's a bunch https://www.linkedin.com/posts/herbertyang_i-joined-amazon-t...

You can also find templates and guidelines online by searching Amazon 6 pager or PRFAQ

anyone have examples of how to write documents in this style?

I miss that culture.

I don't miss having to use Word and Outlook.

Amazonion here. The purpose of doc writing is for the author to dump their ideas and convey the critical pieces of information. It lets the reader consume the information at their pace, and re-read even after the meeting. The document starts the conversation and let’s the reader understand the problem, why it’s important, what things we have or have not considered, what trade offs have been made, and how we arrived at the conclusion or solution.

There are many, many things Amazon does not get right. The document writing culture is probably one of our not so secret, “secret weapons”.

At many companies I worked at, we had a PowerPoint or presentation driven culture. And the purpose of those meetings is to listen to the presenter, at the presenters pace. The meeting becomes about the presenter and what they think is important, as opposed to being about the reader. In presentation driven meetings, the presenter talks and questions actually distract from the presentation - often times presenters will bluntly ask for questions to be saved to the end.

My own team has a strong culture of getting engineers to write, and help them write well. It’s not about perfect English, but it is about touching on the key points and letting readers comment and ask questions.

Meetings without documents often go completely off the rails - especially because if the kinds of problems we’re solving. Without focus, meetings delve into tangents and branches off of those tangents. To be fair - this still happens if the document hasn’t been adequately prepared, but often because you find the document owner hasn’t fully thought through the problem or fully did their homework.

In my experience, the issue is not presentations actually. Whatever can be presented using documents can be presented using slides too.

The real challenge is that slides present much less word-count space to deliver the right message, and most authors fail to do that right. A phrase commonly attributed to Blaise Pascal comes to mind [1].

That presentations being synchronous vs. everyone reading their own pace is not the key issue. Sharing the slides in print for the meetings can solve that.

At one employment I was in, we were using PowerPoint even more effectively than we use Word.

[1] https://intenseminimalism.com/2010/if-i-had-more-time-i-woul...

I read the link you shared. There is something to be said about expressing an idea with sufficient clarity in fewer words, without jargon or “officialise” or more information that’s necessary.

And Amazon doesn’t disagree with that principle. If anything, being clear, crisp, and succinct are the hallmarks of a great document.

>Whatever can be presented using documents can be presented using slides too.

For the kinds of problems that require document writing at Amazon, this statement simply just isn’t true.

And the document review is NOT a presentation. Let me say that again - It is not a presentation. Presentations are about the presenter, often presenting as if they are the authority figure on a topic. Written document reviews are about the reader — giving the reader the opportunity to understand how a problem has or hasn’t been evaluated. The document reader is not the authority. As a matter of fact, they share documents to get feedback and find gaps in their thinking, or seek feedback on how they evaluated alternatives, and so on.

Presentations and Amazon document reviews are fundamentally two different things. There is absolutely zero similarity between the two.

The document should focus on the immediate topic, trade offs, solutions while supporting evidence or technical details, design artifacts, and FAQs etc are provided in appendices. This manner of information sharing is simply not possible in any PowerPoint or presentation slide format. And the simple proof to back my statements — Amazon and everything it has accomplished at what people now call “Amazon scale”. This is literally the secret sauce.

## I see two-three aspects that you are conflating together:

1. Expectations on the flow of information, whether the author/presentor is:

(a) the authority figure, is teaching something to the audience and later answering questions or offer clarifications, but may also receive counter-points and feedback.

(b) presenting their current thoughts and looking for feedback on the same to refine their thoughts and plans.

I see no reason why 'b' isn't doable with slide-presentations, and we have actually done that more frequently than 'a'.

2. The container, slides vs. document, in which the information is presented. We are agreeing that slides require being more crisp, which is hard, owing to expectations of less text. Whereas a document also should ideally be crisp, however, expectations of use of a larger number of words and fuller sentences makes it easier. You have stated that the information for "kinds of problems that require document writing" and "topic, trade offs, solutions while supporting evidence or technical details, design artifacts, and FAQs" cannot be put into slides, but without explaining why so. I am questioning this again because I and my team has done all that successfully and repeatedly.

3. Sync vs. async. consumption of #2 by the audience. Even information put in slides can be shared with the audience for a silent consumption before discussions, and also be referred to later if and when needed.

## The real challenges are:

A. The popular guidance given for slide-presentations is to keep text on the slides to a bare minimum and have the focus instead on presenter speaking during the meeting. This makes things further worse as the slides by themselves end up being uninterpretable without the presentor speaking. Or in other words, the slides end up being little more than speaker notes. I generally disagree with this blanket guidance, and have used slides in both ways:

(a) Everything I need to communicate to the audience is written and visible on the slides, and I am peripheral to the meeting (think of a Teaching Assistant as opposed to a Lecturer), and

(b) The slides carry just the visuals which I explain live verbally.

Both 'a' and 'b' have their place depending on the context, i.e., the subject matter, audience, expected flow of information, etc. As an example, 'b' is more useful for classroom teaching to kids or otherwise for an audience who are averse to reading (there are many of them outside of work).

B. Use of slides require bring crisper, which we're already agreeing to.

C. Slide-presentations are typically done in sync manner under the status quo (but which need not be as noted in '3' above). The analog for documents would be to have all audience read section-by-section or para-by-para and discussing before proceeding. Whether applied to slides or documents, this is more useful only when the material has a sequential structure, i.e., the next section cannot be understood well or agreed upon until the current one is. Even if such sequencing is not there, sync does not always hurt though. Sync will be less optimal if:

(a) The material is somehow such that the readers must go back and forth through the material before they would understand that the author is communicating. Too much of that won't be recommended for documents either.

(b) When different audience members have widely varying (i) prior knowledge or understanding of the material, (ii) reading/absorption speed, or (iii) interest level in the subtopics or detail. Under this scenario, synchronization is at least one of ineffective or inefficient. Going fast would save time for those who already know, absorb fast, or want to skip subtopics/details, while the others would fail to follow. And vice versa. The said variations apply to document reading also, however, async consumption allows some audience members to finish sooner and then do something else while the remaining finish reading.

## Summary of my understanding

If we do not conflate various above points, we'll find that it's not about document vs. slides. The real problem are 'A' above (bad guidance on how to make/present slides) and 'C(b)' above (cited variability in the audience). Between the two, 'A' is more easily fixed by changing guidance and training. Then using slides with silent reading becomes an available option for 'C(b)' too, except for the challenge 'B' above.

If the authors have the skill for 'B' above, then not only slide-presentations, but also documents will be a lot better. So would also be meeting summaries which usually don't have the vigour/quality even at Amazon.

## Closing comments

Please think through the above carefully and then tell me what you think. I am open to debate. :-)

I want to point out the irony that you wrote a lengthy, dense document, despite your argument in favor of slides. And you’re asking for a debate (or saying you’re open to one). Im certainly not in the mood to write a document after what I previously explained, especially since your anecdotal evidence is that for you, slides have worked as well or better than documents. So having said, I don’t think this would be a productive “debate”. Instead, I’ll take this as an opportunity to provide feedback on your document. :)

I think it’s completely possible that for the scale your organization operates at and types of problems you solve, slides are as good as or even more efficient than documents.

That simply just isn’t true at Amazon, for the kinds of problems we solve. Now not every problem requires a document. But many problems are intrinsically hard, and they absolutely do.

Your document above is super dense, and the main points are ambiguous, even after seriously reading a couple times.

> Whereas a document also should ideally be crisp, however, expectations of use of a larger number of words and fuller sentences makes it easier.

There is no expectation that you use more words than necessary in a document. You should use the number of words required to unambiguously convey the idea to the reader. Help THEM understand what’s in your head. You’re looking at it almost as an act of vanity, and that completely misses the point.

That statement is difficult to decipher, and if you shared a complex topic with me using this writing style, I would actually prefer slides or ask you to explain it to me like I’m 5. Why? Because your document isn’t conducive to a productive debate. The conclusion isn’t immediately clear, and I don’t know what the supporting evidence is. Instead, you have a lengthy introductory text trying to break down the problem across several dimensions, but which of these are particularly relevant here? Unclear.

At Amazon, you would get dinged and the reader would question why you’re using complex sentence structure - is it because you’re compensating for not having done enough research? And passive voice is actively discouraged. I would probably ask you bluntly, “how much of this context is actually relevant?”

> If we do not conflate various above points, we'll find that it's not about document vs. slides. The real problem are 'A' above (bad guidance on how to make/present slides) and 'C(b)' above (cited variability in the audience).

Why such a lengthy write up if this is the summary of your argument? And “lengthy” is an understatement. There’s so much dense information here that you, the author, are not able to refer back to your own writing without having to simplify it down to an abbreviation! This is criminal, my friend.

The thesis is hidden at the end of a complex jungle of different points, with lists that are broken down into more lists. “lists” and bullet points, even if you try to weasel them in without newline separated bullet points, dont help the reader. Now The reader has to go back and put all this complexity in context, creating a tree of all this information and each node in their head. You’re actively making the reader work hard to understand your idea. At Amazon, we often dismiss this document writing as the author doesn’t know how to write well (and we need to help them), or they’re intentionally bullshitting us.

Going back to your doc — Why make the reader work hard to decipher everything else, which merely ended up being tangential? And your fundamental argument is a begging the question fallacy. The take away from your post is that slides are as effective or perhaps more so than a document, but you provided nothing to actually back up THAT statement. Your presenting what you are arguing for as being the truth in the first place.

Btw if this was an actual document review, my comments would be attached directly to your document and left as feedback that you or anyone else can revisit later on. We wouldn’t need to record the meeting or have someone separately take notes of the discussion.

Overall, this was more work to read than it ought to be. With so much unnecessary jargon and tangential points, it’s no surprise than you feel something other than a document would be more productive.

I’m convinced if you are able to write with clarity and conciseness, your opinion would change. You certainly produced a document in your post, but it’s as if you have preconceived notion that a document had to include jargon, lengthy sentence structure, and “officialese”.

> I want to point out the irony that you wrote a lengthy, dense document, despite your argument in favor of slides.

I am not opposed to document writing. I am however saying that the true reasons when and why it works better are misunderstood. There is no irony here. :-)

> And you’re asking for a debate (or saying you’re open to one). Im certainly not in the mood to write a document after what I previously explained,

There are flaws and oversimplifications in your previous arguments that I am pointing out. :-)

> Instead, I’ll take this as an opportunity to provide feedback on your document. :)

You're welcome. :-)

> But many problems are intrinsically hard, and they absolutely do.

Problems being intrinsically hard does not mandate requiring of a document vs. slides. The reasoning in the middle is important to cover, which is what I am trying to do. :-)

> > Whereas a document also should ideally be crisp, however, expectations of use of a larger number of words and fuller sentences makes it easier. > There is no expectation that you use more words than necessary in a document.

Nor did I say that there is one. What I am saying is use of slides puts a harder requirement on the author to do that well. :-)

> I don’t know what the supporting evidence is.

I am not providing evidence in support that slides are better than documents. I am only providing counter-arguments to the reasoning you present. Your own arguments are not only non-evidential but also often oversimplified, incomplete or wrong.

> At Amazon, you would get dinged and the reader would question why you’re using complex sentence structure - is it because you’re compensating for not having done enough research?

> I would probably ask you bluntly, “how much of this context is actually relevant?”

Part document-complexity feedback accepted. :-)

However, I am claiming that the complexity of arguments here is inherent complexity, not incidental complexity. If you get deep into the arguments I have made to understand them, you may see how.

Alternatively, please explicitly point out which arguments of mine you find wrong or irrelevant. I wrote the arguments only because I did find jumping-to-conclusions in yours, so I am trying to bring the true ones to light. :-)

> And passive voice is actively discouraged.

So is that why you chose to make the above sentence passive? :-)

It is a myth that passive voice is bad. There are genuine cases where passive voice fits better. Steven Pinker has written about the same [1, 2]. (Note: This isn't an 'appeals to authority' bias like someone once claimed when I said the same thing. I support the arguments made by Pinker.)

> > If we do not conflate various above points, we'll find that it's not about document vs. slides. The real problem are 'A' above (bad guidance on how to make/present slides) and 'C(b)' above (cited variability in the audience).

> Why such a lengthy write up if this is the summary of your argument? And “lengthy” is an understatement. There’s so much dense information here that you, the author, are not able to refer back to your own writing without having to simplify it down to an abbreviation! This is criminal, my friend.

To reduce the density of my writeup, I'll need to increase the length of it which you've also complained about. So the only way to address it is to eliminate irrelevant arguments. I am claiming from my side that they are all relevant to counter the hidden and false assumptions and reasoning I see in your statements like "Now not every problem requires a document. But many problems are intrinsically hard, and they absolutely do."). Problems being intrinsically hard does not directly mandate a document over slides.

Please point out which arguments I have made are irrelevant, and I'll review. :-)

> Now The reader has to go back and put all this complexity in context, creating a tree of all this information and each node in their head. > which merely ended up being tangential?

Yes, agreed that here is very often a tree in arguments (more generally a DAG or unrestricted graph too) and there's one in mine. :-) I am claiming that in this case this could only be helped by writing a longer text as I disagree with the statement that my arguments are tangential.

> And your fundamental argument is a begging the question fallacy. The take away from your post is that slides are as effective or perhaps more so than a document, but you provided nothing to actually back up THAT statement. Your presenting what you are arguing for as being the truth in the first place.

I disagree. This is not "begging the question fallacy". I am not backing my statement with arguments but rather pointing out the nuances which you are not seeing, which is thereby leading you to misunderstanding or oversimplifications in your arguments.

> Overall, this was more work to read than it ought to be.

Deep dive is also one of the leadership principles at Amazon. :-)

---

[1] https://www.theatlantic.com/magazine/archive/2014/11/passive...

[2] https://bobbypowers.net/steven-pinker-writing-tips/

> I am however saying that the true reasons when and why it works better are misunderstood. There is no irony here.

You provided a deeply dense document arguing in favor of slides. You're now stating it was more about "oversimplifications" in my post – and honestly, that's not my take away from your document.

You did write in favor of slides and communicated they're as, or even more effective of a medium, than written documents. And the document that you provided did not provide evidence or substantial points to back that claim. The document you did provide has unnecessary context and excessive, distracting sentence structure. The same argument you made could be provided in 1/4th of the text.

Doc writing is a "tool". If you're not able to use it effectively, it won't be any more helpful than slides or no written material at all. It just becomes a distraction. To restate my point, you offered a document with a different point of view, but the quality of your document, and your statements on expectations of a document (e.g. expectations of using more words) only prove that your definition of a document and its expectations are widely different than Amazons. They're not apples to apples.

>There are flaws and oversimplifications in your previous arguments that I am pointing out.

>Problems being intrinsically hard does not mandate requiring of a document vs. slides. The reasoning in the middle is important to cover, which is what I am trying to do.

You are "trying to do" but you didn't, nor did you outline what those flaws or oversimplifications are. The only reasoning provided was that slides have worked as well or even better for you (anecdotal evidence).

What I'm saying is that the necessary information – the amount of information that you must provide for the reader to truly grasp the issue and your thinking around it in 45-60 minutes – cannot be captured in a PowerPoint deck. And nor does the slide deck provide sections like appendices with varying levels of details. And finally, it doesn't facilitate readers leaving comments and questions directly inline.

And no matter how you try to twist the slide medium into being more like a document by forcing an appendices section or recording notes manually – it doesn't replace the document writing process.

As the author writes a document, they will get stumped on certain topics or struggle to find words to articulate a problem succinctly. This exercise helps the author discover gaps in their thinking and know immediately what areas still need to be disambiguated.

>Deep dive is also one of the leadership principles at Amazon. :-)

This comment comes off as trolling, but I'll give the benefit of the doubt and assume it was meant in good faith.

To force your PowerPoint audience or document reader to actively "work hard" to understand YOU is not an example of having them dive deep. If anything, it comes off as being lazy – you the author didn't care to clean up your document so the reader can focus on the problem itself. Instead, they have to focus on the puzzle you've concocted. If I have to "dive deep" just to understand your ideas, then you haven't adequately prepared your ideas. The mere act of being able to follow your idea shouldn't require a deep dive. Once I read your document and form my questions, the deep dive comes in the discussion when the reader wants to dive deeper into specific parts of your thesis.

>Your own arguments are not only non-evidential but also often oversimplified, incomplete or wrong.

I'm sure my arguments come off as being "anecdotal". And that's fine. No disagreement there.

I think we can end the discussion here –

This is in no way a debate. Amazon has the secret weapon, and I'm literally giving you the blueprints. You can choose to use it or not use it.

Amazon, an almost $2 trillion company operating across retail sales and logistics, cloud services, entertainment, streaming, consumer electronics, and myriad other industries, has decided that 1 pager and 5 pager documents are critical to its success. And so much so that slide decks are banned for any substantial discussion. Slide decks are only acceptable at "presentations", and "presentations" =/= business or tech reviews.

What more evidence would you like? (Yes, this is a rhetorical question).

I presented my understanding in a simple to understand way here: https://news.ycombinator.com/item?id=27551350

The response from you on that comment is not sounding right to me, and so I present counter-arguments.

>> For the kinds of problems that require document writing at Amazon, this statement simply just isn’t true.

This needs details. I can take that what you wrote after the above are those details. :-)

>> Presentations are about the presenter, often presenting as if they are the authority figure on a topic.

Not necessarily true, as I stated in my response comment.

And you haven't yet refuted my that comment. :-)

>> As a matter of fact, they share documents to get feedback and find gaps in their thinking, or seek feedback on how they evaluated alternatives, and so on.

This can apply equally well to slides as well, as I stated before. Hence it is not helping the argument you are making.

>> The document should focus on the immediate topic, trade offs, solutions while supporting evidence or technical details, design artifacts, and FAQs etc are provided in appendices. This manner of information sharing is simply not possible in any PowerPoint or presentation slide format.

Above too is a statement you've made without giving reasoning and which you repeated in the above comment too. Can you please explicitly say why "This manner of information sharing is simply not possible in any PowerPoint or presentation slide format." and why "the necessary information ... cannot be captured in a PowerPoint deck ..."? Why cannot sections like appendices be there in slides (assuming the information has been made short and crisp to fit in a slide or a few)?

>> And the simple proof to back my statements — Amazon and everything it has accomplished at what people now call “Amazon scale”. This is literally the secret sauce.

>> Amazon, an almost $2 trillion company ..., has decided that 1 pager and 5 pager documents are critical to its success. >> What more evidence would you like? (Yes, this is a rhetorical question).

There are many aspects involved contributing to Amazon's success. Well-executed meetings using document-reviews would be one of them, however, that does not counters the points I made in my original comment here: https://news.ycombinator.com/item?id=27551350

I am sure that you do not consider Amazon being successful itself as a proof that document-review is better than slides (that may involve fallacies like hasty generalization, post hoc fallacy, survivor bias, and even appeals to authority).

>> for the kinds of problems we solve. Now not every problem requires a document. But many problems are intrinsically hard, and they absolutely do.

As you are the one who made this statement, the onus is on you to supply the reasoning why intrinsically hard problems requires documents over slides. I am just questioning your statement. :-) And that's where I have said that the reasoning in the middle is important (for you) to cover. :-)

>> You are "trying to do" but you didn't, nor did you outline what those flaws or oversimplifications are.

>> The only reasoning provided was that slides have worked as well or even better for you (anecdotal evidence).

I did lot more than that, did I not? :-) I have given many arguments, which you are finding irrelevant, but I am claiming to be relevant. :-) Only if you supply the reasoning behind your own arguments would you see the relevance of what I am saying. :-)

>> And finally, it doesn't facilitate readers leaving comments and questions directly inline.

PowerPoint has commenting feature too. :-)

It does not have "Track Changes" feature. I would agree if you bring that as an argument for document vs. slides. :-)

>> And no matter how you try to twist the slide medium into being more like a document by forcing an appendices section or recording notes manually – it doesn't replace the document writing process. As the author writes a document, they will get stumped on certain topics or struggle to find words to articulate a problem succinctly. This exercise helps the author discover gaps in their thinking and know immediately what areas still need to be disambiguated.

Can you pls. provide the reasoning as to why the same does not apply when an author creates slides? Whether I create a document, slides, this happens. :-)

>> I think we can end the discussion here

As you wish. :-)

>the onus is on you to supply the reasoning why intrinsically hard problems requires documents over slides.

I think I've provided sufficient examples on why this is the case, and I have almost a $2 trillion dollar company that agrees with me and has made this our policy. You can try to pick whatever logical fallacy, but the actual company and its leadership believes the document culture gives us a strong competitive advantage over PowerPoint or slide deck driven organizations. You're more than welcome to compete us and try to beat us.

>the onus is on you

I honestly have nothing to prove to you. This is turning more into your ego and your refusal to consider that others may be working on problems that require document writing whereas maybe the complexity of your work requires a few bullet points. Not to disparage any of your work, but it's narrow thinking at best.

Furthermore, you're repeating your previous posts, and each of your comments now all ending with a ":-)" is deliberate trolling. It's clear you're posting here in bad faith.

Feel free to respond again, but I won't engage with you any further.

If you want to troll or flash ego, you certainly can. But your personal information and even a profile URL are attached or linked from your HN profile. Maybe that's intentional and the shtick of "I'm right, and I'll condescend with smiley faces to show I'm superior" – that's how you try to sell yourself?

I hope it works out for you. Good luck!

Wonderful that Amazon has a great culture around documentation, got to keep those documents happy. Now they just need to find a way to improve the culture for their employees. Obviously they are a much less important resource than documents but still they should probably give it a go.

This seems to be an indication of a very highly formal culture. All the benefits I’ve seen described sound to me like solving a problem that should not exist in the first place. If we all spend half an hour of reading the doc then, by definition, we all had that half hour for reading in the first place. We just decided not to take the time or were not permitted to do so by a meeting scheduled for an hour. Instead of disadvataging people who can’t publicly speak, the system disadvantages people who can’t write. It wastes time of the writer (who apparently needs special training) and the time of those who can read faster. Why have so many meetings anyway? The format does not seem to work for creative discussions etc., why is there so much collective decisionmaking? But I’m not an Amazon employee. Not trying to diss the idea, just reflecting on how deeply such routines are linked with the organizational culture and would utterly fail in a, say, result-oriented culture.

Everyone should be able to write. If they can’t they should practice. Pretty much everyone needs to write articulate emails but not publicly speak, it seems.

I invite you to open your mind about this practice. I strongly agree with this approach, though admittedly I have not practiced it, because my company is only one employee. There is tons of background about it in a book called Working Backwards written by two longtime Amazon execs that explain further why they use it. If I ever have a larger company I will likely use this approach.

This is explained in the post. The reading time is scheduled for everyone as part of the meeting time; therefore everyone is guaranteed to have time reserved to do the reading. If you only do the document, or only schedule the discussion time and not the reading time, some people will not read the document. I can certainly confirm that from 30 years of experience in companies large and small.

I’ve never worked at Amazon, but it sounds a bit off to imply it isn’t a results-oriented culture.

This is an interesting thing to try and learn from. It is an abusive thing to enforce on everyone all the fucking time.

A meeting is a social event. Silent reading is not.

Why does every young clever person think that his preferred method is the only thing that makes sense? Oh I know. Because young clever people have not had time to live, grow, and appreciate the full spectrum of human productivity.

My meetings are for talking. Come prepared.

Also, documents for everything? Great way to slow everything down and discourage certain people from making suggestions at all.

Interesting that you baselessly accuse the author of saying that his preferred way is the only thing that makes sense, followed immediately by "My meetings are for talking. Come prepared." Your attitude seems to be just as rigid as you imagine the author's to be. And I definitely wouldn't want to encounter that gratuitously sarcastic attitude of yours in a meeting or anywhere else, it'd definitely strike me as abusive.

Okay, so, I figure a post that goes "those darn kids in amazon senior leadership!" is probably not made entirely sincerely

> Also, documents for everything?

I worked for a smaller company with this extremist philosophy, to the point that they forbade voice or text chat outside of scheduled meetings; all discussion had to be written in public Teams threads. The CEO also had a habit of dropping into random threads and micromanaging. I think it was bad for everyone, but for me it was completely paralyzing.

Chat apps are not documentation. What you are describing is just a moronic way of doing things and absolutely not documents for everything.

How many "come prepared" meetings have you had where everyone in attendance had prepared? This format gives the space to read and discuss. Everyone has the same opportunity (often, the people with the least time to prepare in advance would be the people you most want feedback from).

The other interesting dynamic is that in many cases the eventual audience for the doc under review is an executive, and the discussion has the goal of refining it for that audience.

> My meetings are for talking. Come prepared.

That is what they do. They just happen to do the preparation together at the same time right before the meeting, instead of asking people read the documents on their own time. This way a meeting is self-contained.

Over a lengthy career I've discovered that rule number 1 in the engineering world is "Nobody ever reads anything." This holds true even if they were supposed to beforehand and swore on a stack of bibles that they would.

Reply on news.ycombinator.com