Executive Summary

Inverted-pyramid writing for decision-makers - recommendation first, supporting analysis second, structured so that stopping after paragraph one still leaves the reader equipped to act.

Executive Summary

An executive summary is organized around a principle most professional writing violates: the conclusion comes first. Not after the setup, not after the analysis, not after demonstrating that the problem is real - first. The reader who opens an executive summary is a person with authority and limited time. They need to know what you are recommending and why before they decide whether the analysis that follows is worth their attention.

Every paragraph in an executive summary must earn its place by adding information not already present. A paragraph that restates the previous paragraph, provides additional color without changing the picture, or builds to a point rather than leading with it - that paragraph gets cut. The discipline is ruthless. Three minutes is the budget. Anything that cannot be read in three minutes is not an executive summary; it is a report with ambitions.

The inverted pyramid structure means the document degrades gracefully under time pressure. The reader who finishes paragraph one has the recommendation. The reader who finishes the first third has the recommendation and the key supporting rationale. The reader who reads everything has the full analytical picture. No reader is left without the minimum they need to act.

Structural conventions

• Recommendation or conclusion in the first paragraph, never deferred
• Each paragraph adds new information - no paragraph restates or echoes a previous one
• Short enough to read completely in three minutes (typically 250-500 words)
• Supporting analysis appears after the recommendation, ordered by importance not chronology
• Ends when the analysis is complete - no closing pleasantries or summaries of the summary

When to use

When presenting a recommendation to a senior audience with limited reading time. Use to brief a decision-maker who needs the conclusion before the supporting analysis, to preface a longer report so senior readers can route their attention, and in board or steering committee updates where the audience needs to act, not merely learn.

When not to use

When the reader needs to follow the analytical path before the conclusion will make sense. Avoid when the goal is narrative - telling a story rather than presenting a recommendation - or when political sensitivity requires earning the recommendation through the evidence rather than stating it first.

Pairs well with

executive, matter-of-fact, product-thinker, one-pager

Often confused with

decision-log: A decision-log records how a decision was reached - the options considered, the criteria, the reasoning. An executive summary presents a recommendation or conclusion with supporting evidence. The decision-log looks backward at a process; the executive summary looks forward at an action.

one-pager: A one-pager can take many forms - product pitch, project brief, overview. An executive summary is specifically inverted-pyramid: recommendation first, analysis after. A one-pager may build to its point; an executive summary never does.

Instruction

Write as an executive summary. The very first paragraph states the recommendation or conclusion
- do not build to it. Every paragraph after that must add new information; cut any paragraph
that restates or echoes what came before. Keep the total length readable in three minutes. Order
supporting analysis by importance, not by the chronology of how the analysis was done. End when
the analysis is complete - no closing pleasantries or restatements of the opening. The document
should degrade gracefully: a reader who stops after paragraph one still has what they need to
act.

Related

Pairs well with

Executive, Matter of Fact, Product Thinker, One-Pager

Avoid with

Devotional Reflection, Narrative Case Study, Pastoral, Warm

Often confused with

Decision Log, One-Pager

Examples

Should we adopt async-first standups?

Executive Summary: Async Standups for the Platform Team

Recommendation: Adopt async-first standups for the 11-person Platform team, on a 30-day trial starting next Monday, with explicit revert criteria. This change is low-risk, reversible, and addresses a measurable inequity in the current schedule. No additional headcount or tooling is required.

Situation

The team spans four timezones: US Pacific (3), US Eastern (3), UK (2), India (3). The current daily standup runs at 9am Pacific, which is 9:30pm in India. Q1 attendance shows India engineers averaged 3.2 of 5 weekly standups; US-based engineers averaged 4.6. The meeting runs 14 minutes on average. Roughly 4 minutes drives any concrete action. Information shared verbally does not persist, and engineers are repeatedly re-diagnosing problems already solved by teammates earlier in the day.

Proposed change

Replace the synchronous daily standup with a structured async update in #team-standup. Each engineer posts by 10am local time with three fields: Shipped, In progress, Blocked or at risk. Blocked items @mention the unblocker. The reclaimed 9am Pacific slot becomes a 60-minute Thursday working session for discussions that require real-time exchange.

Expected impact

• Attendance inequity disappears. India engineers post during their workday rather than their evening.
• Status becomes searchable. The recurring cost of re-diagnosing solved problems goes down.
• Blockers route to the right person via @mention rather than relying on meeting attendance.
• Aggregate meeting time per engineer drops from roughly 70 minutes per week to roughly 60 minutes per week, with a higher fraction of that time spent on substantive work.

Risks

Two risks are worth naming. First, an async channel can become noise if posts are unstructured. The fixed three-field template addresses this. Second, some engineers prefer the social aspect of the sync standup. The Thursday working session preserves a real-time touchpoint without daily cost.

Decision criteria

