What is a decision-making meeting?

When does a decision need a meeting?

Meet when people need to weigh a trade-off together, settle conflicting constraints or work through a serious objection. A simple choice with agreed criteria can be settled in a shared document.

Jeff Bezos's 2016 letter to Amazon shareholders makes a related point. Many decisions can be reversed, and those deserve a light process. Our advice: send the question and evidence first, so people can judge whether a live discussion is needed.

Keep the question narrow. “What should our launch strategy be?” hides several decisions. “Should we launch to the pilot group this month, or wait for the onboarding changes?” is one you can actually settle.

Who makes the call?

Agree how the decision will be made before you compare options. It might be one accountable person, consensus or a vote. The experts in the room are not always the people allowed to approve.

One option is Atlassian's DACI framework. A Driver runs the process, one Approver decides, Contributors add expertise, and Informed people hear the result. Whatever you use, write it in the meeting brief.

• Invite people whose evidence could change the choice.
• Confirm any approvals the group cannot give itself.
• Tell affected colleagues where they will hear the outcome.

Agree on the criteria before arguing for an option

List the constraints that matter and mark which are requirements and which are preferences. For a launch, support readiness may be a requirement while extra features are a preference. Treat them alike and the group can argue without ever reaching the real constraint.

Label estimates and unknowns. A projected workload is not measured demand. A missing test result does not prove a feature works. If someone adds a new criterion mid-meeting, check whether it changes the decision before you compare the options again.

Example: launch now or wait?

In this made-up example, a small team is deciding when to release a revised onboarding flow to a pilot group. The table is a starting point for discussion, not a recommendation.

• Say which evidence supports each option.
• Ask what would make the preferred option unacceptable.
• Resolve any critical unknown before calling a choice approved.

What should the decision record say?

Write a short record an absent colleague can understand. It should give the question, the choice, who decided, the reason and any conditions. Add the next action and its owner, and link to the evidence instead of pasting it in.

For the pilot example, the team picks the third option. The record reads: “Decision (product lead): release the ready onboarding steps to the pilot group and hold back the unfinished step. Why: we learn from real users sooner.

Condition: support confirms cover for the manual step; Priya owns that check. Without cover, the release waits.”

What if the group cannot decide?

Sometimes a good meeting shows the decision isn't ready. Name the missing information, who will get it and when the choice comes back. “More discussion needed” just moves the same uncertainty to the next meeting.

If the right decision maker isn't present, send them the recommendation. If people disagree about acceptable risk, say that plainly. Once the choice is made, share it with everyone who has to act on it.