Decision rights

Decision rights define who is allowed to decide what, within which boundaries, with which minimum information and with what accountability after the decision is made. In SMEs, decision rights are often not designed; they are inherited from habit, founder proximity and implicit permission. Making them explicit is one of the fastest ways to reduce decision latency without losing control.

In brief

For every type of decision in a company, there is always an answer to the question “who can decide this?” The answer exists even when it has never been written down. Decision rights make that answer explicit.

When decision rights are implicit, every decision pays a tax: time spent identifying the owner, fear of stepping on someone else’s territory, escalation “just to be safe”, and the risk that uncomfortable decisions remain orphaned.

A good decision-rights design does not simply delegate more. It specifies who owns a decision, where the boundary is, what information is required, and how the decision will be reviewed afterwards.

Operational definition

A well-defined decision right has four components.

The first is the decision owner: one person or role that has the right to decide. This is the decision equivalent of the single Accountable in a RACI matrix. If two people own the same decision without a clear tie-breaker, nobody truly owns it.

The second is the boundary. This is the threshold that defines the scope of the right: purchases up to 5,000 euros, discounts up to 8%, delivery exceptions up to seven days, hiring decisions for a certain role level. Without a threshold, delegation is not a decision right; it is an intention.

The third is the minimum information required before deciding. This is where consultation belongs. Instead of adding Consulted roles for political comfort, the company defines what information must be available to the owner of the decision.

The fourth is review. How and when will the decision be checked afterwards? This is the component that makes delegation sustainable for the person granting it. It replaces preventive control, which creates queues, with retrospective learning.

A useful distinction is between the right to decide, the right to propose, the right to ratify and the right to veto. Many organisational paralyses come from mixing these verbs. The person who proposes thinks they decide; the person who ratifies thinks they can redesign; the person with veto power uses it as a design right. Separating the verbs, matter by matter, often dissolves conflicts that looked personal.

Why it matters for SMEs

In SMEs, decision rights are usually formally absent and practically concentrated in the founder, with grey zones everywhere. The cost grows with scale.

Every decision without a clear owner generates escalation. It moves upward until someone feels authorised to take it. Each escalation consumes senior attention and increases system-wide decision latency.

The founder often experiences this as indispensability: “they always need to ask me”. The organisation experiences the same pattern as impotence: “we cannot decide anything”. The facts are the same. The design defect is the absence of explicit rights.

There is also an invisible cost: orphan decisions. When nobody has the explicit right to decide on a difficult matter, the decision may simply not happen. The weak supplier is not replaced, the dead project is not stopped, the wrong price is not corrected. A company can lose more margin through orphan decisions than through wrong decisions.

For an investor or buyer, decision rights are a transferability map. They show how much of the business is system and how much is person. In post-acquisition integration, redesigning decision rights is often one of the first operational workstreams. A company that already has thresholds and delegations in use is selling one less risk.

Observable signals

Confused decision rights have a recognisable language.

“Better ask first” often means the boundary is missing.

“I cannot authorise that” said by someone who later authorises it indicates an informal right that cannot be defended.

“Do it, but do not say I told you” is clandestine delegation: the right exists in practice but not in the official architecture.

Serial escalation is another signal. The same category of decision moves upward every week. The issue is rarely lack of common sense; it is lack of a threshold.

Watch what happens after decisions are made. If decisions are regularly reopened by someone who did not take them, the right to decide is separated from the power to make the decision stand. This is one of the most demotivating forms of ambiguity, because it teaches people that deciding is not worth it.

Common mistakes

The first mistake is delegating the subject without the threshold. “You handle purchasing” is not a decision right. It is a programmed misunderstanding. The delegate does not know where the field ends, and the delegator discovers the boundary only when it is crossed.

The second mistake is granting the right while keeping the wrong control mechanism. If the founder still controls each case before the decision, the queue remains. Delegation requires review after the fact, not authorisation before every act.

