Developer Productivity

Meeting Notes Best Practices: Capture Decisions, Not Just Minutes

Write meeting notes that drive action. Template, best practices, and workflow for capturing decisions, action items, and context from every meeting.

Back to blogApril 16, 20265 min read
meetingsdocumentationdecisionsteam-coordination

Your team just had a 30-minute meeting.

Someone sends notes:

"Discussed Q3 roadmap. Bob said we should focus on API. Alice disagreed. We'll decide next week."

A month later:

Someone asks: "What did we decide about Q3?"

No one remembers.

Why? The notes captured what was said, not what was decided.

Useful meeting notes capture decisions. Transcript-style notes are forgotten.

The difference:

Bad notes: "We talked about database scaling."

Good notes:

  • Decision: Migrate to PostgreSQL
  • Rationale: ACID consistency required
  • Owner: Carol
  • Deadline: End of Q2
  • Open: How to migrate 5TB of data?

This guide covers writing notes that matter.


Why Transcript Notes Fail

Reason 1: Too Much Noise

Transcript-style notes capture everything said.

"I think maybe we could probably consider..."

Pages of rambling.

Reader can't extract meaning.

Reason 2: Decisions Get Lost

Decision happens in middle of conversation.

Hidden among other comments.

Next week: "What did we decide?"

Can't find it in the wall of text.

Reason 3: No Owners

"We should update the docs."

By whom?

When?

Left unclear.

Nothing happens.

Reason 4: No Accountability

Without owners, no one is accountable.

Action items stay open forever.

Reason 5: No Context

"We'll use Redis."

Why? Alternatives?

Context is lost.

Decision seems arbitrary later.

Reason 6: Not Findable

Notes stored on someone's computer.

Can't be searched.

Next quarter: "What did we decide about caching?"

Lost.


What Good Meeting Notes Capture

Element 1: Attendees

Who was in the meeting?

Why: If someone wasn't there, they might have context to add.

Example: "Attendees: Alice (product), Bob (engineering), Carol (ops)"

Element 2: Decisions Made

What was decided?

Only include actual decisions, not discussions.

Example:

  • Decision: Adopt GraphQL
  • Status: Decided
  • Owner: Bob

Element 3: Rationale

Why this decision?

What problem does it solve?

Example:

  • Rationale: REST API hard to version. GraphQL solves versioning elegantly.

Element 4: Alternatives

What other options were considered?

Why were they rejected?

Example:

  • Alternative: Stay with REST + better versioning strategy
  • Why rejected: Versioning strategy not proven, team prefers GraphQL

Element 5: Implications

What does this decision mean?

What changes?

Example:

  • Implication: All new endpoints use GraphQL
  • Implication: Current REST endpoints stay until migration complete

Element 6: Owners & Deadlines

Who is responsible?

When should it be done?

Example:

  • Owner: Bob
  • Deadline: June 15
  • Status: In progress

Element 7: Open Questions

What's still unclear?

What needs follow-up?

Example:

  • Open: How do we migrate existing clients?
  • Open: Who leads the GraphQL training?

Element 8: Action Items

What needs to happen before next meeting?

Example:

  • Bob: Draft GraphQL migration plan (due May 1)
  • Alice: Define client-facing timeline (due May 1)

Element 9: Linked Context

What documents support this decision?

Example:


Meeting Notes Template

Use this template for every meeting:

# [Meeting Title]

**Date:** [Date]
**Attendees:** [List]
**Next Meeting:** [Date and time]

## Decisions Made

### Decision 1: [What was decided?]
- **Status:** Decided / Pending / TBD
- **Rationale:** [Why this decision?]
- **Alternatives:** [What was considered? Why rejected?]
- **Owner:** [Who implements?]
- **Deadline:** [When?]

### Decision 2: [What was decided?]
- **Status:** [...]
- **Rationale:** [...]

## Open Questions

