Somebody arrives at your desk with a problem. You spend fifteen minutes on it — understanding the situation, asking what they've already looked at, working out the options, deciding.
That happens eleven times a week. Some of it is genuinely your call. Most of it isn't, and you know that while it's happening.
The usual fix is to tell people to bring you solutions, not problems. It rarely survives a fortnight, because it's a demand without a format — and a demand without a format lands as stop asking me things, which produces either the same escalations phrased apologetically or, worse, people quietly not raising things at all.
Here's the version that works, because it specifies exactly what to bring.
The protocol
Before anything comes to you, three questions get answered:
1. What's the real problem?
2. What are three possible solutions?
3. Which do you believe is best, and why?
That's it. Three sentences, prepared before the conversation.
What you receive is no longer a problem. It's a recommendation with reasoning attached, and your job changes from exploring to confirming — which is a ninety-second job instead of a fifteen-minute one.
The protocol doesn't make people stop asking. It changes what arrives.
What each question is actually doing
They're not arbitrary, and each one develops a different capability.
Question one builds clarity. A surprising share of escalations dissolve here. The stated problem is almost never the real problem — the client is unhappy about the timeline is usually we never agreed what the timeline was, and those have completely different answers. Forcing the restatement catches a meaningful proportion before anything reaches you at all.
Question two builds resourcefulness. Three options, not one. One option is a request for permission dressed as a plan. Three requires actually surveying the space, and the second and third options are where people discover that the obvious answer isn't the only one. This is the question that changes how somebody thinks over about six months.
Question three builds agency. A recommendation with reasoning is a commitment. It requires the person to have a view and to defend it, and it's the difference between someone who processes decisions and someone who makes them.
The sequence matters. Clarity, then resourcefulness, then agency — in that order, because you can't survey options for a problem you've misidentified, and you can't recommend among options you never generated.
The thing it does that nobody expects
Within a couple of months, a large share of these conversations stop happening entirely.
Not because people are asking less. Because question three answers itself. Somebody works through the three questions, arrives at a recommendation they're confident in, and realizes they don't actually need you — they just needed to think it through, and previously the only thinking-it-through mechanism available was talking to you.
That's the whole mechanism, and it's why this outperforms every version of just make the call yourself. It doesn't ask people to be more confident. It gives them a process that produces confidence, and confidence produced by a process is transferable in a way that encouragement isn't.
How to introduce it without sounding like a jerk
This lands badly if it's 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 actually is, it's received completely differently:
I'm the bottleneck on decisions here and it's slowing you down more than it's slowing me. I want you making more of these calls. So here's what I need in order to get out of the way faster — and when you've got the three answers, most of the time I'm going to say yes to your recommendation.
That framing is true, and it matters more than the mechanics. One version is about your convenience; the other is about their autonomy. Same three questions, entirely different reception.
Then apply it to yourself first, publicly. Spend a fortnight answering the three questions before you take anything to a partner, an advisor, or your own team. People notice, and it removes the sense that this is a rule for other people.
The two ways founders break it
Skipping past the prepared options. Somebody arrives with three options and a recommendation, and you say actually let's just do X — your own answer, arrived at in the moment. It's often a better answer. It's also fatal.
Two instances of that and nobody prepares options again, because preparing them was pointless. If you disagree with the recommendation, engage with it: say which of their three you'd pick and why, or explain what they were missing. The engagement is the teaching, and skipping it discards the entire investment they made.
Answering questions that already have answers. If somebody brings you something you've decided before and you decide it again, you've taught the business that asking is faster than looking. The norm never forms.
Your job isn't to be indispensable. Your job is to build something that doesn't depend on you.
The half that makes it permanent
The protocol changes what arrives. It doesn't stop the same class of question arriving again in three months from somebody else.
For that, add one habit: when you answer, record the rule, not the answer.
Not yes, discount that client — but we discount when the account is over this size and the relationship is over a year.
An answer resolves one instance and teaches nothing. A rule resolves the whole class and can be applied by somebody else next time without asking. It's one word different from what everybody does and it's the entire difference between a log that shrinks your escalation volume and an archive nobody can generalize from.
Then put the rule where the question arises — next to the proposal builder, in the scoping template, wherever the decision actually happens. A central policy document competes with asking you, and asking you is faster. It'll lose.
The decision-rights map it assumes
The protocol assumes something that usually hasn't been written down: which decisions are yours in the first place.
Three categories per role. Decisions they own outright. Decisions they make and tell you about afterwards. Decisions that genuinely need you first.
Most founders have never stated this, so the default is that everything checks — and the default isn't a choice anybody made. Half the escalations you receive are probably decisions the person already owned, and saying so is the fastest way to move the boundary.
And one thing that has to be true and said out loud: it's fine to be occasionally wrong.
Independent decisions require a tolerance for some of them being suboptimal. If every misstep gets examined, a rational person keeps checking regardless of what any document says. The permission that matters isn't permission to decide — it's permission to be wrong sometimes, and it has to be stated rather than implied.
What to do when the answers are bad
The first few rounds will produce weak options and unconvincing recommendations. That's expected, it isn't a sign the protocol is failing, and how you handle it decides whether it survives.
The instinct is to correct — to point out that option two wasn't viable and option three was a restatement of option one. Resist it, at least at first. Somebody who has been told their thinking was wrong twice will bring you a problem again, because that's safer.
Ask instead. What made you rule out doing nothing? What would the version cost twice as much look like? Questions rather than corrections, because the gap is usually in how widely they searched rather than in their judgment about what they found.
The specific failure worth naming early: three options where two are obviously bad. That's a real pattern and it's not dishonesty — it's what happens when somebody generates a preferred answer first and then fills the quota. The fix is asking for one option they'd be genuinely uncomfortable with, which forces an actual search.
And give it a quarter before judging it. The change here is in how somebody approaches a problem, and that's not a fortnight's adjustment. What you're watching for isn't better answers immediately — it's the moment somebody tells you they worked through the three questions and didn't need you after all.
Why this is Enablement rather than management
It's tempting to read this as a delegation technique. It's narrower and more structural than that.
The Enablement pillar argues that enablement is engineered through three forces: empowerment, education and environment. The three questions are all three at once. Question three is empowerment — the authority to have a view. Question two is education — the practice of surveying options. And the protocol itself is environment: the system that makes acting possible.
People don't become low-agency by nature. They become low-agency by design, by being placed in an environment that requires hesitation rather than action.
A business where every question routes to the founder is that environment. Not because anyone chose it — because the alternative was never specified. The three questions are the smallest possible specification.
Start with one person
Say it to one person, framed as being about their autonomy rather than your calendar. Then hold both ends: engage with the recommendation rather than skipping past it, and write down the rule rather than the answer.
Two months of that and the eleven conversations a week become four — and the four that remain are the ones that genuinely needed you.
If the escalation volume doesn't fall, the constraint is usually further upstream — decisions that can't be delegated because the context behind them was never written down. Worth naming which of the seven pillars is actually binding.
Get The OPERATE Report →