Escalation rules for founders who approve too much

Why approvals pile up

Approvals usually pile up for a simple reason: too many decisions still live in the founder's head. Early on, that works. The founder knows the product history, the promises made to customers, the money pressure, and the mistakes the company already paid for once. Later, the same knowledge turns into a traffic jam.

The pattern is familiar. Someone asks a small question, waits for a reply, and leaves three more questions unasked because they assume the founder wants to approve those too. A few weeks later, routine choices start to feel risky. Pricing tweaks, copy edits, tool purchases, customer exceptions, and small product tradeoffs all drift upward.

Fear makes it worse. People do not always wait because they lack skill. They wait because they do not know what happens if they get it wrong. If the founder reverses decisions in public, changes direction without warning, or jumps into details at random, the team learns to ask first.

Moving standards create the same problem. A refund gets approved for one customer and denied for another. One engineer buys a tool without any pushback, while another gets questioned over a smaller amount. A marketer gets told to move fast one day and check every change the next. When the rule keeps changing, people stop using judgment.

Chat tools add another layer of confusion. Quick Slack replies like "fine," "not now," or "ask me first next time" solve one moment but do not create a reusable rule. Soon the company runs on scattered messages, memory, and guesswork.

That is the real issue. Without written decision rights and approval thresholds, the team cannot tell the difference between a true escalation and a normal call. The result shows up early: meetings filled with tiny approvals, repeated questions in chat, and capable people hesitating over decisions that should take two minutes.

Which decisions should stay with leadership

Leadership should keep a short list. If the founder approves everything, the team stops thinking and starts waiting.

Most startups only need leadership to keep control of a few areas:

• financing that changes runway, debt, dilution, or major cash commitments
• legal and compliance risk, especially contracts, privacy issues, and anything that can create liability
• senior hiring and firing for roles that shape the company
• pricing changes that materially affect margins, contract terms, or market position

That covers most cases. Some founders also keep a small set of company-shaping bets, but those bets need clear names. If every feature request gets labeled "strategic," nothing changes.

Routine product decisions should sit with the product owner or engineering lead. They can handle backlog order, small scope tradeoffs, bug priority, release timing within an agreed window, and minor customer requests. A founder should not need to approve a help-page copy change, a one-day sprint swap, or a small tool renewal.

Support leads can usually handle refunds, credits, and common exception cases up to a written limit. Operations owners can approve vendors, tools, and process fixes inside budget. The people closest to the work often make better calls because they see the details first.

A simple test helps: if the downside is limited, reversible, and already covered by policy, the founder should not approve it.

It also helps to write down what leadership will no longer approve. That line is often more useful than a fancy chart. "Leadership will not approve routine discounts under 10%, standard contract edits from the legal playbook, sprint tradeoffs, or normal support exceptions under $200" gives the team something concrete. "Use judgment" does not.

Set thresholds for money, time, and risk

Vague words create bottlenecks. "Large spend," "major delay," and "risky change" mean different things to different people. Put numbers and plain triggers on the page.

Most teams need three kinds of thresholds:

• Money: unplanned spend above $2,000, contracts above $10,000, or discounts above 15%
• Time: delays that move a launch by more than two days, block another team for more than one day, or add more than eight hours of rework
• Risk: anything that touches customer data, changes legal terms, breaks a paid feature, or could lock users out

The exact numbers should match the company. A bootstrapped startup may need a $500 approval limit. A funded company may be fine with $5,000. If almost every decision crosses the line, the threshold is too low.

Time limits matter as much as spending limits. Many founders stop caring about small purchases but still want updates on every slip. That pulls planning back to the top. Decide which delays need attention and which stay with the team. A bug fix that slips by four hours might not matter. A release delay that breaks a customer promise does.

Risk thresholds need plain language. Security, legal issues, and customer harm should never sit in a gray area. If a change affects personal data, payment flow, access control, contract terms, or public claims, call that an escalation trigger directly.

