10 October 2026 · 8 min read · Delegation
How to Give Feedback Without Taking the Task Back
Delegation usually breaks the first time work comes back wrong. Here's how to give feedback that keeps the task off your plate for good.

10 October 2026 · 8 min read · Delegation
Delegation usually breaks the first time work comes back wrong. Here's how to give feedback that keeps the task off your plate for good.

It comes back wrong. Not disastrously. Just not how you'd have done it. The email's a bit stiff. The graphic's slightly off-brand. The report is missing the bit you care about most.
And there's that familiar pull. It'll be faster if I just do it myself.
It will be. This once. Then next week it's yours again, and the week after, and in three months you're doing everything while paying someone to watch.
That moment is where most delegation quietly dies. Not because the person was wrong for the job. Because the feedback either didn't happen, or happened in a way that made the task feel like it still belonged to you.
Before you say anything, reread what you asked for. Was the standard actually written down? Did you show an example of good? Did you mention the detail you're now annoyed about?
If not, the first piece of feedback is for you. Update the SOP or the brief, then talk to them about the gap. Opening with "I didn't explain this properly" is a very different conversation from "this isn't right."
One question. Is the result actually worse, or just not how I would have done it?
If a client email gets the job done and sounds friendly but uses different words than you would, that's different. Let it go. If it promises a deadline you can't meet, that's wrong. That gets feedback.
Founders who correct "different" end up with a team who wait to be told exactly what to do. Founders who only correct "wrong" end up with a team who think.
Don't hover. Let them finish, then review the whole thing in one go. Mid-task corrections teach someone to check with you before every step, which is the opposite of what you're paying for.
Say what worked, specifically. Not "great job" but "the subject line was spot on and the structure was easy to follow."
Name the one or two things that need changing, and why they matter. "The reply needs to say when they'll hear back from us, because clients chase us when we don't."
Ask what they think. They might know something you don't, or spot a better way.
Agree what changes next time, and update the SOP together if it needs it.
Two changes at most. If there are ten things wrong, the instructions failed, not the person.
Every piece of feedback should end with the task still theirs. If you finish the conversation holding it, you didn't give feedback. You took it back.
This matters most, and founders skip it because it's quicker to just do it. Don't make the change yourself. Hand it back and let them make it.
When you edit their work directly, you teach them you'll catch it anyway. When they make the change, they learn your standard and remember it next time.
One mistake is information. The same mistake three times is a conversation. Is it unclear instructions, a skills gap, or a sign the task isn't a good fit for this person? Each needs a different response. None of them is "take the task back."
Feedback goes both ways. Ask your VA or team member, regularly, what would make their work easier. Clearer briefs? Fewer last-minute changes? Faster approvals? Their answers often explain why work comes back wrong better than the work itself does.
Usually that means the feedback felt like a judgment of them rather than a note about the work. Lead with what worked, keep it about the outcome, and ask questions instead of making statements. If it keeps happening, talk about it directly and calmly.
Weekly for the first couple of months, through a short scheduled check-in. After that, every two weeks plus anything that comes up. Small, regular feedback is much easier to hear than a pile of notes saved up for a monthly review.
Small things work well in writing, ideally as comments on the task itself. Anything bigger, or anything that might sting, is better on a short call so the tone doesn't get lost.
Then sort it yourself this time, and say so. "This one needed to go out now so I changed it. Let's talk tomorrow about what to do differently." Then actually have that conversation, and hand the task back the following week.
Before you open their work, decide what good enough means for this task. If it meets that bar, it goes out. Your personal preferences can go into the SOP as guidance over time, not into a rewrite every week.
Sometimes the issue is feedback. Sometimes it's that nobody owns the coordination of the people you've hired, so it all lands on you. The AI Operations Audit looks at both, and you leave with a written plan for what to change first.
Or get in touch and tell me which task you keep taking back. I'll tell you what I think is going on.