Business
Decision rights: who can decide, advise and act?
Stefan Weiss
Decision rights define who is authorised to make a particular decision, within which limits, and who must contribute before that decision can take effect. They answer a practical question: when discussion ends, who can commit the team to a course of action?
A person can own a task without having authority to approve the decision behind it. A specialist can provide essential advice without having a veto. A manager can be accountable for an area without needing to approve every choice inside it. Making these distinctions explicit is the purpose of assigning decision rights.
This guide explains the concept through everyday project decisions: how to define the boundary, distinguish the roles and record what was actually agreed. It is an operational approach for teams, not a substitute for an organisation's formal governance or approval requirements.
Why a job title or meeting invitation is not enough
“Marketing owns the launch” may describe several different responsibilities. It could mean preparing the campaign, choosing the launch date, approving the budget or coordinating work after someone else approves the plan. Those are separate decisions and tasks.
A meeting can include everyone with an interest in the launch and still leave authority unclear. One person leaves believing a recommendation was accepted; another thinks the group merely explored an option. The missing information is not another set of minutes. It is a clear statement of who may decide what.
Harvard Business School's discussion of how organisations allocate decision rights highlights the need to make authority explicit and review its allocation as circumstances change. It also describes the trade-off between placing decisions near relevant knowledge and moving information to a more central decision maker. That is a useful question for a small project team as well as a large organisation: does the person with authority have the information needed to use it?
Start with a decision, not a department
A useful decision has a specific object and boundary. “Customer experience” is too broad. “Choose which two onboarding changes enter the next four-week pilot” gives the team something it can assign.
Define four things before naming the decision maker:
The choice: what is being selected, approved, stopped or changed?
The scope: which customers, work, resources or time period does it cover?
The limits: what may the decision maker commit, and what requires separate approval?
The deadline: when must the decision be made, and what happens if it is not?
For example, a product lead might be authorised to choose the pilot's two changes within an agreed engineering allocation. That does not automatically include permission to increase the budget, promise a delivery date to a customer or expand the pilot to all accounts.
Write those exclusions alongside the authority. A limit hidden in another person's understanding is difficult to apply consistently.
Distinguish the roles around the decision
There are several legitimate ways to organise decision roles. Bain's Decision Rights Tools separates recommending, agreeing, performing, providing input and deciding. Its approach gives one decider final accountability and uses formal agreement roles sparingly. The value is the distinction between contributions; a team does not have to introduce new acronyms to make those contributions clear.
For a practical conversation, ask the following questions.
Who makes the final choice?
Name the person or the formally authorised decision-making body. If your organisation requires a committee, clarify the rule by which that committee decides and who communicates the outcome. Do not quietly replace an established governance process with an individual owner because a diagram looks simpler that way.
For routine project choices that can be delegated to one person, make the delegation explicit. “Prepare a recommendation” and “choose an option within these limits” are different instructions.
Who prepares the recommendation?
Someone needs to gather the relevant evidence, compare the alternatives and bring a clear proposal. That person may also be the decision maker, but the roles need not belong to the same person.
The recommendation should show the trade-offs and unresolved questions. It should not gain the appearance of approval merely because it is detailed or well presented. A decision memo can organise the proposal; the approval still needs to come from the authorised person or process.
Whose input is required?
Name the people whose knowledge is needed and the question you need them to answer. “Consult engineering” is less useful than “ask the engineering lead to assess whether either option exceeds the agreed allocation”.
Set a time for input and a route for raising missing evidence. Avoid treating every invited attendee as an approver. Equally, do not treat a missed reply as consent unless an explicit, applicable process says that is how the decision works.
Who must approve a particular condition?
Some decisions require a separate approval for a defined reason. State that reason and its boundary. For example, an existing budget policy may require a different approval if the proposal exceeds the agreed allocation.
A bounded approval is easier to interpret than an undefined right to block any part of the plan. If two authorities conflict, escalate the conflict before promising an outcome. A meeting facilitator cannot resolve it simply by rewriting the notes more decisively.
Who carries out the result?
The people doing the work need to understand the decision and any conditions attached to it. Involve them early enough to reveal practical obstacles, then assign implementation tasks after the decision is clear.
An implementation owner does not acquire broader approval authority just because their name appears beside an action item. This distinction matters when a task changes: carrying out an agreed pilot is different from approving a larger rollout.
A worked example: choosing the next onboarding pilot
The following is an illustrative scenario, not a customer story.
A team has three possible onboarding improvements. It can implement two during the next four weeks using an already agreed allocation. The product lead is authorised to choose the two changes. The researcher prepares the evidence, the engineering lead assesses effort, and the customer team explains the support implications.
The team could describe the arrangement in plain language:
The product lead chooses two changes for this four-week pilot within the existing allocation. Research provides the evidence and engineering confirms the effort estimate before the choice is made. Any increase in allocation requires the existing budget approval process. The delivery lead coordinates implementation after the choice is recorded.
This statement leaves room for disagreement about the best option while making the authority clear. It also distinguishes an input that informs the decision from a condition that constrains it.
Suppose the engineering estimate later shows that one proposed change exceeds the allocation. The product lead can choose a different combination within scope or seek the additional approval. The delivery lead cannot solve the authority problem by adding the extra work to the task list.
Suppose instead that the researcher disagrees with the final choice. The decision maker should address the evidence and record the material trade-off. Disagreement is not automatically a veto, but it should not disappear from the record either.
Decision rights, decision criteria and decision logs do different jobs
These three ideas work together, but each answers a different question.
Decision rights concern authority: who can make this choice and under which conditions?
Decision criteria concern evaluation: what will be used to compare the alternatives? Agreeing decision criteria can make the reasoning easier to inspect, but a score does not grant authority to whoever calculated it.
A decision log concerns the record: what was decided, why, by whom and when? A decision log preserves the outcome and its context. It does not create permission retrospectively.
If the team has a beautifully written log but nobody can explain who approved the decision, the record needs clarification. If everyone knows the approver but the options are being judged differently, work on the criteria. Diagnose the missing part before adding another document.
Use meeting evidence to clarify authority carefully
A recording can help you recover an explicit delegation, a constraint or the point at which someone approved a proposal. It can also reveal that the group never resolved the question. The aim is to make the evidence visible, not to make an ambiguous conversation sound settled.
When reviewing notes or a transcript, separate statements such as:
“Please bring us two options” — a request for a recommendation.
“You can choose either option within the agreed allocation” — an explicit delegation with a boundary.
“That sounds promising” — encouragement that may still need clarification.
“Proceed with option B, provided the estimate stays within the allocation” — a decision with a condition.
The wording and context matter. These examples are interpretive aids, not automatic rules that establish authority in every organisation.
Weeve can help review saved recording content and prepare a sourced account of what was said. A useful request is: “Find explicit statements about who may approve the pilot, any limits and any unresolved disagreement. Distinguish proposals from decisions and cite the supporting passages.” Review those passages before using the result in the team's working record. If you use an optional external provider, check the selected integration's data-handling settings before including sensitive material.
This genuine demonstration capture shows a task-owner table. Those assignments describe work; they do not establish who authorised the underlying decisions.
A generated document cannot confer decision rights, resolve conflicting governance or turn an implied preference into approval. If the source is unclear, ask the relevant authority to confirm the boundary and record that confirmation through the team's normal process.
Keep the arrangement useful as work changes
Review decision rights when scope, staffing, resources or dependencies change. A temporary delegation should have a clear end or review point. An absent decision maker needs an agreed cover arrangement, not an assumption that the most available person inherits their authority.
You can check whether the arrangement is clear by asking the recommendation owner, decision maker and implementation owner the same three questions:
What can be decided without further approval?
Which condition would require escalation, and to whom?
How will everyone know that a decision has been made?
Different answers reveal something concrete to resolve. Once they agree, put the short authority statement where the team already works and link it to the decision record. The useful outcome is a shared understanding of who can act, within what limits, and on which evidence.
