Jeff Bezos banned PowerPoint presentations at Amazon in the early 2000s. In their place, he required six-page narrative memos read silently at the beginning of every meeting. The reasoning was not sentimental — Bezos is not known for anti-technology sentiment. His reasoning was structural: "PowerPoint-style presentations somehow give permission to gloss over ideas, or go on to the next bullet point when transitions should be questioned, when logic should be examined." The memo format forced the author to think in complete sentences, to construct arguments, and to make logical transitions visible. It forced the reader to engage with the full argument rather than with fragments.

The practice spread throughout Amazon's culture and became a model cited by executives at other companies. Ian McAllister, a former Amazon executive, described the memo culture as central to Amazon's decision-making quality: it raised the information content of every meeting because the audience arrived having read and thought about a structured argument, not having watched someone read bullet points off a screen.

The insight underlying the practice applies beyond Amazon: decision makers — executives, board members, investors, senior leaders of any kind — are perpetually time-constrained and information-saturated. They read dozens of documents every week. They sit in multiple meetings every day. Writing that competes for their attention and judgment must earn its place immediately, or it will not be read at the depth required to influence a decision.

Writing for decision makers is not a dumbed-down version of professional writing. It is a stripped-down version: ruthlessly prioritized, structured around the decision rather than the analysis, and calibrated to the reader's actual time and attention availability.

"The memo format forced the author to think in complete sentences, to construct arguments, and to make logical transitions visible. It forced the reader to engage with the full argument." — Ian McAllister, former Amazon executive, on Amazon's six-page memo culture

Understanding the Decision Maker as Reader

Decision Maker Reading Pattern Implication for Your Writing
Reads in 5-15 minute windows, not sustained sessions Front-load the most important information
Reads with a specific question in mind State the answer to their likely question in paragraph one
Reads for the recommendation, not the analysis Put the recommendation first, evidence second
Has extensive existing context and intuitions Engage with what they already know; do not over-explain basics
Will not search for buried information Every key claim must be visible, not implied

The starting point is an accurate model of how senior decision makers actually read. Understanding their reading behavior allows writing to be designed around it rather than against it.

Decision makers read on context switches. They shift from a call to a document to a meeting to a document. Reading happens in windows of 5-15 minutes, not in sustained 45-minute sessions. Writing that requires sustained context to understand — that builds toward a point over multiple pages — is disadvantaged by this reading pattern.

Decision makers read with a specific question. The question varies: "Should I approve this?" "Is this a risk I need to address?" "Do I need to respond to this?" They are reading to answer their question, not to receive a comprehensive briefing on the topic. Writing that answers the decision maker's question in the first paragraph will be read more carefully than writing that makes the reader search for the relevant information.

Decision makers use documents as decision support, not as the primary source of information. They have context, intuitions, relationships, and prior experience that shapes how they read a document. A well-written document engages with their existing knowledge rather than treating them as blank slates.

Decision makers read for the recommendation, not the analysis. Analysis is evidence. The recommendation is the point. Writing that buries the recommendation inside the analysis forces the reader to extract it — which many will not do, defaulting instead to asking questions that the document already answers if they would read it completely.

The Architecture of a Decision Document

Effective decision documents share a structural pattern regardless of their topic: they state what they are asking, why it matters, what the evidence shows, and what the writer recommends, in that order.

Element 1: The Decision Question

Every decision document should be anchored to a specific decision. "Should we expand into the German market?" "Should we approve the Q2 budget as proposed?" "Should we migrate to the new authentication provider by September?" The decision question frames everything that follows and tells the reader what the document is for.

Documents without a specific decision question are briefings, not decision documents. Briefings are appropriate for building shared context; decision documents are appropriate when a decision must be made. Conflating them produces documents that provide context without enabling action.

Element 2: The Recommendation

The recommendation should appear in the first paragraph. Not at the end of the analysis. Not buried in a section titled "Conclusions." In the first paragraph, clearly stated, with the primary rationale.

"We recommend approving the German market entry in Q1 2025, beginning with Munich and Berlin. This recommendation is based on three factors: favorable competitive positioning, demonstrated customer demand from existing exports, and a partnership opportunity with Krone GmbH that reduces market entry cost by 40%."

