*tl;dr: If every meaningful decision still routes through the founder, the company does not have a leadership problem as much as a decision-rights problem. The fix is to map who recommends, who gives input, who owns real constraints, who decides, who performs, when escalation happens, and where decisions are recorded, so founder judgment is reserved for founder-level calls instead of becoming the company's real-time consensus engine.*

In the last edition, we looked at the leadership layer.

The problem was not that you had hired weak people. You probably had not.

The problem was whether the company had given those people enough ownership, authority, cadence, and visibility to lead without routing every meaningful tradeoff back through you.

Which brings us to the next uncomfortable question:

Who is actually allowed to decide?

This is where many technical founders discover that delegation was only half-installed.

The org chart says Product owns the roadmap.

Then a customer asks for an exception, and Slack quietly asks whether the founder has thoughts.

Finance says the budget is approved.

Reality says the new hire, the contractor, the conference, the tooling request, and the "small" enterprise commitment still need a founder temperature check.

Sales owns the number. Product owns the strategy. Delivery owns capacity.

Then one customer wants something that touches all three, and suddenly the company is standing outside your mental office with a tray of unresolved tradeoffs.

That tray is now very full.

You are not being asked for wisdom every time. Often, you are being used as the missing API between functions.

### The court of final appeal problem

Founders should make founder-level decisions.

That part is not controversial.

You should decide on existential bets, strategy changes, financing choices, material reputation risks, major hiring standards, and decisions that alter the company you are actually trying to build.

But many founders do not become the court of final appeal.

They become the court of all appeal.

Every unclear owner appeals.

Every nervous leader appeals.

Every ambiguous customer promise appeals.

Every budget exception appeals.

Every disagreement that should have been resolved by the operating system appeals.

At first, this feels responsible. You know the context. You can make the call quickly. You prevent a bad decision.

Then the pattern hardens.

The team learns that hard decisions are not owned. They are escalated.

You learn that the company cannot move without you.

Investors learn something too, even if nobody says it directly: the machine still depends on the founder as a live interpreter.

That may be acceptable at the beginning. It is not investor-ready at scale.

The founder should be the court of final appeal, not the court of all appeal.

### Decision rights are operating infrastructure

Decision rights sound like a governance topic, which is why many founders quietly place them in the same mental drawer as policy binders, compliance checklists, and other documents that appear shortly before joy leaves the room.

Wrong drawer.

Decision rights are operating infrastructure.

They define who recommends, who gives input, who owns real constraints, who decides, and who performs once the decision is made.

Frameworks such as Bain's RAPID exist because large organizations discovered the same thing startups discover later, with more calendar drag and more expensive confusion: when accountability is vague, decisions slow down, consensus expands, and implementation gets weird.

BCG makes a similar point in its OVIS work. Decision rights have to clarify who owns, who vetoes, who influences, and who supports. If everyone is generally involved, nobody is specifically accountable.

That sentence is less inspiring than a vision statement.

It is also more useful on a Tuesday.

Most founder bottlenecks are not created by too few smart people. They are created by unclear authority under pressure.

### Speed is not the enemy of quality

Technical founders often tolerate slow decisions because they think slowness is the price of rigor.

Sometimes it is.

If you are choosing a platform architecture, changing clinical validation strategy, renegotiating a major customer contract, or making a financing decision, you should not decide by vibes at 11:47 p.m. because someone used the word "urgent" in Slack.

But slow is not the same as rigorous.

Slow can mean nobody knows who owns the recommendation.

Slow can mean every stakeholder has input, but nobody has the D.

Slow can mean the founder is waiting to be briefed, the team is waiting for the founder to have time, and the decision is aging gently in the backlog like a cheese nobody ordered.

McKinsey's research on organizational decision making is useful here, with the usual caveat: it is large-company evidence, not startup-specific proof. In a survey of more than 1,200 business leaders, only 37 percent said their organizations' decisions were both high quality and fast. The same work found that quick decision makers were twice as likely as slow decision makers to report high-quality decisions.

That does not mean "decide faster" is the strategy.

It means the process matters. Speed and quality can reinforce each other when the decision path is designed.

The founder version is simple:

If every decision requires your private context, your company does not have a quality system. It has a waiting room.

### The Decision Rights Map

Do not start by mapping every decision in the company.

That is how you create an impressive document nobody uses, which is basically technical debt with better typography.

Start with decisions that are high-value or high-frequency.

High-value decisions affect cash, strategy, reputation, major customers, product direction, delivery commitments, hiring standards, or board-visible milestones.

High-frequency decisions happen often enough that small delays accumulate into real drag: discount approvals, scope tradeoffs, roadmap exceptions, customer commitments, hiring backfills, contractor spend, bug triage, support escalation, partner promises.

