The FAIM learning communityKnowledge for the journey ahead

Make Team Decisions Visible and Revisable

Use clear decision ownership, lightweight records, and review points to reduce uncertainty in team work.

Make Team Decisions Visible and Revisable

A team can spend a long meeting discussing a problem and still leave with different ideas about what was decided. The difficulty is often not a lack of commitment. It is that the decision, its owner, and its limits were never made explicit. A lightweight decision practice can make coordination easier without adding a large process around every task.

Separate discussion from a decision

At the start of a conversation, say what needs to be decided and who will make the final call. A team might be gathering information, comparing options, or approving a change; those are different activities. If participants do not know which activity is happening, useful suggestions can be mistaken for commitments.

Define the boundary of the decision. Choosing the first release of a feature does not require resolving every possible future use case. State the problem the team is solving now, the constraints it must respect, and the questions it is deliberately leaving open. This helps people contribute without repeatedly reopening unrelated topics.

Record the reasoning in plain language

A decision record can be short. Capture the situation, the chosen action, the main alternatives considered, and the evidence that mattered. Include the person responsible for the next step. Someone who missed the meeting should be able to understand what will happen and where to raise a concern.

Avoid writing a record that makes the choice appear inevitable. If there were tradeoffs, preserve them. A decision to start with a manual review process might reduce implementation time while creating more operational work. Recording that tradeoff helps the team recognize when the conditions have changed enough to revisit the choice.

Turn the decision into an observable next step

  • Name the action and the person responsible for it.
  • State what a reviewable result will look like.
  • Identify dependencies that could prevent the work from starting.
  • Set a review point linked to an event or a meaningful date.
  • Record how a concern should be raised before the action becomes difficult to reverse.

These details are especially useful when work crosses roles. A designer, developer, instructor, and operator may interpret the word ready differently. Define the evidence each person needs rather than assuming a shared label means a shared understanding.

Revisit choices without turning every change into a failure

A reversible decision can be tested on a small scale and reviewed after the team has evidence. A difficult-to-reverse decision deserves more investigation before action. Treating both categories the same can create either unnecessary delay or avoidable risk. Explain why the review effort matches the consequences of the choice.

When revisiting a decision, compare the original assumptions with what happened. Ask whether the result was unexpected, whether the environment changed, or whether the team learned something it could not reasonably have known earlier. This encourages an honest review rather than a search for someone to blame.

Try the practice with one decision this week. Write a few sentences after the conversation and ask the participants whether the record matches their understanding. If they disagree, you have discovered a coordination problem while it is still small enough to resolve directly.