A decision maker who reads only this paragraph has the essential information. One who has ten minutes reads the supporting analysis. One who has thirty minutes reads the full document. Each reading depth produces a coherent understanding.

Element 3: The Evidence Summary

After the recommendation, provide the evidence in order of importance. Not in order of the analysis process. Not chronologically. In order of how much each piece of evidence supports the recommendation.

The typical hierarchy:

  • Most important factor first, with specific quantitative support
  • Second most important factor, with specific support
  • Third factor, with support
  • Acknowledgment of significant counterarguments and why they do not override the recommendation

Evidence summaries in decision documents should not be comprehensive — they should be sufficient. Including every piece of evidence that touched the analysis creates a reading burden that obscures the most important findings. The editor's question: if I removed this piece of evidence, would the recommendation be less clear or less credible? If no, remove it.

Example: McKinsey's client presentations — which represent some of the most refined decision-support writing produced anywhere — consistently apply the hierarchy of evidence principle. A McKinsey presentation on a market entry decision will open with the recommendation and the three key supporting points. The supporting points will be quantified specifically. The counterarguments will be explicitly addressed. The appendix will contain the full analysis for readers who want the depth. The main deck contains only what is required for the decision.

Element 4: The Request

The decision document should end with an explicit request: what are you asking the decision maker to do?

"We are requesting approval to proceed with Phase 1 of the German market entry plan. If approved, we will execute the partnership agreement with Krone GmbH and begin hiring a country manager by January 15."

A document that makes an argument without a specific ask forces the reader to infer what response is expected. Some will infer correctly. Many will not. The explicit request eliminates this ambiguity and creates a clear path to action.

Writing Formats for Different Decision Types

Different decisions require different document formats, and calibrating format to decision type is part of writing for decision makers.

The One-Pager

For decisions with limited complexity and a clear recommendation, a one-page document is not a sign of shallow analysis — it is a sign of disciplined prioritization. If the recommendation can be clearly stated and supported in one page, adding pages adds reading burden without adding value.

One-pager structure:

  • Decision question (one sentence)
  • Recommendation (one to two sentences with primary rationale)
  • Three to five key supporting points (two to three sentences each)
  • Risks or counterarguments and responses (one to two sentences each)
  • Explicit request (one to two sentences)

A well-executed one-pager is harder to write than a ten-pager because it requires selecting what matters most and excluding everything else.

The Six-Page Memo

For complex decisions with multiple dimensions, significant uncertainty, or major organizational implications, the six-page narrative memo format (associated with Amazon but used more widely) allows fuller development of the argument without the slide-deck fragmentation.

The six-page memo is structured as prose, not bullet points. It reads as an argument, not a presentation outline. The discipline of prose construction — complete sentences, logical transitions, explicit connections between ideas — produces tighter reasoning than bullet points, which allow gaps in logic to pass unnoticed.

Structure for a six-page memo:

  • Executive summary (one page): the full recommendation and key supporting points
  • Context (one page): what makes this decision necessary now
  • Analysis (two to three pages): the evidence, the alternatives considered, the key uncertainties
  • Recommendation and implementation (one page): the specific request and proposed next steps

The Board Paper

Board-level documents have specific conventions shaped by governance requirements: they must be comprehensive enough to demonstrate that the board has fulfilled its oversight responsibilities, specific enough to enable informed decision-making, and organized to serve board members who may be reviewing ten or more papers in a single session.

Board paper structure typically includes:

  • Purpose statement
  • Recommendation with specific approval requested
  • Background and strategic context
  • Analysis and key considerations
  • Risks and mitigations
  • Financial implications
  • Implementation timeline
  • Appendices with supporting detail

The executive summary of a board paper must stand alone — many board members will read the executive summary and appendices and skip the body, which is the standard board-level reading pattern.

The Language of Decision Support

The language of decision documents differs from general professional prose in specific ways.

Quantify everything possible. "The cost reduction is significant" is a judgment. "The cost reduction is 34%, reducing the project's payback period from thirty to twenty months" is evidence. Decision makers cannot evaluate the significance of unquantified claims; they can evaluate quantified ones. Every claim of magnitude — important, large, small, significant, minor, fast, slow — should be replaced with a specific number where the data supports it.

