The Escalation Layer: Why Every Decision Lands on the Founder

Why does every decision end up on my desk?

Decisions land on the founder when there is no escalation layer between the team and the top. Nobody can say who approves what, up to what limit, so the only path that always works is upward. Naming approval limits per role builds that layer, and it takes an afternoon.

Thesis: When decisions have no designed path upward, they take the only path that always works: they land on the founder. That is not a people gap. It is a missing layer, and it is an afternoon's work to build.

The Pattern

Picture a services firm at roughly ₹45 Cr. The org chart shows three layers. The decision flow shows one. Eleven people report, in practice, to the founder. Not because the structure demands it, but because no one in the building can answer a plain question: who can approve what, up to what limit, and when does it cross to the next level.

The symptoms are always the same. A pricing exception sits in a WhatsApp group for four days because no one knows whose call it is. A delivery team routes a client complaint past the ops head straight to the founder, "in case they don't have context," and the ops head, bypassed twice, stops trying. A new hire learns inside a month that every real question ends at one desk.

The founder feels it as time: thirty to fifty decisions a week that were never meant to reach them. The business feels it as drag.

The Misread

Most founders diagnose this as an ownership problem and reach for one of three fixes. All three fail, and they fail for the same reason.

Delegation training tells the team to "own it." Two weeks later they are back to asking permission, because "own it" carries no definition. What can they approve? What budget can they clear? What client risk can they absorb without checking? None of it is written down.

Weekly alignment meetings work for two weeks, then decay into status updates. The real decisions still happen between meetings, in hallways and DMs.

Hiring a COO is the most expensive version of the same mistake. A COO with no decision architecture to operate inside becomes a costlier single routing node. You have not removed the bottleneck. You have renamed it.

Each of these treats behaviour. None touches the structure that makes the behaviour rational.

The Mechanism

Escalation is not a capability failure. It is a permissions failure.

At ₹5 Cr with ten people, the founder holds every context in their head. Being the decision node for everything costs nothing. At ₹50 Cr with seventy people, the same logic collapses: there are now sixty decision moments a day the founder cannot fully see, but the business has no other defined layer, so the decisions still travel up. Revenue scaled. The decision architecture did not.

Three forces hold the pattern in place:

1. No written thresholds. Nothing states that below ₹25,000 the category head decides. So every call is technically ambiguous, and in ambiguity the safe move is always to escalate.
2. Shared ownership. When three roles own a category, none will carry a wrong call alone. Collective ownership is not accountability. It is a system that manufactures escalation.
3. The training loop. Every fast answer to a small, unnecessary escalation signals that escalation pays off. The founder builds the pattern while trying to be responsive.

The team is not being timid. It is being rational inside the system it was handed.

The Method: A Decision Threshold Map

The fix is a two-page artifact, not a mindset shift. It has four defined elements.

Decision categories. List the categories that currently escalate: client exceptions, pricing, hiring, vendor payments, delivery changes, strategic commitments. Name them explicitly.

Authority thresholds by level. For each category, define what a level can approve outright, what it must inform upward without waiting, and what must escalate. Set it by amount, by risk, and by client impact. Assign the authority to the level, not the person, so it survives a hire leaving.

Escalation triggers. State the specific condition under which a decision moves up, and the response time expected at each stage. Ambiguity is what produces escalation; a trigger removes the ambiguity.

Routing paths. For each category, name who receives the escalation, through what channel, and with what supporting information. A decision with a known destination stops drifting to the founder by default.

Two disciplines make the map hold:

Single ownership per category. One named individual owns the decision and its outcome. Not a team, not a committee. Shared ownership removes the accountability that drives an independent call.
Review, not approval. The founder steps out of the individual approval chain and into a weekly summary of decisions made independently. They review patterns, not calls. This moves the founder from gatekeeper to architect, which is the only seat worth holding at this scale.

Treat it the way the business already treats money. Every firm at this size has financial controls: who can sign a cheque for what amount. Almost none have decision controls at the same specificity. Build the second the way you built the first.

The Audit Loop

A map that no one checks decays back into "ask the founder." So you close the loop with a light instrument: an escalation log. Every escalation records the date raised, who raised it, who it went to, the severity, the expected versus actual resolution date, and one field that matters more than the rest: was the protocol followed, yes, no, or partial.

You are not auditing people. You are auditing the map. A cluster of "no" against one category tells you a threshold is wrong or a trigger is unclear. You correct the artifact, not the person. That correction cycle is what turns a document into an operating layer that holds.

What the Install Looks Like

The change is fast because it is structural, not cultural. The recurring shape: a founder clearing thirty to fifty small approvals a week, a set of written thresholds and a single owner per category installed in an afternoon, and first-week escalation volume falling to under a quarter of where it started. No retraining. No reorg. Decisions that used to sit in a queue for three days clear in three hours.

The team did not change. The architecture did.

The Principle

If your team cannot tell you, in one sentence, who owns decisions at each level and what crosses to the next, you do not have a delegation problem. You have a missing layer.

The businesses that scale without breaking are not the ones with the best people. They are the ones that built a path for decisions to move without the founder touching every one.

Why This Is the Real Work

I build operating models for a living, and this is the clearest example of the thing I keep coming back to: the operating model is the asset. A founder who is the operating system has built a company that cannot be sold, cannot be left, and cannot be scaled past their own calendar. A founder who has installed the layer has built something that runs when they are not in the room. The escalation layer is a small artifact. What it actually installs is optionality.

Two pages changes more about how a company runs than six months of coaching. Start with the map.

If you are carrying a week full of decisions that should not need you, the place to look is not your team. It is the layer between you and them.

This is the first in the MetMov Method Memos series: fortnightly working notes on the operating layers that let founder-led businesses run without the founder in every loop.