Why Everything Still Comes Back to the Owner, Even After Delegating
An operations director in place for more than a year, and the owner's phone still ringing. Before concluding that the hire was wrong or that the owner cannot let go, it is worth looking at how information, decision rights, and responsibility were distributed.
Tuesday, 4:40 p.m. The dispatcher at a regional trucking company calls the owner: can a truck go out tomorrow to a customer whose account is 60 days past due? The operations director is in the next office. He was hired fourteen months ago for exactly this kind of decision. The dispatcher is not going around him out of distrust. Last time, the director refused a similar delivery, the customer called the owner, and the truck left the next morning. Everyone saw it. Since then, the fast path to a decision that will hold runs through the owner. The dispatcher is applying what he learned.
When the owner gets pulled in, it is for one of four things: information only he holds, an authorization nobody else has the right to give, a call between two priorities that nobody has the mandate to make, or expertise that is genuinely rare. On the phone, the four requests sound alike. They do not call for the same response, and a hire or a piece of software generally resolves only one of them, when it resolves any. The thesis to examine: the dependency persists less because of the people than because of an inconsistent distribution among three things that should go together, the information needed to decide, the right to decide, and responsibility for the consequences.
A company that has been operating for fifteen years has usually accumulated hundreds of arrangements. The customer who pays at 75 days because he stayed loyal through a bad year. The supplier who was promised volume in exchange for a rate. The employee who leaves at 3 p.m. on Fridays. The price schedule negotiated for a major account and never entered into the system. Each exception was decided by the owner, often verbally, and lives in his memory. The system encodes the rule. The new director inherits the rule and the org chart, not the exceptions. Every time an operation touches a customer or supplier with an arrangement attached, the process runs into information that one person holds, and the question goes up. The director did not lack initiative; he lacked information that existed nowhere else. That is why an ERP or a hire can leave the mechanism intact. One formalizes the rules, the other adds a person to apply them. Neither transfers the memory.
The director answers for service, delays, and complaints. He cannot approve a credit exception, an unbudgeted $1,500 purchase, or overtime on a Saturday. He carries the consequences of decisions he has no right to make. In that position, his rational behavior is to seek approval. The employee's rational behavior is to go straight to the person who can say yes. The owner's rational behavior, knowing the customer and the history, is to answer, because it is faster. Nobody is behaving badly. The system is producing what it was built to produce.
The least visible link sits in the opening scene. A director's decision, reversed by the owner after a call from the customer, is not just an exception. It is a message: it tells the whole team where real power sits and which path avoids a refusal that will not hold. A few reversals are enough to establish the workaround. The workaround sustains the dependency, and the dependency then serves as proof that "the director doesn't have what it takes." The owner observes the consequence of his own ruling and attributes it to the person. The link has limits. Not every consultation of the owner is a symptom: a new situation, a real financial risk, or a customer relationship the owner keeps by choice all justify an escalation. And some reversals are correct. If the credit policy handed to the director was too rigid, the owner was right to contradict it; the problem is then the policy, and the fix is to change the rule rather than work around it case by case.
Then there is the person everyone says the company could not do without. Her indispensability often has less to do with talent than with position: she compensates, by hand, for the breaks in a process. She knows the orders promised outside the system, calls back the supplier who has not confirmed, knows which customer will tolerate a delay. She is recognized for it, and that recognition is the rewarded behavior. Documenting her workarounds would cost her what sets her apart. The process stays broken, and the dependency moves from the owner to her, which is not an improvement.
A trucking and warehousing company, 45 employees. The owner hired an operations director fourteen months ago, still receives frequent requests from the team, and is considering replacing him. First reading: a people problem. The clue comes from a log kept for five days: 47 requests. Eleven come from two people, the dispatcher and the credit clerk, and concern seven customers. All seven have an arrangement negotiated by the owner: payment terms, service priority, or a special rate. The log also shows three of the director's decisions reversed within the week, each time after a direct call from the customer. The verification: list the accounts with arrangements attached, about twenty, then look for where those arrangements are recorded. Nowhere in the system, except for a parallel price schedule in an Excel file kept by the credit clerk, which the director had never had access to. Classifying the 47 requests gives 19 missing pieces of information, 15 authorizations, 8 priority conflicts between dispatch and the warehouse, and 5 questions of genuine expertise.
What this allows the owner to conclude: most of the dependency is about information and authorization, not the director's initiative. What it leaves uncertain: how the director would decide once equipped with the information and the right to decide. The log does not say; only an actual transfer will. The decision: an exceptions register for the twenty accounts, written with the owner. Transfer of a first process, the handling of past-due accounts, with explicit thresholds and the owner's commitment to redirect every customer call to the director for 60 days. A new log at the end of the 60 days. If the requests do not fall, the question about the person becomes legitimate again, and it will be asked on facts.
For one week, the owner notes every request: time, person, subject, and above all what was actually being asked for.
| What the person was asking for | What it reveals | Appropriate intervention |
|---|---|---|
| Information only the owner holds | An unrecorded exception | Transfer the memory: an exceptions register by customer, supplier, employee |
| An authorization | A decision right that is absent or unclear | Set explicit thresholds; the owner commits not to reverse within them |
| A call between two priorities | Nobody has the mandate to decide | Designate an arbiter or a priority rule, not one more meeting |
| Exceptional expertise | A rare skill | Keep it, but count it: if it comes up every week, it is no longer exceptional |
Three questions complete each line: could someone else have answered? Would the owner's answer have differed from the manager's? Was an earlier decision reversed? The log has limits. One week can be atypical. The team, knowing the owner is taking notes, may stop asking for five days, which is itself information. And the log does not capture commercial dependency: if customers want to talk to the owner because he is the salesperson, no internal redistribution will change that until the relationship is transferred as well.
Not everything. The memory of exceptions first: it is the one thing no hire can bring, and it transfers in writing. Then authorizations within thresholds, with the hardest commitment for an owner: not reversing them, and when he wants to change one, going through the manager rather than over him. Genuine expertise and strategic decisions can stay, provided the owner knows how many times a week they are actually called on.
Mirabilys supports this work as a decision mapping and the transfer of a first process: log, classification, exceptions register, decision thresholds, and follow-up of the transfer over 60 days. If you have hired and the phone still rings, this is the first thing to examine.
Why does delegation fail even after a good hire?
Because three things that should travel together are distributed inconsistently: the information needed to decide, the right to decide, and responsibility for the consequences. A hire or a piece of software generally fixes only one of them.
What is the memory of exceptions?
The hundreds of arrangements the owner decided over the years: payment terms, service priorities, special rates. No system or hire transfers it automatically; it transfers in writing, in a register.
What should stop being centralized first?
The memory of exceptions, then authorizations within explicit thresholds, with the hardest commitment for an owner: not reversing decisions made inside those thresholds.
Book a 30-minute discovery call
For owners of 1-20 M$ businesses. A fixed-fee mandate, identical for every client: six weeks, nine components.