Use active voice with specific actors. "The analysis shows that the partnership reduces entry cost" is less powerful than "Our analysis of three alternative entry strategies shows that the Krone partnership reduces entry cost by 40% compared to direct market entry." The specific version cannot be dismissed as vague or unsupported.

Address the counterargument before it is raised. Decision makers with experience in an area will have objections — concerns they know from prior experience are often overlooked. Writing that anticipates and addresses these objections before the reader raises them demonstrates analytical thoroughness. Writing that is silent on predictable objections creates the impression of selective analysis.

Example: In Amazon's memo culture, experienced reviewers test memos by generating the three or four most obvious objections to the recommendation and checking whether the memo addresses them. If it does not, the memo goes back for revision — because the meeting conversation will focus on those objections rather than on the recommendation, and the meeting time is wasted.

Express uncertainty honestly. Decision makers who approve recommendations based on overstated confidence are setting themselves up for bad outcomes when the uncertainty materializes. Writing that accurately represents confidence levels — "the market size estimate has a wide range of $400-800M due to limited data on the target segment" — is more credible and more useful than writing that projects false precision.

For related frameworks on writing clearly for any audience, see writing for clarity. For how to structure longer arguments, see structure in writing explained.

What Research Shows About How Decision Makers Read

The empirical study of how senior executives process written information has produced findings that contradict several assumptions embedded in standard document design practice. Michael Porter and Nitin Nohria published a landmark time-use study in the Harvard Business Review in 2018, tracking how 27 CEOs of major companies actually spent their time over three months. CEOs devoted 24% of their time to email and other written communication -- but they read in windows averaging 8 minutes, and they returned to documents they had started reading only 18% of the time. The implication for document design is direct: a document that does not deliver its essential content within the first page will not deliver that content at all for a majority of senior readers.

Barbara Minto built the empirical foundation for decision-document structure through her work at McKinsey beginning in the late 1960s. She observed that partners reviewing associate work consistently stopped reading at the first sign of unfounded reasoning -- a conclusion without visible support, or a claim that seemed to contradict their prior knowledge. By restructuring documents to place conclusions at the top, supported by three to five specific arguments, each with explicit evidence, Minto found that partners read further and reported higher confidence in the analysis. The pyramid structure is not primarily a clarity device; it is a credibility device for skeptical readers who are trying to decide, as early as possible, whether the document is worth reading.

Russell Ackoff, the organizational theorist at the Wharton School, articulated the distinction between data, information, knowledge, and wisdom in a 1989 paper in the Journal of Applied Systems Analysis. His hierarchy is directly applicable to decision-document design: decision makers do not need data or information -- they have more of both than they can use. They need knowledge structured as judgment: what does this data mean for this decision, and what should we do? Documents that provide data without judgment, or analysis without recommendation, fail to deliver what decision makers actually need. Ackoff's framework implies that the recommendation is not the conclusion of a decision document -- it is the purpose.

Herbert Simon, Nobel laureate in economics and pioneer of decision theory at Carnegie Mellon, introduced the concept of "bounded rationality" in 1955 to describe how decision makers actually decide under real-world constraints of limited time, limited information, and limited cognitive capacity. Simon's research demonstrated that decision makers do not optimize -- they satisfice, choosing the first option that meets a minimum acceptable threshold rather than exhaustively evaluating all options. The writing implication: decision documents should make the recommended option's case immediately and clearly, because bounded rationality means that a decision maker who finds the first presented option adequate will not read on to evaluate alternatives unless the first option is clearly inadequate.

Case Studies: What Happened When Organizations Transformed Decision Communication

Amazon's Memo Culture: Documented Effects

The transition from PowerPoint to six-page narrative memos at Amazon in the early 2000s has been described in detail by multiple former executives. Colin Bryar and Bill Carr, in Working Backwards (2021), document specific mechanisms by which the change affected decision quality.

The most significant effect was on pre-meeting preparation. When executives received a PowerPoint deck before a meeting, they typically browsed it and arrived with impressions rather than understanding. When they received a six-page narrative memo, they arrived having read a complete argument and having formed substantive questions. The quality of objections raised in meetings -- their specificity, their logical relationship to the argument, their relevance to the actual decision -- improved noticeably after the transition, because objections based on complete understanding differ in quality from objections based on slide-deck impressions.

