ArticlesMessages

How do you give critical feedback to a coworker in writing without sounding harsh?

What the research on feedback supports, where it stops, and five messages before and after.

By Samet Durgun · Co-founder of Subtext · 19 min read

In short

Point at the work and not the person, say what it caused, and ask for one change someone could make without guessing. In a meta-analysis of mixed tasks, over a third of feedback interventions lowered performance, and feedback worked less well as attention moved toward the person. In five experiments, givers also tended to underestimate how much others wanted constructive feedback. No study I found tests real written criticism between coworkers, so the steps are my framework.

Before you send it

  1. Swap each word about them, such as “careless” or “you always”, for what happened in the work.
  2. Check that it says what the problem caused and asks for one change someone could make without guessing.
  3. Ask whether it is accurate, whether you would want to know it in their place, and whether they can do anything about it.

Does your feedback sound harsh?

Subtext marks wording that could sound harsh and offers up to three versions.

The comment box is open on page four of a shared proposal. You have typed “This doesn’t make sense” and deleted it, then “Maybe tighten this up?” and deleted that too, because it asks for nothing. The section is wrong. It leaves out the cost of the second option, the decision is on Thursday, and the author is someone you work with every week. Every version you try seems to land either as an accusation or as so little that nothing will change.

I co-founded Subtext, an app that reads your draft and marks the words that could land badly, so I have a stake in you using it, and none of this is HR or legal advice. It covers criticism between colleagues in writing, whether chat, email, document comments or code review, and not a manager’s performance review. Further down, Subtext reads a note about a thin handoff document, and I show the two tags it returned and the three versions it offered.

The feedback can be right and still land as an attack. The research points toward aiming the comment at the work and away from the person, giving the reader something they can act on, and not assuming they would rather not know. It does not support any one script, and the closest study I found to written criticism between coworkers used imagined code review comments1. To skip to the wording, see the four jobs and the five messages.

What makes written criticism read as harsh?

In my reading, how harsh a criticism sounds depends a lot on how it is built, as well as on how serious the problem is. The research offers one workable definition. In his 1988 paper, Robert Baron called criticism constructive when it was specific, considerate and did not put poor performance down to internal causes, which I read as something about the person and not the situation, and destructive when it broke those rules2.

In his first study, 83 undergraduates received either constructive or destructive criticism of their work, and those given the destructive kind reported more anger and tension and said they would be more likely to resist or avoid the critic in future disagreements. In his second, among 106 undergraduates, those who received destructive criticism on a first task set lower goals and reported lower self-efficacy on two later tasks than those given constructive criticism or none2. These were students in a laboratory, so they show what criticism can do and not what a colleague does after a harsh email, and the abstract reports no effect on task performance, so I would not claim one.

Does criticism help, or does it often backfire?

Feedback helps on average, but not in every case. Kluger and DeNisi’s 1996 meta-analysis of feedback and performance pooled 607 effect sizes from 23,663 observations. On average feedback improved performance by about 0.4 of a standard deviation (d = .41), but more than a third of the interventions lowered it, and neither chance variation in the samples nor whether the feedback was positive or negative explained that3. I would not read that as a one in three chance that your email backfires. The studies mixed tasks and settings, none of them modern workplace chat.

The authors’ explanation is that feedback changes where attention goes. In their comparisons across studies it became less effective as attention moved toward the person and away from the task3. That is the strongest research basis I found for the familiar advice to comment on the work and not on the person. Applying it to a coworker’s message is still an inference, because the comparison was across studies, not between messages that differed in one feature only.

A later education meta-analysis, of 435 studies and more than 61,000 learners, found that high-information feedback, meaning corrective feedback plus information on how learners were regulating their own learning, had the largest average effect (d = 0.99), against 0.46 for corrective feedback alone, meaning what was right or wrong and the correct answer, and 0.24 for reward or punishment alone4. The categories were coded from study abstracts, and the comparisons are across studies of students, not coworkers. The inference I would draw is a loose one, that a comment with usable information beats a verdict. “The totals row still includes the cancelled orders” shows a reader where to look. “Be more careful with the totals” does not.

