You learn to pay attention. Sometimes you also learn to hold on too tightly.
Over the years, I’ve moved between building products myself and working with people who could take parts of the business further than I could alone. Today, through MyRemote.Team, I help companies build remote technology teams. That work keeps bringing me back to delegation: what people need to know, which decisions they can make, and what happens when something goes wrong.
AI adds another layer to those questions.
If I ask someone to rely on a system, how much responsibility am I actually allowing them to hand over?
I can understand the person who checks again
Imagine a developer uses AI to prepare a change to a client’s application. The code looks reasonable. Automated tests pass. The company wants the team to benefit from the tools and deliver faster.
The developer still spends time checking the change manually.
From the outside, this might look inefficient. Why introduce AI if people repeat the work?
But imagine being the person whose name is attached to that release. If it breaks the checkout on Friday evening, you will be investigating it. You will explain what happened. You may spend the weekend fixing it.
“The AI produced it” will explain how the code arrived. It will do very little to restore the checkout.
Some of that checking is necessary professional judgment. Some may be excessive. I would want to understand the difference before asking the developer to move faster.
What have we tested? What kinds of mistakes does the system make? Which checks are still needed? And have we changed the delivery expectations without properly answering any of those questions?
Delegation can look clearer from the founder’s side
As a founder, you can believe you have delegated something because you have explained what you want and given someone permission to proceed.
The other person may experience the arrangement differently.
They are allowed to decide, provided their decision matches what you would have chosen. They own the work, but you keep changing the standard. They should ask for help, although every question seems to interrupt you.
I wrote previously about how easily a preference can become a requirement when a founder keeps rewriting other people’s work. AI creates another place where that ambiguity can hide.
We tell someone to use the system. Then we question why they followed its recommendation.
Perhaps they missed an obvious warning. Perhaps the recommendation was outside the system’s intended use. Those are legitimate concerns.
But we need to establish what the person was expected to notice. Otherwise, “use your judgment” becomes an instruction whose meaning is revealed only after the result arrives.
I find that worth examining in myself too. When I ask someone to take ownership, am I giving them a decision they can genuinely make? Or am I hoping they will remove work from my day while leaving me comfortable with every choice?
The workflow carries the mistake forward
In my earlier article about AI and service businesses, I described a chain: source, agent, human, client.
I still find that useful because responsibility can become surprisingly vague between those stages.
Imagine an AI prepares a marketing report from campaign data. A person checks the report and sends recommendations to the client. The client changes their spending.
If the original data was incomplete, a polished explanation may carry the error through the whole process. The reviewer might see a convincing conclusion without seeing what was missing.
Calling this “human-reviewed” tells us very little.
I would want to know whether the reviewer can trace the recommendation back to the source, whether they have time to investigate it, and whether they can stop the report from going out.
The founder or manager has responsibilities here as well. Choosing the tool, designing the process, setting the deadline, and deciding what the reviewer can access all influence the result.
We should remember those decisions when something fails.
What would make me comfortable relying on it?
When I developed the CONCLAVE concept, I was interested in how AI agents could connect company knowledge and turn those connections into opportunities people could examine.
The examination matters. Different agent roles do not automatically create independent judgment. A proposal can sound compelling while resting on an assumption nobody has tested.
Before relying on such a system, I would want a focused starting point: one business question, relevant sources, visible assumptions, and a practical test.
I would want the same discipline when asking an employee to use AI.
We should agree on what the system can handle, what the person must check, and which situations need escalation. Someone also needs the authority to pause the workflow when the evidence stops supporting it.
That gives us something concrete to improve after a mistake.
People will watch what we do next
The first serious failure will reveal how the arrangement actually works.
If someone completes the agreed checks and the result is still poor, do we examine the system and our own management decisions? Or does responsibility settle on the person who approved the output?
Employees will notice. Their next decision will reflect what they learned.
After years of building products and teams, I’m interested in that moment: the point where a promise of autonomy meets an uncomfortable result.
Before asking why people keep checking, hesitating, or overriding AI, I would ask them:
“What do you believe will happen to you if you follow this process and it goes wrong?”
Then I would ask myself whether I have given them a reason to believe otherwise.
Leave a Reply