You delegated a function three months ago. You are still answering questions about it.
Not every day. But often enough that you have noticed. A Slack message asking whether a certain call is okay to make. A "quick question" that takes twenty minutes. A decision that lands back on your desk because the person you handed it to was not sure it was theirs to make. You delegated the work, and somehow the work still routes through you.
If that is happening, you do not have a trust problem and you do not have a people problem. You have a system gap. And it is almost always one of four specific gaps.
The 60-second self-diagnostic
Here is the fastest way to find which one. Think about the last few questions someone asked you about something you already delegated to them.
Gap one, decision rights. If they asked whether they were allowed to make a particular call, whether a decision was theirs or yours, then their decision rights are undefined. They are not asking because they lack judgment. They are asking because nobody told them where their authority ends.
Gap two, information access. If they asked for context, what happened with this client before, why the budget is set this way, how this kind of thing usually gets handled here, then they have an information gap. They cannot make the call because they do not know something you know.
Gap three, feedback cadence. If you cannot remember the last time they asked, but the function has quietly drifted off course, then there is no feedback rhythm. Nothing signaled the drift until it got expensive.
Gap four, escalation protocol. If they bring you either everything or nothing, never the right things at the right time, there is no escalation protocol. They are guessing at when to involve you, and guessing wrong in both directions.
Decision rights. Information access. Feedback cadence. Escalation protocol. Almost every delegation failure is one of those four. The work got handed off. The architecture that would let someone else actually run it did not get handed off with it. Naming which of the four gaps you have tells you exactly what to build.
Intentions are not systems
Most organizations do not have a delegation system. They have delegation intentions.
A delegation intention is the decision that someone else should do the thing. A delegation system is the architecture that lets them actually do it: reliably, knowing when they are getting it right, able to course-correct when they are not, and clear on when to bring it back to you. Without that architecture, the intention produces handoffs that break, ownership that is theoretical, and a founder who re-enters every delegated domain within thirty days because the alternative is watching it fail.
Here is the sequence that plays out when delegation runs on intention alone. You decide to delegate a function. You tell the person. They understand the instruction. Then they hit the first decision the handoff conversation did not cover. It has stakes. They are not sure it is within their authority. They do not want to make the wrong call. So they ask. You answer. They file it away. Two weeks later, a similar decision shows up with slightly different parameters. They ask again. You answer again.
Over time, the person learns that asking is the correct move in any ambiguous situation. You learn that the delegated function still needs your regular input. You changed the distribution of the work. You did not delegate the cognitive load. You are still the operating system. You are just running on a different interface now.
That is not a failure of trust. It is a failure of system design. The person asking does not have what they need to make the call themselves. They were handed responsibility without being handed the framework for exercising it. The asking is rational. The system that requires the asking is the problem.
The four components of a delegation system that works
You may already be familiar with RACI: responsible, accountable, consulted, informed. It is the standard framework for mapping who does what on a given task. It is fine. The problem I see with RACI is the overcomplication of participation design early on. I have watched teams spend hours filling in the grid, color-coding the matrix, debating whether someone is consulted or merely informed, and then the whole thing stays in the deck and never gets practiced. If you are flying a plane or running an operating room, define it to that level. Most teams are not, and rarely follow it when they do.
So here are four simpler components of a solid delegation system. They will make sense the moment you read them, because you already know them. They have just never been defined out loud for the function you delegated.
What decisions can the person make. Be specific. Which decisions they make alone, which require a conversation with you before acting, and which require your approval. Define those three buckets explicitly, or every ambiguous decision defaults to the highest authority available, which is you, which is the failure. The test is behavioral: if they are asking you scope questions, the rights are not clear enough yet.
What information do they need to make those decisions. You hold the history of the client relationship, the reasoning behind the budget, the unwritten rules about how certain calls get made here. That context is what makes your judgment possible. It has to move with the function, or the person cannot exercise the judgment the delegation assumes. Information gaps produce asking. Close the gap and most of the asking stops.
When and how is feedback planned. A delegated function with no check-in rhythm drifts. Not from inattention, drift is just what happens without a feedback signal, and drift caught late costs far more than drift caught early. The cadence does not need to be frequent. It needs to be regular and aimed at the right thing: not what happened this week, but whether the function is trending the way it needs to over a longer arc. A monthly conversation about the health signals beats a daily review of activity.
What is the escalation protocol. When should the person bring something back to you, and how? This is the part most frameworks skip, and it generates the most expensive failures. The best model I know for it comes from the Toyota Production System: the andon cord. On a Toyota line, any worker who spots a problem pulls the cord, which signals a team leader to come look immediately. What made it work was not the cord. It was the culture around it. Workers were not given a right to pull it, they were considered obligated to pull it the moment they saw a problem, and when they did, a leader actually came to see, rather than ignoring the signal.
Most teams run significant inefficiencies because one of those two things is broken. Either someone is too afraid to pull the lever, or they pull it and the person above them ignores the signal. Building a culture where people escalate freely, not just the major problems but the micro-inefficiencies, and where leadership actually responds when they do, is one of the highest-return moves available to an operation. The escalation protocol is just the andon cord for your delegated functions: the specific, limited set of situations that warrant a pull, and the guarantee that pulling it gets a real response instead of a penalty.
The pattern nobody wants to name
There is a founder-side dynamic here that deserves honest attention, because it is often the real reason.
Some founders do not actually want delegation to work. Not consciously. Not as a stated intention. But somewhere in how they set up the handoff, in the standard they hold the work to, in how they react when it comes back at ninety percent of what they would have produced, they build the conditions for it to fail.
The standard gets set at the level of the founder's own execution rather than the level the function actually requires. The feedback is critical enough to discourage without being constructive enough to produce improvment. The founder re-enters at the first real error instead of letting the person learn from it. The message, sent through behavior even when the words say otherwise, is that the bar is the founder's personal standard and anything short of it is insufficient.
Underneath that, often, is ego. Not the cartoon kind. The quiet kind that wants to remain the hero of the company's story. The founder keeps positioning themselves as the brain, the strategy, the source of every real insight, because that position is load-bearing for their identity. A system where everything routes back through them is not an accident. It is the system the ego wants, because it keeps them indispensable. It is why one of my favorite lines I have ever landed on is this: a founder cannot scale a company past his ability to micromanage it. If you are the bottleneck by design, the company's ceiling is your personal bandwidth, and that ceiling is one of the most common constraints I see in early-stage companies.
That is not a delegation system. It is a retention system for the founder's own involvement, and it works perfectly. Either the person hits the founder's standard, which takes the founder's continuous input to reach, or they do not, which justifies the founder stepping back in.
If your delegation keeps failing across different people, different frameworks, and different conversations about trust, it is worth asking whether the system you built is designed to succeed or designed, underneath your awareness, to need you.
The most expensive version
The costliest delegation failure is not one handoff breaking. It is the slow accumulation of single points of failure: functions where one person's departure, absence, or burnout would make the whole thing unworkable, because the function lives entirely inside that person's knowledge, judgment, and availability.
Every organization has some. Most have more than they know. The discovery comes at the worst possible time, someone leaves or gets sick, and the function turns out to be entirely person-dependent, with no documentation, no backup, and no system anyone else can run.
This is a delegation problem too, just one level deeper. Not the delegation from you to the person, but the delegation from the person to a documented, reproducible system. A function only one person can run is not a delegated function. It is a dependency wearing someone else's name. You moved the dependency off your desk. You did not remove it from the organization.
Real delegation builds functions, not just assignments. For every significant function, the question is: if the person running this left tomorrow, what breaks, and how long to recover? That answer is the system gap. Closing it, through documentation, cross-training, and explicit design, is what turns delegation from a management habit into an operational asset.
What to do with this
Map every function you have delegated or intend to, and score each against the four components: decision rights, information access, feedback cadence, escalation protocol.
For each function, find the weakest one. In most organizations it is decision rights, because clarity there takes the most explicit conversation and most founders prefer to keep it implicit. Information access is usually second, because it forces you to externalize knowledge you have always just carried in your head. Feedback and escalation tend to be better by default, since they involve scheduled interactions rather than definitional work.
Build the weakest one first. Write out the decision rights for a single delegated function clearly enough that the person could run it for a month without asking you one scope question. Then watch. Their questions are your system gap, not their capability gap.
If you're a founder or CEO
The hardest part of this is not building the four components. It is the pattern nobody wants to name: whether the standard you hold delegated work to is the standard the function needs, or the standard your own hands would produce, and whether some part of you is keeping the company routed through you because being the hero of it is load-bearing for your identity. If that is live, no new hire or framework will fix it. This is where constraint coaching with a founder usually goes, past the org chart and into the wiring. A founder cannot scale a company past his ability to micromanage it. The ninety percent, done by someone else, reliably, is the whole point of delegation, and getting there means letting your ego stop being the operating system.
If you're a nonprofit executive director
Nonprofit delegation tends to break in two specific relationships. Between you and program staff, and between you and the board. Program staff are often handed accountability for outcomes without authority over the decisions that determine those outcomes. They own the results but not the resources, the partnerships, or the design. That is not delegation, it is a setup for failure. And board-to-ED delegation has the mirror problem: you hold broad operating authority in practice while the board retains governance authority that has never been clearly defined, so the escalation corridor between you exists in the bylaws but not in language either side can actually navigate. The result is either an ED who over-escalates and turns governance into operations, or one who under-escalates and leaves the board to learn about major developments in the worst possible context. Clear delegation architecture between board and ED is one of the highest-leverage governance investments a nonprofit can make, and one of the least often made. Building it is core leadership facilitation work, and it is worth doing before the crisis that exposes the gap.
Frequently asked questions
Why does delegation keep failing even when founders genuinely try to let go? Usually because there is no delegation system, not because there is no trust. A delegation intention transfers responsibility. A delegation system transfers the architecture for exercising it: decision rights, information access, feedback cadence, and escalation protocol. Without those four, the person hits ambiguity, lacks context, gets no reliable feedback signal, and has no clear protocol for when to ask. The resulting behavior, asking, re-escalating, operating with incomplete judgment, is rational given the conditions, not a failure of capability.
Is RACI a good delegation framework? RACI (responsible, accountable, consulted, informed) is useful for mapping participation on a task, but it tends to get overcomplicated early. Teams spend hours building the matrix, then it lives in a deck and never gets practiced. Unless you are in an environment that demands that level of precision, like aviation or surgery, a simpler model works better: define what decisions the person can make, what information they need to make them, when and how feedback happens, and what the escalation protocol is. Those four get practiced because people already intuitively understand them.
What are decision rights and why do they matter most? Decision rights define specifically what a person can decide alone, what requires a conversation before acting, and what requires approval. They matter more than the other components because their absence is the main generator of escalation, every undefined decision defaults upward. The test is behavioral: if the person you delegated to is asking scope questions, the rights are not clear enough. That ambiguity is a system gap, not a capability gap.
How does the Toyota andon cord apply to delegation? The andon cord is Toyota's escalation model: any worker who spots a problem pulls it, and a leader comes immediately to help. It works because of the culture around it, workers are obligated to pull it, and leaders actually respond when they do. Most teams fail at escalation in one of two ways: people are too afraid to raise problems, or they raise them and leadership ignores the signal. A delegation system needs the same thing the andon cord provides, a clear, safe, expected path for escalating both major problems and small inefficiencies, with a guarantee that escalation gets a real response rather than a penalty.
How do you know if you are unconsciously designed to need the delegation to fail? Ask whether the standard you hold delegated work to is the level the function requires or the level your own execution would produce, and whether being the indispensable center of the company is load-bearing for your identity. If the bar is your personal standard and anything short triggers your re-entry, you have built a system that needs you rather than one that succeeds. A founder cannot scale a company past his ability to micromanage it, so if everything routes back through you by design, the company's ceiling is your own bandwidth.
So much respect.