Skip to content
Writing Style Library

Meeting Notes

A structured capture of what was decided and what was assigned - not a transcript. Organized by outcome so someone who missed the meeting can act without asking follow-up questions.

Meeting Notes

Section titled “Meeting Notes”

Meeting notes are not a transcript and not a summary. A transcript records everything that was said; a summary compresses it. Meeting notes record the outcomes: what was decided, what was assigned, and what questions remain open. The reader who missed the meeting should be able to act from the notes without sending a follow-up message to someone who was there.

The organizing principle is outcome, not chronology. Organizing by “who said what, in order” produces a document that is accurate but nearly useless - it requires the reader to reconstruct the conclusions from the raw material. Organizing by decisions, actions, and open items produces a document that is immediately actionable. A decision section states what was decided, not how long the group debated it. An action section states who owns what by when, not the discussion that led to the assignment.

Meeting notes serve a secondary function as institutional memory. They are the difference between a team that relitigates the same discussion every month and one that can point to when a decision was made and why. For this reason, notes should be filed where they are findable, dated, and include enough context that someone reading six months later can reconstruct the situation without needing anyone to explain it.

Canonical template

Section titled “Canonical template”
# Meeting Notes - [Topic or Meeting Name]
Date: [YYYY-MM-DD]
Attendees: [Name, Name, Name]


## Decisions
- [Decision stated as a fact, not as a discussion topic]
- [Decision stated as a fact]


## Actions
- [ ] [Specific task] - owner: [Name] - due: [date or "next meeting"]
- [ ] [Specific task] - owner: [Name] - due: [date or "next meeting"]


## Open Items / Parking Lot
- [Question or item that needs resolution, with owner if known]


## Context (optional)
[1-3 sentences of background for anyone reading later who lacks context]

When to use

Section titled “When to use”

Use meeting notes any time a synchronous meeting produces decisions or assignments - team syncs, planning sessions, retrospectives, stakeholder meetings, design reviews. If people who were not present need to stay informed or take action, notes are required. Recurring meetings especially benefit from a consistent notes format that accumulates as institutional memory over time.

When not to use

Section titled “When not to use”

Skip formal notes for casual conversations and informal 1:1 check-ins with no action items. During real-time incident response, speed matters more than format. If a meeting’s decisions will be immediately captured in an ADR or PRD, redundant notes add noise. Informational-only presentations with no decisions or assignments do not need a decisions/actions structure.

Pairs well with

Section titled “Pairs well with”

operator, direct-communicator, matter-of-fact, candid

Often confused with

Section titled “Often confused with”

adr: An ADR is a permanent, structured record of a specific architectural decision designed to explain the reasoning to future engineers. Meeting notes capture everything decided in a meeting, including non-architectural matters, and are organized for immediate action by attendees and absentees alike.

daily-standup: A daily standup is a recurring short-form status communication with a fixed three-part structure. Meeting notes cover a specific meeting’s full set of outcomes, including decisions and assigned work, across any topic or time range.

Tells

Section titled “Tells”
  • A header with topic, date, and attendees
  • Organized by outcome - Decisions, Actions, Open Items - not by chronology
  • Each decision stated as a concluded fact, not as a topic that was discussed
  • Each action item names a specific owner and a due date
  • An optional Context section of 1-3 sentences for a later reader
  • Someone who missed the meeting can act from the notes without a follow-up question

Anti-patterns

Section titled “Anti-patterns”
  • Recording who said what in the order it was said - That produces a transcript or a chronological log; meeting notes capture outcomes, and a chronology forces the reader to reconstruct the conclusions.
  • Reframing a single architectural decision into a permanent reasoning record - That is the confusable adr; meeting notes capture everything a meeting decided across any topic, organized for immediate action, not the deep rationale of one technical choice.
  • Collapsing the notes into a recurring three-part personal status update - That is the confusable daily-standup; meeting notes cover one meeting’s full set of outcomes, not one person’s done/next/blocked.

Failure modes

Section titled “Failure modes”
  • Strips so hard toward outcomes that the rationale disappears - future readers see what was decided but cannot reconstruct why it was chosen over the alternatives - Keep the one-line because behind each decision; outcome-focus means the conclusion is findable, not that the reason it won is deleted.
  • Over-documents a meeting that produced nothing - the Decisions and Actions structure is filled out for a check-in with no real outcomes - Write notes only when a meeting decided or assigned something; if the Decisions section is empty, a one-line summary serves better than the full scaffold.