Then build a Decision Rights Map for each recurring decision category.

For each decision, answer eight questions.

#### 1. What decision are we actually making?

Name the decision in plain language.

Not "align on enterprise customer."

That phrase has done enough damage.

Try:

• Do we commit this feature to close this customer?
• Do we discount below the approved range?
• Do we delay a roadmap item to protect delivery quality?
• Do we hire ahead of plan for this role?
• Do we accept implementation work that does not match the product strategy?
• Do we change a board-visible milestone?

If the decision is vague, the process will become political.

Ambiguity is where every department quietly brings its own definition and calls it alignment.

#### 2. Who recommends?

The recommender owns the structured proposal.

They gather the facts, describe the options, state the tradeoff, and make a recommendation.

This is not a group therapy role. It is a thinking role.

The recommender should write enough context that the decider can choose without reopening discovery from scratch.

A good recommendation includes:

• The decision needed
• The options considered
• The evidence behind the recommendation
• The expected upside
• The risk or cost
• The constraint that matters most
• The consequence of doing nothing

If nobody recommends, the founder usually becomes the recommender by accident.

That is how a "quick approval" turns into you rebuilding the whole decision tree in your head while someone waits politely on Zoom.

#### 3. Who gives input?

Input is not permission.

This distinction will save you hours.

Input means someone has relevant information: customer context, technical risk, delivery capacity, market evidence, financial impact, people implications, regulatory exposure, support load.

Input does not mean everyone gets to relitigate the strategy.

Bain's decision-rights work is blunt on this point: useful input is fact-based and relevant to the decision. General opinion creates fog.

Founders often invite too much input because it feels inclusive.

Then they wonder why every decision has the texture of a product requirements document written by committee.

Keep input narrow enough to matter.

#### 4. Who has a real constraint?

Some people do need stronger rights than input.

Finance may own the cash constraint.

Delivery may own capacity.

Security or regulatory leads may own risk boundaries.

Product may own strategic fit.

These constraint owners should be explicit. Otherwise veto power leaks everywhere.

That is how you get the worst version of consensus: everyone can slow the decision, nobody owns the result, and the founder eventually ends the meeting because payroll continues to be a subscription product.

A veto should be rare, named, and tied to a real boundary.

Not discomfort.

Not preference.

Not "I thought we were going in a different direction."

A real boundary.

#### 5. Who decides?

One person decides.

That does not mean one person ignores everyone else.

It means one person is accountable for closure.

_Closure is the part most companies pretend will happen by consensus._

This is where founders struggle, because many decisions still feel founder-adjacent.

Customer promises affect strategy.

Hiring affects culture.

Discounting affects positioning.

Delivery commitments affect reputation.

Roadmap changes affect investor narrative.

Yes. That is the point.

If everything that touches strategy comes back to the founder, strategy is not a company capability. It is a founder dependency.

Define which decisions remain founder-level and which are owned by leaders inside agreed boundaries.

For example:

• Product decides roadmap priority within the agreed strategic theme and capacity envelope.
• Revenue decides commercial terms within defined margin, positioning, and approval thresholds.
• Delivery decides implementation sequencing when capacity data shows the current plan will break.
• Finance decides spend controls inside the approved operating plan.
• People decides role-level hiring process and performance cadence inside agreed standards.
• The founder decides when the choice changes company strategy, financing logic, core reputation, or a material board commitment.

That last category should be real.

It should not include every decision that makes someone mildly nervous.

#### 6. Who performs?

Decision rights fail when nobody owns implementation.

A decision without a performer is just an expensive opinion with a meeting invite attached.

The performer may be the decider, but often it is someone else.

Name them.

Name the next action.

Name the date.

Name where the decision will be recorded.

This is the part that feels boring until it is missing. Then everyone discovers six weeks later that the "decision" was interpreted three different ways, none of them compatible with the customer email that already went out.

#### 7. When does it escalate?

Escalation is not failure.

Escalation is part of the design.

What you want to remove is ambient escalation, the kind that happens because nobody knows whether they are allowed to decide.

Define triggers:

• The decision exceeds an approved budget boundary.
• The decision changes a board-visible milestone.
• The decision creates a material customer promise outside current product strategy.
• The decision affects runway assumptions.
• The decision creates legal, regulatory, security, or reputation exposure.
• Two accountable owners cannot resolve a real constraint conflict.
• The decision contradicts an agreed company principle.

Now escalation has a shape.

The founder is no longer a human exception handler for every unresolved branch.

#### 8. How do we record the decision?

If a decision matters, record it.

Not in twelve places.

Not as a Slack message everyone will later search for using the wrong keyword.

Record:

• The decision
• The decider
• The reason
• The constraints considered
• The expected consequence
• The owner of implementation
• The date for review, if the decision is reversible

