Decision rights: the thing most organisations never write down

I've sat in a lot of meetings that felt like reruns. Same faces, same tension, same unresolved question about who actually gets to decide something. After a while I started noticing the pattern wasn't about the people or even the topic — it was structural. The organisation had never written down who owns which decisions, so every decision became a fresh negotiation. This post is my attempt to lay out what decision rights actually are, why leaving them implicit is so costly (in ways that are easy to dismiss until they aren't), and a simple framework I use with clients to make them explicit without launching a six-month governance programme. I'm still refining parts of this, so treat it as a working note rather than a finished doctrine.

what decision rights actually are (and aren't) ¶

A decision right is an explicit assignment: this person or role has the authority to make a specific category of decision, within defined constraints, without needing approval from above. That's it. It's not a RACI (though the two are cousins). It's not an org chart. It's not a policy. It's a sentence — sometimes literally one sentence — that says 'the regional marketing lead decides campaign spend up to £20k without sign-off from the CMO.' What it isn't is a vague norm like 'the team handles day-to-day stuff.' That vagueness is where the rerun meetings live. The distinction that matters most: decision rights define who decides, not just who is consulted or who does the work. Those are different things, and conflating them is the root of most of the dysfunction I see.

the real cost of leaving them implicit ¶

The obvious cost is slowness. Decisions that should take a day take two weeks because nobody's sure who needs to sign off, so the default is to escalate, then schedule a meeting, then wait for diaries to align. But I think the less visible cost is actually larger: implicit decision rights train people to stop deciding. If you've been overruled once or twice when you thought you had authority, you learn to check upward, even when you don't need to. That learned helplessness compounds. Senior leaders end up in the weeds on things they shouldn't touch; the people closest to the work stop trusting their own judgment. I watched one mid-sized organisation spend eleven weeks deciding on a vendor for a £8k software tool because nobody was sure whether IT, Finance, or the business unit owned the call. Eleven weeks. The tool cost less than the meeting time spent debating it.

why organisations don't fix this (the honest version) ¶

Partly inertia — if the implicit system more or less works, there's no burning platform. Partly because writing decision rights down feels like it will start a political argument (it sometimes does, briefly). But the deeper reason, I think, is that vague authority is comfortable for people who currently benefit from being the informal escalation point. If every ambiguous decision lands on the CTO's desk, the CTO has information and influence that doesn't show up on any org chart. Making rights explicit can feel like a demotion even when it isn't one. I've had leaders tell me directly that they want decisions documented — and then drag their feet at the exact moment we mapped a domain they'd been quietly controlling. That's not hypocrisy; it's just human. It's worth naming it openly when you run this kind of work.

a lightweight framework: four questions, not a six-month project ¶

The approach I keep coming back to is simple enough to run in a half-day workshop. For any decision domain (hiring, budget, product roadmap, vendor selection — pick the ones causing pain), you answer four questions. One: what is the decision, described concretely enough that two people would agree whether a given choice falls inside or outside it? Two: who decides — one named role, not a committee? Three: what constraints bound the decision (a spend threshold, a policy ceiling, a strategy document)? Four: who needs to be informed after the decision is made, and by when? That's the whole structure. You can capture it in a simple table. I usually start with the five or six decisions that have caused the most friction in the last quarter — those are the ones where implicit rights are obviously broken. Fix those first. Don't try to map every decision in the organisation at once; you'll never finish and the artefact will go stale before anyone uses it.

the difference between deciding and recommending (it matters more than you think) ¶

One thing I always surface explicitly: the role of recommender is different from the role of decider, and treating them as equivalent is a common failure mode. A good recommendation process — where the person closest to the work gathers options, assesses trade-offs, and proposes a path — is genuinely valuable. But the recommender doesn't decide. Conflating the two means either the recommender feels disempowered when their recommendation is changed, or the decider rubber-stamps whatever comes up and stops adding value. The framing I find useful is: the decider is accountable for the outcome, so they need enough information to make a real choice, not just ratify. If a decider is always saying yes to the recommendation, ask whether the decision right is sitting in the right place or whether it should be pushed down.

making it stick: a few things that actually help ¶

Writing down decision rights is the easy part; getting people to use them is harder. A few things I've seen work. First, reference the document when a decision comes up — out loud, in the meeting. 'According to what we agreed, this one belongs to Priya. Priya, what's your call?' That repetition builds the habit faster than any training. Second, treat the first version as explicitly provisional — say it has a three-month review date. This lowers the political temperature enormously because people don't feel like they're signing away influence permanently. Third, when someone escalates a decision that should have been made at a lower level, don't just answer it. Ask why it came up. Is the right unclear? Is the constraint wrong? Is the person lacking information they need? Fix the system, not just the instance. The goal is that after six months, people stop escalating things they shouldn't escalate — not because they're told not to, but because they trust the structure.

where this connects to broader organisational design (a note for later) ¶

Decision rights don't live in isolation. They're downstream of your operating model — how you've structured teams, where you've drawn accountability lines, what your strategy actually requires in terms of coordination versus autonomy. A highly interdependent product (where changes in one area break things in another) needs tighter coordination rights than a portfolio of independent business units. I keep meaning to write a longer piece on how decision rights interact with team topology thinking (Skelton and Pais's work is useful here) and with the kind of mission-command framing the military uses. For now I'll just flag it: if you map decision rights and they look wrong, the answer might not be to redraw the rights but to rethink the structure underneath them. Sometimes the rights are trying to tell you something about the design.

If any of this is resonating, the most useful thing you can probably do this week is pick one decision that has caused friction more than once in the last two months and write down the four answers I described above — decision, decider, constraints, inform. Show it to the people involved and see what they push back on. The pushback is the data. I'm at the point where I think most organisational dysfunction I see is really a decision rights problem wearing a different costume, and I find that strangely hopeful — because decision rights, unlike culture or leadership style, are something you can actually write down and change.