How Do I Delegate When I Don't Trust My Team to Get It Right?
By Brendan Levin. 20+ years scaling businesses, from teams of 8 to 600 and budgets from startup to $100m.
Key takeaways
- Founders rarely distrust the person. They distrust the absence of a rule that defines when the person is allowed to act alone.
- A written decision threshold (a real dollar amount or a named risk line) makes delegation reversible because you can see exactly where it broke down.
- One defined review checkpoint after the first handoff gives you proof of quality before you fully let go.
- Fixing this is a structure problem, not a management or hiring problem.
The real reason you can't let go has nothing to do with your team
Here is what founders almost never say out loud: the distrust is not really about the person. It is about the absence of a rule. If you have never written down what the person is allowed to decide on their own, at what dollar amount, and with what information, then handing work to them genuinely is risky. You are not being irrational. You are responding correctly to a gap you built.
Most founder-led businesses under about fifty people have never defined who decides what below the founder. Every real call routes upward by default, not because the team is weak but because there is no written line that says otherwise. The founder becomes the decision layer by accident, and then calls themselves a bottleneck while wondering why nobody takes ownership.
The fix is not a conversation about trust. It is a document.
The artifact: a written decision threshold with one review checkpoint
A decision threshold is a written rule that defines the boundary between acting alone and involving you. It is not a value statement about trust. It is an operating rule, like a speed limit. Below the line, the person acts and tells you after. Above the line, they surface it to you before acting. That is the whole thing.
Here is a real example you can copy and adapt. For a marketing manager in a ten-person B2B business: 'Any spend under $2,000 on a single campaign or tool, Sarah acts and tells Brendan after in the weekly update. Any spend of $2,000 or more, or any commitment that locks us in for more than 60 days, Sarah brings to Brendan before acting.' That sentence replaces a hundred judgment calls. It also gives you, the founder, a clear place to look if something goes wrong. Either the threshold was crossed without escalation, or the threshold was wrong and needs adjusting.
Pair that threshold with one defined review checkpoint, usually the first three handoffs. You look at the output, give specific written feedback, and note whether the threshold held or bent. After three rounds you have real evidence. You are not guessing whether to trust anymore. You are reading a record.
Why the handoff feels irreversible (and how the threshold fixes that)
The reason delegation feels so high-stakes for founders is that it feels permanent. You hand it over and then you have lost visibility. That fear is correct if there is no threshold and no checkpoint. A handoff with no defined rules and no scheduled review really is a black box. Of course you want to keep hold of it.
A written threshold plus a review checkpoint makes the handoff reversible. If the output at the first checkpoint is wrong, you know exactly what failed: either the person crossed the threshold without escalating, or the threshold itself was drawn in the wrong place. Either way, you fix a rule, not a person. That is a much smaller problem than discovering three months later that something was quietly mishandled.
This is the structural pre-condition that most delegation advice skips. The conversation about how to delegate as a founder usually starts at the moment of handoff. It needs to start with writing the threshold.
What the threshold looks like across common founder bottlenecks
The format is the same across contexts. What changes is the specific dollar amount, risk type, or decision category. Adjust the numbers to the actual stakes in your business.
| Decision type | Below this line: act and tell me after | Above this line: tell me before acting |
|---|---|---|
| Vendor spend | Under $2,000 single purchase | $2,000 or more, or any contract term over 60 days |
| Hiring commitment | Extending an existing contractor's hours by up to 10 hours per week | Any new headcount offer or contract over $5,000 total |
| Client-facing promises | Adjusting a project timeline by up to one week | Any timeline or scope change that affects billing or contract terms |
| Operational changes | Changing a tool or internal process affecting only the owning team | Any change that affects another team's workflow or the client experience |
The honest self-test before you write the threshold
Before you write the threshold, answer this question honestly: if your team member made the wrong call on this task, what is the worst realistic outcome? Write it down in one sentence. Then ask whether that outcome is recoverable in less than a week. If yes, the threshold should sit lower than your instinct says. Your instinct is calibrated to worst-case, and most day-to-day calls are not worst-case.
The second question: have you ever told this person, in writing, what a good outcome looks like for this task? Not 'do a good job.' A specific output. If the answer is no, the distrust you feel is not evidence about their capability. It is evidence that you never defined the target. Delegation that feels faster to do yourself almost always has this as the root cause.
If you take a full week away with no contact and watch what stalls, what stalls is what still runs on you. That is the honest inventory of where your thresholds are missing.
This is a structure problem, not a staffing or coaching problem
Founders sometimes respond to the trust problem by hiring a more senior person, on the theory that a better hire will be more trustworthy. That logic fails because the problem is not the person. Hiring a senior operator into a business with no written decision rights relocates the dependency onto them at a higher cost. When they leave, it routes straight back to the founder.
The same applies to coaching. Coaching develops the person. A founder who has never built a decision-rights structure does not need to develop themselves. They need to install a rule. That is structural operating work, and it is done to the business, not to the founder. Once decision rights are defined, most teams can be trusted with far more than founders currently give them. The structure is what makes that safe.
If decisions are still routing back to you and you are not sure where the structure is missing, the free Founder Dependency Diagnostic maps exactly where your week goes and what still runs on you.
Take the free diagnosticCommon questions
What if I write the threshold and my team member still gets it wrong?
Then you have useful information. Either the threshold was drawn in the wrong place, the person lacked the specific context they needed to act correctly, or they crossed the threshold without escalating. All three are fixable with a written rule adjustment or a clearer briefing. What you cannot fix is a vague 'use your judgment' handoff, because there is nothing to adjust. A written threshold gives you a place to look when something breaks.
How do I know where to set the dollar amount in the threshold?
Start by asking what the worst realistic outcome is if they get it wrong, and whether you can recover from it in a week or less. If yes, set the threshold higher than your instinct says. Your instinct is usually calibrated to the worst case. Most operational calls are not worst-case. You can also look at the last ten decisions you made yourself and note which ones anyone competent could have made with the right information. Those are the ones that belong below the line.
My team always escalates everything back to me even when they could decide. Why?
Because you have never given them a written rule that says they are allowed to act alone below a certain line. Without that rule, escalating is the rational choice. If they act and get it wrong, they have no protection. If they escalate and you decide, they are safe. The written threshold is what changes that calculus. Once they know the rule, acting alone is explicitly permitted and escalating minor calls is actually the wrong move.
Is this the same as delegating a task versus delegating a decision?
Related but not identical. A task delegation tells someone what to do. A decision-rights threshold tells someone when they are allowed to choose. Most founders delegate tasks adequately but never define decision rights. The result is a team that can execute a defined task but escalates any call that involves a choice, even a small one. Both are needed. The threshold handles the choice layer.
Should I involve my team in writing the thresholds?
Yes, at least in testing them. Write your first draft yourself, because you know where the real risk lines are in your business. Then share the draft with the person and ask where they would have been uncertain without it. Their answer tells you whether the threshold is drawn at the right level of specificity. A threshold that still leaves them unsure is not specific enough.
What if the real problem is that my team is genuinely not capable enough?
It is possible, but it is less common than founders think, and it is almost always worth ruling out the structure problem first. If a person has never been given a clear target, a written threshold, and a defined review checkpoint, you do not yet have evidence about their capability. You have evidence about the absence of structure. Run three handoffs with the threshold in place. If the output is consistently wrong even with clear rules and clear targets, then you have a real capability question. Most of the time, the output improves considerably once the structure exists.