Leading by exception: what reaches your desk once the system runs.

Two founders, two weeks. One reads every Slack channel, signs off on every approval herself, answers customer emails at 11pm because otherwise she has no idea what's actually happening. The other pulled back on purpose, delegates hard, and hears about a major account escalating only after the cancellation is already signed. Both are convinced they're leading. Neither is, right now.

This comes down to design, not effort or trust. Leading means knowing exactly what has to reach you, and letting everything else run, without "letting it run" turning into "not knowing."

Leading by exception means the system knows what you need to know before you have to ask.

The false choice

Most founders think in terms of a dial between two poles: control on one end, letting go on the other. The question they ask themselves is: where am I on that scale right now, and should I turn the dial a notch?

That question already contains the mistake. It treats visibility as a single, continuous variable you can turn up or down depending on how the week is going. Real leading by exception is a classification more than a dial. Some decisions must always reach you. Most must never reach you. And where that line sits comes down to what the decision actually is, not how much you trust your team.

What the classification actually is

I described the Decision Impact Classification in an earlier article: four tiers, structured like a tree, Root, Trunk, Branch, Leaf, sorted by impact rather than rank. And in an even earlier article, I described what happens once that sorting actually holds: a company moves from Founder Mode, where every decision runs through one person, into Growth Mode, where AI operators run the routines and the CEO leads by exception. Those two words, by exception, are what this article is actually about.

The tree itself is just the map. What matters is the timing: this assignment happens in advance, once, for every recurring type of decision, not reactively in the moment something goes wrong and someone has to figure out who's supposed to own it.

Escalation is engineered, not hoped for

What that classification alone doesn't do is enforce itself day to day. Every Role Contract, which I covered in an earlier article, carries escalation triggers: concrete thresholds and conditions where a decision has to jump a level. FTT drops below a defined value. A routine task suddenly touches a Root question. A Role Contract is about to exceed its own boundary. When that happens, the case moves up automatically, not because someone happened to be paying close enough attention.

"Leading by exception" sounds like a stance, a matter of personality. What it actually runs on is something far more mechanical: whether those triggers exist in advance, explicit, in writing. Without them, "I only step in when it matters" is a hope that someone remembers to tell you.

A system that forces you to see everything proves exactly one thing: that nobody decided what actually matters.

That's the real difference from the founder still reading customer emails at 11pm. She's seeing more because nobody defined, in advance, which cases genuinely need to reach her. By default, everything does, whether she wanted to know it or not.

Company 0

I've described elsewhere that the weekly content production at Rocket Routine runs in Growth Mode: AI operators produce, I review by exception. What that left open is the sharper question: what actually defines the exception?

The answer is one very narrow point in the entire monthly cycle. Every week, this operation produces a blog article in two languages, several LinkedIn posts, a set of X posts, and a video, none of it approved by me individually. But the monthly Build Log carries a section called Company 0, reporting on concrete events from my actual month. That one section is deliberately built so no operator can fill it in. Without a real detail from me, the line stays empty.

This escalation is engineered, not left to luck: that one piece of information can only come from me, structurally, regardless of how much any given operator trusts its own output. Everything else in this operation runs without ever reaching me.

What this means for you

Take any decision that landed on your desk last week and ask the honest question: did it land there because it was structurally a Root or Trunk decision? Or did it land there because "when in doubt, just ask" was the only rule you ever had?

If the honest answer is the second one, what you have is a default setting that pushes everything upward, because nobody defined what doesn't belong there. That's not a classification. Write down, for every recurring decision type in your company, which tier it belongs to, and what concrete threshold pulls it up to you in the exception case. Not "flag it if unsure." A threshold. A condition. A trigger.

The difference between a founder who leads and one who just looks busy shows up in whether her system knows what she needs to know before she has to ask for it, rarely in hours worked.

If you're running a founder-led B2B company with 15 to 50 employees and want to know how to engineer escalation as a mechanism instead of a gut feeling: https://www.rocket-routine.com/en.