The third mistake is silent revocation. The founder intervenes inside a delegated area without saying that the boundary has changed. The organisation learns from behaviour more than from documents, and stores the delegation as fiction.

The fourth mistake is designing rights around current people rather than roles. “Franca handles that because she is good at it” works while Franca is there. It turns every replacement into a constitutional crisis.

Operational example

An installation company with 33 employees says it has a slow sales process. Quotes take an average of nine days, while competitors respond in three.

A one-month review of escalations shows that 70% of quotes reach the founder for one of three recurring reasons: discount above an unwritten threshold, non-standard payment terms, or a delivery date below 15 days.

For each matter, the company defines the full package: decision owner, threshold, minimum information and review. The sales manager can approve discounts up to 10%, choose among three predefined payment schemes, and commit to deliveries down to ten days after checking capacity in the system. Decisions are reviewed every two weeks for 30 minutes, not to re-authorise them but to learn from them.

After two months, average quote time falls to 3.5 days. Escalations fall to one fifth. The most interesting discovery appears in review: the sales manager’s decisions are often more prudent than the founder’s rushed decisions between meetings. Retrospective control did not only free the flow; it improved decision quality.

Diagnostic questions

For the five most frequent decisions in the company, can you write the owner, threshold, minimum information and review mechanism now?

Which decisions reached the founder this week, and how many would have stayed lower with a written threshold?

Which uncomfortable decisions have been known for months but are not being taken? For each one, ask not “why does nobody decide?” but “who has the right to decide it?” If the answer is “nobody, exactly”, the problem is architecture, not courage.

Practical implications

Start with frequency, not theory. Take the three or four decision categories that most often escalate upward and define the full package for each one on a single page.

Then comes the decisive part: eight weeks of disciplined use. The delegator must not intervene inside the agreed boundaries, and the retrospective review must actually happen. During these weeks, the organisation decides whether the new rights are real.

Thresholds can then be adjusted with experience. Enlarging a threshold is a natural reward. Narrowing one can be done, but it must be explicit.

MARTRO reading

In MARTRO’s reading, decision rights are where the diagnosis moves from flows to architecture. Many SME decision problems are not about the intelligence of decisions but about their home: decisions without owners, owners without thresholds, thresholds without review.

The typical MARTRO intervention does not teach people to decide better in the abstract. It redesigns where decisions live and measures the result through decision latency: the time between a signal and authorised action.

When to go deeper

Go deeper when serial escalations occupy senior attention, when orphan decisions create recurring costs, or when a new delegation has not produced real autonomy.

Natural next steps are governance, decision latency and stop rule. Stop rule is particularly important because the right to stop is one of the most neglected decision rights in growing organisations.

Frequently asked questions

What is the difference between decision rights and RACI? RACI assigns responsibility for activities in a flow. Decision rights assign authority over decisions, with thresholds and review. They meet in the Accountable role when an activity includes authorisation.

Do thresholds make the company rigid? Well-designed thresholds do the opposite. Inside the threshold, speed is maximal because no authorisation is needed. Outside the threshold, escalation is clear. Rigidity comes from thresholds set too low or from preventive controls that deny the threshold.

Where should a founder-led company start? Start by counting. Track one week of decisions that reach the founder and classify them by category. The first delegations should cover frequent, repetitive and limited-impact decisions, where the risk is low and relief is immediate.

What does an investor look for? Whether decision rights are written, whether actual escalations respect them, and how long they have held without founder intervention inside the boundaries. A delegation written yesterday is a promise. A delegation respected for a year is an asset.

License

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International. Required attribution: Source: MARTRO Observatory, "Decision rights", https://www.martrosystems.eu/en/knowledge/decision-rights.

https://creativecommons.org/licenses/by-nc-sa/4.0/

CLEW

When an issue crosses roles or areas, a structural diagnosis helps read the operating evidence.

Explore CLEW