A secondary effect was on the writing process itself. Executives who had to construct complete prose arguments before their proposals were considered discovered earlier whether their reasoning was sound. The memo-writing process surfaced logical gaps that the presentation-building process had concealed. Amazon executives report that proposals that could not be written clearly at the six-page level typically could not be executed clearly at the organizational level -- the writing discipline served as a pre-commitment filter for ideas that sounded better than they were.

McKinsey Structured Decision Documents in Client Engagements

McKinsey's client-facing work provides extensive evidence of how structured decision documents affect client decision-making. The firm's standard approach to client deliverables -- pyramid structure, recommendation first, evidence organized by strength, explicit acknowledgment of counterarguments -- has been studied by researchers examining consulting industry practices.

A study by Matthias Kipping and Lars Engwall published in Management Consulting: Emergence and Dynamics of a Knowledge Industry (2002) examined how consulting recommendations were received by client organizations. A consistent finding across consulting firms: recommendations delivered in structured documents with explicit recommendations and quantified supporting evidence were accepted at significantly higher rates than recommendations delivered through presentations or unstructured reports, even when the underlying analysis was equivalent. The document structure affected not only comprehension but persuasion -- a reminder that decision documents serve rhetorical as well as informational purposes.

The U.S. National Security Council Principals Committee Process

The National Security Council's formal process for preparing decision documents for senior U.S. government officials represents one of the most codified decision-communication systems in existence. NSC "options papers" follow a fixed structure: situation summary, statement of U.S. interests at stake, policy options (typically three), analysis of each option, and a recommendation from the drafting department.

Former National Security Advisor Zbigniew Brzezinski described the structure's effect in his memoir Power and Principle (1983): the fixed format prevented the common failure mode of advocacy documents that presented only one option in a favorable light while omitting alternatives. The requirement to present genuine alternatives -- with honest analysis of each -- forced drafters to reckon with the weaknesses of their preferred option, producing recommendations that were more robust because they had survived comparison. The NSC process illustrates a structural insight applicable to corporate decision documents: requiring writers to honestly analyze alternatives before stating a recommendation improves the quality of the recommendation itself.

References

Tags

writing executive-communication decision-making professional-writing work-skills

Frequently Asked Questions

What do decision makers need from written communication?

Decision makers need clarity on what decision you're asking them to make, what you recommend, why it matters, and what happens if they do nothing—all delivered concisely because their time is constrained. They're not interested in the journey of how you arrived at your recommendation or comprehensive background; they want the conclusion first, then supporting rationale they can drill into if needed. Effective communication for decision makers starts with an executive summary or BLUF (Bottom Line Up Front) that states the recommendation and key reasoning in 2-3 sentences. It provides specific options with clear tradeoffs rather than open-ended exploration—'We should choose Option B, which costs 20% more but delivers 6 months faster, or Option A if budget is the primary constraint.' It quantifies impact whenever possible: not 'significant improvement' but 'reduce processing time from 2 hours to 15 minutes, saving \(200K annually.' It addresses risks and implementation requirements directly rather than burying them: 'This requires 3 engineering months and temporary performance degradation during migration.' Decision makers also need confidence that you've considered alternatives and thought through implications—showing your work without drowning them in it. They appreciate knowing what you need from them: 'Please approve the \)50K budget so we can start in Q2' versus leaving next steps ambiguous. The goal is enabling fast, confident decisions by providing exactly the information needed and nothing more.

How do you structure executive summaries that actually get read?

Executive summaries that get read follow a strict structure: recommendation first, key reasoning second, critical details third. Start with one sentence stating what you recommend or what decision is needed: 'I recommend migrating to the new platform by Q3.' Follow with 2-3 sentences explaining the primary reasons: 'This will reduce hosting costs by 30% ($150K annually), improve page load times by 40%, and enable features our largest customers are requesting. The migration requires 8 weeks of development time and a temporary feature freeze in July.' Then provide essential context in bullet points: what options were considered, what the impact is if no action is taken, what resources are required, what the timeline is. Keep the entire executive summary under one page—ideally half a page. Use concrete numbers, specific dates, and named tradeoffs rather than vague language. Avoid background or methodology unless it's essential for credibility ('Based on analysis of 12 months of performance data...'). Structure sentences for scanning: front-load key information, use parallel construction, avoid subordinate clauses. Bold or highlight the recommendation itself so it's impossible to miss. Include a one-line action item: 'Please approve by March 15 for Q2 delivery.' The full document can contain supporting analysis, but the executive summary must stand alone as a complete, actionable communication. Test by asking: can someone read only this summary and make an informed decision? If they need to read further to understand the basics, the summary has failed.

