Cases from the MBA and the Vanguard · MBA module — when operational stability begins to depend on one person
Subtitle: When operational stability begins to depend on one person.
The operation was finally stable. That was when he started to think he had created a new problem.
At one point in his career he had taken responsibility for a high-volume operation run by a large international company. On a busy day the operation served thousands of guests across multiple service locations, with capacity expected to grow significantly. A core team worked alongside staff from other departments. The operation was growing faster than its systems. Many procedures were only habits, and nobody was sure who owned what. Information lived in chat groups, spreadsheets and the heads of a few people who had been there long enough. A broken machine, an unexpected staffing gap or a late delivery could stop an outlet within a short time. His role regularly took him away for several weeks at a time.
He was brought in to stabilize it, and he did what most experienced operators do in that situation. He was everywhere. Morning prep, deliveries, technical problems, staffing, service openings, and every evening a detailed report. If a problem crossed two departments, he found the person who could fix it. If nobody was responsible, he took it himself.
It worked. Problems were caught earlier. Decisions that used to wait for hours were made in minutes. The team knew that if something reached him, it would get solved. For the first time, senior management had the day in writing instead of in phone calls.
Then the behavior around him changed. Supervisors started copying him on things they used to decide alone. Managers waited for his confirmation, because his answer took the risk off them. Other departments learned that the quickest way to get anything done was to call him directly. The more reliable he was, the more landed on his desk.
None of this looked like a problem. Guests were served, audits were passed, the team was grateful. But he could see what was forming. On busy days, the whole operation ran through one phone, and it was his.
During one scheduled absence, the company assigned an experienced relief manager. The person was confident and accustomed to a setting with fixed routines and a clear chain of command. This operation had neither. Some decisions were made without consulting the people who ran the outlets every day, and several did not fit the reality on the ground. Experience from elsewhere could not replace the local context the team already held.
The team saw the gap, but largely remained silent. They knew their regular leader would return, and nobody wanted to be seen as challenging temporary leadership. So they waited.
They did not wait because they could not decide. They waited because he was coming back.
The timing did not help. More facilities were about to open, guest numbers were going up and new people were joining. The operation needed stronger managers and clearer authority. But several of his managers were still learning their jobs, and giving them too much too fast could expose the gaps exactly when mistakes were becoming more expensive.
In this operation, a late decision can affect thousands of guests. A misunderstood staffing instruction can leave an outlet closed at opening time. A technical problem handled without coordination can stop production. In that environment, allowing people to learn through mistakes sounded responsible in a leadership workshop and much less responsible on an operating day.
He saw three options.
The first was to keep close control until the next phase of growth was finished. Standards would hold and the immediate risk would stay low. But the message to everyone would be that difficult decisions still belonged to him. The operation would work well when he was there and become fragile every time he left.
The second was to hand over real authority now, including decisions where mistakes would be visible. Each manager would get a defined area, limits, and a rule for when to call him, and then act without asking for approval. They would grow faster and the gaps would show early. There would also be failures that could have been avoided, and he would have to defend decisions he would not have made himself.
The third was to bring in an experienced second-in-command from outside the current team and give that person the authority the existing managers did not have yet. Standards would be protected quickly and he would be free from daily execution. But the period of temporary coverage had already shown the risk. Experience from elsewhere did not automatically transfer to the operation. And the managers who had been growing into their roles would read the appointment as a message about them.
There was also a personal question he could not avoid. Was he staying this involved because the operation really needed it, or because being needed was more comfortable than watching someone else decide differently? His whole career had been built on walking into difficult situations and fixing them. Stepping back meant watching things get worse for a while, and being seen to allow it.
He had already started to document decisions, clarify who owns what, and ask managers to come with a proposal instead of a problem. But every day pulled him back into execution. Each urgent exception made sense on its own. Together, they kept the new way of working from ever becoming normal.
His next scheduled absence would come during the next stage of growth, and its timing would depend partly on how the new openings progressed. He might need to leave before the expanded operation was fully settled. Senior management expected stability. The team expected him to remain available. He knew that if he waited until everyone felt ready, nothing would change. If he pushed too early, guests and his own people could pay for it.
Before the timing is set, he has to decide what he is ready to let go, what stays with him, and how much short-term risk the company should accept to build managers who can run the operation without him.
Before any discussion, ask everyone to pick one of the three options: keep control through the next phase of growth, hand over real authority now, or bring in an experienced second-in-command from outside the current team. Ask first someone who has taken over an operation that depended on one strong person. They usually know the difference between what an operation really needs and what people have simply learned to expect. Then ask someone from a safety-critical or highly regulated business whether the acceptable cost of developing people changes when one mistake reaches many customers.
The fact most likely to change the room’s answer is why the team waited during his previous absence. They could decide. They waited because they knew he was coming back. If the room decides early that the team is not ready, take them back to that paragraph. If the discussion gets too abstract, ask one practical question: which decision should be handed over next Monday, what are its limits, and what result must never happen? This case is a composite drawn from experiences across the author’s hospitality career. Names, locations, figures and organizational details have been generalized to preserve confidentiality.
The operation has no such system today. But imagine that before his next scheduled absence he could leave an AI operating agent in place, built from daily reports, SOPs, incident history, equipment issues, staffing limits and his own past decisions. Managers would have a shared memory of the operation. The agent could suggest responses, spot repeating problems and flag exceptions. Used well, it would bring context and decision support closer to the people doing the work and reduce the dependence on him.
It could also make the dependence worse. If the agent learns mostly from his decisions, it will copy his judgment at scale, and personal control simply becomes control by a system. Managers stop waiting for him and start waiting for the agent, without becoming any more capable. So the real question is whether the agent should decide the way he does, or help his managers learn to decide for themselves. And when a manager follows a recommendation built on the leader’s past choices, whose decision is it?
He built an operation that works. He has not yet proved it works without him.
A live case: every round can be improved, and the author's feedback is the next one.
The same two questions, answered twice: first without the mentor's corpus, then from it — both volumes of Vanguard Leadership and its handbook.
Without the mentor's corpus
1. I read the silence as borrowed authority, not missing ability. The team saw the relief manager's mistakes, so the judgment was there. What they lacked was ownership: every hard decision had been lent to them, never given, and everyone knew the lender was coming back. Speaking up against a temporary boss costs something. Waiting costs nothing. That is rational, not weak. Management writing calls it upward delegation: the problem climbs back to whoever takes it most reliably, and you took it most reliably of all. So the test is not whether they can decide. It is whether a decision stays with them while you are in the building. Name one owner for each recurring decision and write down its limits. When a decision comes back to you, send it back, even when you would decide it faster. Ask yourself: which decisions did you lend, and which did you actually give away?
2. I would not accept failure in general. I would budget it. Sort the decisions by what a mistake can reach. Where one error touches thousands of guests or anyone's safety (food safety, opening an outlet, critical equipment), keep a checklist and a hard limit, and hand those decisions over last. Where a mistake is reversible and stays inside one outlet or one shift (a rota change, a substitute supplier, a local repair), hand them over now. Allow a set number of visible errors a month, as reliability teams run an error budget. Spend that budget before the growth phase, not during it. Make your coming weeks on site a rehearsal of your absence, reachable only for three named red lines. Small, early, visible mistakes are the price. Mistakes that reach thousands are prevented by design, not by your presence. Ask yourself: which three decisions could go wrong next week without a guest noticing, and why are you still making them?
From the mentor's corpus
1. Vanguard Leadership's second volume explains the silence. In its Command Layer chapter, trust is the medium through which intent travels. Where trust is missing, intent reads as vague instruction; where it is present, intent reads as pre-authorised judgment. Your managers were never pre-authorised; they were covered by you. When a relief manager arrived without that trust, silence was rational. They had the judgment, because they saw the gaps. They did not have the authority. The same chapter splits the accountability. The subordinate answers for the action. The commander answers for the intent, the boundaries and the authorisation, and both are on the record. You have been answering for both. For each manager's area, write down the intent, the boundaries and the authorisation, and show them to the whole team, so nobody waits for your return to know who decides. Ask yourself: if I wrote down today what each manager may decide without me, how long would the list be?
2. The Vanguard Leadership Handbook sorts decisions by reversibility and impact. Irreversible, high-impact decisions take time and documented logic. Reversible, low-impact ones are made fast. Reversible, high-impact ones move quickly but are instrumented heavily. Hand the second kind to your managers on Monday. Hand over the third kind with its instruments: the daily report, one escalation line, and an after-action review, which the book uses to turn a blame-filled post-mortem into safe learning. Keep the first kind, but set a date for handing it over. The first volume then asks you to test your own motive. It describes the micromanagement impulse and the difficulty of delegating as control used to relieve anxiety, and it warns that a leader who does not develop others leaves the operation dependent on him. Accept failures that are survivable and teach something; refuse only those that are not. Ask yourself: am I keeping these decisions because the operation needs me, or because I need them?
On the NEO Turn. The Command Layer chapter also answers the NEO Turn. It gives an AI agent a declared autonomy level (HAI5), boundary conditions it cannot cross without leaving a receipt, and an after-action review. Set the operating agent at "Human decides after AI recommends", so the decision stays the manager's and on the record as theirs. Volume 2's warning about AI applies here: the failure is using AI as a substitute for judgment instead of as a tool for preparation. Built only from your past decisions, the agent would copy you at scale. Built to prepare your managers, it would build them.
A question for the table, a disagreement, what you would have done. The case lead reads every comment; the ones the table takes up enter the chapter as questions from the room, with your name.