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.
Instruction
Section titled “Instruction”Write as meeting notes. Organize by outcome: decisions first, then action items, then openquestions. Do not organize chronologically or by who said what. State each decision as aconcluded fact, not as a topic discussed. State each action item with a specific owner anddue date. The person who missed this meeting should be able to read these notes and actwithout sending a follow-up question. Use plain, direct language - meeting notes are notprose, they are a structured record.Template
Section titled “Template”See the Meeting Notes template.
Related
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”- Q1 standup attendance and time-cost data (Maya, 10 min)
- Proposed async-first format (Maya, 15 min)
- Trial scope, success metrics, concerns (group, 15 min)
- 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”| # | Action | Owner | Due |
|---|---|---|---|
| A1 | Pin standup template to #team-standup with field definitions | Priya | 2026-05-16 |
| A2 | Send trial kickoff email to eng-platform | Maya | 2026-05-15 |
| A3 | Draft standup format reference doc (PTO, on-call, partial weeks) | Priya | 2026-05-16 |
| A4 | Schedule Thursday working session series, cancel daily 9am Pacific | Maya | 2026-05-15 |
| A5 | Brief on-call rotation on daily triage responsibility | Tom | 2026-05-18 |
| A6 | Set up day-15 pulse survey (3 questions) | Priya | 2026-05-29 |
| A7 | Day-30 review meeting on calendar | Maya | 2026-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).
Personal Quarterly Retro - Q2 2026
Section titled “Personal Quarterly Retro - Q2 2026”- Date: 2026-05-14
- Time: 7:00pm - 8:15pm
- Attendees: Jordan P. (self), Dana K. (accountability partner, by phone)
- Note-taker: Jordan
Agenda
Section titled “Agenda”- Review Q1 commitments (10 min)
- Energy management - morning routine experiment (30 min)
- Q3 commitments (20 min)
- Logistics for next retro (5 min)
Decisions
Section titled “Decisions”- D1: Continue the morning routine as designed through end of Q2. Do not modify the four-module sequence until 30-day window is complete.
- D2: Cap weekday planning at 10 minutes. Move weekly planning to a new Sunday evening block (8:00pm - 8:30pm, paper notebook).
- D3: Treat travel mornings with a compressed version (water + 5 min planning only). Stop counting these as misses; they are a separate category.
- D4: Defer evening routine design to Q3. Do not stack a second habit experiment in Q2.
Discussion Highlights
Section titled “Discussion Highlights”- Adherence story: 26 of 35 weekdays is above the 80 percent target. Dana pushed back that “above target” should not automatically mean “expand scope.” Agreed.
- Phone-in-kitchen rule: Discussed whether to extend the cutoff from 7:30am to 8:00am. Decided no, because the current cutoff aligns with when the family wakes and a clean handoff already exists.
- Planning bleed: Root cause identified - weekly and daily planning were getting confused in the same 10 minute block. The Sunday evening block (D2) addresses this without breaking the morning cap.
- Friction points: Light module on rainy days is still a soft spot. No decision needed yet, but flagged for review at next retro.
Action Items
Section titled “Action Items”| # | Action | Owner | Due |
|---|---|---|---|
| A1 | Block Sunday 8:00pm - 8:30pm on calendar as recurring | Jordan | 2026-05-18 |
| A2 | Buy second paper notebook dedicated to weekly planning | Jordan | 2026-05-17 |
| A3 | Send Dana a one-line weekly check-in each Friday | Jordan | Ongoing |
| A4 | Draft Q3 evening routine spec (no commitment yet, just a draft) | Jordan | 2026-06-30 |
Logistics
Section titled “Logistics”- Next retro: 2026-08-13, 7:00pm. Same format.
- Mid-quarter check-in by text on 2026-06-25.
Parking Lot
Section titled “Parking Lot”- Sleep / bedtime drift - acknowledged as upstream of everything else, still not addressed. Candidate for Q4.
- Whether to share the routine writeup publicly. Decision deferred.
Meeting Notes - Notification Service Datastore Decision
Section titled “Meeting Notes - Notification Service Datastore Decision”Date: 2026-05-13 Time: 2:00pm - 3:15pm Pacific Attendees: Ana Rivera (tech lead), Marcus Chen (senior eng), Priya Shah (PM), Jordan Patel (on-call lead), Sam Okafor (backend eng) Absent: Two backend engineers off-cycle this week (notes shared via #notify-arch)
Decisions
Section titled “Decisions”- Lattice Notify will build the new notification service on Postgres, extending the existing primary cluster with a
notificationsschema and apg_notify-backed job queue. DynamoDB option declined for this release. - A revisit threshold of 5M events/day sustained is set; crossing it triggers a new decision review, not an automatic migration.
- Ana owns drafting ADR-0023 to record the decision and rationale; Marcus has explicit sign-off on the revisit threshold language.
- Decision will be locked at the Ana-Priya 11am sync on Friday 2026-05-16 so sprint planning at 2pm Friday can proceed on the Postgres assumption.
- DynamoDB spike work moves to
experiments/notify-ddb/and is deprecated; no production code depends on it.
Actions
Section titled “Actions”- Draft ADR-0023 (Postgres for notification service) - owner: Ana - due: 2026-05-15 EOD
- Review and approve ADR-0023 revisit threshold language - owner: Marcus - due: 2026-05-15 EOD
- Lock decision in 11am sync, confirm sprint plan - owner: Priya - due: 2026-05-16
- Spec out
notificationsschema andnotification_jobstable - owner: Sam - due: 2026-05-20 - Add
notifications.write_rateand queue depth to the on-call dashboard - owner: Jordan - due: 2026-05-22 - Announce decision in Friday all-hands engineering update - owner: Ana - due: 2026-05-16
- Archive DynamoDB spike to
experiments/notify-ddb/with README explaining context - owner: Marcus - due: 2026-05-19
Open Items / Parking Lot
Section titled “Open Items / Parking Lot”- Whether to provision dedicated read replicas now or after first production traffic - owner: Ana, to be resolved in sprint planning
- Long-term partitioning strategy for the
notificationstable at the 3M events/day mark - owner: Ana, parked until growth data is available - Whether to revisit the decision if the Slack deal closes faster than expected - owner: Priya, will track in the partnership review cadence
Context
Section titled “Context”The team evaluated Postgres vs DynamoDB for a new real-time notification service expected to handle 500K events/day at launch with a potential 10x growth scenario in 12 months tied to a pending Slack-partnership deal. The decision turned primarily on operational capacity (8 backend engineers, 4-person on-call rotation, deep Postgres operational knowledge, no production DynamoDB experience) rather than on access-pattern fit. The team has 3-6 weeks of rework as the recovery cost if Postgres becomes the wrong choice, which the room considered acceptable given the predictability of that recovery.