Would they actually want to hear it?

One possible reason for holding back is the belief that the other person would rather not know. Abi-Esber and colleagues ran five experiments with 1,984 participants. People giving feedback tended to underestimate how much the receiver wanted constructive feedback, in hypothetical workplace scenarios, in recalled episodes and in live feedback between friends, roommates or romantic partners5.

The feedback in these experiments was constructive, meaning specific, actionable and given with the person’s wellbeing in mind, about a problem the receiver did not know about and could fix. Most of the evidence is predictions and recalled episodes, and written feedback was not tested. So it does not show that every colleague welcomes criticism that is unsolicited, disputed or hard to fix, and a receiver can reasonably reject criticism that is inaccurate, intrusive or unfair. I use the finding as a test. Would I want to know this in their place, is it accurate, and can they change it?

One of the four authors of the Abi-Esber paper, Francesca Gino, was found by Harvard to have committed research misconduct in four other papers, which she denies5. Crossref, OpenAlex and PubMed list no correction, retraction or expression of concern for that paper5.

Is it yours to say, and should it be written at all?

Two questions come before any wording. The first is about standing. A problem in work you depend on, measured against something you both agreed, is yours to raise. I would leave a pattern in someone’s overall performance, or whether they suit the job, to whoever manages them. If it is mostly that you would have done it differently, say it is a preference.

The second is whether to write it. The nearest evidence on writing against talking is about other things. Writers overestimate how clearly their tone comes across by email, in experiments with students and assigned tones6. Mostly strangers and college students reached more understanding and less conflict when they spoke about a contested topic than when they wrote, though most people in a separate sample said they would rather write7. People expected a call with an old friend to feel more awkward than an email, which it did not8. None of those is criticism of someone’s work, and none shows that a call beats a comment. The piece on firm Slack messages goes through the first study, and the piece on cancelling plans the third.

My working rule is to write it when the facts and the change you want are clear, and to talk first when the issue is contested, recurring or likely to start a run of rebuttals, then write down what was agreed. Writing lets you revise, lets them answer in their own time and leaves a record. If you do not know which they prefer, ask.

What should the message say, and what should it cut?

A written criticism has four jobs, and I would do them in this order. This is my working framework, built from Baron’s three rules, the attention finding above and the practitioner guidance below.

  1. The specific thing. Name the document, passage, incident or agreed deliverable, and how it differs from the agreed standard. Keep what you observed apart from what you infer. “The totals row includes cancelled orders” is observed, and “careless” is inferred.
  2. What it caused. Say what it changed in the work, from your own side and without claiming everyone agrees, as in “so I couldn’t finish the summary”.
  3. One ask. A change they can make, with a time only where there is a real dependency. Say which parts are required and which are your preference, as Google’s published code review guidance does with labels such as Nit, Optional and FYI9, though that is practitioner guidance, not a trial. Specific does not mean exhaustive, so lead with the change that matters most and label the rest. In chat, send a single message, and in email put the request early under a clear subject line.
  4. A door, and an offer you mean. Ask a real question where you may be missing context, and do not hide a demand inside a fake one. Offer a review or a call only if you will do it.

For the comment on page four, that could read: “This section doesn’t give the cost of the second option, and Thursday’s decision depends on it. Could you add a rough figure before then? If it’s covered somewhere I’ve missed, point me to it.”

Then cut. Cut words that describe them instead of the work, such as careless, lazy, “you always”, “again” used as a charge and “obviously”. Cut rhetorical questions, vague verdicts like “not really there yet”, sarcasm, a smiley used to soften a complaint, comparisons with named colleagues and claims about what everyone thinks. Baron’s definition covers only the vague, the inconsiderate and the personal, so the rest of that list is mine, and the emoji studies point different ways on the smiley. I would not put direct or short on the list.

Before you send it, ask whether a reasonable reader could find the issue, understand the standard, act without guessing and correct a mistake in your account. I would use that test in place of counting polite words.

Do the sandwich, SBI, Radical Candor and NVC work?