Each threshold also needs one owner and one backup. Do not assign "leadership" or "the founders." Name the role. If the team is small, name the person. One person decides, one person covers when they are away, and everyone else knows where the issue goes.

Clear limits may look boring on paper. Good. Boring rules save time.

Build the escalation table

Most founders do not need a perfect system. They need one page that shows who decides, when they decide, and when something moves up.

Start with real work from the last 30 days. Pull decisions from Slack, email, meeting notes, and ticket comments. If the same approval came up five times, it belongs in the table.

Start with recent decisions

Write each decision in plain words: "Discount above 15%." "Customer refund over $500." "Scope change that adds more than three days." "Production fix that touches billing."

Then group those decisions by area. For a small company, product, sales, support, and operations are usually enough. If a decision does not fit anywhere, that is useful information. It often means ownership is still fuzzy.

Start with the common, annoying approvals first. Those are the ones that keep dragging the founder back into the weeds.

Add the rules that matter

Each row in the table should answer four questions:

• Who owns this decision day to day?
• What threshold turns it from routine into escalation?
• How fast does that owner need to respond?
• If they cannot decide, who gets it next?

The threshold must be concrete. Use money, time, customer impact, legal risk, or system risk. "Big deal" is vague. "Any contract above $10,000 ARR" is clear. "Important bug" creates arguments. "Any issue that blocks checkout for more than 15 minutes" gives people a real trigger.

Response time matters more than many teams expect. If the owner has 24 hours to answer and the founder usually replies in four, people will skip the owner every time. The system has to match how the work actually moves.

Before rollout, test the table on three recent decisions: one easy case, one messy case, and one that caused a delay. Walk through each one step by step. Who would own it? Is the threshold clear? Is the escalation path obvious?

Weak spots usually show up fast. Two people may think they own the same call. The money limit may work, but the risk rule may still be too fuzzy. Fix those gaps while the table is still small.

A good escalation table should feel almost boring. People should read a row, make the call, and move on.

How teams should escalate and decide

Teams move faster when they know two things: what they can decide alone, and how to escalate when they hit a real limit. If every issue goes up the chain, the founder becomes the default project manager, reviewer, and safety net. That feels manageable for a short time. Then everything slows down.

Good escalation is small and specific. A team member should not send, "We have a problem, what should we do?" They should send a recommendation: what happened, what options they considered, what they want to do, and what approval they need.

That one shift matters. It forces the owner to think before escalating, and it keeps decision-making close to the work.

Use a simple escalation format

In most cases, a short note is enough:

• what happened
• the recommended action
• the cost, delay, or risk involved
• the deadline for a reply

Keep it short. If someone needs three pages to escalate, the process is too heavy.

Teams also need response windows. Without them, "waiting for approval" turns into a polite way to hide delay. Set one window for urgent cases and another for normal ones. A production issue might need a reply within an hour. A vendor choice can probably wait until the next business day.

If the founder or team lead does not answer in time, the owner should follow the default rule already in place. In most cases, that means choosing the safest option inside the team's limits. Silence should not stop the company.

The other half matters just as much. If a decision sits inside the owner's threshold, they make it. No extra sign-off. No courtesy approval. No "just checking."

Some decisions will still be messy. That is normal. Review those after the fact. Ask whether the threshold was right, whether the team used sound judgment, and whether the rule needs to change. Do not block ten routine decisions because one edge case might go badly.

A simple example from a small startup

A 12-person SaaS startup had a founder who approved almost everything. She signed off on every refund, every homepage copy edit, and every new software purchase, even when the cost was tiny. It looked careful on paper. In practice, small requests sat in Slack for two or three days while she handled sales calls, product meetings, and fundraising.

The damage showed up in ordinary work. Support agents knew a customer deserved a $49 refund, but they still had to wait. Marketing spotted a confusing headline and left it live until the founder replied. An engineer wanted a simple bug-tracking add-on that cost less than a team lunch, yet nobody bought it because nobody wanted to guess wrong.

