Decision Rights: Who Decides What in a Small Team

The everyday cost of unclear decision rights

In a small team, unclear decision rights don't usually show up as a dramatic conflict — they show up as small, constant friction: someone asks the founder something they could reasonably have decided themselves, a decision gets made and then quietly overridden because someone else assumed it was theirs to make, or two people each think the other was handling something and neither did. None of this looks like a serious problem on any given day, but it adds up to real slowness and, eventually, frustration on both sides.

The founder usually experiences this as 'people keep asking me things they should just know', while the team experiences it as 'I don't actually know what I'm allowed to decide, so I ask to be safe'. Both are accurate descriptions of the same underlying gap: nobody has written down, in one place, who decides what.

Three levels of decision right, not one

It's tempting to think of decision rights as binary — either someone can decide something or they can't — but a more useful model has three levels, because most real decisions in a small business sit somewhere between full autonomy and no autonomy at all.

Decides alone means the person acts without checking first and simply reports the outcome later if at all. Consults then decides means they gather a quick view from someone (often the founder) but the final call is genuinely theirs. Recommends, founder decides means they do the analysis and bring a recommendation, but the founder makes the actual call. Naming which of the three applies to a given decision removes most of the ambiguity that causes friction.

• Decides alone: acts independently, reports outcome afterwards if relevant
• Consults then decides: checks a quick view first, but owns the final decision
• Recommends, founder decides: prepares the option and reasoning, founder makes the call

Building the decision rights map

Start by listing the decisions that actually recur and actually cause friction — there's no need to map every conceivable decision a business could ever face. A realistic list for a small team might include: customer refunds and goodwill gestures, scheduling and shift changes, small supplier purchases, pricing exceptions for a specific client, hiring for a given role, and marketing spend above a certain amount.

For each one, write down which level applies, and to which role rather than to a named individual, since the map should still work if someone leaves or a new person joins. A simple table works better than prose here — one column for the decision, one for the role, one for the level, and a short note on any limit that applies, such as a spending threshold.

1. List recurring decisions that currently cause confusion, delay, or duplicated effort
2. For each, decide the appropriate level: decides alone, consults then decides, or recommends only
3. Assign the role (not just the individual) responsible at that level
4. Add any numeric limits (spend, discount percentage, time-off days) that apply
5. Share the finished map with the whole team, not just the people directly affected
6. Set a review point, ideally tied to your quarterly priorities review

What to do when two roles both feel entitled to decide

Overlapping decision rights are common in a small team where roles blur, and they cause a particular kind of friction: two people both act, in good faith, on the same decision, and one ends up feeling undermined when the other's version wins out. This isn't usually a personality clash — it's a gap in the map that hasn't been resolved yet.

When this comes up, resist the urge to resolve just the specific instance and move on. Use it as the trigger to update the map itself: decide explicitly which role has the decision right going forward, communicate the change to both people (and anyone else it affects) at the same time, and note briefly why the split was made this way, so it doesn't feel arbitrary.

A recurring disagreement about who should decide something is a sign the map needs fixing, not a sign the people involved need to communicate better.

When the founder should keep final say — and when to actually use it

Some decisions reasonably keep the founder as final decision-maker even after a team has grown: hiring and firing, significant financial commitments, anything with legal exposure, and decisions that affect the fundamental direction of the business. Naming these explicitly on the map, rather than leaving them as an unstated assumption, prevents the awkward moment where a team member reasonably assumed they had a decision right that was never actually granted.

Where the founder is the final decision-maker on something a team member has prepared a recommendation for, it matters to actually engage with the recommendation rather than treating the process as a formality. If recommendations are consistently overridden without explanation, people stop investing effort in preparing them properly, and the 'recommends, founder decides' level quietly collapses back into the founder doing all the thinking themselves.

Keeping the map alive rather than letting it go stale

A decision rights map is only useful if people actually refer to it, which means it needs to live somewhere accessible — alongside your operations manual or SOPs rather than buried in an old email or a one-off meeting note. It should be short enough that someone can scan it in under a minute when they're unsure who should decide something.

Review it whenever a role changes materially, when someone new joins, or when the same disagreement about ownership comes up more than once. Treating it as a living document that evolves with the team, rather than a document you write once and forget, is what keeps it actually solving the problem it was built for.