A manager is handling a difficult client. The founder joins the call, promises a concession and ends the argument. The client has an answer. The manager now has a different problem: nobody knows whether the next decision is still theirs.
If you step into a decision you've delegated, say why, limit what you're taking over and name when authority returns. Then debrief before the next similar situation. A rescue without a handback can teach customers and employees to wait for you.
For a founder working with a new finance or client-service leader, that distinction matters more than whether the intervention felt helpful in the moment.
Founder rescue delegation needs an end date
Delegation means giving someone room to decide within agreed limits. Handing over tasks while reserving every uncomfortable judgment leaves the founder's job largely intact.
There are sound reasons to intervene: a decision exceeds the manager's authority, new information changes the risk, or an irreversible commitment is close. Discomfort alone is weaker ground. A manager may take a different route to an acceptable outcome.
Before joining, ask what would go wrong if you waited. Is the concern money, the client relationship, timing or simply a preference for your own approach? Answer honestly. If the manager can research the missing fact and respond within the deadline, support that work.
Arron's published discussion of key-person dependence supports deliberate transfers of relationships and responsibility. The intervention rule here is an editorial application of that principle, not a reported Bennett client procedure.
His article on when the founder becomes the bottleneck provides the wider context. This note deals with the narrower repair after one takeover.
Protect the decision, then restore its owner
A founder intervention should specify four things:
Trigger: the new fact that makes escalation necessary.
Temporary scope: the promise, approval or conversation the founder will handle.
Owner: the person responsible for implementing and following up.
Return point: the event or date after which that person decides again.
Write these in the decision record while the issue is live. A short comment can be enough: founder approval applies to this disputed invoice only; the manager owns future concessions within the existing limit.
Instructions that say “keep me involved” leave people guessing. Does involved mean consulted, copied or asked for permission? Decide which one before the next call.
For most founders, the hard part is allowing the manager to close the loop publicly. If the founder announces the exception and the manager silently executes it, the customer may learn to reach around the manager again. Explain whose authority will govern the next request.
The broader design belongs in an authority map. The map is useful only if behavior follows it when a decision becomes difficult.
Hypothetical: a $15,000 promise made on the call
Assume a fictional service firm invoices a client $75,000. Delivery cost for the agreed work is $48,000. Before a concession, contribution is $75,000 minus $48,000, or $27,000.
A manager has authority to approve up to $5,000 of concessions. The client requests $15,000. The founder joins and agrees immediately.
Assuming delivery costs stay unchanged, the fee becomes $60,000 and contribution falls to $12,000. The concession removes $15,000, or about 55.6%, of the original $27,000 contribution. These are hypothetical results, not a client story or an acceptable-discount benchmark.
The request exceeded the manager's limit, so founder approval was needed. The failure was leaving the scope of that approval unstated.
A better sequence is to pause the commitment, confirm the disputed work and let the manager present options. The founder can approve a one-time exception after considering the evidence. The manager then communicates the resolution, records the revised amount and remains the next point of contact.
If overrides are becoming expensive but hard to trace, a Profit & Tax Leak Check can help frame the concession-review conversation around the decisions consuming margin.
Don't turn the debrief into a verdict on the manager
Review the reasoning, not just whether the customer stopped complaining. What did the manager know? What context did the founder have that hadn't reached them? Which information was missing, and who should supply it next time?
A CFO partnership needs operating access and CEO context; Arron's published partnership post supports that point. Expecting independent judgment while withholding the background is a poor test of delegation.
Keep the debrief specific. The manager's goal might be to check the contract earlier, offer a staged remedy or escalate before a deadline. The founder's action might be to share relationship history rather than enter every client conversation.
A single outcome doesn't prove a person can't do the job. Repeated errors may justify training, narrower authority or reassignment. State that change directly instead of maintaining a delegation arrangement that the founder no longer trusts.
What most founders can test after the rescue
Set a review date, perhaps after the next comparable request or a week later. Check whether the manager made the decision, whether the agreed boundary held and whether the founder stayed out of routine approval.
The exception is an immediate material threat outside the manager's authority. Intervention can still be necessary; it should leave a visible record and another return point.
Start with a one-line record of the next decision, its owner and the evidence needed. Put it beside the contract or account notes. Authority lives in the team's actions, so review whether those actions match the record.
A process built for scale needs a clear order: the manager's research, any exceptional approval and the handback. Review the content of the manager's proposal before entering the conversation. Finding a better way to handle one decision is useful; treating market pressure as a reason to reclaim every decision isn't.
Founder freedom depends on people being able to run ordinary work. Bennett's discussion of owner dependency and the key-man discount examines the related business-value issue; the title isn't a promise about your exit price.
Choose one recent rescue and repair its unfinished handback today. If the financial consequence is unclear, bring the override and its cost assumptions to a Leak Check before changing the whole team's authority.
Frequently asked questions
When should a founder step into a delegated decision?
When new risk or a commitment exceeds the manager's agreed authority. Name the trigger and temporary scope rather than relying on a feeling that intervention is needed.
Is every founder intervention a delegation failure?
No. Escalation can be part of sound delegation. The failure is letting an exception quietly become permanent founder ownership.
What if the client insists on speaking to the founder?
The founder can listen while confirming that the manager remains responsible for the decision and follow-up. State any exception clearly.
Who should communicate an approved concession?
Usually the responsible manager, with the founder supporting their authority. Adapt that choice when the specific relationship or risk requires founder communication.
What belongs in the decision record?
The reason for intervention, approval boundary, financial effect, implementation owner and return point. Keep the record short enough to use during live work.
How soon should the debrief happen?
Before the next similar decision, while the facts are available. Waiting until a distant performance review leaves the authority problem unresolved.
Should the manager's limit increase after a rescue?
Only if the evidence supports it. Missing context, training and authority are different problems and may require different changes.
How do you know authority has returned?
The manager makes the next comparable decision within the agreed boundary and the founder honors it. A rewritten job description alone doesn't establish that.