The sandwich, praise then criticism then praise, has three papers that point different ways. In two studies of written peer feedback among third-year medical students (20 and 350 students), students believed sandwiches helped their later performance, and there was no evidence that they did10. In a randomised experiment with 91 university students, a correction between two general positive statements was followed by more maths problems solved than the correction alone, though the authors call it partial evidence11. In a study of eight undergraduates doing simulated office tasks, each tried every sequence, and the sandwich was not the most effective on average12. So it is neither debunked nor shown to work. My view is to praise only what is true, specific and relevant, because praise whose only job is to cushion adds length and a question about what is coming.

SBI, Radical Candor and NVC are practitioner frameworks: Situation-Behavior-Impact, Kim Scott’s pairing of caring personally with challenging directly, and Nonviolent Communication. The Center for Creative Leadership, which sells training in SBI, calls it research-based, but the page I read shows no outcome study13. The vendor page for Radical Candor cites no outcome study of the framework either14. A review of 31 studies of NVC training, published on 5 November 2026, rated the certainty of the evidence very low to moderate, found that most lacked adequate controls and relied on self-report, and called the pattern more modest than the common assumption that NVC improves social functioning15. Many were training programmes tested in settings such as prisons and hospitals.

Five messages, before and after

These five are made up for this post, and none is the correct text. Each is one way through. Each after uses only the facts its setup and its before give, plus a request, which is mine.

A thin handoff. Owen’s handoff document lacked the staging login and the open bug list, and you pieced most of it together yourself.

Before “Thanks for the handoff doc, Owen. Bit thin tbh 😅 I ended up piecing most of it together myself. Maybe next time add the staging login and the open bug list? No worries at all.”

After “Thanks for the handoff doc, Owen. It didn’t have the staging login or the open bug list, so I ended up piecing most of it together myself. Could you add both for the next handoff? If they’re somewhere I didn’t find, point me to them.”

“Bit thin tbh 😅” is a verdict with a smile on it, and “No worries at all” takes back the complaint. The after names the two missing things, keeps the cost you stated, asks for the fix and leaves room in case they exist elsewhere.

A deadline that cost you. Callum’s test report was due Monday and arrived Wednesday, so the release moved from Wednesday to Friday. It is the second time this quarter, and QA needs the report two days before a release.

Before “The test report was due Monday. This is the second time. If it’s late again I’ll have to take it to your manager.”

After “Callum, the test report was due Monday and arrived Wednesday, so the release moved from Wednesday to Friday. QA needs it two days before a release, so I need the next one that early. If something is in the way, tell me now.”

The dates and the consequence stay. “Second time” keeps score inside a request about one report, so it goes, and if the pattern is real it belongs in a separate conversation, as with Tobias below. The threat goes too, because I would not make one I might not carry out.

A first draft that misses. Ingrid’s draft of the onboarding guide opens with the company history and leaves out the first week. Its tools section is clear. You think a new hire needs to know what to do on day one and who to ask.

Before “Love the energy here. Just needs a bit of tidying up before it goes out.”

After “Thanks for the draft, Ingrid. The tools section is clear. What’s missing is the first week. I think a new hire needs to know what to do on day one and who to ask, and the guide starts with the company history. Could you add the first week at the top and move the history after it?”

This looks harmless and I think it is the riskiest of the five, because “a bit of tidying up” says the draft is nearly done, and the restructure can arrive later as a surprise.

A habit in meetings. At three planning calls running, Tobias has reopened the vendor decision the team made in October, using time the team had for the sprint. You are about to post in the team channel.

Before “Since apparently nothing is ever decided around here 🙃”

After (as a private message) “Hi Tobias, in the last three planning calls we went back to the vendor choice we agreed in October, and it used the time we had for the sprint. If there’s new information, could you send it before the call so we can see whether it changes anything?”

The before goes to the whole channel, so everyone gets the dig, and “nothing is ever decided” is a claim no one can check. The after goes to Tobias alone, counts the calls and asks for one change. For a habit I would talk first and send this as the record.

A review comment. Farah’s change crashes when the list is empty, because the loop reads the first item without checking. That must change, and you also find one variable name, tmp, hard to read.

Before “Why is there no check for an empty list here? Basic stuff.”

