Review your decisions, not your calendar

A typical periodic review–be it for yourself, your team, or your org–often ends up looking something like:

• set a date for a review meeting
• everyone involved looks back at their calendar and tries to remember and piece together what they did since the last review
• if there’s benchmarks or set goals to compare against, reframe the outcomes of the last time period to fit a desired narrative around those benchmarks or goals
• have a meeting and possibly come up with next actions based around the intersection of those narratives, which are based entirely on outcomes

This isn’t the worst thing for taking the pulse of an organization as a whole, but it’s really not ideal for actually learning whether or not you and your teams’ decisions are good ones.

Instead, consider basing your review structure on the decisions themselves, not just “what happened last quarter”. You can do this by:

• recording when you and your team reach a consensus on a decision–be it around architecture (for which a fair amount of documentation on decision records exists), communications, assignments, goals, etc.–and capturing the context, justification, and expected outcomes, along with the team’s confidence in those outcomes.
• setting a date to loop back and review the decision
• have a meeting on that date, to wit:
  • what were the actual outcomes of this decision?
  • was that good, bad, in between, or something else?
  • how much of that was luck? how much of that was skill?
  • what did we misjudge given the information and context at the time, if anything?

This won’t make for clean, date-aligned columns in a periodic report, but you’ll actually learn from your decisions.