When Jeff Bezos banned PowerPoint in 2004, he wasn’t just changing meeting formats at Amazon. He was changing how technical decisions get made, how systems get designed, and how engineering organisations work at scale.
Here’s the problem: most technical decisions happen in meetings packed with PowerPoint slides and verbal discussions. The result? Poorly documented choices. Misaligned systems. Nobody really knows why things were built the way they were.
Amazon’s six-page memo culture and silent start meetings create something different—a forcing function for rigorous thinking about system design. By requiring complete written narratives before any technical decisions, you prevent over-engineering, surface logical gaps earlier, and build more maintainable systems.
In this article we’re going to explain what Amazon’s memo culture is, how it influences system architecture, and give you practical guidance if you’re thinking about trying it yourself.
What are six-page memos and why does Amazon use them?
Six-page memos are structured narrative documents written in full prose. Amazon employees create them to propose ideas, document system designs, or communicate strategies.
Jeff Bezos instituted them after banning PowerPoint in 2004 because narrative writing forces deeper thinking than slide presentations. The six-page limit creates discipline. Long enough to be comprehensive, short enough to demand clarity.
They’re read silently at the start of meetings for 15-30 minutes before anyone says a word.
What makes six-pagers different is complete sentences with logical flow. No bullet-point shortcuts. You can’t hide behind vague points or hand-wave complexity when you’re writing in full prose.
Writing rules are strict: use less than 30 words per sentence, replace adjectives with data, and avoid jargon.
Before meetings, employees read memos together in silence. Bezos explained he didn’t ask people to read in advance because “The problem is people don’t have time to do that, and they end up coming to the meeting having only skimmed the memo, or maybe not read it at all.”
A great memo takes a week or more. Andy Jassy wrote 30 drafts when pitching what would become AWS. That’s not a typo. Thirty drafts.
How do written narratives force architectural clarity?
Writing complete sentences about a system design forces engineers to articulate relationships, dependencies, and trade-offs that stay hidden in diagrams or bullet points.
When you must explain “Service A calls Service B which queries Database C,” you immediately confront questions about failure modes, latency impacts, and data consistency. If you can’t write a coherent explanation of how components interact, your architecture isn’t coherent either.
Here’s an example. A slide deck about microservices migration might show “Phase 1: Extract User Service” with a neat diagram. Done, right? Not even close.
A narrative memo forces you to explain why you’re starting with the user service, what dependencies you’ll need to mock, how you’ll handle the transitional state where data lives in two places, and what success criteria will tell you it’s safe to proceed.
The cognitive load of writing complete sentences creates better system designs. You discover edge cases while explaining the happy path. You identify hidden dependencies while describing how components interact.
If you can’t explain it clearly, you don’t understand it well enough to build it.
Why does Amazon’s architecture reflect memo culture?
Amazon’s service-oriented architecture emerged alongside and was reinforced by memo culture. Both require clear interface definitions and explicit contracts.
The Working Backwards methodology prevents building systems that solve the wrong problems. You start with the customer outcome and work back to the technical implementation. Memo culture’s emphasis on documenting decisions created a forcing function for loosely coupled services.
Conway’s Law states that “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” Just as memos require explicit written communication, service-oriented architecture requires explicit API communication. They mirror each other.
In 2002, Jeff Bezos issued the “Bezos API Mandate” requiring all teams to expose their data and functionality through service interfaces. The mandate stated: “All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed.”
That’s pretty clear language. No room for interpretation.
The Working Backwards methodology takes this even further. Before writing code, teams write the press release, FAQ, and documentation. This inverts the typical design process—you start by defining what success looks like from the outside and work backward to the technical implementation.
This forces engineers to justify technical complexity based on actual value delivered. You can’t write “we’ll implement event sourcing” and leave it at that. You have to explain what customer problem this solves.
When you must justify technical complexity in writing, unnecessary complexity gets eliminated. It’s that simple.
When should your organisation adopt memo culture?
Adopt memo culture when you struggle with poorly documented technical decisions, frequent misalignments between teams, or systems built without clear purpose.
It’s most effective for teams of 20+ engineers where verbal communication breaks down and knowledge silos form. A strong indicator: you’re repeatedly rebuilding systems because nobody documented the original design assumptions.
Signal indicators you need it:
“Why did we build it this way?” questions have no documented answers. New engineers struggle to understand system design rationale. Technical debt from unconsidered alternatives piles up. Meetings produce more meetings instead of decisions.
When NOT to adopt: early-stage startups needing speed over rigour, teams already struggling with shipping velocity, or cultures that cannot support writing discipline.
Start with one meeting type, expand based on results. Cultural prerequisites include leadership commitment to reading documents and valuing written communication. If your leadership won’t read, don’t bother.
How do you implement written decision-making in your teams?
Start small with one meeting type like architecture reviews requiring a two-page narrative instead of slides.
Create templates: problem statement, context, proposed approach, alternatives considered, decision rationale, open questions. That’s your starting structure.
Train engineers in technical writing—most developers haven’t written narrative documents since university. This is a real skills gap and you need to address it.
Enforce the silent reading ritual: first 15 minutes of meetings are silent reading, no exceptions. Everyone reads together. This is non-negotiable.
Share drafts with 2-3 people for feedback before wider distribution. Send meeting invitations 3-7 days in advance. The review session includes 15-20 minute reading period followed by discussion.
Use collaborative document tools like Google Docs, Notion, or Confluence. Measure success with decision quality improvements and reduction in rework.
Start with a pilot. Choose one area—perhaps architecture reviews—and require written proposals with silent starts. Run this for three months. Lead by example. Write the first memo yourself. Celebrate when a memo catches a flaw before implementation.
Make it visible when the process works. When someone catches a major issue during the reading period, share that win with the team.
What are the limitations and when does memo culture not fit?
Memo culture adds upfront time investment that may not be justified for reversible, low-stakes decisions or rapid experimentation phases.
It requires writing skills many engineers lack—poor writers produce poor memos, defeating the clarity purpose. It can become bureaucratic if applied dogmatically. Not every decision needs six pages.
It doesn’t replace all communication. Whiteboard sessions, pair programming, and verbal brainstorming still have roles.
When speed trumps rigour: emergency responses, experimental prototypes, and throwaway code don’t need six-page memos. The writing skills bottleneck is real—the solution involves teaching writing skills, but this takes time.
Sometimes RFCs, ADRs, or lightweight design docs are more appropriate than full narratives. Don’t be dogmatic about it.
AI writing assistants change the economics of document creation. AI can help with memo writing mechanics, but can’t do the design thinking that narratives force.
When AI generates code quickly, the thinking work shifts even more to “what should we build and why?” This makes writing culture more important, not less.
FAQ
How long does it take to write a six-page memo?
Typical timeline is 4-8 hours for a thorough six-pager covering system design, with experienced writers faster than beginners.
Jeff Bezos believes “a great memo probably should take a week or more” and requires careful editing, sharing, and reflection. Andy Jassy wrote 30 drafts of his six-page vision doc when pitching AWS.
The time spent writing saves multiples in meeting time and prevents rework from misunderstood requirements. You pay upfront or you pay later. Upfront is cheaper.
Can junior engineers write effective technical narratives?
Yes, but with mentorship and feedback.
Junior engineers often produce better first drafts than seniors expect because they can’t rely on implicit knowledge. Narrative writing surfaces their knowledge gaps explicitly, creating teaching opportunities.
Reading enough six-page memos teaches people to express themselves in the same format. It’s a learned skill.
What’s the difference between Amazon’s six-pagers and Google’s design docs?
The key differences are in format (narrative prose vs mixed format), culture (mandatory reading vs optional advance reading), and purpose (decision-making vs documentation).
Both achieve similar goals of rigorous thinking, just different approaches. Amazon’s is more prescriptive, Google’s more flexible.
How do you handle technical diagrams in a narrative memo?
Diagrams complement but don’t replace narrative explanation.
Best practice: diagram shows structure, prose explains why that structure, how components interact, and what happens in failure cases.
If you can’t describe it in words, you don’t understand it clearly. The diagram is the illustration, not the explanation.
Does memo culture slow down development velocity?
Upfront time investment is offset by fewer misunderstandings, less rework, and faster decision-making during meetings.
Studies from Amazon show overall velocity increases because teams spend less time in back-and-forth alignment meetings.
It feels slower initially, but proves faster over months. You’re front-loading the thinking instead of distributing it across endless meetings.
How do I convince engineers who hate writing to adopt memo culture?
Frame it as preventing the meetings they hate even more.
Quality documentation reduces interruptions and “can you explain this system?” questions. Start with an opt-in pilot for one decision type, demonstrate value with concrete examples.
Address the skills gap with training and templates. Reading enough six-page memos teaches people to express themselves in the same format.
Show them the time saved. Make it concrete.
What happens if someone shows up to the silent reading without having written a good memo?
Silent reading in the meeting surfaces document quality immediately. Poor memos generate obvious questions during discussion phase.
A cultural norm develops that submitting poor memos wastes everyone’s time more than taking time to write well.
Social pressure is a powerful thing. Use it.
Can memo culture work for distributed/remote teams across time zones?
Actually easier than in-person in some ways—async written communication is already remote work best practice.
Silent reading can happen asynchronously, discussion can be threaded comments plus shorter sync meeting. Send meeting invitations 3-7 days in advance to allow asynchronous reading before sync discussion.
Remote work and memo culture are natural partners.
How does AI coding assistance impact the need for memo culture?
AI makes writing culture more important, not less.
When AI generates code quickly, the thinking work shifts even more to “what should we build and why?” AI can help with memo writing mechanics, but can’t do the design thinking that narratives force.
The faster you can generate code, the more important it becomes to think carefully about what code to generate.
Should we adopt Amazon’s Working Backwards method or just the memo format?
They’re most effective together but can be adopted independently.
Working Backwards (PR/FAQ) works best for new products with customer impact. Memo format works for any technical decision needing documentation.
Start with memo format for architecture reviews, add Working Backwards if product development is a pain point.
What’s the minimum viable version of memo culture for a 20-person startup?
Two-page narratives (not six) for architecture decisions and significant feature work only. Silent reading for architecture reviews but not every meeting. Template with clear sections.
Monthly review of whether it’s helping or creating bureaucracy. Focus on “can we explain this clearly in writing?” not page count compliance.
Don’t gold-plate it. Start simple, expand if it’s working.
How do memos relate to Architecture Decision Records (ADRs)?
ADRs are lightweight, structured, version-controlled decision documentation. Memos are more comprehensive narratives.
Many organisations use both: memo for initial design thinking and discussion, ADR as the formal record of the decision and rationale.
The combined use works well—use a memo for design thinking and discussion, then capture the decision in an ADR as the formal record. They complement each other nicely.