After “Required before merge: this crashes when the list is empty, because the loop reads the first item without checking. Could you add a check for the empty case, or tell me if a caller already rules it out? Nit, optional: the name tmp is hard to read.”

“Basic stuff” judges Farah, and the question asks for an answer nobody wants to give. The after labels what is required and what is optional, as Google’s guidance does, and comments on the code and not the developer9.

Does it change with seniority, culture or who they are?

Equal job titles do not mean equal influence. A senior engineer may control approval, and a junior colleague may have little room to push back on a deadline. So say what authority the request carries, whether a release blocker, an agreed team requirement or your preference, and do not make an optional suggestion sound like an order. The piece on firm Slack messages covers what is and is not known about how the sender’s role changes how a message reads.

Culture is a prompt to ask. Erin Meyer, writing for INSEAD, describes direct cultures strengthening criticism with words such as “absolutely” and indirect ones softening it with “kind of”16. That is practitioner experience with no measured sample, and it describes tendencies. Ask how your team handles corrections.

In some data, gender shows up in what feedback people get. In 360-degree reviews of 4,328 senior managers in one UK public-sector organisation, women received more specific feedback about strengths, and less specific feedback about what to develop, than men did. That report is not peer reviewed, and its gender differences are observational17. I read that as a reason to check that you give everyone the same specifics, not to treat anyone as fragile.

Neurodivergence is not one communication style. A synthesis of 34 articles on autistic adults’ working lives found that feedback was sometimes hard to understand or of little use, and that clear expectations helped18. It does not cover ADHD, dyslexia or other conditions, so ask. The AuDHD piece goes through the channel evidence.

What if they reply defensively, or do not reply?

A defensive reply is still a reply. I would check first whether there is a factual disagreement under it. “I may be missing context. Which part of the timeline do you see differently?” asks that without giving up the requirement. If they are right about something, say so, then restate the shared requirement once. If your first message included an unfair generalisation, repair that part directly, which how to apologise over text covers. Then stop adding written rebuttals, and offer a call or a short written agenda.

Silence does not by itself mean agreement, hostility or refusal. Send one short follow-up in the channel where the work lives, naming the decision it is holding up, and otherwise allow your team’s usual response time.

When the problem is about priorities, ownership or repeated missed agreements, or resources you cannot settle as peers, bring in the person who can decide, with the facts, the effect on the work and the decision you need. I would tell your colleague first, unless it involves harassment, safety or discrimination, and I would start with your employer’s own policy.

The thread should not hold guesses about someone’s health or motives, confidential information about other colleagues, threats you cannot or will not carry out, or claims about what the group thinks that you have not checked. Allegations of harassment, discrimination, retaliation or serious misconduct belong in your employer’s reporting process. If the person frightens you or threatens you, this has stopped being a wording problem. If you are in immediate danger, call your local emergency number. Please keep that conversation out of Subtext and out of every other AI tool.

When a tool helps

Subtext is an AI tool, so the nearest evidence is the research on AI help with a message, which Do AI message rewriters actually work? covers. I found no independent study showing that Subtext, or any AI rewriting tool, improves how coworker feedback lands, how fair it is or how the working relationship goes.

Two habits cost nothing. Write the unfiltered version privately and replace each judgement with what happened and what you want changed. Then say it aloud the way the sharpest reader would hear it, which does this text sound rude? covers in its closest tested form.

Subtext reads a feedback draft you wrote and marks words that could read as an attack, an always or never judgement, a talking down, or a rule imposed with should or must, with a short reason for each. It names the feeling in the draft in one word and offers up to three versions, one staying close to your wording, each marked safe to send or heads-up, and, for versions made from your draft, an estimate of how much of your wording it changed. A safe to send badge is Subtext’s own estimate from the words in front of it, and a heads-up is a reason to read that version again, not proof of a problem. It sends nothing, so you copy the version you want and send it yourself.

Subtext cannot judge whether your criticism is fair or correct, and it cannot tell you what your coworker meant, which its FAQ says too, or how they will take it. It does not know the history between you or your team’s norms, beyond the words you give it and any notes you saved in Memory. A version written from an instruction, such as a request for a shorter or warmer one, leans warm, plain and short, so a message that has to stay firm needs a read for what it dropped. It is a writing assistant, not therapy, mediation or an HR process.

