Frameworks

Who actually decides in your company? The one-hour decision rights audit

Most companies have a decision system that grew instead of being designed. People spend real energy every week guessing where the line is: escalating things they could decide, deciding things that should have come up, and waiting on calls that belong to nobody. Here is a two-question test that exposes it, the three ways decision rights fail, and a one-hour audit to fix them.

Szilard Kacso · 7 min read

Here is a test you can run today, with no budget and no consultant. Ask two people on your team, separately: "What should you bring to me, and what should you decide yourself?" Then compare the answers.

In most companies I work with, the answers don't match. Not because people are careless, but because nobody ever defined the line. Meetings multiply. The founder becomes the bottleneck. And everyone quietly assumes this is a people problem. It isn't. It's an architecture problem, and it has a name: decision rights.

TL;DR
  • Decision rights are the explicit allocation of decisions: one named owner per decision, a known escalation line. Most companies never wrote them down.
  • The two-question test: ask two people separately what they should bring to you vs decide themselves. Mismatched answers mean the line is being guessed.
  • Three failure patterns: decisions pool at the top, accountability blurs across, the escalation line stays unwritten.
  • The cost is measured: in McKinsey's global survey, only 46% of respondents rated their organizations' delegated decisions as high quality, against 65% for big-bet decisions.
  • The fix takes an hour: ten recurring decisions, one name each, an explicit escalation trigger, said out loud.

What are decision rights?

Decision rights are the explicit allocation of decisions in an organization: who owns each decision, who contributes input, who must be informed, and which decisions escalate upward. When decision rights are designed, every recurring decision has one named owner and a known escalation line. When they're not, the same decisions get made by whoever is loudest, most senior, or simply in the room.

Simply put: your org chart says who reports to whom. Decision rights say who decides what. These are not the same document, and in my experience the second one usually doesn't exist. Titles describe status; decision rights describe authority. A company can have a clean org chart and a chaotic decision system at the same time, and most do.

This matters because decision rights sit underneath almost everything organizations try to fix with other tools. You can hire better people, run leadership programs, and buy new software, and none of it changes who is allowed to make which call. I've written before about why leadership training doesn't stick; unclear decision rights are one of the main structural causes of poor execution. You can train a manager to decide faster, but if the decision was never theirs to make, the training has nowhere to land.

The two-question test: is your decision system designed or guessed?

The quickest diagnostic I know is the one from the top of this piece. Ask two of your people, separately: "What should you bring to me, and what should you decide yourself?" If the answers don't match, the line isn't defined. It's being guessed.

Guessing is expensive in both directions. When people over-escalate, you get slow decisions, crowded calendars, and a leader who can't get out of operational mode. When people under-escalate, you get surprises: commitments you didn't know about, risks nobody flagged, and the corrosive feeling that you need to check everything. Most leaders respond to that feeling by pulling more decisions back up, which teaches the team to escalate even more. The system trains itself in the wrong direction.

