Define Decision Rights So Escalation Resolves a Specific Question

Overview

Define decision rights by naming the decision, the person authorized to make it, the people whose input is needed, and the conditions that require escalation. Escalation should resolve a specific question that the current owner cannot decide within their authority.

A vague instruction to “escalate when necessary” often produces two problems. Staff either send ordinary decisions upward, slowing the work, or keep consequential decisions too long because they cannot tell when the boundary has been crossed.

Atlassian's DACI framework distinguishes the people driving, approving, contributing to, and receiving a decision. Its roles-and-responsibilities practice helps expose ownership gaps. A team can use those ideas without adopting an elaborate governance system.

Name decisions at the right level

Start with recurring choices that create delay or disagreement. Examples include approving a customer concession, changing a release date, selecting a supplier, or reallocating a specialist between projects.

“Own customer success” is a responsibility area, not a sufficiently precise decision. “Approve a service credit within the agreed policy” describes an action whose authority can be defined.

Avoid making a matrix for every small task. Focus on decisions where ambiguity causes a meaningful consequence or repeated interruption.

The delegation guide helps distinguish an outcome from a method. Decision rights clarify which choices the delegated owner may make while delivering that outcome.

Separate the decision owner from the coordinator

One person may gather evidence, arrange discussion, and maintain the record while another has final authority. Make that distinction explicit.

The coordinator should know what information is needed and when the decision must be made. The approver should know that they are responsible for choosing, not merely offering another comment.

Contributors provide relevant expertise or represent affected work. Their input can be essential without giving each person an undefined veto over the entire decision.

People who only need the outcome should not be required to attend every discussion. Tell them what changed, when it takes effect, and what action they need to take.

Describe authority with boundaries

A decision owner needs to know the conditions under which they can act. Boundaries may concern cost, service commitment, privacy, safety, contract terms, or effects on another team's capacity.

Use concrete descriptions that fit the business. A spending limit may be useful, but money alone may not capture the consequence. A low-cost configuration change can affect many customers.

State what requires consultation and what requires approval. These are different. “Consult operations about capacity” should not become “wait until everyone agrees” unless that is the intended rule.

Where law, regulation, or formal policy assigns authority, the team matrix must respect it. A local working agreement cannot grant powers that the organization does not have.

Write escalation triggers as observable conditions

Useful triggers include a decision outside the owner's authority, conflicting mandatory requirements, a material dependency the team cannot resolve, or an approaching deadline with missing essential evidence.

“Escalate if uncomfortable” may be a helpful cultural invitation, but it does not replace an operating rule. Pair openness to concerns with clear examples of situations that require action.

For a delivery-date change, the trigger might be that the proposed date conflicts with a contractual commitment or requires another team's reserved capacity. For a customer concession, it might be that the requested remedy falls outside the approved policy.

Also define urgent routes. A decision needed within an hour cannot depend on a weekly committee meeting.

Send a decision request, not an unstructured problem

An escalation should contain the current situation, the decision required, relevant options, the consequence of delay, and the evidence available.

A useful request might say: “We need a decision by 14:00 on whether to move the installation or authorize the approved alternative component. The original component is unavailable. The two options have the following cost and customer effects.”

Include the current owner's recommendation where appropriate, with assumptions. This shows the work already done and helps the approver focus on the unresolved choice.

Do not bury the question under a long message history. Link the underlying evidence and provide enough context for a sound decision.

Agree what happens while waiting

Work often continues while a decision is pending. Define which actions may proceed, which must pause, and who communicates with affected people.

For example, the team may continue preparation while holding procurement of a disputed item. Another situation may require pausing the entire dependent task.

Avoid allowing silence to create accidental approval. If a deadline passes without a decision, the fallback should be known in advance: escalate to a backup, use a previously authorized option, or pause the affected work.

Record the cost of waiting where it matters. This helps the decision-maker understand urgency without encouraging exaggerated crisis language.

Prevent conflicting parallel decisions

Cross-functional work can produce several owners who each believe their authority is final. Map the boundary before the conflict becomes personal.

A sales owner may decide commercial terms within policy while operations decides whether a delivery plan is feasible. A sound customer commitment may require both decisions, with a named person integrating them.

If two authorities disagree, identify the specific conflict and the person authorized to resolve it. Do not send the same question to several leaders hoping one gives the preferred answer.

The meeting management system should preserve the resulting decision and rationale. A meeting that produces several interpretations has not closed the issue.

Make remote work explicit

In distributed teams, people cannot rely on overhearing a discussion or noticing that a leader is unavailable. Publish decision channels, expected response windows, and backup ownership.

Use the remote-team working agreements to connect those rules with time zones and coverage. A message marked urgent in one location may arrive outside the approver's working period.

For important decisions, record acknowledgment and the final outcome in a shared system. Chat can carry the alert, but it should not be the only place where the decision exists.

Keep the process proportionate. Routine reversible decisions should not require the same ceremony as a commitment that is difficult to unwind.

Test the rules with recent cases

Take a few real decisions that were delayed or disputed and walk them through the proposed model. Who would have owned the decision? What evidence would they have needed? At what point would escalation have occurred?

Include an absence scenario and a cross-team conflict. These expose whether the model depends on one unusually knowledgeable person always being available.

Revise unclear boundaries with the people who do the work. A matrix written only by senior leaders may miss the choices that actually arise in daily operations.

Then try the rules on new work and inspect whether decisions arrive sooner with adequate evidence. More escalations are not automatically worse if they reveal previously hidden authority gaps.

Keep the outcome traceable

Check backup authority before a planned absence. A substitute may be able to coordinate the discussion while lacking permission to approve the result. The coverage plan should preserve both functions where the decision requires them.

Record the decision, owner, date, main rationale, conditions, and people informed. If new evidence changes the decision, preserve the earlier state and explain what changed.

Review repeated escalations. They may indicate a need for better delegation, clearer policy, more capacity, or a different service promise.

The purpose is a dependable route from uncertainty to an authorized choice. People should be able to act within their role and know exactly what question to send upward when the boundary is reached.