The team did not need more meetings. They needed clear decision rights.

They changed the rules. The support lead could approve refunds up to $100 per customer unless fraud, legal risk, or a public complaint pushed the case higher. The marketing lead could update copy on emails, ads, and site pages as long as the change did not touch pricing, legal claims, or the brand promise. The operations lead could buy tools up to $150 a month if the spend fit the existing budget.

The founder kept the decisions that could actually change the business: pricing changes, security issues, and senior hires. Those affect revenue, trust, and team shape. A refund or headline tweak does not.

Within a month, work moved faster. Support closed small cases the same day. Marketing fixed copy in hours instead of days. The founder got fewer pings, and the pings that remained were worth the interruption.

Mistakes that pull work back to the founder

Most approval systems do not fail because the first rule was bad. They fail because exceptions pile up until nobody trusts the rule anymore.

A common version looks like this: the founder says, "The team can approve refunds under $500," then adds five side cases over the next two weeks. One customer is strategic. One is loud on social media. One came through a partner. The rule disappears, and everyone asks the founder again.

Vague language causes the same mess. If a policy says "large discount" or "urgent issue," people will read it five different ways. Use numbers and explicit triggers instead: over $1,000, more than two days of delay, any legal risk, any customer outage longer than 15 minutes.

Founders also pull work back to themselves when they reverse decisions in public. A manager approves a hire, spend, or deadline change. Then the founder jumps into chat and cancels it in front of everyone. After that, no one believes decision rights are real.

Weak escalation creates another problem. People send issues upward without a point of view. They write, "What should we do?" and stop there. That turns leadership into a live help desk.

A useful escalation should include the decision that needs a call, the options already considered, one recommended choice, and the cost, delay, or risk behind it.

Rules also fail when they live in chat threads, meeting notes, and old voice messages. People remember the last thing they saw, not the official rule. Keep the current version on one shared page, and update it the same day a rule changes.

A quick checklist before rollout

If the rules only make sense after a long explanation, they are not ready. A new manager should be able to read them on day one and make a decent call without asking the founder what every line means.

That usually means the document is short, plain, and a little boring. Good approval systems do not depend on memory, personal style, or the founder's mood that day.

Check a few basics before rollout:

• Every common decision type has one named owner and one backup
• Thresholds use numbers or plain triggers, not fuzzy language
• Routine work stays with the team
• A new manager can follow the table without tribal knowledge
• A review is already scheduled for 30 days later

One useful test is to take five decisions from the last month and run them through the new table. If the founder still appears in most of them, the thresholds are too low or the owners are still unclear.

The goal is not to remove leadership from everything. The goal is to keep leadership focused on the few decisions that can seriously affect cash, risk, or customer trust.

What to do next

Start small. Pick the team that sends the most routine approvals and write one page that defines what they can decide alone, what still needs escalation, and the exact threshold that triggers it. If you try to fix the whole company at once, the document will turn into theory and nobody will use it.

For the first week, track one number: how many approvals still reach the founder each day. Count them by type, not just by total. Ten budget questions point to one problem. Ten product scope questions point to another. That makes the leak visible.

A simple first pass is enough. Choose one steady team, set limits for money, delivery delay, customer impact, and legal or security risk, assign one owner, and review the rules after five working days. If people still need to ask what a line means, rewrite it.

After a week or two, fix the repeat escalations before you add new rules. Many founders do the opposite. They keep writing more policy while the same two unclear cases keep bouncing upward. If one decision type shows up every day, solve that one first.

This is the point where escalation rules stop being a memo and start becoming a habit. Keep the rules short, keep the limits visible, and review exceptions in plain language.

If you want an outside view, Oleg Sotnikov at oleg.is works with startups as a fractional CTO and advisor. He can help map decision rights across product, engineering, and operations using real approval patterns instead of guesswork.