The thin handoff above, made up for the run, went through Subtext. The draft read “Thanks for the handoff doc, Owen. Bit thin tbh 😅 I ended up piecing most of it together myself. Maybe next time add the staging login and the open bug list? No worries at all.” Subtext named the feeling in it as Frustration and returned two tags. Passive-aggressive went on the opening, with the note that it “opens with thanks and then a dig, which can read as indirect criticism”. Mixed messages went on the closing line, “No worries at all”.

All three versions were marked safe to send. The first, Close to yours, still ends with “No worries at all”, the line Subtext had just tagged. The second, Warmer polish, changed “most of it” to “a few things”, which softens the draft, and added that the document “gave me a starting point”. Its note says the version “should land kindly”, which is an estimate from the words and not knowledge of Owen. The third, Fresh rewrite, is the only one that asks for the two missing items as a question, “Could you include those in future handoffs?”, though it drops your line about piecing most of it together and says “I got there in the end”. None of them offers a review or asks whether you may be missing context, so the fourth job, the door and the offer, stays yours. Subtext’s own closing line began “I dropped the emoji and the ‘tbh’ so the feedback reads as a request, not a dig.” That is the app’s real output, unedited.

Thanks for the handoff doc, Owen. Bit thin tbh 😅 I ended up piecing most of it together myself. Maybe next time add the staging login and the open bug list? No worries at all.

  • Passive-aggressive: "Thanks... Bit thin tbh 😅" opens with thanks and then a dig, which can read as indirect criticism.
  • Mixed messages: "No worries at all" after the criticism can feel at odds with the complaint.
  • Frustration: You're a bit annoyed that the handoff doc was thin, though you're trying to keep it light.

Piecing a handoff together yourself is annoying, and it's good that you're giving Owen useful feedback. Here are a few versions that keep it friendly and make the ask clear.

  • Close to yours (Calm, safe to send): Thanks for the handoff doc, Owen. It was a bit light on detail, so I pieced a lot of it together myself. Next time it would help to have the staging login and the open bug list in there. No worries at all. Keeps your point and tone, but states the gap plainly and turns it into a clear ask, so it reads as feedback, not a dig.
  • Warmer polish (Appreciation, safe to send): Thanks for the handoff doc, Owen, it gave me a starting point. I did have to piece a few things together myself, so for next time, the staging login and the open bug list would be a big help. Appreciate it! Opens with real thanks and frames the staging login and bug list as a helpful request, so it should land kindly.
  • Fresh rewrite (Confidence, safe to send): Hey Owen, quick note on the handoff doc. I got there in the end, but two things would have saved me time: the staging login and the open bug list. Could you include those in future handoffs? Thanks for putting it together. Leads with the two specific items and asks for them directly, then closes with thanks. Clear and collaborative.

I dropped the emoji and the "tbh" so the feedback reads as a request, not a dig. Want it shorter, warmer, or more direct?

Try Subtext in your browserDownload on the App StoreGet it on Google Play

With any tool, ask it to keep the facts, the requirement and the deadline and to add no praise, promises or apologies, then compare what comes back with your original, because a rewrite can soften a fact along with the edge, as the second version above did.

What should you paste into Subtext or any AI tool?

A feedback draft pasted into Subtext or any other AI tool can hold confidential commercial information and details about someone who never chose the service, and removing a name does not remove every identifying detail. Check your employer’s policy and your contract first, use an approved tool and account where one exists, and paste only your own feedback, with roles in place of names and no client names, figures or thread history the task does not need. Keep anything about the other person’s health, money or private life out of it.

Subtext’s terms ask you to confirm that you may submit other people’s words and, if you use it for work, that you are allowed to. Its privacy policy says nothing you send is used to train an AI model, by Subtext or by its providers, and that your text goes to the AI providers it names. A conversation deletes itself five days after you last use it, or 90 days if you pin it, and you can delete one straight away19. Notes saved to Memory stay until you delete them. Which AI writing assistants train on your messages has the long version for other tools.