After 30 days, the trial extends if at least two of three indicators are positive:

1. Median blocker resolution time during overlap windows is under 2 hours.
2. At least 9 of 11 engineers post at least 4 of 5 weekdays.
3. Team survey shows equal or better context on teammates’ work than under the sync model.

If two of three are negative, revert and document the failure mode.

Cost

Zero direct cost. Roughly 2 hours of lead time to set up the channel, pin the template, cancel the sync invite, and announce the trial.

How to start a morning routine

Morning Routine: Recommendation

Recommendation. Install a fifteen-minute morning routine starting Monday: phone stays in another room overnight, water and outdoor light within five minutes of waking, one short quiet activity (read, journal, or plan on paper) before the phone enters. Do this for thirty days, then reassess. Expected effort: low. Expected impact on day quality: high, visible within two weeks.

Why this matters. The first hour of the day currently sets the tone for the next eight. Beginning the day with incoming messages cedes that hour to other people’s priorities and creates a measurable energy cost by mid-morning. A short, pre-committed routine reclaims that hour at minimal cost. The opportunity is not in optimizing the morning. It is in making the morning yours before the day takes it.

What the routine looks like. Five minutes of physical activation (out of bed, water, light), five to ten minutes of one chosen quiet activity, then the phone. Total time: fifteen minutes minimum, forty-five maximum. The specific content is flexible. The only fixed rule is that the phone does not enter the first window.

Why short and modest. The routine is designed for recoverability rather than ambition. A fifteen-minute routine survives sick days, travel days, and deadline days. A ninety-minute routine does not. The metric that matters is recurrence, not intensity. A modest routine that runs three hundred days a year produces more change than an elaborate one that runs forty.

Risks. The main risk is that the routine creeps in scope and becomes hard to sustain. Mitigate by capping total duration at forty-five minutes for the first ninety days. The secondary risk is that the routine is too small to feel meaningful. The fifteen-minute version often feels insufficient on day three and obvious on day twenty-one. Stay with it through the dip.

What to expect. Days 1 to 7: high friction, particularly around the phone-distance rule. Days 8 to 21: the routine begins to install as a default. Days 22 to 30: the routine runs without willpower, and the contrast between routine and no-routine days becomes clear.

Cost of doing nothing. The reactive morning is not free. It costs roughly the first two hours of each day in degraded attention and elevated emotional reactivity. Across a working year, that is approximately five hundred hours of suboptimal output and several hundred small mood decisions made from a worse baseline. The routine is the lowest-cost intervention available against that loss.

Decision required. None from anyone but you. Start tomorrow. Track on paper. Reassess in thirty days.

How to choose between Postgres and DynamoDB for a new service

Executive Summary on: Choosing between Postgres and DynamoDB

Recommendation: ship the Lattice Notify notification system on Postgres with a queue. Pre-commit to a DynamoDB migration trigger if real volume crosses 2M events/day on a 30-day rolling average. This is the decision the architecture meeting should ratify on Wednesday 2pm Pacific, with the team executing against it from sprint planning on Friday.

Why Postgres now. Three of the five evaluation criteria favor Postgres at launch volume of 500K events/day: the eight-backend-engineer team has shipped at this scale on Postgres before; the four-person on-call rotation can debug Postgres incidents without ramp-up; cross-database queries to the existing billing, analytics, and product reads stay native SQL. Operating two storage systems doubles the on-call cognitive load on a rotation that does not have slack to absorb it. The cost of being wrong is bounded: 3-6 weeks of rework if a migration is forced, on a schedule the team can plan rather than an incident the team has to survive.

Why the trigger condition. The 10x growth scenario depends on the Slack-partnership deal closing. CRO estimate is 60% confidence. At that probability, the expected operational cost of running on DynamoDB from day one (a year of two-database operations on an untrained team) exceeds the expected cost of a deferred migration. The 2M events/day threshold is roughly the point at which Postgres sharding work becomes urgent rather than discretionary; defining the trigger now converts a future emergency into a scheduled engineering project.

Risks accepted. If the Slack deal closes and volume ramps faster than expected, the team will face a migration project they could have avoided. Marcus’s prototype Dynamo schema is preserved in the design-docs repo to shorten that path if it becomes necessary. If volume stays flat, the team gains a year of stability on familiar infrastructure with no architectural debt.

What this decision rejects. It rejects DynamoDB-from-day-one as too operationally expensive for the current team size. It rejects an unconditional Postgres commitment as insufficiently planned for the high-volume scenario. It rejects deferring the decision past Friday, which would block next sprint’s planning.

Owners and dates. Ana owns the Postgres schema and queue integration; target in production by 2026-06-15. Marcus owns the preserved Dynamo design and will be lead engineer if the trigger fires. Priya owns the quarterly volume review against the 2M events/day threshold, starting 2026-Q3. The on-call rotation stays at four people on one storage system.