- [ ] [What's still unclear?]
- [ ] [What needs follow-up?]

## Action Items

- [ ] [Person]: [Action] (due [date])
- [ ] [Person]: [Action] (due [date])

## Linked Context

- Related: [Link to supporting docs]
- Related: [Link to previous decision]

## Notes

[Any additional context worth noting]

## Follow-up

Next meeting will address:
- [Unresolved question 1]
- [Pending decision 1]

How to Take Notes During Meeting

During: Capture Skeleton

Don't write everything.

Capture:

  • Decision being made
  • Owner named
  • Deadline mentioned
  • Open questions raised

Don't capture: Every comment, full sentences, rambling

During: Mark Decisions

When you hear "We'll do X":

Mark it as DECISION.

Use shorthand:

  • D: We'll use PostgreSQL
  • A: Alice owns implementation
  • Deadline: May 1

During: Ask for Clarity

If something isn't clear:

Ask in the meeting.

"So the owner is Alice and the deadline is May 1?"

Get confirmation live.

No confusion later.

After: Synthesize

Within 2 hours of meeting:

Fill in template from skeleton notes.

  • Expand shorthand into full sentences
  • Add rationale you remember
  • Add context you know
  • Format clearly

Why 2 hours? While meeting is fresh in mind.


How to Connect Notes to Async Work

Connection 1: Link From Decision Memo

Decision is made in meeting.

Meeting notes link to decision memo.

Decision memo has full context.

Meeting decision:
- We'll adopt PostgreSQL

See decision memo: [ADR-001: Database Choice]

Connection 2: Update from Notes to Wiki

Decision is made in meeting.

Wiki already has template for it.

Update wiki from notes.

Meeting decision: Adopt GraphQL

Wiki page updated: [Architecture: API Protocol]

Connection 3: Link Action Items to Issues

Action from meeting notes:

Create GitHub issue.

Link from notes to issue.

Action: Bob drafts migration plan
Related issue: [#1234: GraphQL migration plan]

Connection 4: Link From FAQ

Someone has same question later.

FAQ links to meeting notes + decision memo.

No repeat discussion needed.


Common Meeting Notes Mistakes

Mistake 1: No Owners

"We should update the docs."

Who? No one assigned.

Nothing happens.

Fix: "Carol owns updating docs. Deadline: May 1."

Mistake 2: Vague Action Items

"Improve performance."

Too vague.

What does "improve" mean?

By how much?

Fix: "Bob optimizes database queries to <100ms p99. Deadline: May 1."

Mistake 3: Lost Decisions

Decision hidden in paragraph of notes.

Someone later: "What did we decide?"

Can't find it.

Fix: Use template. Decisions at top. Clearly marked.

Mistake 4: Notes Stored Nowhere

Notes on laptop.

Can't be searched.

Can't be shared.

Fix: Store in wiki. Link from README. Make searchable.

Mistake 5: Never Updated

Decision made in meeting.

Reality changes.

Notes never updated.

Later: "What was decided?"

Notes say one thing. Reality is different.

Fix: Decision memo (not just notes) is source of truth. Update memo, not notes.

Mistake 6: Too Much Detail

Full transcript of meeting.

60 pages of rambling.

No one reads.

Fix: Just decisions, owners, deadlines, open questions. Concise.


Realistic Implementation

Week 1: Choose Template

  • Pick template above or modify it
  • Share with team
  • Agree on format

Week 2: First Meeting

  • Use template
  • Take notes during
  • Synthesize after
  • Share with team
  • Get feedback

Week 3+: Refine

  • Team gives feedback: "What's missing?"
  • Update template
  • Continue using

Metrics That Matter

Metric 1: Decision Clarity

Track: % of decisions that have clear owners and deadlines

  • Low: <50% (notes unclear)
  • Good: 70%+
  • Excellent: 90%+

Goal: 90%+

Metric 2: Action Item Completion

Track: % of action items completed by deadline

  • Low: <40% (unclear ownership)
  • Good: 60%+
  • Excellent: 80%+

Goal: 80%+

Metric 3: Note Findability

Track: When someone asks "what was decided?" can you find it in 2 minutes?

  • Low: Often can't find it
  • Good: Usually can find it
  • Excellent: Always can find it

Goal: Always can find it


Conclusion

Good meeting notes capture decisions, not transcripts.

Essential elements:

  1. Attendees
  2. Decisions with rationale
  3. Alternatives considered
  4. Owners & deadlines
  5. Open questions
  6. Action items
  7. Context links

How to take notes:

  1. During: Mark decisions, ask for clarity
  2. After: Synthesize from skeleton
  3. Link: Connect to memos, issues, wiki

Why it matters:

With good notes:

  • Decisions are clear
  • Owners are accountable
  • Action items get done
  • Team moves faster

Without good notes:

  • Decisions get rehashed
  • Work gets blocked
  • Meetings multiply

For async documentation, see Async Documentation for Remote Teams. For team wiki setup, see Team Wiki Setup Guide.

Capture decisions. Assign owners. Move forward.

Keep reading

More WebSnips articles that pair well with this topic.