Ask a team why a piece of work is late and the first answers are usually about capacity: too many priorities, not enough people. Keep asking and a different pattern often appears. The work was ready. It was waiting for a decision, and it was not clear who could make it.
Unclear decision rights are one of the most common and least visible causes of slow execution. They rarely appear on a risk register because they do not look like a problem. They look like a meeting that ends with "let's take this offline," an approval that sits for a week, or a decision that gets made, reopened, and made again.
How it shows up
- Decisions escalate by default. Items go to senior leaders not because they need senior judgment, but because nobody below them is sure they have the authority.
- Decisions get relitigated. A choice made in one meeting is reopened in the next because someone who expected to be consulted was not.
- Approvals stack up. A request needs four signatures, and none of the four people knows what the others are checking for.
- Silence is treated as agreement, until it is not. Work proceeds on an assumption, and a stakeholder objects after the fact.
Each of these costs time. Together they can add weeks to work that should take days, and they wear on the people doing the work, who learn that taking initiative is risky.
Why it happens
Organizations rarely set out to be unclear. Decision rights drift for ordinary reasons. The organization grows, and decisions one founder used to make are now spread across a leadership team without anyone deciding how. A reorganization moves reporting lines but leaves the old approval steps in place. A new program crosses several departments, each with its own authority, and nobody is assigned to decide across them. Informal habits fill the gap, and they work until the person who held the habit leaves.
Map the recurring decisions
The fix starts with a short list. Identify the decisions that recur and matter: approving spend above a threshold, changing a project's scope or schedule, accepting a risk, hiring into a role, signing a contract, releasing a deliverable to a customer. Most organizations can name fifteen to twenty that account for the majority of their delays.
For each one, answer four questions:
- Who decides?
- Who must be consulted before the decision is made?
- Who needs to be told afterward?
- At what threshold does the decision move up a level?
Frameworks such as RACI give this a structure, but the framework matters less than the conversation. The value comes from getting the people involved to agree, out loud, on answers they had each been assuming differently.
The value of the matrix comes from the conversation that produces it.
Set thresholds, not just names
The most useful decision rights are conditional. A program manager might approve schedule changes of up to two weeks, with anything larger going to the sponsor. A department head might approve purchases up to a set amount, with finance reviewing anything above it. Thresholds let routine decisions move quickly while keeping leadership involved where the stakes justify it. They also make escalation predictable, so nobody has to guess.
Put it where the work moves
A decision rights matrix that sits in a shared folder changes nothing. It has to be built into the places where work actually moves: the intake form that routes a request, the approval workflow in the system, the agenda of the weekly leadership meeting. When a decision is made, record who made it and when, so it is not reopened without a reason.
Review it after ninety days. Some thresholds will be too low and send too much upward. Some decisions will turn out to need a consultation step that was missed. Adjust them. Decision rights are part of the operating model, and like the rest of it they should change as the organization does.
Where to start
Pick one area where work regularly stalls and trace the last few items that were delayed. For each, find the moment it stopped moving and ask who needed to act. In most cases the answer points to a decision without a clear owner. That is the first entry in the matrix, and usually the first place the work speeds up.
A working template for this exercise is in the library: the Decision Rights Map.