Drive-By Feedback Doesn't Stick

You are in the middle of a deploy. Someone leans over your shoulder: “Don’t do it like that, run the migration first.” You nod, fix it, ship.

A week later you do the exact same thing on a different deploy.

If you have worked on a team for more than a month, you have been on that side. And if you have led one, you have probably been the person leaning over.

Why it feels bad to receive

A drive-by correction usually comes at the worst moment to learn anything. Your attention is on the terminal, the release, the customer waiting. The fix arrives as a command, not a conversation.

There is no reason attached. Just “not like that.” So you apply it to the screen in front of you and nothing else.

There is no room to ask. Asking “why?” mid-deploy feels like pushing back, so you don’t.

And if anyone else heard it, there is a small sting. You get a little defensive, even when the fix is right. Especially when the fix is right.

So you nod. The nod means “I heard you,” not “I get it.” Those are very different things, and the lead walks away thinking it was the second one.

Then the same miss comes back, and the lead says “I told you this.” They did. Kind of.

What Kim Scott would say

I went back to Radical Candor expecting it to tell me to slow down. It doesn’t.

Kim Scott pushes for fast feedback: short, impromptu conversations, usually about two minutes, close to the moment.¹ The lead was right to say something right away.

The part we skip is the line she repeats constantly: Radical Candor “gets measured, not at the speaker’s mouth, but at the listener’s ear.”¹ If the other person didn’t take it in, “you may as well not have said it.”²

She also says to criticize in private, because public criticism makes people defensive and less able to absorb the message.³ And she treats feedback as a conversation, not a monologue. You watch how it lands and adjust.⁴

The over-the-shoulder fix gets the speed right and misses everything else. It is spoken at your hands, not your ear.

What two minutes buys you

Same deploy. The lead waits until it’s out, then pulls you aside:

“Hey, the migration order. If the app restarts first, it boots against the old schema and errors for a minute. That’s why I always run it before. Make sense?”

That took two minutes. It is still fast. The difference is space.

You hear the reason, so you can apply it to the next deploy, not just this one. You can ask a question without looking like you’re arguing. Nobody else is watching. And the lead can see whether it landed, instead of guessing from a nod.

That’s the difference between renting a correction and owning it. A rented fix works until the context changes. An owned one comes with you.

The AI version is the same mistake

I noticed all this because of my AI agents, not my team.

I corrected one mid-task in chat. It said “Good catch, updating now,” fixed that one output, and kept going. Next morning, new session, same miss. It was very polite about it, and technically a first-time offender, since as far as it knew we had never met.

The chat correction was my drive-by. It lived in one session and died there. The real conversation, for an agent, is stopping and editing the instructions file it loads before every run: one rule, in plain words, with the reason. It takes about as long as Scott’s two minutes, and the next run gets it right without me. (I wrote more about that habit in A Retry Pass Is a Bug.)

Humans and agents fail the same way here. Neither one can own a lesson that never had anywhere to land.

What to try tomorrow

Drive-by fixes aren’t always wrong. Sometimes the deploy has to go out and “run the migration first” is exactly the right thing to say. That’s triage. Just don’t count it as feedback.

Before you drop a fix in the middle of someone’s work, ask yourself one thing: will this still be true next week?

If no, say it and move on.

If yes, say the quick version now, then book the two minutes. After the deploy, at their desk, on a short call. Give the reason. Ask if it makes sense. With an agent, write it in the file instead of the chat.

Then check the next deploy, or the next run. If it comes out right without you there, you gave feedback. If not, you were renting.

When was the last time a drive-by fix actually stuck for you?