Instruction

Section titled “Instruction”
Write as meeting notes. Organize by outcome: decisions first, then action items, then open
questions. Do not organize chronologically or by who said what. State each decision as a
concluded fact, not as a topic discussed. State each action item with a specific owner and
due date. The person who missed this meeting should be able to read these notes and act
without sending a follow-up question. Use plain, direct language - meeting notes are not
prose, they are a structured record.

Template

Section titled “Template”

See the Meeting Notes template.

Section titled “Related”

Pairs well with

Section titled “Pairs well with”

Operator, Direct Communicator, Matter of Fact, Candid

Avoid with

Section titled “Avoid with”

Columnist, Pastoral, Playful, Warm

Often confused with

Section titled “Often confused with”

Architecture Decision Record, Daily Standup

Examples

Section titled “Examples”

Platform Eng Weekly - Standup Format Review

Section titled “Platform Eng Weekly - Standup Format Review”

Date: 2026-05-14 (Thursday) Time: 09:00 - 09:45 Pacific Location: Zoom + #eng-platform thread Facilitator: Maya Chen Notes: Priya Raman

Attendees

Section titled “Attendees”

Present (9): Maya Chen, Priya Raman, Devon Park, Sara Okafor, Jamie Liu, Tom Bradley, Aditi Sharma, Ravi Krishnan, Nikhil Iyer Absent (2): Emma Walsh (PTO), Oliver Hughes (on-call handoff)

Agenda

Section titled “Agenda”
  1. Q1 standup attendance and time-cost data (Maya, 10 min)
  2. Proposed async-first format (Maya, 15 min)
  3. Trial scope, success metrics, concerns (group, 15 min)
  4. Decisions and owners (5 min)

Decisions

Section titled “Decisions”
  • D1. The team will run a 30-day async standup trial starting Monday May 19. The 9am Pacific sync slot is paused for the trial duration.
  • D2. Daily updates are posted in #team-standup by 10am local time using the three-field template: Shipped / In progress / Blocked or at risk.
  • D3. The Thursday 9am Pacific slot is repurposed as a 60-minute working session (not status). Agenda required, posted Wednesday EOD.
  • D4. On-call engineer owns daily channel triage by 9am Pacific and 30-minute blocker response during business hours.
  • D5. Trial review checkpoints are day 15 (lightweight pulse) and day 30 (go / no-go / extend).

Discussion summary

Section titled “Discussion summary”

Maya presented Q1 data: India attendance 3.2/5 vs US 4.6/5, 14-min average standup with ~4 min driving any action, and three documented duplicate-work incidents that a searchable record would have caught.

Aditi and Nikhil supported the change and noted 9:30pm IST is particularly hard on evenings with family commitments. Devon raised concern that async loses the social moment that makes the team feel like a team. Maya acknowledged this is the strongest argument against and is the reason the Thursday session is being added rather than the time fully reclaimed.

Tom asked what happens if someone consistently misses async posts. Group agreed the on-call engineer pings missing posters at 11am local, and persistent gaps escalate to Maya at day 7. Sara asked about PTO and on-call days - resolved by adding an explicit “out” or “on-call, no update” line, captured in the reference doc.

Jamie raised a tooling question (Geekbot vs Slack pinned template) - group decided to start with the pinned template and revisit at day 30 if friction warrants tooling spend.

Action items

Section titled “Action items”
#ActionOwnerDue
A1Pin standup template to #team-standup with field definitionsPriya2026-05-16
A2Send trial kickoff email to eng-platformMaya2026-05-15
A3Draft standup format reference doc (PTO, on-call, partial weeks)Priya2026-05-16
A4Schedule Thursday working session series, cancel daily 9am PacificMaya2026-05-15
A5Brief on-call rotation on daily triage responsibilityTom2026-05-18
A6Set up day-15 pulse survey (3 questions)Priya2026-05-29
A7Day-30 review meeting on calendarMaya2026-05-15

Open questions

Section titled “Open questions”
  • OQ1. Do we need a separate channel for blockers or does #team-standup with @mentions work? Revisit at day 15 if signal-to-noise is a problem.
  • OQ2. How do we surface async updates to stakeholders outside the team (PM, design)? Owner: Maya, by day 15.

Next meeting

Section titled “Next meeting”

Day-15 async pulse review, Friday 2026-05-29, async in thread (no live meeting).

Appears in diff-pairs

Section titled “Appears in diff-pairs”