The two halves of the system
There is an inbound half — the protocol governing how something reaches you — and a persistence half — the log that means it does not reach you again. Businesses that build only the first get better-structured escalations at the same volume. Businesses that build only the second get a document nobody contributes to.
The inbound half changes what arrives. The protocol is the one from the framework, asked before anything is brought to you: what is the real problem, what are three possible solutions, and which do you believe is best and why. Three questions, and they do most of the work.
The persistence half changes what recurs. Every escalation that results in a decision produces a written rule, and the rule is what a competent person consults instead of asking. Volume drops because the class is resolved, not because people were told to stop asking.
It is worth being clear about what this is not. It is not an approval workflow, and building it as one produces the opposite of the intended effect — more things routing to you, more formally. The measure of success is that escalation volume falls, and a system whose volume is flat after two quarters is documenting the bottleneck rather than dissolving it.
The architecture, part one: the escalation protocol
Stage one is the decision-rights map, which has to exist before any protocol makes sense. Three categories per role: decisions owned outright, decisions made and reported afterwards, decisions requiring you first. Most founders have never written this, so the default is that everything checks — and the default is not a choice anybody made.
Stage two is the pre-escalation format. Anything in the third category arrives with the three answers attached: the real problem, three options, and a recommendation with reasoning. This converts a fifteen-minute exploration into a ninety-second decision review, and it does something more useful than saving time — it develops the person's judgment instead of substituting for it.
Stage three is the response, and there are three shapes. Confirm the recommendation. Choose a different option and say why. Or — and this is the valuable one — state the rule that decides this class of question, which means the next instance does not come to you at all.
Stage four is the routing check. Before answering, one question: is this in the third category, or has it drifted there? A significant proportion of escalations turn out to be decisions the person already owned, and saying so is the fastest way to move the boundary.
The architecture, part two: the log and its maintenance
Stage five is the record, written at the moment of the decision by whoever made it. Five fields: the question class, the rule, the reasoning in one sentence, the date, and the owner. The reasoning field matters more than it looks — a rule without its rationale cannot be sensibly overridden or updated when circumstances change.
Stage six is placement. The rule lives where the question arises, not in a policy repository. A discount rule belongs where proposals are built; a scoping rule belongs in the scoping template. A central log that everyone must remember to search is a second system competing with asking you, and asking you is faster.
Stage seven is the search-first norm, and it needs stating explicitly because it does not emerge on its own. Before escalating, check whether the rule exists. This is the half that makes the log worth maintaining, and it is set by whether you answer questions that were already answered — if you do, the norm never forms.
Stage eight is the review, quarterly, against two lists: rules that keep getting overridden, and questions that keep recurring despite having a rule. Overridden rules are wrong. Recurring questions with an existing rule are placement failures — the rule is real and it is not where the question happens.
Stage nine is the boundary adjustment. Every quarter, move something from category three to category two. The decision-rights map should be steadily loosening, and if it is not, the log is documenting a bottleneck rather than dissolving one.
The failure edges
The first: recording answers rather than rules. Produces an archive of instances that cannot be generalized, so the volume never drops and the log becomes a chore with no visible payoff.
The second: a central log nobody searches. Competing with asking the founder, and losing, because asking is faster and always will be. Placement at the point of the question is the only version that wins.
The third: no decision-rights map. Without it the protocol has nothing to apply to, and every question is potentially an escalation.
The fourth: the founder answers pre-empted questions anyway. Somebody arrives with three options and a recommendation, and you skip to your own answer. Two instances of that and nobody prepares options again, because preparing them was pointless.
The fifth: no rationale captured. Rules without reasoning become rigid, get applied in circumstances they were not meant for, and cannot be updated because nobody remembers what they were solving.
The sixth: the boundary never moves. If the same decisions require you in year two, the log is documenting the dependency in more detail rather than reducing it.
Introducing it without it reading as bureaucracy
The three-question protocol lands badly if it is introduced as a process requirement, because from the other side it looks like a barrier between somebody and the answer they need. Introduced as what it is — a commitment that you will decide faster and they will get more autonomy — it is received completely differently, and the framing genuinely matters here more than the mechanics.
Start by applying it to yourself for a fortnight. Log every question you are asked and write the rule behind each answer as you give it. That costs about ten minutes a day, it produces the first twenty rules without anybody else changing behaviour, and it tells you how short the list actually is — most founders are surprised that the recurring questions number in the dozens rather than the hundreds.
Then move one decision category outward and say so explicitly. Naming a decision that used to need you and no longer does is the single most credible signal that the system is for their autonomy rather than for your convenience, and it is what makes people contribute to the log rather than route around it.
What done looks like, and what it takes to build
Done is a measurable drop in escalations, arrivals that come with three options and a recommendation, and a set of rules living where the questions happen — with the decision-rights boundary demonstrably looser than it was six months ago.
The checklist: a written decision-rights map per role in three categories; the three-question pre-escalation format; a response protocol whose best outcome is a stated rule; rules recorded with question class, rule, rationale, date and owner; placement at the point of the question rather than in a central archive; a search-first norm the founder enforces by not answering answered questions; a quarterly review of overrides and recurrences; and a standing commitment to move one decision category outward each quarter.
The build is light — this is mostly protocol and habit — but it needs a place for rules to live that people already use, and it needs the founder to hold the line on two behaviours: not answering questions that have rules, and not skipping past prepared options.
The prerequisite is a genuine willingness to be occasionally wrong. Independent decisions require tolerance for some being suboptimal, and if every misstep is examined, a rational person keeps checking regardless of what the map says. The permission that matters is not permission to decide; it is permission to be wrong sometimes.
Record the rule, not the answer, and put it where the question arises rather than in a central log. Every quarter, move one decision from needs-me to tell-me-after.