Architecture Decision Records: Template and Best Practices
Implement Architecture Decision Records to document why you made important technical decisions. ADR template, examples, and workflow for software teams.
Developer Productivity
Write meeting notes that drive action. Template, best practices, and workflow for capturing decisions, action items, and context from every meeting.
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:
This guide covers writing notes that matter.
Transcript-style notes capture everything said.
"I think maybe we could probably consider..."
Pages of rambling.
Reader can't extract meaning.
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.
"We should update the docs."
By whom?
When?
Left unclear.
Nothing happens.
Without owners, no one is accountable.
Action items stay open forever.
"We'll use Redis."
Why? Alternatives?
Context is lost.
Decision seems arbitrary later.
Notes stored on someone's computer.
Can't be searched.
Next quarter: "What did we decide about caching?"
Lost.
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)"
What was decided?
Only include actual decisions, not discussions.
Example:
Why this decision?
What problem does it solve?
Example:
What other options were considered?
Why were they rejected?
Example:
What does this decision mean?
What changes?
Example:
Who is responsible?
When should it be done?
Example:
What's still unclear?
What needs follow-up?
Example:
What needs to happen before next meeting?
Example:
What documents support this decision?
Example:
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]
Don't write everything.
Capture:
Don't capture: Every comment, full sentences, rambling
When you hear "We'll do X":
Mark it as DECISION.
Use shorthand:
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.
Within 2 hours of meeting:
Fill in template from skeleton notes.
Why 2 hours? While meeting is fresh in mind.
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]
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]
Action from meeting notes:
Create GitHub issue.
Link from notes to issue.
Action: Bob drafts migration plan
Related issue: [#1234: GraphQL migration plan]
Someone has same question later.
FAQ links to meeting notes + decision memo.
No repeat discussion needed.
"We should update the docs."
Who? No one assigned.
Nothing happens.
Fix: "Carol owns updating docs. Deadline: May 1."
"Improve performance."
Too vague.
What does "improve" mean?
By how much?
Fix: "Bob optimizes database queries to <100ms p99. Deadline: May 1."
Decision hidden in paragraph of notes.
Someone later: "What did we decide?"
Can't find it.
Fix: Use template. Decisions at top. Clearly marked.
Notes on laptop.
Can't be searched.
Can't be shared.
Fix: Store in wiki. Link from README. Make searchable.
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.
Full transcript of meeting.
60 pages of rambling.
No one reads.
Fix: Just decisions, owners, deadlines, open questions. Concise.
Track: % of decisions that have clear owners and deadlines
Goal: 90%+
Track: % of action items completed by deadline
Goal: 80%+
Track: When someone asks "what was decided?" can you find it in 2 minutes?
Goal: Always can find it
Good meeting notes capture decisions, not transcripts.
Essential elements:
How to take notes:
Why it matters:
With good notes:
Without good notes:
For async documentation, see Async Documentation for Remote Teams. For team wiki setup, see Team Wiki Setup Guide.
Capture decisions. Assign owners. Move forward.
More WebSnips articles that pair well with this topic.
Implement Architecture Decision Records to document why you made important technical decisions. ADR template, examples, and workflow for software teams.
Build async documentation practices for remote teams. How to write documentation that answers questions before they're asked and reduces meeting load.
Build a personal documentation system for developers. Capture solutions, architecture decisions, and technical context so you never solve the same problem twice.