Free Quarterly Decision Review Template

A quarterly decision review is a structured look back at the decisions a team made in the last three months. Not a retrospective — retros focus on process and feel. A decision review focuses on the calls themselves: which ones were correct, which ones were premature, which ones the team avoided when they should have made them. It is one of the highest-leverage governance practices an engineering team can adopt, and almost nobody does it.

The template below assumes you have been writing decision records (see the async decision documentation template). Without a list of decisions to review, this exercise becomes a memory test and degrades into the same vague "things felt rushed" that retros produce. With the record, it becomes a calibration exercise: were we right? Were we right for the reasons we wrote down? What does our hit rate look like over time?

When to use it

• End of every fiscal quarter, two to three hours blocked on the team calendar.
• After a major release, in addition to the regular cadence.
• When a new leader takes over the team and needs to inherit the decision history.
• When the team is considering a process change — review the past first, propose the change second.

The template structure

This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.

QUARTERLY DECISION REVIEW — [team name]
Quarter:    [Q? YYYY]
Date:       [date of review]
Attendees:  [names]
Facilitator: [name]

PART 1 — INVENTORY
  Total decisions recorded:       [N]
  Decisions still in effect:      [N]
  Decisions superseded:           [N]
  Decisions deferred / abandoned: [N]
  Decisions made informally
    (no record, surfaced later):  [N]

PART 2 — REVIEW EACH DECISION
  For each decision recorded last quarter, fill the row:

  Decision     | Outcome so far | Right for the right reason? | Notes
  -------------+----------------+-----------------------------+-------
  [title]      | [good/bad/ttd] | [yes/partial/no]            | [...]
  [title]      | [good/bad/ttd] | [yes/partial/no]            | [...]

  "Too early to tell" is a valid outcome; flag it for next quarter.

PART 3 — PATTERNS
  Decisions we made too quickly:
    - [example]
  Decisions we delayed too long:
    - [example]
  Decisions we made without a record:
    - [example]   (why? was the record the right tool?)
  Decisions that surprised us in outcome:
    - [example]

PART 4 — DECISIONS WE SHOULD HAVE MADE BUT DIDN'T
  - [topic] — should have been decided by [when]
  - [topic] — still unresolved, decider: [name], by: [date]

PART 5 — DECIDER LOAD
  Who is named "decider" most often?
    - [name]: [N] decisions
    - [name]: [N] decisions
  Is the load distributed appropriately?
  Is any decider also the bottleneck?

PART 6 — ACTIONS FOR NEXT QUARTER
  [ ] [specific action with owner and date]
  [ ] [specific action with owner and date]
  [ ] [specific action with owner and date]

NEXT REVIEW: [date]

How to use it well

• Inventory first, judgment second. Count the decisions before evaluating them. A team that thinks it made twenty decisions and actually made eight is a team that should write more decisions down, not change its decisions.
• "Right for the right reason" is the load-bearing column. A decision that worked out for reasons unrelated to your stated rationale is luck, not skill. Track the distinction. Over enough quarters it reveals whether your team is reasoning well or rolling well.
• Decider load is the most actionable section. If one person decides 80% of everything, you have a single point of failure and a development bottleneck. The fix is to push specific decision classes down, which the decision authority map is designed for.
• Decisions-we-should-have-made are the highest signal. Avoided decisions cost more than wrong decisions. A team that knows it should have picked a vendor in Q1 but didn't is operating on default-by-inaction.
• Two to three hours, not an afternoon. A four-hour decision review degrades into a retro about feelings. Time-box hard.

What to skip

Skip blaming individuals for decisions that went sideways. The point of the review is calibration, not accountability. Decision records already have a "decider" field; if there is a pattern of bad calls from one person, that is a 1:1 conversation, not a team review item.

Skip the temptation to re-litigate every decision. The point is to look at the set, not the items. Spending forty-five minutes on one decision means the next twelve get five minutes each, which is worse than the original problem.

Frequently asked questions

Is this template free?

Yes. The template above is the whole structure. Run it as a Notion doc or a working session in any tool your team uses.

Can I edit it?

Yes. Many teams add a Part 7 for upcoming-quarter decisions to schedule them ahead of time. Others drop Part 5 if their team is too small for decider-load to be meaningful.

Do I need to give my email?

No. The structure above is the template; the email is only for the downloadable polished version.