Field notes · 2 min read · Keep commitments
The meeting ends. Keep the decisions and commitments connected.
You remember that the meeting was useful. A week later, you are less certain what everyone agreed to. Was the prototype approved, or only approved for testing? Who was going to check the numbers? Why did the group reject the other option?
The problem sits between meeting notes and the task list. The notes hold the conversation. The task list holds a few commitments. The reasoning that joins them has gone. For why recording the reasoning matters and what the books say, see Write the decision down before you know the outcome.
A two-minute template
Straight after the meeting, write four lines:
- Decision: one sentence specific enough to tell from a different choice. "We will test option B with five users before committing to the full design."
- Why: the reason and the evidence that mattered. "It addresses the largest uncertainty with the smallest investment" beats "everyone agreed".
- Next steps: each with an owner and what done looks like. "Ask James whether option B changes our security review" beats "security follow-up".
- Open question: what you still do not know. "We do not know expected transaction volumes." Do not let it turn into an agreed fact because it appeared in a summary.
If there was no decision, write that. An accurate "we did not decide" is a useful record.
Software teams keep something similar for each significant technical decision. Michael Nygard's "architecture decision record" holds the context, the decision, its status and its consequences on one or two pages, so people who arrive later can see why. A meeting decision needs less, but the same four ideas apply.
Use it before the next meeting
Read the record first. What changed, which commitments are still open, and does the earlier decision still apply? Preparation becomes "check these three points" instead of reconstructing the story. If a decision changes, keep the old wording with the new, because a revision is not necessarily a bad earlier choice; it may reflect new information.
Where Trellis helps, and where it does not
Trellis has Meetings, Decisions and Actions as separate things that stay connected. A Decision holds its statement and rationale, can cite evidence and can link to the meeting, and earlier wording stays in its history. A capture after the meeting can produce all of them in one review, and the meeting's context screen shows earlier decisions and open follow-ups before a repeat meeting. Attendees are plain names, so Trellis does not track who owes what to whom. Put the person's name in the Action's title.
Try this week
- Reserve two minutes at the end of your next meeting, or straight after it.
- Write the four lines above.
- Before the following meeting with the same people, read them first (3 minutes).
Sources
Trellis is not affiliated with or endorsed by the authors below. Each link goes to the original work or its publisher.
- Michael Nygard, Documenting Architecture Decisions (2011) — The short record software teams keep for each significant decision: context, the decision, its status and its consequences, so later readers can see why. Software practice, widely adopted, not studied in controlled trials.
Try one real week.
Keep one important area in view, capture a commitment, and return to what happened.
See how the pieces fit together in a busy week.
Request early access ↗