Name the decision owner before the meeting

Name the decision owner before the meeting. Tell participants who will make the call, what choice is in scope, what authority that person has and what input they need from the room.

Without that clarity, people optimise for different processes. One person thinks the meeting is advisory, another expects consensus, and a third assumes an executive outside the room will approve the result later. A thoughtful discussion can still end with no legitimate decision.

Define the decision before choosing the owner

“Leon owns launch” is too broad. Ownership only becomes useful when it is attached to a specific choice.

Write the decision as a question with bounded options:

Should we release the onboarding change to the pilot group on 5 October, delay it for one cycle, or reduce the pilot scope?

Now the owner can be named against real authority. The person who controls the release may own the date and scope, while somebody else owns pricing, staffing or a contractual exception.

Avoid giving one meeting a false umbrella decision such as “finalise the launch.” Break it into separate calls when different people have authority over different parts. Otherwise the room may settle one question and mistakenly report that it settled all of them.

State what kind of authority the owner has

The invite should make the decision process visible. Common versions include:

• owner decides after input: participants advise; the owner makes the call;
• owner recommends: the meeting produces a recommendation for a named approver;
• owner decides within limits: the owner can choose within a budget, policy or scope boundary;
• group consent is required: named participants must all agree, or a defined objection can block the call.

These are not interchangeable. A person who can recommend but not approve should not be presented as the final owner. A facilitator who gathers views should not become the owner merely because they scheduled the call.

If the true decision-maker cannot attend, decide whether the room can prepare a recommendation or whether the meeting should move. Do not imply that a group vote can substitute for authority it does not have.

Tell participants what input they own

One decision owner does not mean one person does all the thinking. The meeting works when each participant understands why their perspective is needed.

For the onboarding decision:

• support identifies the workload the options create;
• engineering tests feasibility and dependencies;
• research explains what the pilot evidence does and does not show;
• finance confirms any spending boundary;
• the decision owner weighs those inputs and states the call.

Put the requested input in the invite or pre-read. This keeps expertise from turning into an undeclared veto and prevents seniority from becoming the only voice the owner hears. The related practice is to give every pre-read a question and a reading lens.

Participants also need permission to say that their input is not ready. Missing evidence can be a legitimate reason to defer. It should become an explicit gap with an owner and return point, not a vague feeling that more discussion is needed.

Put the role in the invitation

Do not keep the decision structure in the organiser's head. A practical invite can use four lines:

Decision: Pilot on 5 October, delay one cycle, or reduce scope.

Decision owner: Leon, product lead.

Authority: Leon decides within the approved pilot budget; security exceptions require Mira's approval.

Input needed: Support capacity, engineering dependencies and unresolved security risk.

This changes how people prepare. It tells them whether they are bringing evidence, making the call or representing a required approval. It also exposes missing roles early. If Mira's approval could be required but she cannot attend, the organiser can narrow the decision or arrange the approval path before the meeting.

The invitation should match the meeting record. Scripta lets teams keep the objective, agenda, participants, notes, decisions and resulting action items together. It does not infer organisational authority; the organiser must state that truth.

Let the owner close the discussion

During the meeting, the facilitator manages the process, but the decision owner should close the question.

A useful close has three parts:

1. state the decision in an active sentence;
2. give the central reason and the trade-off accepted;
3. name any condition or trigger that would prevent execution or reopen the call.

For example:

We will run the smaller pilot on 5 October. It gives support a manageable starting group while preserving the learning we need. The release depends on the security review closing by Friday; if it does not, the pilot moves one cycle.

That statement gives the note owner something durable to record. “It sounds like we are leaning toward the pilot” does not.

The facilitator should then use a short read-back to confirm the decision and resulting commitments. If the owner decides against serious advice, preserve the objection and response without turning the outcome back into an open debate.

Do not confuse ownership with immunity

A decision owner is accountable for a process, not entitled to ignore constraints.

The role does not override legal, security, contractual or ethical obligations. It does not let the owner invent facts, suppress material objections or claim authority somebody else holds. It also does not transfer execution work automatically: the person who makes the call may assign actions to others only through a clear, accepted handoff.

Good ownership is visible enough to challenge. The record should show who decided, the reasoning, the material evidence and any agreed revisit trigger. That is what makes the call inspectable later instead of merely final in the moment.

This is why a durable decision record needs more than the outcome. The guide to writing a decision record that survives covers the context a future reader will need.

Cancel or redesign meetings with no owner

If you cannot name the decision owner, do not describe the session as a decision meeting.

Choose an honest alternative:

• run a working session to develop options;
• gather evidence asynchronously;
• ask a named leader to assign authority;
• prepare a recommendation for the real approver;
• cancel the meeting until the decision path exists.

This may feel slower than putting everyone in a room. It is usually faster than discovering after an hour that the group produced an unauthorised answer.

The purpose of naming the owner is not hierarchy for its own sake. It gives the meeting a legitimate way to end. People can disagree, contribute specialist judgment and still know who must turn the discussion into a call.