The Delegation Problem Was Not Trust. It Was Clarity.

[DENNIS TO VERIFY: In month and year], I realised I had become the bottleneck in a business I was trying to grow.

The warning sign was not a missed target or an angry client. It was a Tuesday afternoon and a team member was waiting for my approval before sending a routine piece of work. I had promised to review it before lunch. Then a call ran over, another decision landed in my inbox, and the day disappeared. By the time I opened the document, the person who had prepared it had already gone home.

[DENNIS TO VERIFY: Replace this composite scene with the exact task, date, team member role and consequence.]

I had told myself I was protecting quality. That was the respectable explanation. The less comfortable truth was that I had kept the task because I knew how I wanted it done, but had never explained that standard clearly enough for someone else to own it.

That is the part of delegation founders often miss. We call it a trust problem when it is usually a clarity problem.

What I thought I was delegating

I thought I was handing over a task. In practice, I was handing over a vague instruction, an invisible set of preferences, and the expectation that the other person would somehow produce the version I had in my head.

Then I would review the result, find three things I would have done differently, and quietly take the task back. The team learned the wrong lesson. They learned that ownership ended when the work reached me. I learned that delegation was unreliable.

Neither conclusion was fair.

The mistake was mine. I had delegated execution without transferring context. I had given away the work but kept the judgement, the definition of done, and the right to change the brief halfway through.

That is not delegation. It is subcontracting with a surprise inspection.

The moment the bottleneck became visible

The pattern became impossible to ignore when I looked at the decisions waiting for me. Some were genuinely mine. They affected positioning, relationships, or the direction of the company. Others were small operating choices that only reached my desk because nobody knew the boundaries.

I was spending founder attention on work that did not need founder judgement.

The distinction changed how I approached the next handover. Before assigning the task, I wrote down three things: what outcome mattered, what decisions the owner could make without me, and what would count as a reason to escalate. I also agreed on the first review point before the work started, rather than hovering over every step.

That sounds basic. It was not easy. I had to resist the urge to correct the work before the agreed review point, and I had to accept that a different route could still reach the right outcome.

The Implement step of the GUIDE framework helped me name the difference between discussing a better way of working and making one real enough to survive a busy week. Delegation only became useful when it changed who made the next decision.

What I do differently now

I no longer ask, "Can you take this off my plate?" That question makes delegation sound like relief for me. I ask, "What would you need to own this properly?"

Sometimes the answer is a clearer brief. Sometimes it is access to information, a defined budget, or permission to make a decision without checking first. Sometimes it is training. And sometimes the honest answer is that I have chosen the wrong person for the work.

I also separate a learning review from a performance review. If someone is taking on a task for the first time, the first version is a chance to improve the system, not proof that they cannot do the work. Without that distinction, founders create teams that wait for instructions because initiative has become expensive.

This is why team growth determines AI results. Tools and processes only improve a business when the people using them have enough context and authority to act. The same applies to ordinary work, long before AI enters the picture.

The implementation gap is not limited to technology projects. Founders can have a perfectly sensible plan for delegation and still remain the final approval point for everything that matters. The plan is not the operating system. The repeated behaviour is.

I still get delegation wrong. I still catch myself rewriting work because it is quicker than explaining the standard. But now I recognise the warning sign: if work keeps returning to me, I ask whether the person failed, or whether I failed to transfer the conditions for success.

Most of the time, the second question is the useful one.

What are you still doing yourself because nobody else can do it, and what are you still doing because you have not made the handover clear?

Dennis Kriel is a South African entrepreneur, international speaker and AI automation specialist. He founded VerdanTech, Veratex Works and The Leadership Boardroom, and works with CEOs and founders on AI adoption, leadership and the future of work. Strategy. Technology. Craft.