Give Feedback Juniors Can Use — Mentoring Engineers, Part 3
Mentoring Engineers · Part 3
A junior engineer's pull request comes back with fourteen comments. Most are small: naming, a missing null check, a test that asserts too little. One says "this whole approach feels over-engineered". The junior fixes the thirteen small ones in an hour. The fourteenth sits there for two days, because they don't know what "over-engineered" means here, what the reviewer would have done instead, or whether the reviewer now thinks less of them. Eventually they ask a peer, who shrugs. The pull request merges with the approach unchanged and the junior a little more anxious about the next one.
The reviewer meant well. Thirteen of the fourteen comments were useful. The one that mattered most was the one the junior couldn't act on, because it described the reviewer's reaction rather than anything in the code.
The working claim for this part: feedback helps when it points the junior's attention at the task, and hurts when it points their attention at themselves. That isn't a soft preference. It's the central finding of the largest review of feedback research we have.
Before you start
Pull up the last five review comments or one-to-one notes where you gave a junior engineer critical feedback. You'll audit them in Step 2.
Find one piece of good work they did recently that you didn't comment on. You'll use it in Step 5.
Book 15 minutes with them this week with no agenda except feedback in both directions (Step 6).
Step 1: Know why feedback backfires (10 min)
Kluger and DeNisi's 1996 meta-analysis pooled 607 effect sizes from feedback studies, covering more than 23,000 observations. On average feedback improved performance, with an effect size of d = 0.41. But more than a third of the feedback interventions decreased performance, and that wasn't explained by whether the feedback was positive or negative.
Their explanation was about attention. Feedback changes where the person's attention goes: to the details of the task, to their motivation for the task, or up to themselves ("am I good at this?", "what do they think of me?"). The further feedback pulls attention away from the task and toward the self, the less it helps. "This whole approach feels over-engineered" sends a junior straight to the self level. "This adds a factory and two interfaces for a single implementation; a plain function would be easier to test" keeps them on the code.
Test you can run: take one piece of critical feedback you gave recently and ask, "after reading this, what is the junior thinking about: the code, or themselves?" If the honest answer is themselves, rewrite it before you send the next one like it.
Step 2: Describe the behaviour and its effect, not the person (15 min)
The Center for Creative Leadership's Situation–Behavior–Impact (SBI) model is a simple structure that keeps feedback at the task level:
Situation: when and where. "In yesterday's PR for the export job..."
Behaviour: what you observed, specifically. "...the retry loop catches every exception, including the validation error..."
Impact: what it caused or will cause. "...so a bad input retries five times and then fails with a timeout, which hides the real problem from whoever's on call."
CCL suggests adding a second "I" for intent: ask what they were trying to do. Often the junior had a reason, and the reason is where the real teaching is.
Test you can run: audit your last five critical comments against SBI. Mark each one S, B and I if present. Any comment with no B ("this is messy", "not great") gave the junior nothing to change.
Step 3: Shrink the gap between work and feedback (10 min)
Feedback on a pull request is worth most within a day, while the junior still remembers why they made each choice. Feedback saved for a quarterly review arrives as a list of things they can no longer change, about work they've forgotten. Give small feedback continuously, and keep formal reviews for patterns, not surprises.
Test you can run: check the median time from "PR opened" to "first review comment" for your juniors' last ten changes. If it's over a working day, the feedback loop is too slow to shape habits.
Step 4: Prioritise, so the important point isn't buried (10 min)
Fourteen comments of equal visual weight tell a junior that everything matters equally. Separate them. Label the one or two that matter ("blocking: the retry loop") and mark the rest as optional or nits. If the important feedback is about the approach, say it in a conversation, not only in a comment thread.
Test you can run: on your next review of a junior's work, before submitting, count the comments and mark which ones you would block the merge for. If more than three are blocking, the problem is probably upstream (the task was too big, or the approach wasn't discussed first), and that's a conversation, not more comments.
Step 5: Make praise specific enough to repeat (5 min)
"Nice work" tells the junior you're pleased. It doesn't tell them what to do again. Hattie and Timperley's 2007 review of feedback in learning made the same distinction: praise aimed at the person carries little information about the task, while feedback about the work and the process behind it is what learners can use. "Splitting the migration into two deploys meant we could roll back the second half alone. That's exactly the right instinct for schema changes" is praise they can reuse.
Test you can run: look back at the last three times you praised a junior's work. For each, could they tell you which specific choice you were praising? If not, the praise was encouragement, which is fine, but it wasn't feedback.
Step 6: Ask for feedback on your feedback (10 min)
Ask them directly: "When I comment on your PRs, which comments help and which ones leave you unsure what to do?" You'll get a polite answer the first time. Ask again a month later and you'll get a real one. Juniors rarely volunteer that a comment confused them, because asking feels like admitting they should already know.
Test you can run: after your next review, ask the junior to rank your comments from most to least useful. If their top choice isn't your top choice, you've learned something about what's landing.
Step 7: Close the loop on whether it changed anything (10 min)
Feedback is a hypothesis: "if you change this, the work gets better." Most mentors never check the result. Two or three weeks after an important piece of feedback, look at the junior's recent work for the specific behaviour you named. If the retry loop pattern has gone, say so, specifically. If it hasn't, the feedback didn't land, and repeating it louder rarely helps. Ask what got in the way. Often it's that they understood the comment but not the principle behind it, so they fixed one instance and repeated the pattern elsewhere.
This is also where you find out whether your feedback was right. Sometimes the junior tried your suggestion and it made things worse in a case you hadn't considered. That's worth hearing, and it's only heard if you go back and look.
Test you can run: pick the most important piece of feedback you gave a junior last month. Find two pieces of their work since then where it would apply. Did the behaviour change? Either answer tells you what to do next.
Worked example: "over-engineered" (composite scenario)
A senior engineer at a healthcare software company reviewed a junior's change to an appointment-reminder service. The junior had added a strategy pattern with three classes so reminders could be sent "by any channel in future". Only SMS existed, and nothing on the roadmap added another channel.
The senior's first draft of the comment was "this feels over-engineered". Before sending, they rewrote it with SBI: "In this PR (situation), the reminder sender is split into an interface, a factory and an SMS implementation (behaviour). Right now there's one channel, so anyone reading this has to follow three files to find the one line that sends a message, and the tests mock the factory instead of testing the send (impact). What were you planning for?" (intent).
The junior replied that a product manager had mentioned email "at some point". The conversation that followed was the real lesson: how to weigh a possible future requirement against the cost of carrying the abstraction now, and who to ask whether "at some point" meant this quarter. The junior simplified the code to one function and wrote a one-line note in the pull request about where an interface would go if email arrived. Three months later, a second channel was added in an afternoon. The junior had learned a judgement, not a rule, and the senior had learned that their first-draft comments usually described their own reaction.
Trade-offs to make deliberately
Choice | You gain | You risk |
Written feedback in review | A record; time to phrase it well | Tone gets lost; approach-level points get buried |
Spoken feedback in a one-to-one | Nuance; they can ask "why" immediately | No record; easy to soften until it says nothing |
Every issue flagged | Nothing slips through | The important point drowns; anxiety grows |
Only blocking issues flagged | A clear signal | Small habits go uncorrected for longer |
A good default: blocking issues in writing with SBI, approach-level concerns in conversation as well, and nits batched or skipped.
Common failure modes
Feedback about the reviewer's reaction. "Feels off" points attention at the self, not the code.
Saving it up. Thirty points in a quarterly review is a verdict, not feedback.
Equal weight for every comment. The important point gets lost among the nits.
Generic praise. It feels kind and teaches nothing.
Never asking how it lands. You find out from their exit interview.
Final takeaway
Feedback works when it keeps the junior's attention on the work: the situation, the specific behaviour, its effect, and a question about their intent. It backfires when it sends them to wondering what you think of them. Your next action: rewrite the last critical comment you gave a junior using Situation–Behavior–Impact, then compare the two versions and ask which one they could have acted on.
Sources
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–284.
Hattie, J. and Timperley, H. (2007). The Power of Feedback. Review of Educational Research, 77(1), 81–112.
Center for Creative Leadership. Situation-Behavior-Impact (SBI) feedback model (CCL leadership guidance, ccl.org).
Continue the Mentoring Engineers path
Previous — Part 2: Pair Programming That Helps
Next — Part 4: Help With Stuck
Part of the Mentoring Engineers learning path. Related: Give Feedback That Lands · Review Junior Engineer PRs.
