Near the end of a design review, fifteen minutes of back and forth ends in "let's go with that." All three people in the call are satisfied.
The short version
| Do this | Why |
|---|---|
| Keep three fields | Decision, assumptions, open. No transcripts |
| Record the meeting | You cannot type while presenting. Extraction can wait |
| Promote heavy decisions to an ADR | One file per decision, with the reasoning attached |
Full minutes fail because they are long. Three fields take five minutes after the call.
What is lost is the rejected option, not the decision
The decision survives. The reasoning does not.
"We went with token-based auth" is recoverable from the code. What vanishes is everything upstream of it:
- Why sessions were ruled out
- Which constraints forced the call (legacy systems, deadline, who operates it)
- Who was uneasy about what
The cost is re-litigating the same call
When reasoning is not recorded, a rejected option comes back around. Nobody is being difficult; the constraint simply was not written down. So the team re-runs the analysis and lands in the same place.
Meeting records are the cheapest available defense against that kind of rework. Trim what you write and the cost approaches zero.
Three lines is enough
Decision, assumptions, open
After a meeting, these three fields carry the load:
## 2026-08-31 Payment retry design review
### Decision
- Exponential backoff, max 3 retries. Attempt 4+ goes to a manual queue
### Assumptions
- Payment API rate limit is 60/min (revisit if it changes)
- SRE handles retries from the manual queue by hand for now
### Open
- Where the manual queue UI lives (decide at the 9/7 review)
Do not skip the open items either. Things that were not decided disappear unless recorded. Naming the date they get decided keeps them from floating.
Decide what you are not writing
Minutes collapse under their own weight. You can leave all of this out:
- Verbatim quotes (who phrased what rarely affects the decision)
- The narrative of the discussion ("A proposed X, then B pointed out...")
- Small talk and status updates (the tracker already has them)
There are moments when a verbatim record matters, and for those, keep the recording. You do not have to type it out.
Share it within 24 to 48 hours
Circulating notes within 24 to 48 hours of the meeting lets people correct misunderstandings while memory is fresh. Past that window, corrections stop arriving and whatever you wrote becomes the official version, mistakes included.
With three fields you can write it immediately after the call, which is also when it is easiest.
Promote hard-to-reverse decisions to an ADR
What an ADR is
The minimal template, known as the Nygard format, has five parts:
| Field | Content |
|---|---|
| Title | The decision, stated briefly |
| Status | Proposed / accepted / deprecated / superseded |
| Context | The background and constraints that forced a decision |
| Decision | What was chosen |
| Consequences | Upsides and downsides that follow |
If you want the alternatives compared explicitly, the MADR 4.0 line of templates (published September 2024) structures the options side by side.
ADRs are not a personal habit. Microsoft's Azure Well-Architected Framework treats maintaining them as an architecture practice, which is useful ammunition when you propose the idea to a team.
Never edit one, supersede it
An ADR is not revised. When a decision is overturned, write a new ADR and mark the old one superseded.
Not every meeting produces one
| Kind of decision | Where it goes |
|---|---|
| Auth scheme, datastore choice, API contract, async strategy | ADR |
| Library upgrades, naming conventions, retry count tuning | The decision field in your notes |
| Task assignments, review scheduling | Tracker and calendar |
Almost everything from a weekly sync fits in three lines. One or two ADRs a month is already a lot. Without that filter, writing ADRs becomes theater.
Start from the fact that you cannot take notes during the meeting
Whoever is presenting has no hands free
You share your screen, walk through code, answer questions and sketch a diagram. Typing notes in that state is not possible. "Let's assign a notetaker" means, in a three-person review, removing one third of the discussion.
The predictable result: the meetings that produce the most decisions are the ones with the least record.
Record it, extract afterwards
A recording keeps things an audio-only note would drop:
- Diagrams drawn on a whiteboard or a canvas tool
- Shared code and the diff on screen
- Reproduction steps and the error output
- What "this part, here" was actually pointing at
Design discussions rarely stand up as words alone. "Let's split this function" is unreadable later without the screen it referred to.
Doing this on a Mac
- Screen and audio recording are free with no time limit, and no watermark
- Your voice and the other side's audio are both captured with no virtual audio driver (no BlackHole setup)
- On the Pro plan, AI generates minutes from the recording. Templates are configurable, so setting it to output "Decision / Assumptions / Open" cuts the extraction work further
- Generated minutes can be sent straight to Notion
Pro is free for the first month, no credit card required.
One caveat: Qureco is macOS only, with no Windows or Linux version, and it does not show live captions during a call. It is built on the assumption that you use the recording after the meeting, not during it.
Say one sentence before you start recording. "I am recording this to write up the notes" is enough. Internal reviews almost never object, and stating it makes sharing easier afterwards.
Keep the pieces in different places
Three-field notes and ADRs work better stored separately.
| What | Where | Why |
|---|---|---|
| ADRs | In the repo (docs/adr/0001-xxx.md) | Reviewed and versioned alongside the code |
| Three-field notes | Notion or your docs tool | Non-engineers read them; you search them later |
| The recording itself | Cloud, linked from the notes | Large files. Only some people need to open them |
Starting at tomorrow's review
- Say one sentence and start recording ("recording this for the notes")
- Stay in the discussion. Take no notes
- Afterwards, write the three fields (five minutes; open the recording only where needed)
- Share it the same day. Fix whatever people correct
- If a hard-to-reverse decision came up, write one ADR and link the meeting notes
For the first week, steps 3 and 4 are plenty. ADRs can wait until a decision actually calls for one.
FAQ
How do I tell people I am recording?
How is an ADR different from a design doc?
A design doc proposes and circulates the design of something you are about to build. An ADR records one decision and its reasoning. Work through a design doc, and when a significant decision falls out of it, split that into an ADR.
Who should write the notes?
With only three fields, you no longer need a designated notetaker. Accuracy is highest when whoever presented writes them afterwards. Given that a recording exists, "whoever noticed writes it" works better than a rotation.
Is an AI summary enough on its own?
How do I track the open items?
Write them in the notes, then create tickets for anything with a date. "We will decide next review" alone tends not to make it onto the next agenda.
Does this change for in-person meetings?
What if I develop on Windows?
The three-field notes and the ADR practice are OS independent. Only the recording tool needs to be something that runs on Windows.
Glossary
| Term | Meaning |
|---|---|
| ADR | Architecture Decision Record. One architectural decision and its reasoning, one file each |
| Nygard format | The minimal ADR template: title, status, context, decision, consequences |
| MADR | An ADR template that structures the compared options. The 4.0 line was published September 2024 |
| Superseded | Status marking an old ADR replaced by a newer one rather than edited |
| Design doc | A document proposing the design of something to be built. Broader scope than an ADR |
| Assumption | A condition the decision depends on. If it changes, the decision is revisited |
| Open | Something the meeting did not settle, recorded with the date it will be |
Summary
- What a meeting loses is not the decision but the rejected option and its reasoning, which is why the same debate returns
- Keep three fields: decision, assumptions, open. Skip transcripts and narrative
- Share within 24 to 48 hours so misunderstandings get corrected while memory is fresh
- Promote only hard-to-reverse decisions to an ADR, and supersede rather than edit
- In a design review you are presenting and have no hands free, so record it and extract the three fields afterwards
Minutes do not fail for lack of discipline. They fail because there is too much to write. Cut it to three fields, hand the rest to a recording, and the practice survives past tomorrow's review.
Qureco Screen Recorder
Powerful screen recording app for Mac
Record meetings, let AI handle the notes, just read what arrives in Notion.
Try all features free for the first month.
