Meeting Notes Template in Markdown

A good meeting notes template separates decisions from discussion, gives every action item a named owner and an ISO-8601 date, and keeps an Open Questions section for what the meeting did not close. This is that template — backbone plus five variations (1-on-1, standup, retro, decision, design-review) — in plain markdown, copy-paste ready.

The file is text on purpose. It opens in VS Code, Obsidian, Bear, Slack code blocks, GitHub, the Linear comment box, an email. Twenty years from now it will still open. Atlassian's State of Teams 2024 found that organizations with poor meeting cultures see employees spend 50% more time in unnecessary meetings than making progress on high-priority work.¹ Microsoft's 2025 Work Trend Index, which surveyed 31,000 knowledge workers and separately mined Microsoft 365 telemetry, found that 57% of meetings are ad hoc calls without a calendar invite; among the most-pinged fifth of users, the telemetry shows an interruption every two minutes during core hours — 275 times a day from meetings, emails, and chats.² A template will not fix that. A template will make the meetings that happen worth the hour they took.

Why most meeting notes fail

Most meeting notes fail because they are written as a transcript of speech instead of a record of decisions. The reader two weeks later cannot find what was decided, who owns it, or when it is due — the three pieces of information the meeting actually produced. Everything else is paragraph-shaped noise the brain will not re-read.

Steven Rogelberg, the organizational psychologist who wrote The Surprising Science of Meetings (Oxford University Press, 2019), opens with the scale of the thing: by his estimate, employees endure a staggering 55 million meetings a day in the United States.^{3 4} Separately, Leslie Perlow, Constance Noonan Hadley and Eunice Eun reported in Harvard Business Review in 2017 that executives spend an average of nearly 23 hours a week in meetings — up from less than 10 hours in the 1960s.⁵ The Harvard Business Review's meeting-cost calculator was prompted by a Bain & Company study that found a single weekly meeting of midlevel managers was costing one organization $15M a year in salaried time.⁶ If the meeting is going to happen anyway, the notes are the only artifact that earns the hour back.

The template

Copy the block below and save it as meeting-notes.md in any editor. Forty lines, fits on one screen, uses only markdown the rest of your stack already understands — YAML frontmatter, headings, lists, checkboxes, links. No proprietary syntax, no plugin dependencies. The full template is below; section-by-section commentary follows immediately after.

---
title: "Weekly engineering sync"
date: 2026-05-15
time: 09:30–10:15
type: weekly-team
attendees:
  - "@noah (chair)"
  - "@dana (notes)"
  - "@miguel"
  - "@priya"
absent:
  - "@river (PTO)"
tags: [eng, weekly, q2]
---

# Weekly engineering sync — 2026-05-15

> One-paragraph summary for those who couldn't attend.
> Shipped staging rollout. Decided to drop the Redis dependency. Two follow-ups to Priya before Friday.

## Decisions

- **Drop the Redis dependency from auth service.** Owner: @miguel. Rationale: cache hit rate < 5%; complexity not earning its keep.
- **Defer the OAuth refactor to Q3.** Owner: @noah. Rationale: Priya's roadmap higher priority through end of Q2.

## Action items

- [ ] @miguel — Remove Redis client + tests — by 2026-05-22
- [ ] @priya — Share Q2 staging metrics in #eng — by 2026-05-17
- [ ] @noah — Update ADR-0014 to reflect deferred OAuth work — by 2026-05-20

## Discussion

- Staging rollout went clean. No regressions in 48 h window.
- Two flaky tests in `auth/session_spec` — Priya investigating.
- Discussed whether to merge the feature flag library; held over.

## Open questions

- How do we measure success of the dropped Redis change? (revisit 2026-06-12)
- Do we need a separate on-call rotation for the new ingest pipeline?

## Links