Questions people ask

How do I criticise a coworker’s work politely in an email? Point at the specific thing, say what it caused, ask for one change and leave room for what you do not know. Polite here means precise and respectful. Padding adds neither.

Is it OK to give critical feedback over Slack or email at all? Yes, when the facts and the change you want are clear. Talk first when the issue is contested, recurring or likely to start a run of rebuttals.

Should I start with a compliment? Only if it is true and about the work. The sandwich has three papers behind it that point in different directions, and in my view praise whose only job is to cushion the criticism adds length and a question about what is coming.

How long should I wait before sending it? I found no study that gives an interval. If you pause, I would use the time to replace each judgement with what happened and what you want changed, and send it before the correction stops mattering.

The order to do it in

Decide first whether it is yours to say and whether writing is the right way. If the issue is contested, recurring or likely to start a run of rebuttals, talk first. If you write it, point at the specific thing, say what it caused, ask for one change, and leave room for what you do not know.

If they reply defensively, check for a factual disagreement first, repair what you got wrong and restate the requirement once. If nothing comes back, send one short follow-up. If it is harassment, discrimination or something that frightens you, it has stopped being a wording problem.

Write the smallest message that names the work, says what it caused and asks for one change. Then send it.

Sources

Numbered in the order they appear above. Where a figure could not be verified against the primary source, the text says so. Checked 6 November 2026.

  1. Gunawardena, S. D., Devine, P., Beaumont, I., Garden, L. P., Murphy-Hill, E., and Blincoe, K. (2022). Destructive Criticism in Software Code Review Impacts Inclusion. Proceedings of the ACM on Human-Computer Interaction, 6(CSCW2), 1 to 29. Survey of 93 software practitioners reacting to hypothetical constructive or destructive code review comments; vignettes and self-report.
  2. Baron, R. A. (1988). Negative Effects of Destructive Criticism: Impact on Conflict, Self-Efficacy, and Task Performance. Journal of Applied Psychology, 73(2), 199 to 207. Three studies: 83 undergraduates, 106 undergraduates, and a survey of 108 employees of one food-processing company; laboratory manipulation and self-report.
  3. Kluger, A. N., and DeNisi, A. (1996). The Effects of Feedback Interventions on Performance: A Historical Review, a Meta-Analysis, and a Preliminary Feedback Intervention Theory. Psychological Bulletin, 119(2), 254 to 284. Meta-analysis of 607 effect sizes (23,663 observations): feedback improved performance on average (d = .41), but over a third of the interventions lowered it. Mixed tasks and settings, none of them modern workplace chat; the full text could not be opened, so the laboratory and field split is not known.
  4. Wisniewski, B., Zierer, K., and Hattie, J. (2020). The Power of Feedback Revisited: A Meta-Analysis of Educational Feedback Research. Frontiers in Psychology, 10, article 3087. Meta-analysis of 435 studies and 994 effects with more than 61,000 learners, average d = 0.48 after removing extreme values; feedback types coded from the primary studies’ abstracts; students, not coworkers.
  5. Abi-Esber, N., Abel, J. E., Schroeder, J., and Gino, F. (2022). “Just Letting You Know …” Underestimating Others’ Desire for Constructive Feedback. Journal of Personality and Social Psychology, 123(6), 1362 to 1385. Five experiments (N = 1,984) and a campus pilot: hypothetical workplace scenarios, recalled episodes, live feedback between friends, roommates or partners, and a speaking contest with students. Record on the co-author Francesca Gino, checked 6 November 2026: Harvard’s finding of research misconduct in four other papers, and her denial, are reported by the Harvard Crimson on 15 March 2024. The four retraction notices are at Crossref under PNAS, Psychological Science, Psychological Science and Journal of Personality and Social Psychology. No correction, retraction or expression of concern is attached to this paper at Crossref, OpenAlex or PubMed, and the journal’s own page could not be opened.
  6. Kruger, J., Epley, N., Parker, J., and Ng, Z.-W. (2005). Egocentrism Over E-Mail: Can We Communicate as Well as We Think? Journal of Personality and Social Psychology, 89(6), 925 to 936. Five experiments, US undergraduates, email; assigned tones, not workplace criticism.
  7. Bevis, B., Schroeder, J., and Yeomans, M. (2026). Spoken Disagreement Is More Constructive Than Written Disagreement. Nature Communications, 17, article 5792. Randomised experiments with 1,576 conversation partners and 1,432 observers, mostly strangers and college students disagreeing about contested topics, not criticism of work; open access.
  8. Kumar, A., and Epley, N. (2021). It’s Surprisingly Nice to Hear You: Misunderstanding the Impact of Communication Media Can Lead to Suboptimal Choices of How to Connect With Others. Journal of Experimental Psychology: General, 150(3), 595 to 607. A field experiment in which 200 University of Chicago students were asked to reconnect with an old friend by phone or email (103 completed the follow-up) and laboratory experiments in which people chatted with a stranger by video, voice or text. About reconnecting and getting acquainted, not criticism.
  9. Google Engineering Practices. How to Write Code Review Comments. Practitioner guidance, undated, read 6 November 2026; not a controlled study.
  10. Parkes, J., Abercrombie, S., and McCarty, T. (2013). Feedback Sandwiches Affect Perceptions but Not Performance. Advances in Health Sciences Education, 18(3), 397 to 407. Two studies (N = 20 and N = 350) of written peer feedback among third-year medical students writing patient notes; students thought sandwiches helped later performance, with no evidence that they did.
  11. Prochazka, J., Ovcari, M., and Durinik, M. (2020). Sandwich Feedback: The Empirical Evidence of Its Effectiveness. Learning and Motivation, 71, article 101649. Randomised experiment with 91 university students solving maths problems; the sandwich group prepared longer and solved more in a second set; the praise was general and unrelated to performance, and the authors call the evidence partial.
  12. Henley, A. J., and DiGennaro Reed, F. D. (2015). Should You Order the Feedback Sandwich? Efficacy of Feedback Sequence and Timing. Journal of Organizational Behavior Management, 35(3-4), 321 to 335. Eight undergraduates (seven women, one man) did simulated office tasks, each under all four conditions (three feedback sequences and no feedback), half given verbal feedback before each session and half after; the sandwich was not the most efficacious sequence. Sample size confirmed from the full text.
  13. Center for Creative Leadership (2025). Use Situation-Behavior-Impact (SBI)™ To Understand Intent. Practitioner article, 19 August 2025; it calls the method research-based but presents no outcome study of the method itself.
  14. Radical Candor, LLC. Our Approach: Kim Scott’s Feedback Framework. Vendor page of a commercial training business, read 6 November 2026; it cites no outcome study of the framework itself.
  15. Lazzari, G., Jean, B. R., de la Sablonnière, R., and van Vugt, F. T. (2026). A Systematic Review of Quantitative Studies Testing Nonviolent Communication Training Interventions. Frontiers in Psychology, 17, article 1800455. 31 studies; certainty of evidence rated very low to moderate; most lacked adequate controls or randomisation and relied on self-report; published online 5 November 2026.
  16. Meyer, E. (2015). Giving Negative Feedback Across Cultures. INSEAD Knowledge, 16 September 2015. Practitioner article drawing on the author’s teaching, consulting and anecdotes; no measured sample.
  17. Burd, H., Bremner, G., Schein, A., and Rudzeviciute, M. (2021). Gender Bias and Performance Feedback: An RCT. Behavioural Insights Team research report, June 2021. 360-degree reviews of 4,328 senior managers in one UK public-sector organisation; reviewers, not the people reviewed, were randomised to different instructions; not peer reviewed.
  18. Thorpe, D., McKinlay, M., Richards, J., Sang, K., and Stewart, M. E. (2024). The Lived Experience of Autistic Adults in Employment: A Systematic Search and Synthesis. Autism in Adulthood, 6(4), 495 to 509. Qualitative synthesis of 34 articles; no funding and no conflicts declared; it covers autistic workers’ accounts, not other neurodivergence.
  19. Subtext. Terms and privacy. Privacy policy and terms last updated 22 October 2026. First party.