This is not bureaucracy. It is memory.

Your company needs memory that does not live entirely inside the founder's head.

DORA's work on technology organizations points to the importance of information flow, trust, and loosely coupled teams. That is software delivery evidence, not proof that a founder decision map will improve fundraising. Still, the operating analogy is useful: teams move better when they have clear boundaries and the information needed to act inside them.

Decision rights do the same thing for company execution.

They make authority visible.

### The founder-control objection

There is an honest objection here:

"If I give away decision authority, I lose control of the company."

Sometimes that fear is not paranoia. Founders have seen bad decisions made from incomplete context. They have watched teams optimize a function and damage the whole. They have heard "empowerment" used as a polite way of saying "please stop caring so much."

Noam Wasserman's work on the founder's dilemma captures part of the deeper tension: founders often face a real tradeoff between retaining control and building a company that can grow beyond them.

So do not solve this with slogans.

Do not give away decisions blindly.

Do not keep them all either.

Map them.

The founder's job is not to be absent. It is to decide which decisions truly require founder judgment, then make the surrounding system strong enough that everything else can move without founder translation.

That is the mature form of control.

Not control through personal approval.

Control through clear principles, explicit boundaries, trusted leaders, visible information, and disciplined escalation.

### What investors can see

Investors do not need to see your internal decision map to feel its absence.

They feel it in inconsistent reporting.

They feel it when the roadmap changes depending on which customer shouted last.

They feel it when budget conversations detach from milestone logic.

They feel it when every hard question gets answered by the founder while the leadership team provides atmospheric support.

Good governance guidance for venture-backed companies makes the same broad point: fast-growing startups often outgrow their systems and controls. Governance is not there to make the company look adult in a decorative sense. It helps decision making, alignment, risk management, and investor confidence.

Again, do not overclaim this.

A Decision Rights Map will not guarantee funding.

Nothing honest does.

But it does make the company easier to inspect because authority, reasoning, and accountability stop being hidden in founder reflexes.

That matters when the company is trying to become more than a brilliant product with a heroic central processor.

### Try this this week

Pick one decision category that keeps coming back to you.

Choose something live.

Not a philosophical leadership topic. Those are pleasant because they do not require anyone to change a workflow by Friday.

Pick one:

• Enterprise feature commitments
• Discount approvals
• Hiring ahead of plan
• Roadmap exceptions
• Delivery timeline changes
• Customer success escalations
• Tooling or contractor spend
• Product-quality tradeoffs
• Burn-rate interventions

Now write the decision map in one page.

Use this structure:

• Decision category:
• Recommender:
• Required input:
• Constraint owners:
• Decider:
• Performer:
• Escalation triggers:
• Decision record:

Then run the next real decision through it.

Do not announce a transformation program.

Do not design a laminated operating model.

Just take one decision that currently travels through your head and give it a better route.

_One route is enough to expose the real system._

If the route works, add the next decision category.

If it fails, inspect why.

Usually the failure is one of five things:

• The decider did not have enough context.
• Input became permission.
• Too many people had invisible veto power.
• The escalation trigger was vague.
• Nobody owned implementation after the decision.

That is useful failure. It shows you where the operating system is still undocumented.

### The next version of leadership

Your company should not need founder approval for every meaningful decision.

It should need founder judgment for founder-level decisions.

That sounds obvious until you watch a 40-person company route a $900 software subscription, a roadmap exception, a pricing concession, and a senior hire through the same human because nobody wants to be wrong in public.

The answer is not to care less.

The answer is to design the decision system.

You still set the standard.

You still protect the strategy.

You still make the calls only the founder can make.

But the company must learn to decide inside clear boundaries without asking you to become its real-time consensus engine.

That is the shift.

Not from control to chaos.

From personal control to designed authority.

And once that authority is visible, something important changes.

Your leadership team stops asking, "Can Rob approve this?"

They start asking, "Who owns this decision, what evidence do they need, and what would make it founder-level?"

That is a much healthier question.

It is also a quieter calendar.

Which, after the last few editions, feels only fair.

### References

• Previous edition: "You hired leaders. Why are you still every escalation path?"
• Bain & Company: "RAPID Decision Making"
• Bain & Company: "Who has the D?"
• BCG: "Clarifying Decision Rights with the OVIS Framework"
• McKinsey & Company: "Decision making in the age of urgency"
• FMO: "VC Governance Guidance Note"
• DORA: "Loosely coupled teams"
• DORA: "Generative organizational culture"
• PubMed: "The founder's dilemma"

Rob

P.S. Which recurring decision in your company still cannot move unless you personally decide who owns the tradeoff?

If you want help turning this kind of founder-dependent decision path into a cleaner operating system, you can find more at RobKonrad.com.