- [ADR-0014 OAuth refactor](../adrs/0014-oauth-refactor.md)
- [Staging metrics dashboard](https://example.com/metrics)
- [PR #842](https://github.com/example/repo/pull/842)

Six sections — frontmatter, summary, decisions, action items, discussion, open questions, links. The order matters. Decisions live above discussion because the reader who skims the file in six months should see the outcome before they see the noise that produced it.

What each block is doing

Each block of the template solves a specific failure mode that ruins ordinary meeting notes. The frontmatter answers when and who. Decisions answer what was concluded. Action items answer what happens next, by whom, by when. Discussion captures context for future readers. Open questions admit that not everything closes. Links provide the durable trail back to source artifacts.

Frontmatter. YAML at the top of the file — supported natively by Obsidian, Hugo, Astro, and most static site generators. The (chair) and (notes) inline role markers keep responsibility visible without a separate field; diffuse responsibility is how decisions get unmade in the hallway afterward. Robert's Rules of Order (12th ed., 2020) still recommends recording body, time, and presiding officer as the first lines of any formal minutes.⁷

One-paragraph summary. Three sentences for the absentee — the most reread part of any meeting note. Treat it as the abstract of a paper: written last, scanned first. Jeff Bezos built Amazon's memo culture on the same instinct. Amazon replaced slide decks with a "six-page, narratively-structured memo" that attendees read silently for about the first thirty minutes of the meeting — and of banning the slides that made room for it, Bezos said it was "probably the smartest thing we ever did."⁸

Decisions. A list. Each item is a complete sentence. Each names the owner. No more than five — six decisions in one meeting was three meetings stapled together. Bain's RAPID and Atlassian's DACI both exist because organizations bleed time when nobody can say later who decided.^{9 10} The named-owner discipline is what either framework reduces to at the file level.

Action items. Checkboxes. Owner. Date. In that order. The format - [ ] @name — task — by YYYY-MM-DD is dense and machine-parseable. The owner field is the load-bearing one. Fellow, which builds meeting software and has every commercial reason to understand where action items die, states the rule without hedging: "If nobody owns a task, nobody does it. The diffusion of responsibility is real: when everyone is responsible, no one is responsible."¹¹ A named owner and an ISO-8601 date is the cheapest discipline there is — it turns a sentence somebody said into a commitment somebody made.

Discussion. A bulleted, terse log. Not a transcript. Three to seven lines, capturing why the decision above was made. If you cannot keep it under seven bullets, the meeting was too long.

Open questions. The block most teams skip and most need. Some questions do not close in the hour; writing them here forces them into the next agenda. Stripe's writing culture runs on the same instinct — that the durable form of a thought is the written one. Dave Nunez, then Stripe's documentation manager, put it plainly: "From leadership on down, we default to writing. We don't really have slide decks."¹²

Links. The durable trail. PRs, dashboards, ADRs, Figma files, prior notes, ticket numbers. A meeting note with five links is a node in a graph; without them, it is an island.

The five variations

The backbone adapts to five meeting types every working professional encounters. Each variation keeps the same six-section frame and changes only the labels and prompts. You memorize one shape; you swap the section names.

1-on-1 meeting notes template

A 1-on-1 is the subordinate's meeting. Andy Grove, in High Output Management (1983), was explicit: "A key point about a one-on-one: it should be regarded as the subordinate's meeting, with its agenda and tone set by him."¹³ Mark Horstman's Manager Tools canon recommends a 30-minute weekly cadence split 10 minutes for them, 10 minutes for you, 10 minutes for the future.¹⁴

---
title: "1:1 — @noah / @priya"
date: 2026-05-15
type: one-on-one
cadence: weekly
---

# 1:1 — Priya / 2026-05-15

## Their topics (10 min)

- Sprint felt heavy — investigating root cause
- Considering applying to internal speaker slot at Q3 all-hands

## Manager topics (10 min)

- Feedback on PR #842 review tone — thoughtful, keep doing it
- One concern: Tuesday demo missed setup time

## Career + signals (10 min)

- Wants stretch on architecture work — propose owning ADR-0015
- Watch for sustainable load through end of sprint

## Decisions

- **Priya owns ADR-0015.** By 2026-05-29.

## Action items

- [ ] @noah — Introduce Priya to @miguel (architecture peer) — by 2026-05-17
- [ ] @priya — Draft ADR-0015 outline — by 2026-05-22

## Open questions

- Will the Q3 speaker slot conflict with the staging migration window?

The Career + Signals block is the differentiator. Lara Hogan keeps a permanent file per direct report with feedback preferences, recognition preferences, and grumpiness triggers — "Have the answers to these questions WAY before you need them."¹⁵ Will Larson, author of An Elegant Puzzle, recommends the same practice: work out why the meeting is happening before you are in it.¹⁶ Camille Fournier, in The Manager's Path (2017), insists "good 1-1s are not status meetings" — they build human connection.¹⁷

Standup notes template

Three questions; fifteen minutes; written down so the asynchronous half of the team is not excluded. The three classic questions are Jeff Sutherland's, from the first Scrum team in 1993: What did you do yesterday? What will you do today? Is anything blocking you?¹⁸

---
title: "Standup — 2026-05-15"
type: standup
sprint: 2026-Q2-S4
---

# Standup — 2026-05-15

## @noah
- Yesterday: shipped auth metrics to staging
- Today: code review backlog
- Blocked: nothing

## @priya
- Yesterday: ADR-0014 draft
- Today: pair with @miguel on Redis removal
- Blocked: waiting on infra approval

## @miguel
- Yesterday: PR #842 merged
- Today: Redis removal
- Blocked: nothing

## Decisions

- **Skip Friday standup — half team OOO.** Owner: @noah.

## Action items

- [ ] @noah — Ping infra in #platform re ADR-0014 — by 2026-05-15 EOD

If you run async standups, this is also your template — paste it into Slack as a code block.

Retrospective notes template

Esther Derby and Diana Larsen's Agile Retrospectives (Pragmatic Bookshelf, 2006) defined the canonical five-stage retrospective: Set the Stage, Gather Data, Generate Insights, Decide What to Do, Close.¹⁹ The most copied data-gathering pattern inside that frame is Keep / Stop / Start.

---
title: "Retro — Sprint 2026-Q2-S4"
date: 2026-05-15
type: retrospective
facilitator: "@dana"
---

# Retro — Sprint 2026-Q2-S4

## Keep

- Tight PR review turnaround (median < 4 h)
- Friday demo cadence

## Stop

- Slack threads as decision records
- Re-estimating mid-sprint without telling the chair

## Start

- ADR for every interface change
- One async standup per week (Wednesday)

## Decisions

- **Adopt ADR-for-every-interface change.** Owner: @priya. By next sprint.
- **Replace Wednesday standup with written update.** Owner: @noah.

## Action items

- [ ] @priya — Draft ADR template adoption note — by 2026-05-22
- [ ] @noah — Update Wednesday calendar invite — by 2026-05-17

## Open questions

- How do we know the async standup is working? (Revisit at next retro.)

A retro produces decisions, not feelings. If your retros end without two or three named owners on the action-item list, the retro was a venting session.

Decision-meeting notes template (lightweight ADR)

For any meeting whose purpose is to decide one thing, borrow the structure of Michael Nygard's Architecture Decision Record, published November 2011. Nygard defined the five sections every record needs: Title, Context, Decision, Status, Consequences.²⁰ The template below is a meeting-shaped ADR — the same five sections plus an owner and a date.

---
title: "Decision — Redis vs in-memory cache"
date: 2026-05-15
type: decision
status: accepted
---

# Decision — Redis vs in-memory cache

## Context

Auth service uses Redis for session cache. Hit rate < 5% over Q1.
Operating cost: $180/mo. Adds a network hop and a SPOF.

## Options considered

1. Keep Redis as-is.
2. Replace with in-process LRU cache.
3. Replace with Redis Cluster (HA).

## Decision

**Option 2 — replace Redis with an in-process LRU cache.**

## Consequences

- Loses cross-instance cache coherence (acceptable; hit rate already < 5%).
- Removes one external dependency.
- Saves ~$2,000/yr in infra.
- Forces a migration window in late May.

## Owner + date

- Owner: @miguel
- Implementation deadline: 2026-05-29
- Review date: 2026-08-29

## Open questions

- Do we revisit if hit rate falls further? (Yes — review date above.)

## Links

- [ADR-0014 in repo](../adrs/0014-redis-removal.md)
- [Redis cost dashboard](https://example.com/cost)

ADRs have an established ecosystem: the canonical site at adr.github.io, the MADR format, and adoption inside Microsoft Azure's Well-Architected Framework and AWS Prescriptive Guidance.²¹ The point of recording a decision is not to defend it later — it is to give the future team enough context to know whether it still applies.

Design-review notes template

A design review is a structured walkthrough of a proposed solution before it is built. The template inverts the decision format: Constraints and Trade-offs sit above the decision, because the value of the meeting is making them explicit, not approving the design. Microsoft's Engineering Fundamentals Playbook builds its trade-study practice on the same footing — the studies "evaluate potential choices against a set of objective criteria/requirements to clearly lay out the benefits and limitations of each solution," and have "proved to be a critical tool to drive alignment with the stakeholders, earn credibility while doing so and ensure our decisions were backed by data and not bias."²²

---
title: "Design review — Auth refactor v2"
date: 2026-05-15
type: design-review
proposer: "@priya"
---

# Design review — Auth refactor v2

## Goal

Cut auth round-trip latency from ~280 ms to < 100 ms p95.

## Constraints

- Cannot break existing OAuth tokens issued before 2026-06-01.
- Must keep on-call rotation unchanged.
- $0 net infra cost increase.

## Trade-offs

- In-process cache → loses cross-instance coherence.
- New token format → migration cost ~3 sprint-days.
- Sharded session store → adds operational complexity.

## Feedback raised

- @miguel — Concerned about migration path for stale tokens.
- @noah — Suggests phased rollout via feature flag.
- @dana — Asks about observability story.

## Decisions

- **Proceed with in-process cache + feature flag rollout.** Owner: @priya. By 2026-06-12.

## Action items

- [ ] @priya — Migration plan doc — by 2026-05-22
- [ ] @miguel — Stale-token audit script — by 2026-05-29

## Open questions

- What is the rollback path if p95 worsens?
- Who owns the feature flag after launch?

## Links

- [Design doc v2](https://example.com/auth-v2)
- [Latency dashboard](https://example.com/latency)
- [Related ADR-0014](../adrs/0014-redis-removal.md)

A design review's notes are the only durable summary anyone will read in six months. Make the constraints and the trade-offs the first two sections — they are what the future engineer needs.

How to use the template

A template is not a routine; the routine is what makes the template work. Three habits separate teams whose notes get used from teams whose notes accumulate. Each takes about a minute, none is glamorous, and all of them compound over a year of meetings into something that looks like institutional memory.

Before. Five minutes. Paste the template, fill the frontmatter, paste the agenda. If you cannot name the meeting's purpose in one sentence, cancel it. The one-sentence purpose is the cheapest filter there is, and the one most meetings skip.

During. Name a single note-taker before the first sentence is spoken. Diffuse responsibility ("we'll all take notes") reliably produces zero notes. The chair runs the meeting; the note-taker captures decisions and action items in real time. If you cannot spare a note-taker, the chair is the note-taker — but only one human types.

After. Two minutes. Re-read the decisions and action items aloud before everyone closes the call. Confirm each owner has accepted their action item. Paste the note into the team's canonical location (folder, Slack channel, wiki, issue tracker — pick one). The two-minute close converts notes from transcript-of-the-call into record-of-the-decision.

Why markdown specifically

Markdown is the right format for meeting notes because the file is text. It opens in any editor, diffs cleanly in git, and survives the platform that produced it. John Gruber and Aaron Swartz published the original spec in 2004 — twenty-two years later, every major note app, code editor, and chat platform renders it.²³

Portability matters because meetings outlive tools. A .md file opens in Obsidian, Bear, Logseq, VS Code, GitHub, Linear, the macOS Finder preview, and a plain cat in the terminal. Steph Ango captured the durability argument in one sentence: "In the fullness of time, the files you create are more important than the tools you use to create them."²⁴ Writing in markdown is also writing without theatre — no font picker, no autocomplete, no AI summariser confidently misattributing a decision.

Common mistakes

Six failure modes ruin meeting notes templates across every team that adopts them: transcript-style notes, unowned action items, missing dates, decisions buried in discussion, no open-questions block, and the single-vault-file trap. Each is named below with the fix.

• Transcripts, not records. A line for every sentence said. The decisions section is the only artifact that earns its keep.
• Unowned action items. Every action item names one person. Not a team. Not a role. A person.
• Missing dates. "Soon" and "ASAP" are not dates. ISO-8601 (YYYY-MM-DD) is unambiguous across calendars and time zones.
• Decisions buried inside discussion. Move every decision into the decisions block, even if it feels like duplication.
• No open-questions block. Forces premature closure and leaves landmines for the next agenda.
• The single-file vault. One file per meeting, named YYYY-MM-DD-type.md. Twenty years of discipline in one filename.

A subtler failure: trusting an AI notetaker to do the writing. Granola, Otter, Fireflies, and Fathom now transcribe meetings at 90–95% accuracy in clean audio.²⁵ What the transcript is not is a decision record. Use the bot for the recording. Write the notes yourself.

Frequently asked questions

Seven questions surface in every team's first month with this template — about format, length, AI tools, storage, 1-on-1 privacy, dates, and the open-questions block. Each answer below carries the working consensus from the practitioners cited above.

What's the difference between meeting minutes and meeting notes?

Meeting minutes are the formal parliamentary record (motions, votes, attendees) required by Robert's Rules of Order for boards and nonprofits.⁷ Meeting notes are the informal team artifact — decisions, owners, dates — used inside companies. Most teams need notes; only boards and nonprofits need minutes.

How long should meeting notes be?

Short. A 30-minute meeting should produce 100–300 words of notes. A 60-minute meeting, 200–500. If your notes for a one-hour meeting exceed one page, you are transcribing instead of recording. Steven Rogelberg's research finds that the average attendee retains roughly one-third of a meeting's content within 24 hours — the notes are the institutional version of what you wish your memory did.³

Should I use AI to summarize the call?

Use it for the transcript; not for the notes. AI tools achieve 90–95% transcription accuracy in clean conditions and drop into the 60–70% range in degraded audio.²⁵ More importantly, an AI summariser does not know which sentence in your one-hour conversation was the decision. A human who was present does. Treat the transcript as a searchable backup; treat the human-written decisions block as the record.

Where should I store the .md files?

In one place, indexed by date. A meetings/ folder in your team repo. A single Notion or Obsidian vault. A Slack channel pinned for the week. The format does not matter; the rule is that there is exactly one canonical place, a named filename pattern (YYYY-MM-DD-type.md), and no second source of truth. Two sources of truth means zero.

Is a 1-on-1 a meeting that needs notes?

Yes — but only the manager keeps them, and only the career-and-signals block is private. The action items and decisions are shared with the direct report. Lara Hogan, Camille Fournier, and Mark Horstman all converge on the same practice: a permanent file per direct report, updated each week, used as the substrate for promotions, feedback, and growth conversations.^{14 15 17}

Why ISO-8601 dates?

Because 2026-05-15 sorts alphabetically into chronological order. 5/15/2026 does not. Across calendars, locales, and time zones, ISO-8601 is the only date format that survives a ls on the meetings folder five years from now.

Do I really need the open-questions section?

Yes. It is the section most teams skip and most need. A meeting that does not name what was left open silently produces the next meeting. The five-minute version of this discipline: at the close of every meeting, ask aloud — "what did we not decide?" Write those down. The next agenda is half-written before the chair has hung up.

Download the templates

Every template above is in this file — copy any markdown block directly into your editor. The six templates (backbone, 1-on-1, standup, retro, decision, design-review) are ready to paste. Save each as a .md file in a templates/ folder, then duplicate it per meeting using the filename pattern YYYY-MM-DD-meeting-type.md.

There is nothing to sign up for. No account. No email gate. The templates are markdown. The point of markdown is that it travels.

Take this template anywhere you take markdown. Decisions above discussion, owners on every action item, dates that sort — that is the whole discipline, and a plain text file is the only place it survives intact.

MNMNOTE (mnmnote.com) is one place to keep it — opens in your browser, stays in your browser.

References

All URLs re-verified live as of 2026-07-17.