Friday was the problem
👋 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 gave Dev feedback every Friday. By the third Friday in a row, Friday was the problem. (Maya and Dev are fictional, built to illustrate this series.)
Three weeks earlier she had sent Dev the rewritten message about the definitions check. He replied the same afternoon: he would run the check on every draft, internal ones included, and the source-file queue was the hard part. Maya put the definitions check on their Friday agenda so it wouldn’t drop.
The first Friday, she raised it. Dev said he was on it. The second Friday, she raised it again. No new forecast had gone out in between. On the third Friday, she opened her notes to the same line, in the same words: Definitions check, all drafts.
Dev listened, nodded and said he had been checking. After the meeting, he reopened the forecast he had already finished and rechecked every definition in it. Maybe the recheck caught something. Maybe it didn’t. Neither of them could say. Nothing in the request had changed. The only new thing that week was the meeting.
Maya didn’t think of it as repetition. She thought of it as follow-through. Good managers keep the thread alive. Good managers don’t let things drop. And the calendar kept offering Friday. The meeting itself was worth having. What she brought to it, week after week, was the part she hadn’t looked at.
I’ve run that meeting. A recurring one-on-one arrives, there’s no new work to look at, and the old correction is the only thing on my list, so I say it again. It feels like diligence. Looking back, the second and third times rarely told the other person anything they didn’t already know. Mostly they told them I was still watching.
Research Binder: the receipts, methodology notes, and source boundaries are compiled at the bottom of this post.
Previous:
Last week Maya turned a six-word judgment into a message Dev could check. This week the message isn’t the problem. The schedule is.
I promised to look at why more frequent feedback isn’t automatically better feedback, and how to tell whether a message is arriving too early, too late or too often. The research answers the first half more cleanly than the second. More conversations don’t guarantee better results. Nothing in the evidence turns that into a rule for less.
So here is the boundary for this whole episode, before any study.
Frequency is one of four questions on that page. The others ask what useful information or clarification the feedback adds, what the task needs and what should happen next. For three Fridays, Maya had been answering only the first one. She knew how often she was giving Dev feedback. She hadn’t asked what the next conversation needed to accomplish.
An average isn’t a cadence
First, the counterweight, same as the last two weeks. Feedback is not the villain of this series.
In 1996, Avraham Kluger and Angelo DeNisi published a meta-analysis of 131 papers and 607 effect sizes, each comparing a feedback group with a no-feedback control. Most of the studies were laboratory research. On average, feedback helped: d = 0.41, a standardized effect size, not a 41% improvement. Over a third of the effects went the other way.
The same paper tried to find out whether frequency explained that spread. The authors coded how many times feedback was given in each study. Across all the studies, the link between frequency and effect size was small and not statistically significant. Depending on which studies were included, its direction changed. The authors wrote that the frequency effect “may be an artifact.” They never coded how long feedback was delayed.
So the paper this series started with doesn’t settle frequency or timing in either direction. It doesn’t say Friday feedback helps. It doesn’t say Friday feedback hurts. Later research took the question on directly, and the answers depend on where you look.
More often isn’t the same as more useful
Three kinds of study point in three directions. Each answers a slightly different question.
A laboratory experiment. In 2011, Chak Fu Lam, Scott DeRue, Elizabeth Karam and John Hollenbeck varied how often people received feedback on a task. Performance didn’t climb steadily as feedback increased. It rose, then fell: an inverted U. Their explanation is that very frequent feedback can overwhelm the attention people have available, so effort on the task drops. People’s mood also changed the shape of the curve. This was one laboratory task. The best frequency there says nothing about whether weekly or monthly is right for your team.
A field experiment. Pablo Casas-Arce, Sofia Lourenço and Asís Martínez-Jerez randomly assigned about 800 home-repair professionals in Spain to weekly or monthly performance reports, either detailed or summarized, and tracked customer satisfaction. Detailed monthly reports produced the best results. Weekly reports, detailed or summarized, did no better than the comparison group, which received a monthly summary.
A workplace observation. Shana Mertens, Eveline Schollaert and Frederik Anseel asked employees how many feedback conversations they’d had. The average was 3.8 over three weeks. More conversations went with better performance and satisfaction, with no drop at the highest frequencies.
Put those side by side and the honest summary is short. Frequency matters, but it doesn’t push results in one direction.
Look at what changes from row to row in that table: the setting. A laboratory task, a firm’s reporting system and a survey of employees aren’t the same place. None of them is a manager talking with a senior analyst on a Friday. That’s why the four boxes above the table matter more than any single row. The task, the information, the recipient and the setting all change what more feedback does, so the useful question isn’t “how often?” It’s “under what conditions?”
Same schedule, different conditions
The most useful studies don’t ask whether frequency helps. They ask when.
In four experiments, Nicholas Lurie and Jayashankar Swaminathan had people manage inventory and gave them feedback on results at different intervals. When demand jumped around, more frequent feedback made decisions worse. When demand was stable, frequency made no significant difference. Their analysis showed that under noisy conditions, recent results weighed too heavily in people’s decisions. Fresh numbers looked like signal when they were often noise.
The repair-network experiment offers a similar explanation. With weekly reports, the most recent week loomed largest, and the authors suggest people overweighted it. That’s their interpretation, not something they measured directly. What they did measure points the same way: detail mattered alongside frequency. Detailed monthly reports beat detailed weekly ones. When everyone moved to detailed monthly reports after the experiment, the gap disappeared.
The person receiving the feedback matters too. In one experiment, Joseph Johnson, Khim Kelly and Wioleta Olczak found that more frequent feedback hurt accuracy more for people high in what the researchers call narcissistic oversensitivity, a trait the authors say may cause especially strong reactions to performance feedback. A brief growth-mindset prompt reduced the effect. One experiment, one specifically defined trait, and no license to sort your team by personality.
The field experiment on that page carries a note worth repeating: performance reports, not live coaching conversations. A report arrives whether anyone discusses it or not. A Friday one-on-one involves two people, a relationship and whatever else is on the agenda. That difference cuts both ways. It’s also why none of these studies can tell Maya how often to meet with Dev. They can tell her that the calendar doesn’t tell the whole story.
Sometimes more helps
If you’re tempted to read all this as “cut the cadence,” the strongest workplace evidence points the other way.
The Mertens finding deserves more than a row in a table. In ordinary workplace ranges, employees who reported more feedback conversations also reported better outcomes. The authors suggest the relationship between employee and manager may help carry that link. But it’s an observational study. People reported their own feedback frequency, and better relationships may produce more conversations rather than the reverse. That’s an association, not proof that adding conversations improves anything.
Health care adds a second line. In the audit-and-feedback research I covered last week, one review found more frequent feedback was associated with stronger effects, and the Cochrane review says feedback may work better when it’s provided more than once. That’s clinical performance data, not one-on-ones. The two reviews also draw on overlapping evidence, so count them as one signal, not two.
And sometimes the person across the desk is the one asking. A request like “Could we review this?” may reflect a genuine need for clarification or support. It’s a reason to talk, whatever the calendar says.
Both findings matter, and neither cancels the other. More feedback may help. Its benefits can’t be assumed. For Maya, that rules out the easy fix. Dropping Dev’s Friday meeting would replace one rule with its opposite. The decision box on that page says it plainly: don’t prescribe less feedback by default.
Sooner isn’t a rule either
Frequency and timing are related, but they aren’t the same question. Frequency asks how often feedback happens. Timing asks when it arrives relative to the work. The other half of the cadence belief is about timing: give feedback right away, every time. The evidence here is thinner, and almost none of it comes from workplaces.
The most current synthesis I found is a 2026 meta-analysis by Erva Nihan Kandemir, Emanuele Esposito, Lilas Gurgand and Franck Ramus. It pooled 51 studies and 160 effect sizes comparing immediate and delayed feedback in computer-assisted learning. On average, timing made no meaningful difference: g = 0.03. Like d, g is a standardized ruler. A value of 0.03 is close to zero, and the plausible range ran from slightly negative to slightly positive.
The average hides a lot of variation. Results differed by educational level, by subject and by whether learners answered under time limits. Delays ranged from about a second to a week, and few lasted a day or more.
An older review by James and Chen-Lin Kulik found the answer depended on the kind of study. Applied classroom studies tended to favor immediate feedback. Some list-learning experiments favored delay. Getting an answer right today, remembering it next month and using it in a new situation are different outcomes, and timing doesn’t affect them all the same way.
I couldn’t find a study comparing a manager who corrects an analyst now with one who waits until Friday.
Two lines on that page hold whatever the research says. A consequential error may need correcting promptly, and a person asking for clarification shouldn’t wait because of a timing rule. Everything else depends on the task, the purpose and what happens if you act now instead of later. Waiting isn’t automatically better. Neither is speed.
What Maya changed
That Friday evening, Maya scrolled back through her notes. The same line, three weeks running. Between the second and third mentions, Dev hadn’t produced a new forecast. There was nothing new to look at. The meeting wasn’t reviewing new work. Without anyone intending it, it had become a check on whether Dev still remembered.
Repeating a correction isn’t wrong in itself. If Dev had misunderstood the ask, if a draft had gone out unchecked, or if accountability needed a follow-up, saying it again would have been the job. Maya hadn’t asked which of those, if any, applied. The calendar had answered for her.
She kept the Friday one-on-one. It’s where Dev raises blockers, and it’s the one half-hour each week that isn’t about a deliverable. What she dropped was the repeated correction.
The next Friday, she asked a different question. “What have you tried with the definitions check, and where does it get stuck?”
Dev walked her through it. The check itself took about twenty minutes. Waiting on source files from the other team’s queue took days. Maya wrote the queue down as its own problem, separate from the feedback. That one needed a different conversation, with a different team.
Then she named the next review point out loud. “The forecast draft due Wednesday. I’ll go through that one with you. If something comes up before then, don’t wait for Friday.”
The same week showed the other side. On Tuesday, a figure in a forecast summary going to the executive staff the next morning didn’t match the model. Maya walked over to Dev’s desk that afternoon. Waiting for Friday, or for any checkpoint, would have been the wrong call.
And when Priya, another analyst on the team, stopped her after a meeting and asked, “Could we review this?”, Maya made the time that afternoon. The question was never how little she could say. It was what the next conversation needed to accomplish.
