The complaint sounds familiar. The team is slow. Decisions take days. Projects stall mid-execution, and nothing moves without a nudge.

You have hired capable people and briefed them properly, but the output is still lagging. So the question becomes: what is wrong with them?

The harder question is: what if the answer is you?

Most founders who complain about slow teams are the same ones who require approval for every email, brief, and design iteration. The team is slow because it is waiting. And it is waiting because you have trained it to.

The team is slow because it is waiting. And it is waiting because you have trained it to

This post is a management diagnosis. It traces a specific failure pattern: centralised decision-making disguised as quality control. It explains why the instinct to stay involved in everything leads to the very slowness you are trying to fix.

And it gives you a structural remedy, a documented decision framework that removes you from the critical path without removing your standards.

The fix requires less heroics from you.

The target reader is anyone who has ever said, “My team can’t work independently,” and also has their name on every final approval. These two facts are related. This post explains how.

The Symptom

The symptom looks like a people problem but behaves like a system’s problem.

When a team consistently escalates decisions upward, waits before acting, or produces work that requires multiple rounds of revision before it gets approved, the natural diagnosis is competence. The team lacks judgment. The hires were wrong. The culture is soft.

But organisational design research consistently shows that escalation behaviour is a learned response.

When the person at the top frequently overrides decisions, teams stop making them. Every override sends the same signal: your judgment is unreliable. Keep asking.

Companies where frontline managers hold real authority make decisions up to five times faster

The data on decision velocity is specific. A 2023 McKinsey study on organisational agility found that companies where frontline managers hold real authority make decisions up to five times faster than those where decisions are routed to senior leadership. Five times.

The bottleneck is the approval layer sitting above it. And in most small businesses, that approval layer has a name.

The symptom worth auditing is how many decisions were made in the last week that required your direct input before moving forward? If the answer is more than a handful, the system is structured around your presence rather than your standards.

Those two things feel identical from the inside. They produce very different results on the outside.

The Diagnosis

Centralised control is a confidence problem wearing a quality-control costume.

The mechanism is straightforward. A founder builds a business by making every decision themselves. That works at the start, because the founder holds all the context. Then the team grows, and the habit of deciding everything persists.

The founder continues to review copy, approve meeting agendas, and comment on client email drafts, as the quality is better with their involvement.

The conclusion drawn is that their involvement is what makes the output good. The conclusion should be that their involvement prevented the team from developing its own standard.

Harvard Business School research on delegation found that only 30% of managers believe they delegate effectively.

Only 30% of managers believe they delegate effectively

Most founders think they are delegating when they assign a task. Assigning a task while retaining the final decision is outsourcing the work while keeping the authority.

The team does the work. The founder thinks. The result is a system that scales the founder’s bandwidth rather than the team’s capability.

The diagnosis is dependency by design. The team is behaving exactly as it was trained. When every decision flows upward for approval, teams learn to optimise for your preferences rather than for outcomes.

They stop trusting their own reading. They stop taking initiative. And then you say, “This team has no initiative.”

The Mechanism

Approval chains create the exact dysfunction they were designed to prevent.

The logic of centralised approval seems sound: if the best person reviews every decision, the quality will be higher. But this logic fails under two conditions that apply to every growing team.

First, the bottleneck’s time is finite. When you are the required reviewer for every decision, you rate-limit the entire organisation to your available hours. Every hour you spend approving a social caption is an hour you cannot spend on strategy.

The team slows down because it is waiting for you.

Teams in high-autonomy environments develop faster

Second, centralised approval atrophies the team’s decision-making muscle. Research from Harvard Business School professor Amy Edmondson on psychological safety shows that teams in high-autonomy environments develop faster, surface better ideas, and catch errors more reliably than teams in approval-heavy cultures.

The reason is structural: when people know their judgment will be overridden, they stop exercising it. Approval cultures produce compliance.

The RACI framework (Responsible, Accountable, Consulted, Informed) exists precisely to break this pattern. RACI separates who does the work (Responsible) from who owns the outcome (Accountable) from who provides input (Consulted) from who needs to know (Informed).

Most approval-heavy founders are simultaneously Responsible, Accountable, and Consulted on everything. RACI forces the question: which of these roles actually requires you?

The Fix

Delegate authority. The tasks will follow.

The most common delegation failure is giving someone a task without the authority to complete it. The team member writes the brief, runs the meeting, builds the slide, and then waits for approval before sending it.

Nothing has been delegated except effort. Authority remained with the founder. True delegation means transferring the right to make a final decision, including the right to be wrong.

That transfer is what builds capability. Without it, you are running a very expensive filing system.

The SBI framework (Situation, Behaviour, Impact) provides a structure for delegation that actually sticks.

Situation: provide the full context, including the goal, constraints, and success criteria. Behaviour: define specifically what you need done. Impact: explain why it matters and what a good outcome changes.

The team stops asking for permission because the framework has already granted it

Most delegation conversations skip all three and go straight to “Can you handle this?” The team member says yes, and neither party has agreed on what yes means. Failure is almost guaranteed, and the founder concludes that they cannot delegate.

The second structural fix is a documented decision framework. This is a single page that answers three questions for any recurring decision type: who can decide it unilaterally, who needs to be consulted before making the decision, and who should be informed afterwards.

When this document exists and is trusted, it removes the need to escalate, because the authority boundary is explicit. The team stops asking for permission because the framework has already granted it.

You stop getting pulled into decisions because the document has already resolved them.

The Standard

A well-run team does not need you for the day-to-day. That is the goal.

The leadership standard shifts when you move from operator to architect. The operator is in every decision. The architect designs the system that makes good decisions without them.

A useful way to think about this distinction comes from organisational design research on decision rights: not all decisions carry equal stakes.

Irreversible, high-impact decisions warrant deliberation and senior input. Reversible, routine decisions should be made quickly by the person closest to the information.

Most founders treat everything like the former. Most decisions are the latter.

Routine decisions should be made quickly by the person closest to the information

The test of a well-delegated system is clean. If the work moves forward when you are out of the office, the system is working. If it stalls, the system depends on you. That dependency is neither loyalty nor quality control. It is fragility.

A business that requires its founder’s presence to function is a job with expensive overhead. The goal is to make the routine unnecessary.

Clarity about who decides what is the minimum viable structure for any team that plans to grow.

The decision framework, the RACI, and the SBI handoff are the infrastructure of autonomy. And autonomy is the only way to remove yourself from the critical path without lowering the standard.

Build the System First

The bottleneck problem is fixable, and the fix is structural.

The symptom is a slow team. The diagnosis is a founder who retained every approval. The mechanism is a dependency created by unclear or absent decision rights.

The fix is to delegate authority through documented frameworks, starting with an RACI that defines who owns what and an SBI approach for every handoff.

The standard is a team that moves without you, because the system carries your judgment forward.

The standard is a team that moves without you, because the system carries your judgment forward

This is the same philosophy that runs through every Zazoozoo engagement. The deliverables, the documented SOP, the decision checklists, and the publishing governance systems are all designed to create independence.

The strategy your team executes should work whether the founder is in the room or not.

A system built on one person’s approval is a bottleneck waiting to stall. A system built on documented standards is an infrastructure that scales.

This week, identify one decision your team currently escalates to you. Write down the criteria for a good outcome. Assign it permanently.

That is how you start removing yourself from the critical path, one decision at a time.