How to Run Constructive Engineering Reviews (That Engineers Actually Use)
Constructive feedback is not a speech. It's a system — and the engineer, not the manager, decides whether it was constructive. The script below assumes you already run (or are about to run) a real review cadence. If you don't, [start with the cadence guide first](/blog/how-often-should-you-review-your-engineers) — the language below only holds up if the cadence underneath it does.
Engineering managers don't have a language problem with feedback. They have a delivery problem.
Ask ten engineering managers to define "constructive feedback" and you'll get ten answers — and every one of them will sound reasonable in isolation. Two of them are sending engineers to therapy they didn't ask for. Three of them are using the word "constructive" to dress up a critique the engineer can't actually act on. The rest are paraphrasing Radical Candor or An Elegant Puzzle and hoping the framework substitutes for a working script.
Engineers experience the result. They describe the same feedback as "useful" in one meeting, "vague" in another, and "got talked at" in a third. The reviews land differently because the delivery is different, not because the engineers are different.
The script below has three parts. The framework, the language, and the failure modes you're already running. If you can name what you're doing in each part, your engineers will tell you — within one cycle — whether it worked.
A working premise: constructive feedback is not kindness and it's not cruelty. It's language an engineer can translate into a single next action before they leave the room. If they can't, the feedback was decorative. If they can, the feedback was constructive. Everything below is in service of that test.
And before anything in the guide works, the cadence underneath has to hold. If you're reading this and your weekly 1:1s are running on project status — fix that first, in [the cadence guide](/blog/how-often-should-you-review-your-engineers). The language below assumes that the engineer already trusts the meeting. Without trust, the same words read as a performance review you didn't mean to write.
The Framework: Three Filters, Not One
Constructive engineering feedback is a filtering operation. Three passes, each removing a different category of feedback that doesn't belong in the review doc or the conversation. Skip any pass and you've shipped something that won't survive contact with the engineer.
| Filter | Question You Answer | What Gets Removed |
|---|---|---|
| 1. Stance | What is the engineer's actual stance — what they're trying to do, what they're optimizing for? | Generic feedback that isn't aimed at the work the engineer is doing. |
| 2. Evidence | What is the specific behavior, PR, decision, or moment this feedback is grounded in? | Character-level feedback, vibes, "smell tests," and unspoken comparisons. |
| 3. Action | What is the single next action the engineer can take this week — and how will we know it worked? | Feedback that the engineer could not act on if they tried. |
If any feedback you're planning to give fails one of the three filters, do not give it yet. Most of the "constructive feedback" engineering managers write fails the Action filter — they describe what they observed without ever telling the engineer what to do differently.
Write the feedback down before you say it. If it doesn't survive writing, it doesn't survive delivery. If you cannot write the feedback in three sentences — one for stance, one for evidence, one for action — your feedback is not yet constructive. It is a feeling. Feelings are valid. They are not feedback.
The Language: Five Sentences That Travel
Below are the five sentences I have seen produce the most consistent, durable signal across engineering managers. They are not magic. They are each the shortest deliverable version of one of the framework passes — and they're sequenced the same way every time.
- "Here's what I see you optimizing for." The stance sentence. Forces you to articulate the engineer's actual frame. Almost always the contrast between your view and the engineer's view is the entire signal.
- "Here's the specific moment I'm grounding this in." The evidence sentence. Names the PR, the design review, the on-call shift, the meeting where the behavior showed up. Without this, the engineer cannot evaluate whether the feedback applies elsewhere.
- "Here's the part that's working." Lead with the working slice first. Engineers who've been burned by critique-only meetings read the first paragraph for evidence of a knife. Disarm the read in one sentence.
- "Here's the part I'd change — and what I'd change it to." The action sentence. Two halves: the behavior, and the replacement behavior. A behavior without a replacement is a complaint, not feedback.
- "Here's how we'll know if it changed." The check-back sentence. Tells the engineer when, and in what form, you'll revisit this. Constructive feedback without a check-back is a monologue.
The five-sentence structure is not a script you read aloud. It is the shape of the language you use — and almost every well-received piece of constructive engineering feedback maps onto this shape even when the deliverer never named it.
Kudo writes performance reviews in your voice — free to try
The hardest part of the script above is the Action sentence — naming the specific replacement behavior, in the engineer's voice, in your voice, with the right weight. Kudo interviews you in your own voice, asks the right questions, and produces a complete review draft in about 8 minutes.
Start a free review →The Failure Modes You're Probably Already Running
Five patterns I see consistently, across new and experienced managers. None of them are obvious in isolation. All of them cost you the engineer's trust within a cycle if you keep doing them.
| Failure Mode | What It Looks Like | Why It's Failing |
|---|---|---|
| The compliment sandwich | Positive → critique → positive. Always. | Engineers learn to skip the first and last sentence. The critique arrives in the middle, alone, and reads as the part the manager actually meant. |
| The book report | "What do you think you should work on?" | This is a question for the engineer to answer alone, not alongside you. If you both identify the same gap, no signal. If you identify different gaps, you've made them do your prep. |
| The bundle | Three critiques in one sentence. "Your code is messy, your tests are weak, and you missed the standup." | The engineer can only do one of those three things this week. The other two will read as decorations. |
| The reframe | "I don't think you're bad at this — I think you're early at this." | Engineers hear the same critique with new packaging. A reframed critique is still a critique. They feel it as a softer insult, not as growth. |
| The pending praise | "I was going to give you kudos for X at standup today — but I want to talk about Y first." | You have withdrawn the engineer's positive reinforcement to lower the temperature of the critique. They will remember this and start avoiding the meeting before the meeting. |
Three or more of these patterns in your last review doc and the engineer has already decoded you. They know the structure. They will start protecting themselves in the cadence itself — bringing less to 1:1s, recommending less in design reviews, and showing up to the next quarterly already rehearsed. The technical feedback you've been writing is still technically correct. The trust underneath it is gone.
If your cadence has been quietly failing — and your last two reviews read, in retrospect, like the engineer was performing rather than engaging — [the cadence guide walks through the reset](/blog/how-often-should-you-review-your-engineers). You can fix the language without fixing the cadence, but you cannot fix the cadence without fixing the language.
When the Engineer Doesn't Trust the Meeting Yet
If the engineer reads every review as a setup, you have to do three things in order before the language in this guide starts working. None of them are optional.
- Stop giving packaged feedback for one cycle. Move all critique into the 1:1, spoken, in five sentences. No documentation. The engineer should see the review doc as a summary of conversations they've already metabolized — not as the meeting they have to survive.
- Audit your last quarter in writing. Write down every piece of feedback you've given this engineer. Which of them did the engineer actually do? Be honest. If less than half produced action, the language was decorative and you know it.
- Co-author the next review. Send the engineer a draft of the next review doc 48 hours before the meeting. The doc is not "what I observed" — it's a working document the engineer is allowed to edit. If they're willing to edit it, the trust is back. If they won't touch it, the trust is gone and you reset the cadence again.
This sequence is unglamorous. It is also the difference between constructive feedback and constructive feedback the engineer has stopped believing you can deliver.
Build Your Next Review in Your Voice — Free
Kudo interviews you about your engineer in your own words and drafts the review in your voice — with the action sentences, evidence sentences, and check-backs already wired in. Free tier covers two reviews per cycle. Pro is $15/mo for unlimited.
Start a free review →The framework, the language, and the failure modes above all assume a working cadence underneath. If you're reading this because you've just realized your 1:1s have been quietly failing for a quarter — that's where the work starts, not with the feedback script. [Step back to the cadence guide](/blog/how-often-should-you-review-your-engineers) and run the diagnostic first. Then come back to this page.
Kudo is an AI interview tool for engineering managers who care about getting the review right. Free tier covers two reviews per cycle. Pro is $15/mo for unlimited.