How is a decision-rights map different from a job description?

A job description lists responsibilities, what someone owns. A decision-rights map answers a different question: what can they actually do about it without asking you first? It's the difference between "you own vendor relationships" and "you can approve vendor invoices under $5,000 without my sign-off."

How long should a decision-rights document be?

One page per role is enough to start. The goal is a specific, written answer to the three columns, what they can decide alone, what needs sign-off, and what's off-limits, not a comprehensive policy document. Brevity makes it more likely anyone actually reads it.

What if the person's authority needs to change as they build trust?

That's normal and expected. The point of writing it down isn't to freeze authority in place, it's to make the current boundary explicit so both sides are working from the same map. You can update it. What you can't do is expect someone to navigate a boundary that was never drawn.

How do I know which decisions to put in which column?

Start with the decisions that have already caused friction. If something came back to you unexpectedly in the last 90 days, that's a decision that needed to be in the map and wasn't. The ELOS Decision-Rights Worksheet prompts you through this category by category.

Why delegation keeps burning you even with good people

Last updated 3 July 2026

Delegation usually fails because founders hand off responsibility without defining who can decide what. Without a written decision-rights map, specifying what a person can act on alone, what needs sign-off, and what's off-limits, the person guesses, the founder gets pulled back in, and both sides lose trust.

Why Delegation Keeps Failing (And What to Do Before the Next Handoff)

Why does delegation keep coming back to the founder?

The handoff isn't the problem. The authority boundary is.

When you give someone a role without a written answer to "what can you actually decide on your own," they guess. You assume they know. Then something lands on your desk you thought they'd handle, or they move on something you wanted to weigh in on, and now you're both frustrated and slightly less trusting of the whole arrangement.

One founder in ELOS onboarding described it this way: he'd handed his ops lead full ownership three times. Same person, same role, same result. That's not a people problem. That's the same structural gap repeating because nobody closed it.

The instinct after a bad handoff is to conclude the person can't handle ownership. Sometimes that's true. More often, they were handed responsibility without authority, and nobody noticed until something broke.

What does "decision-rights design" actually mean?

It means writing down, for every role you're delegating to, a one-page map with three columns:

What this person can move on without telling you
What needs your sign-off before they act
What's off-limits for them to touch, full stop

Not a job description. Not an org chart. A specific answer to the question your ops lead is guessing at every Monday morning.

Founders inside ELOS who documented this, even just a single page per role, escalated 60 to 70% fewer decisions to the founder within 90 days. That's not a marginal improvement. That's getting your mornings back.

What's the most common thing founders say after a bad delegation?

It's almost word for word the same across post-mortems: "I told them what to do. I just didn't tell them what they were allowed to decide."

The gap isn't competence. It's clarity about authority. And it's closeable before the next handoff, not after.

How to fix it before you hand anything off again

The ELOS Decision-Rights Worksheet walks you through this role by role. It takes about 20 minutes, and you'll see exactly where the ambiguity lives before you hand anything off again.

[Grab the Decision-Rights Worksheet →] ===BODY===