The Feedback Was Clear. Why Didnât the Work Change?
The circle on the page
đ Welcome to my paid subscriber-only edition of Empathy Engine (đ Leaderâs Dispatch). Each week I build evidence-forward tools for product leads who need to say no, defend tradeoffs, and lock in decisions before they get rewritten later.
Maya Chen circled the line before she finished reading the page. (Maya and Dev are fictional, built to illustrate this series.)
It was Wednesdayâs forecast draft, the one she had promised to go through with Dev. Three customer segments. Two had their source definitions confirmed, each logged in the modelâs assumptions tab. The third, a new enterprise segment, had nothing. No confirmation. No note saying one was coming.
Maya had asked for the definitions check in a one-on-one. She had rewritten the ask so it covered every draft that leaves the team, internal stakeholders included. Dev had replied the same afternoon: understood, every draft that goes out. She had stopped repeating it on Fridays and named this draft as the next review point. The feedback was clear. It was specific. By any reasonable standard, it was well timed.
And there was the circle.
She opened her notes and typed: Agreed three times. Still not done. Then she sat with the cursor blinking after the last word, because the next word she wanted to type was accountability, and the sentence after that was going to be about Dev.
Then the other reflex arrived, the one last week had trained. The source-file queue. Dev had told her it was the hard part. Maybe the file never came. Maybe this one wasnât on him at all.
One circled line. Two explanations. Neither one checked.
Iâve written that note. The feedback was clear, the person said yes, the next piece of work came back looking the same, and my notes jumped straight from what I saw to why it happened. Sometimes the why I wrote down was right. I couldnât have told you which times.
Research Binder: the receipts, methodology notes, and source boundaries are compiled at the bottom of this post.
Previous:
Last week I promised to look at why a clear, well-timed message can still go nowhere when the person receiving it canât act on it. The research narrowed that promise, and I think it made it more useful. It doesnât support âfind the blocker.â It doesnât support âfind the excuseâ either. It supports something less satisfying and more honest: before deciding why the work didnât change, find out what the work can actually tell you.
Look at the three boxes in the middle. Feedback communicated. Acknowledgment expressed. Subsequent work observed. Each is a separate event, and each gives you a different kind of evidence. The first is what you said. The second is what they said back. Only the third is the work.
Mayaâs circle sat on the third box. Her note had already filled the space between the boxes with an explanation. So had the queue theory, pointing the other way. Thatâs the banner across the middle: a result isnât an explanation. It tells you what happened. It doesnât tell you why.
The question at the bottom is where this episode goes. Before deciding why, ask what the next task actually showed. Was the expected behavior required, possible, observable, and relevant to this task? Maya hadnât asked any of those four. By Friday, three of the answers had surprised her.
Feedback still isnât the villain
Same counterweight as every week, and this episode needs it more than most, because it leans hard on what feedback canât do by itself.
In the 607 effect sizes from 131 papers Kluger and DeNisi reviewed (mostly laboratory studies published before 1996), feedback improved measured performance on average (d = 0.41), and over 38% of those effects were negative. About a third were still negative after the authors removed outlying data.
Two things follow, and Maya needs both. Feedback helps on average, so a disappointing result is no reason to stop giving it. And feedback doesnât move the work in every case, so âI told him and he agreedâ isnât the end of the story.
That sets the boundary for this episode. Nothing below says employees are usually blocked, or usually unwilling. The research I found doesnât say how often either explanation is the right one. It says they are different explanations, and that one result rarely chooses between them.
Said, intended, observed
Before her 2 p.m. review with Dev, Maya split her note into three lines.
Said. In their one-on-one, Dev said the ask made sense. When she rewrote it, he replied: understood, every draft that goes out.
Intended. He said he would run the check on every draft. She had no reason to think he didnât mean it.
Observed. One draft, sent to her for review, with two of three definitions confirmed.
Seen that way, her note had collapsed three different things into one.
The three boxes name what each line can hold. Acknowledgment is what someone said. Intention is what someone plans to do. Behavior is what the work may show. Notice the hedge in the third box: may. Even the work is evidence only when it was a fair place to look. Weâll come back to that, because itâs where Mayaâs week turned.
I looked for a study testing whether an employeeâs âunderstood,â after corrective feedback at work, predicts what the next piece of work looks like. I didnât find one. So treat this as careful reasoning, not a research finding: acknowledgment alone isnât evidence that the change happened. It isnât evidence that it didnât, either. Itâs a different observation.
Thatâs the instruction at the bottom. Donât treat the conversation as proof of the change. Maya had done exactly that, in reverse. Because Dev had agreed three times, one unconfirmed line felt like a broken promise instead of a data point.
It offers three better questions. What action was expected? Where could it be observed? What was actually observed?
Maya could answer the first: confirm the source definitions before any draft leaves the team. The circle answered the third. She skipped the second, where the change could be observed. It turned out to matter most.
A clear goal, a complicated task
Mayaâs request passed every test Episode 2 set for it. It named the work, the standard and the next step. If clarity alone produced change, this request should have.
That assumption has a research line behind it, and the research is more careful than the assumption.
In 1987, Robert Wood, Anthony Mento and Edwin Locke published a meta-analysis of 125 goal-setting studies conducted between 1966 and 1985. Goal-setting effects were larger on less complex tasks, d = 0.76, than on more complex ones, d = 0.42. Both effects were positive. Both are standardized effect sizes, the same ruler from Episode 1, not percentages. A d of 0.76 does not mean 76% better.
Read the scope before the numbers. These are older studies, a mix of laboratory and workplace tasks, and none of them tested what happens after a managerâs corrective feedback. What they support is narrower and still useful. Specific goals can help. How much they help depends on the task.
Thatâs what the three boxes under the chart say: specific goals can help, complexity can modify effects, and clarity isnât capability. A clear goal tells someone what to aim at. It doesnât make the task any simpler to do.
Mayaâs standard was simple to state. Dev had told her the check itself took about twenty minutes. But confirming a definition for a brand-new segment wasnât a twenty-minute task. It needed a source file that lived with another team, a request in that teamâs queue, and enough days between the request and the draft.
The instruction at the bottom is two moves, not one. Specify the goal. Examine the task. Maya had done the first carefully, twice. She had never done the second. So before the review, she answered its question for this draft: what skill, information, coordination and conditions does this work require?
Skill. Tracing a segment back to its source definition. Dev had done it on the other two segments.
Information. The source file for each segment, including the new one.
Coordination. A request to the data team, and a turnaround she didnât control.
Conditions. Enough time between the scope change and the draft date.
She noticed she had never written that list when she set the Wednesday date.
What the request record showed
At 2 p.m., Maya started with a question instead of the circle. âWalk me through the enterprise segment.â
Dev did. The enterprise segment hadnât been in the forecast until Mondayâs stakeholder sync. He requested its source file that afternoon. The data teamâs queue listed a three-business-day turnaround, which put the file at Thursday. âThis version isnât going anywhere until that file comes in,â he said.
Maya opened the request record herself. The timestamp matched: Monday, 3:40 p.m. Status: in progress. Devâs account was now partly an observation. The other part, whether anything else had slowed the check, was still his account.
The infographic lays out six conditions around the work: skill, information, authority, time, resources and dependencies. Mayaâs draft touched three of them. Information, because the file hadnât arrived. Dependencies, because the data team owned the turnaround. Time, because the Wednesday date came before Thursdayâs file.
The research on conditions comes mostly from a neighboring field. In 2010, Brian Blume, Kevin Ford, Timothy Baldwin and Jason Huang published a meta-analysis of 89 empirical studies on training transfer, meaning whether people applied what they learned in training to their actual work. Transfer was positively related to person factors, including cognitive ability, conscientiousness and motivation, and to a supportive work environment. The relationships varied with the trainingâs objectives and with how transfer was measured. When the same source supplied both measures, relationships tended to look stronger.
Training transfer isnât feedback follow-through. And âsupportive work environmentâ is a much broader idea than one file in one queue. So this is adjacent evidence. What it supports is the infographicâs first box: conditions can matter, alongside the person.
A service-sector field study by Adkins and Naumann gets closer to the workplace. Situational constraints shaped how strongly peopleâs achievement orientation showed up in objective performance, with modest effects. Constraints shaped the personâs part. They didnât replace it.
The second box says who controls it can differ. Put plainly: who actually controls the thing thatâs missing? Maya mapped it for this draft.
The data team controlled the turnaround.
Dev controlled when he asked. He asked the same day the scope changed.
Maya controlled the Wednesday date, and whether a draft could arrive with a gap marked as a gap.
That last line stung. She had set Wednesday the Friday before, before the scope changed, and never asked what the date required.
The third box keeps all of it honest: cause isnât established. So does the red line under the headline. A missing condition isnât automatically the cause. The missing file explained why the enterprise definition wasnât confirmed on Wednesday. It didnât explain why the draft carried no note saying so. Whether a note was expected, nobody had ever said.
Maya caught herself about to swap one verdict for another. âHe didnât follow throughâ had become âthe queue did it.â Same jump, opposite direction.
The question at the bottom slowed her down. Which necessary conditions were available, unavailable or still unknown?
Available. The skill. Two definitions confirmed and logged.
Unavailable. The enterprise source file, until Thursday.
Unknown. Whether an unconfirmed definition should have been marked in the draft. That one was a question about her standard, not about Dev.
âEvery draftâ is a goal, not a plan
Before the review ended, Maya asked one more question. âWhen the file lands, what tells you itâs time to run the check?â
Dev paused. âI check before I send.â
That covered drafts he sent himself. It didnât cover a version someone else forwarded, or a segment that changed after he had checked it. âEvery draft that goes outâ named the change. It didnât name the moment.
The next two infographics use a project handoff, while Maya and Dev are working through a forecast. The task is different. The question is the same.