One clarification, because this gets misread: defining an escalation line is not centralizing. (If your team escalates every decision to you, that's the opposite failure, and it has its own fix.) A good escalation line pushes more decisions down, not fewer. It just makes the few that should come up unmistakable. The goal is not control. The goal is that nobody spends energy guessing.

Three ways decision rights fail.

When I audit an organization's decision system, the failures cluster into three patterns. Most companies have at least one; many have all three.

01
Decisions pool at the top
Decision Authority Dependency — every meaningful call travels up

Every call with money or a client attached waits for the founder or a small leadership group. It's usually not a flaw in the leader: early on, the founder really was the best person to decide. The company scaled; the dependency didn't get designed down. The exposure test: could you take two weeks fully off, unreachable, without decisions stopping? I've written a full piece on scaling a founder-led company past this.

02
Accountability blurs across
"We all own it" means, in practice, nobody does

Shared work is healthy; shared accountability is usually a design gap. When a decision belongs to three people, it belongs to nobody: it waits for a meeting, and the meeting waits for consensus. The rule that scales: one owner, many contributors. A single owner is not about blame. The owner is the person you help, not the person you punish.

03
The escalation line stays unwritten
Everyone works from a private guess of where the line is

Even where owners exist, the boundary of their authority lives in people's heads, calibrated from past reactions: that time a decision got overruled, that time an escalation got waved away. People are not working from your decision system. They're working from their private reconstruction of it, and every reconstruction is different.

Diagram: three ways decision rights fail — decisions pool at the top, accountability blurs across, the escalation line stays unwritten

I saw the first pattern recently with a client, a founder-led company where we mapped a normal week of decisions. On paper, the leadership team owned their domains. In practice, nearly every decision with money or a client attached waited for the founder, including ones the team was formally free to make. Nobody had ever told them the opposite, so they inherited the safest assumption: when in doubt, bring it up. The founder read the same behavior as lack of ownership. Both sides were responding rationally to a line that didn't exist.

The cost shows up in the research. In McKinsey's global survey on decision making, executives reported spending nearly 40 percent of their time making decisions and judged most of that time poorly used; only 20 percent of organizations qualified as "winning" on both decision speed and quality. The sharpest finding for this topic: just 46 percent of respondents rated their organizations' delegated decisions as high quality, against 65 percent for big-bet decisions (McKinsey, "Decision making in the age of urgency"). Delegation without designed decision rights is where quality leaks out.

How to run a one-hour decision rights audit

You don't need a transformation program to start. You need a list and an honest hour.

  1. List the ten most frequent recurring decisions in your company or team. Not the strategic once-a-year ones; the weekly ones. Pricing exceptions. Hiring approvals. Client commitments. Spending above a threshold.
  2. For each, write one name. Not a committee, not a role family. One owner. If you can't write a single name, you've found a decision that is currently being made by ambient negotiation.
  3. For each, define the escalation trigger. What specifically sends this decision up? An amount, a risk type, a precedent-setting case. If you can't define the trigger, the owner will keep guessing, and so will you.
  4. Say it out loud. The audit only counts once the owners know they own it and everyone else knows too. Silent authority is not authority; it's a trap you set for your own team.

Then re-run the two-question test in a month. If the answers match, the line exists. If they don't, you learned exactly where the design is still missing, which is more than most companies know about their own decision system.

The pattern behind all of this is the same one that runs through everything I write about Leadership Architecture: behavior follows structure. If you want people to own decisions, ownership has to be designed, not hoped for.

So here is the question I'd leave you with. If you disappeared for two weeks, unreachable, which decisions in your company would simply stop? Write down the first three that come to mind. That list is not a to-do backlog. It's the most accurate map you own of where your organization's architecture still ends at you.

Frequently asked questions

What are decision rights in an organization?

Decision rights are the explicit allocation of who owns each decision, who contributes input, who is informed, and which decisions escalate upward. They describe authority, while the org chart describes reporting lines. In most companies decision rights are implicit and inconsistent rather than designed.

How do you find out who really decides in a company?

Ask two people separately: "What should you bring to your manager, and what should you decide yourself?" If their answers don't match, decision rights are being guessed rather than designed. Mapping a normal week of real decisions, and where each one actually waited, reveals the true decision system faster than any policy document.

Is a shared decision better than a single owner?

Shared input is healthy, but shared accountability usually means no accountability. The scalable pattern is one owner with many contributors: one named person decides, others advise. A single owner is not about blame; it means there is one clear person to support, inform, and help.

What is founder dependency in decision making?

Founder dependency (Decision Authority Dependency) is the condition where most meaningful decisions still travel up to the founder, even when others formally hold the authority. It usually develops because the founder was the best decision-maker early on. The test: whether the company can run two weeks without them. The fix is deliberately designing decision rights downward, not working harder.

When should a decision be escalated?

A decision should escalate when it crosses a pre-defined trigger: a spending threshold, a defined risk category, or a precedent-setting situation. If escalation triggers aren't written down, people escalate based on guesswork and past reactions, which produces both bottlenecks and surprises. A well-designed escalation line pushes more decisions down and makes the exceptions unmistakable.

Sources: McKinsey & Company. Decision making in the age of urgency. Global survey: ~40% of executive time spent on decisions; 20% "winning organizations"; 46% vs 65% quality of delegated vs big-bet decisions. Client examples are anonymized; no figures are invented.

Find out where your decision system still ends at you.

Five minutes. No account. A structural read on whether decision rights — not people — are your bottleneck.