How to Delegate Without Micromanaging: 5 Levels

How to Delegate Without Micromanaging (What Actually Works)

September 02, 20267 min read

How to Delegate Without Micromanaging (What Actually Works)

Micromanaging is not a character flaw. It is a gap between authority and trust.

Delegation is not the transfer of work. It is the transfer of decisions.

There are two ways to get delegation wrong, and most advice only warns you about one of them.

The one you have heard about is micromanaging. Hovering, checking, correcting. Everybody knows that is bad.

The one nobody warns you about is the opposite. You hand something over, you deliberately stay out of it, and it comes back to you anyway — late, half-finished, or as a question. Now you are the problem twice: you were too involved, and then you were not involved enough. That is delegation by disappearance, and it works about as well as it sounds.

Both failures have the same cause. Once you can see it, delegation stops being a personality trait you are supposed to fix and becomes something you can design.

The three layers of any piece of work: the tasks, the outcome, and the decisions — with decisions marked as the layer almost nobody transfers and the only one that determines whether the work comes back.
Exhibit 1 — Every piece of work has three layers. You are probably transferring the first two.

What you are actually handing over

Almost every delegation conversation gets one thing wrong: it treats delegation as the transfer of work. It is not. It is the transfer of decisions.

When you hand over work but keep the decisions, you have created something that looks like delegation and behaves like a bottleneck. The person does the task. Then they reach the first point requiring judgment — and they come back to you. Which they should, because you never gave them the authority to go further.

At that point you have two options and both are bad. You answer, which teaches them to come back. Or you say figure it out, which feels like abandonment, because you have handed over responsibility without permission.

Any piece of work has three layers. The tasks — what gets done. Most owners transfer this. The outcome — what "done" means. Some transfer this. The decisions — the judgment calls that come up on the way. Almost nobody transfers this, and it is the only layer that determines whether the work comes back.

Owners skip the third layer for a reason worth naming. Decision authority feels riskier than task assignment. If I give you a task and you do it badly, I can fix it. If I give you authority and you use it badly, there is a decision out in the world I did not make. So we keep the authority, hand over the work, and then wonder why nothing is really off our plate.

The five levels of decision authority

Authority is not binary. It transfers in stages, and naming the stage is most of the work.

Level one — Inform. You decide, and you tell them what you decided and why. It sounds like the lowest level, and it is, but the why is doing real work. Every time you explain your reasoning you are installing it.

Level two — Consult. You still decide, but you ask what they would do first. They practise judgment at no risk, and you get a read on how close their thinking is to yours — which is the information you need before going further.

Level three — Delegate. They decide and tell you before they act. You can intervene, and mostly you will not. This is where most delegation should live for a while. It is also the level most people skip straight past.

Level four — Ratify. They decide, they act, and they tell you afterwards. You are informed, not consulted. The decision is genuinely theirs now; you simply stay in the loop.

Level five — Decide. It is theirs. You find out through the normal reporting rhythm, or you do not find out at all, because it does not need you.

The five levels of decision authority: inform, consult, delegate, ratify, decide — with level three marked as where most delegation should live and the level most people skip.
Exhibit 2 — Authority is not binary. It transfers in stages.

The failure I see most often is a founder going from level one to level five in a single conversation — usually out of frustration, usually with the phrase you own this now. Then being surprised when it comes back, or comes back wrong.

That is not the person. That is a four-level jump.

Why you hover

Here is the part that answers the question in the title.

Micromanaging is what you do when someone is operating at level four and you only trust them at level two. The gap between actual authority and earned trust is exactly the space where hovering happens.

So you do not fix micromanaging by trying harder to back off. You fix it by naming the level, out loud, explicitly:

"On this decision, you are at level three. You decide, tell me before you act, and I will only step in if I see something you cannot. In two months, if this keeps going well, we move you to level four."

Two things happen. You stop hovering, because you have been given a legitimate touchpoint instead of an anxious one. And they stop guessing, because they know exactly how much room they have.

The sixty-second conversation script for naming a delegation level out loud, moving a person from an unnamed level to level three with a review point at level four.
Exhibit 3 — You do not fix hovering by backing off. You fix it by naming the level.

The fifteen-thousand-dollar sentence

I sat with a CEO of a manufacturing business, around eighteen million in revenue, who told me he had delegated purchasing to his operations lead three times. Three times it came back.

So I asked him what the operations lead was allowed to spend without asking.

He did not know. There had never been a number.

What actually happened every time was this: the ops lead would take it as far as he could, hit something above what felt safe, and come back. And each time the CEO read that as this person cannot own purchasing.

We set a number. Fifteen thousand dollars — decide it yourself, tell me afterwards. Above that, come to me with what you would do and why.

It never came back again. Same person, same job. The only thing that changed was that the boundary existed.

What to do this week

Pick one thing you have delegated that keeps coming back. Just one.

Write down which of the five levels the person is actually operating at right now. Then write which level they should be at. Then have a sixty-second conversation:

"I realised I gave you this without telling you how much room you have, and that is on me. From now on, on this, you are at level three. You decide. Tell me before you act. I will only step in if I see something you cannot see from where you are sitting. Let's review in a month, and if it is going well you move to level four, where you just tell me afterwards."

Sixty seconds, and you have done something no amount of trying-to-hover-less would achieve.

The objection I get every time: what if they make a bad call?

They will. That is not a risk of the system; it is a feature of it.

Ask two questions instead. First: what is the most expensive bad decision this person could make at level three? The honest answer is usually recoverable — annoying, costly, fixable. Second: what is the cost of every decision in this area routing through you for the next three years? That number is almost always bigger. It is just spread out, so you never get an invoice for it.

A comparison of two costs: the most expensive recoverable mistake someone could make at level three, versus every decision in that area routing through the owner for three years.
Exhibit 4 — One of these arrives as an invoice. The other never does.

And there is a compounding effect on the other side. Someone who makes a recoverable mistake at level three, is shown how you would have thought about it, and stays at level three is materially better six months later. Someone who never gets to decide is exactly the same six months later.

Which means you will be solving this same problem again next year, with the same person, having learned nothing you could not have learned this week for the price of one recoverable mistake.

𝗧𝗮𝗸𝗲 𝘁𝗵𝗲 𝗙𝗿𝗲𝗲 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗦𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗗𝗶𝗮𝗴𝗻𝗼𝘀𝘁𝗶𝗰: https://dynamomethods.com/business-os

Isaac Wambua is an industrial engineer, business systems architect, and the creator of the Dynamo Business Operating System (DBOS) and the Dynamo Leadership Operating System (DLOS). He is the author of The Dynamo Business Blueprint: How to Build a Business That Runs, Grows and Thrives Without You. Through Dynamo Methods, he helps owners and executive teams install the operating systems and leadership capacity that allow a company to run — and improve — without depending on any one person.

DYNAMO METHODS

Isaac Wambua
Isaac Wambua is a business systems strategist, speaker, and founder of Dynamo Methods. He helps entrepreneurs reclaim their time and scale their companies by installing the 7 Core Systems that create true business freedom. Through his books, challenges, and coaching programs, Isaac equips business owners to build self-managing businesses that thrive without constant hustle. When he’s not teaching frameworks that free leaders from burnout, you’ll find him mentoring entrepreneurs, speaking at events, or creating new tools to help business owners keep building, keep winning, and keep making a difference.
Back to Blog