Delegation Dies at the First Mistake
Most handovers die at the first mistake. Not because the person was wrong, but because nobody agreed in advance how much could go wrong.
I watched a founder hand his weekly production plan to a plant manager on a Monday morning. By the second week there was one stockout. A single product, one day, one unhappy client. By the third week he was back to signing every plan himself. When people talk about founder burnout scaling a business, they picture overwork. What I saw that month was quieter and more structural than overwork. It was a handover that lasted eleven days.
The Moment Delegation Dies
Almost every delegation in a founder-led company has a precise moment of death, and it is rarely the handover. It is the first mistake. The task leaves the founder's desk, runs for a week or two, hits one error, and comes straight back. Everyone in the room calls it a lesson. The founder says the person was not ready. The person, in most cases I have seen, was perfectly ready. What was not ready was the founder's tolerance for an imperfect first attempt.
What Actually Broke
Here is the part that took me years to see clearly. The founder transferred the task. He did not transfer the right to be wrong. He handed over the doing while quietly keeping a standard that only he is allowed to miss: correct on the first try. A plant manager who makes one scheduling error in week two is not failing. He is doing exactly what a human doing a new job does. But if the unspoken rule is zero defects from day one, then the first mistake is not feedback. It is a verdict.
A person operating with no margin for error is not being delegated to. They are being supervised with a longer leash. The leash felt like freedom for eleven days. The moment it was tested, it snapped back, and the founder mistook the snap-back for wisdom.
The Second Version of the Same Story
I saw the identical pattern at a Rs. 35 Cr services firm, in a completely different function. The founder handed client scoping to a senior account lead. One proposal went out underscoped, the margin on that project thinned, and within a fortnight the founder was reviewing every scope again. Same disease, different organ. The account lead had not become incompetent overnight. She had made one reversible mistake, and the founder responded as if it were a fatal one. That confusion, between a mistake you can undo and a mistake you cannot, sits at the centre of this whole problem.
The Misdiagnosis
When this happens, founders almost always reach for one of two explanations, and both are wrong. The first is I hired the wrong person, which sends them into another hiring round for a problem no hire can solve. The second is I will delegate again when they are ready, which is a polite way of saying never, because readiness is defined as never making a mistake, and no one clears that bar. Both explanations protect the founder from the harder truth: the terms of the delegation were never set.
The Real Cause
The structural cause is missing tolerances. In a working system, every delegated decision carries a defined margin: how much can go wrong, how it gets caught, and at what point someone steps back in. In a founder-led business that runs on the founder's instinct, none of that is written down, because the founder never needed it. He absorbed his own errors silently and corrected them before anyone noticed. So when he hands the task over, he hands over the visible work but not the invisible shock absorber. The delegate inherits the job without the buffer, and the first bump throws them off the road.
What the Fix Actually Looks Like
The fix is not motivational and it is not a personality change. It is a small piece of architecture you install before the handover, not after the failure. Three parts. First, an error budget: name, in advance, how many mistakes or what size of mistake the role is funded to make. Second, a correction loop: a defined moment, weekly or per decision, where the mistake is examined together and the pattern is adjusted. Third, a re-engagement threshold: the specific point at which you, the founder, step back in by design rather than by reflex. When those three exist, the first mistake stops being a verdict and becomes data.
How to Size the First Error Budget
When founders ask me how to set the number, I give them four questions to answer before the handover, not after. Is this decision reversible within a week? If yes, fund at least three mistakes before any review, because the cost of a wrong reversible call is a day, not a year. What is the worst realistic cost of one wrong decision here? Put a rupee ceiling on it, and delegate freely under that ceiling. Who catches the error, and how fast? Name the detection point, so a mistake surfaces in days rather than quarters. And finally, at what point do you step back in? Decide that in advance, so re-engagement is a rule, not a reflex triggered by the first bad week.
The Objection Founders Always Raise
But some mistakes are fatal, they tell me, and they are right. This is why you sort decisions by reversibility before you fund them. A reversible mistake, a wrong reorder, an underscoped proposal, a mistimed campaign, deserves a generous error budget, because you can undo it cheaply. An irreversible one, a compliance breach, a safety call, a contract you cannot exit, deserves a tight one or none at all. The founder's error is not funding mistakes. It is collapsing both kinds into a single zero-defect standard, so the reversible mistakes get punished as harshly as the fatal ones, and nothing ever leaves the founder's desk.
The Principle
The founders who eventually scale past themselves are not the ones with unusually gifted teams. They are the ones who fund the first mistake in advance instead of punishing it in hindsight. Founder burnout, the kind that comes from re-absorbing every task after every stumble, is not a workload problem you fix with a holiday. It is a tolerances problem you fix with a number.
Delegation without a margin for error is not delegation. It is supervision with extra steps. If your last three handovers all came back to you after one error, do not look at your team. Look at the standard you never wrote down.
If you want to find where this is sitting in your own company, that is what a structured diagnostic is built to do.