What is the difference between writing for executives versus writing for technical teams?

Writing for executives versus technical teams requires fundamentally different approaches to content, structure, and detail level. Executives need to understand business impact, risk, and required decisions—they want to know why something matters to organizational goals, what it costs in money and time, and what alternatives exist. Technical teams need to understand implementation details, technical rationale, and how components interact—they want to know how something works, what edge cases exist, and what technical tradeoffs were made. For executives, organize by business outcomes and strategic implications, front-load recommendations, quantify everything possible ('$200K annual savings' not 'significant cost reduction'), and minimize jargon or translate it ('API rate limits—the maximum number of requests we can handle per second'). For technical teams, organize by architectural components or implementation sequence, provide comprehensive technical details, use precise technical terminology without apology, and include code examples, architecture diagrams, and edge cases. Executives want the 'so what'—why this matters and what to do about it. Technical teams want the 'how'—mechanisms, interactions, and implementation specifics. Executive communication should be skimmable with clear hierarchy and executive summaries; technical communication can be dense and sequential because readers need comprehensive detail. Executives make decisions about whether and when; technical teams need information to implement how. The same information often needs to be written twice—once as a business case for executives, once as a technical specification for implementers—because these audiences have completely different needs and contexts.

How do you write recommendations that build confidence and drive action?

Writing recommendations that drive action requires demonstrating that you've thought through the problem thoroughly, making your preference clear, and showing you understand the risks. Start by explicitly stating what you recommend—don't bury it or hedge it so heavily that readers aren't sure what you actually think. Confidence comes from showing your reasoning: explain the criteria you used to evaluate options (cost, time, risk, strategic alignment), show that you considered alternatives, and address obvious objections preemptively. Quantify the impact whenever possible: 'This will increase conversion by 15-20% based on A/B test results' is more convincing than 'This will improve user experience significantly.' Be honest about uncertainties and risks rather than pretending everything is certain—'The main risk is that adoption may be slower than projected if users resist the workflow change; we can mitigate this through training and a gradual rollout.' Acknowledge tradeoffs explicitly: 'We're choosing speed over cost here because the competitive window closes in Q3.' Provide clear next steps and timeline: 'If approved by March 1, we can complete this by May 15.' Specify what you need from the decision maker: budget approval, headcount, stakeholder alignment, or simply a green light. Back your recommendation with credible evidence: data, expert opinions, proof of concepts, case studies, or pilot results. The goal is making the reader think 'This person has done their homework, understands the risks, and has a clear point of view'—that confidence enables decision makers to act quickly.

What are common mistakes when writing for busy executives?

The most common mistakes when writing for executives are burying the recommendation, providing too much detail too early, using vague language, and failing to clearly articulate what decision is needed. Burying the recommendation means starting with background, methodology, or analysis before stating what you actually think should happen—executives lose patience or miss the point entirely. Always lead with your conclusion. Providing too much detail too early overwhelms readers who need the high-level picture first—save detailed analysis for appendices or later sections that executives can read if they want more depth. Using vague language ('significant improvement,' 'substantial savings,' 'better performance') forces executives to guess at real impact when they need concrete numbers to make decisions. Failing to articulate the decision means writing something that could be informational or could be seeking approval, leaving executives uncertain whether action is required. Other major mistakes include writing chronologically through your analysis process rather than organizing for the reader's decision-making needs, including tangential information that dilutes focus from the core message, using passive voice that obscures who's responsible for what, assuming executives have context they don't have (explaining acronyms and background), and failing to address obvious concerns (if cost is clearly an issue, acknowledge it and explain why the investment is worth it). Poor formatting that creates walls of text without visual hierarchy makes scanning impossible. Missing a clear timeline or next steps leaves executives uncertain about urgency and implementation. The underlying issue is usually writing to demonstrate your work rather than to enable their decision—executives don't need to see your entire thinking process; they need the insights and recommendations that emerge from it.

Share this article