Your VA Keeps Making the Same Mistake. That's a Feedback Loop Problem.

executive support feedback working with a va Aug 26, 2026

A mistake made once tells you about a task.

A mistake made three times tells you about a loop.

That distinction sounds like a technicality until you notice what it changes. The first is a training moment. The second is a systems failure with a person standing in the middle of it, taking the blame for a machine that was never built. And most executives spend months treating version two as version one — correcting the same error over and over, getting steadily more frustrated, and concluding they've hired someone who doesn't listen.

They usually haven't. They've built a loop that can't carry a correction.

What a working loop requires

Four things have to be true for a correction to stick. Miss any one and the error repeats no matter how clearly you explained it or how willing the person is.

The correction reaches them before the task repeats
It shows them the right version, not just the wrong one
It updates the rule, not just the instance
It lands somewhere that isn't memory

Take them in order. Each has a distinct symptom, and the symptom tells you which one you're missing.

1. The correction arrives after the task has already repeated

Say a task runs daily and you review the week's work on Friday.

By the time you flag Monday's error, the same task has been performed four more times, the same way, because nothing in the intervening days told the person otherwise. You've corrected once. They've now practised the wrong version five times, and practice is exactly how habits form.

Next week, the correction competes with a week of repetition. That's not stubbornness. That's how learning works, and it's what the timing produced.

The symptom: the error keeps appearing after you've raised it, and there's a lag of days between the work and your response.

The fix: move feedback closer to the work, and let the task's frequency set the clock. Daily tasks need feedback the same day, weekly tasks within a day or two. That's not micromanagement — it's the opposite. Fast correction early is what makes hands-off later possible.

2. You described what was wrong instead of showing what's right

Corrections tend to come out as negations. Not that much detail. Too formal. That's not the tone we use with them.

Every one of those tells someone where the boundary isn't. None of them says where it is. A person receiving that feedback has to infer the target from the misses, which is slow, and each new attempt is a fresh guess at a range you've only ever described from the outside.

This is the mechanism behind the frustrating pattern where work keeps missing in a different direction each time. They're not ignoring you. They're triangulating.

The symptom: revisions cycle rather than converge. Too long becomes too short. Too formal becomes too casual.

The fix: send one real example of output you approved without edits, and say this is the standard. One example carries more information than ten corrections, because it encodes all the things you'd never think to articulate — length, tone, structure, how much context to include, when to flag versus decide.

If you don't have an example, that's the finding. It means the standard has never existed outside your head, and the first version of it is something you'll have to make.

3. You fixed the instance and left the rule alone

A VA sends a client update with the wrong attachment. You catch it, they resend, everyone moves on.

Nothing about that exchange changes what happens next month. The instance got corrected. The rule that produced it — whatever step is missing from how updates get assembled — is untouched, so the same conditions will produce the same result whenever they recur.

This is the failure mode that makes a capable person look careless over a long enough period. Each error is different. The underlying gap is identical, and nobody has looked at it because every individual instance was small enough to just fix.

The symptom: lots of small, varied errors that never quite repeat exactly, and a growing sense that they're "not detail-oriented."

The fix: after the third instance of anything, stop fixing and ask what rule is missing. Usually it's a checkpoint — a verification step, a second look before send, a required field. Then write the rule down and hand it over. You're not correcting a person at that point, you're patching a process, which is a much better use of the same conversation.

4. The correction lives in memory, so it decays

You explained the exception on a call in March. It was clear, they understood it, and it worked for two months. Now it's June and it's back.

Memory is a poor storage medium for operational rules, and it's a worse one when someone is holding forty of them across a dozen recurring tasks. Corrections that live only in conversation have a half-life. They survive while the task is frequent and fade when it isn't, and quarterly tasks are where they go to die.

The symptom: things that were fixed months ago resurface, particularly on anything infrequent.

The fix: the correction has to land in a document, not a conversation. It doesn't need to be elaborate — a running notes file per recurring task is enough, updated by your VA as corrections arrive, so the person receiving the feedback is the one recording it. That's the version that sticks, because writing it down is part of understanding it.

The one-page version

If you want the whole thing as a habit rather than a project:

Same day. Show the right one. Fix the rule after the third time. Write it down.

Executives who install that find repeat errors drop off inside a few weeks, and the drop is usually steep enough to be startling — because the underlying problem was rarely capability. It was a correction that had nowhere to go.

When repeat mistakes are a real signal

Two cases where the loop isn't the issue.

The same error persists after all four conditions are met. Fast feedback, a clear example, an updated rule, written down — and it still recurs. That's a genuine read, and it's a fair one, because the person had everything they needed.

Errors that involve concealment. A mistake covered up, work reported as done that wasn't, a problem you found rather than were told about. That's not a feedback loop question. It's a trust question, and trust doesn't respond to better systems.

Everything outside those two is a loop you can rebuild in a fortnight — and the version of your VA on the other side of it is often the person you thought you were hiring.

Find out where your loop breaks

Feedback and measurement is one of the five dimensions in the VA Scorecard, alongside ownership, context, definition of done, and operating rhythm. Four questions each, twenty in total, about ten minutes — and a result that names the specific gap producing your specific symptom.

Score your setup →