How to Give Effective Feedback in Engineering 1-on-1s

Published May 28, 2026

Most engineering managers are technically excellent and interpersonally under-trained. They can diagnose a memory leak in a distributed system in an afternoon. They struggle to tell a senior engineer that their pull request review style is demoralising junior teammates without it becoming a three-day crisis.

Feedback in engineering 1-on-1s is different from feedback in most other professional contexts. Here is why, and how to get it right.

Why Feedback in Engineering 1-on-1s Is Different

Developers are trained to optimise for precision. Vague feedback triggers a debugging loop. When you say "your communication could be better", a developer does not hear "you should be more empathetic in Slack messages". They hear a bug report with zero stack trace. They do not know where to start.

The second problem is ego investment. Senior engineers frequently identify themselves with their technical decisions. Criticising a system design choice can feel indistinguishable from criticising the person who made it. This is the mechanism behind defensive code reviews.

Finally, engineers are context-switchers. The cognitive overhead of shifting from a complex technical problem to processing interpersonal feedback mid-conversation is higher than most managers appreciate. Dropping critical feedback immediately after a technical problem-solving discussion is bad timing.

The SBI Framework

SBI stands for Situation, Behaviour, Impact. It is the most effective feedback structure for engineering contexts because it is precise, observable, and not personal.

Situation — Anchor the feedback to a specific, observable moment. Not "you are often dismissive in code reviews." Instead: "In the pull request review you left on Monday for the authentication service."

Behaviour — Describe only what you directly observed. Not "you were condescending." Instead: "You left three comments that said 'this is wrong' with no explanation of the correct approach."

Impact — Describe the downstream effect on the team or system. Not "it made people feel bad." Instead: "Two engineers on the team told me separately that they are now hesitant to submit PRs for your review, which is creating a bottleneck in our review cycle."

The full feedback statement: "In the pull request review you left on Monday for the authentication service, you left three comments that said 'this is wrong' with no explanation of the correct approach. Two engineers told me they are now hesitant to submit PRs for your review, which is creating a bottleneck in our review cycle."

That is a feedback statement a developer can act on. It has a specific location, a specific behaviour, and a measurable consequence.

Timing and Delivery

Do not give critical feedback in the first five minutes. The opening of a 1-on-1 should establish psychological safety. If the first thing you say is "I need to give you some feedback about Monday", you have guaranteed that the engineer will be defensive for the remaining 25 minutes.

Give feedback before the end of the meeting, not at the end. Many managers leave feedback to the last minute. This is a mistake. The engineer walks away with the feedback as the final memory, and has no time to respond or ask clarifying questions. Leave at least ten minutes after delivering feedback for a proper conversation.

Separate critical feedback from performance reviews. If you only give feedback during quarterly reviews, you have failed. Feedback in 1-on-1s should be a routine, low-stakes operation. It should feel like a code review, not a performance improvement plan.

Write it down beforehand. Engineers respect preparation. Improvising feedback mid-conversation leads to imprecise language, which leads to defensiveness, which leads to a derailed meeting. Prepare the SBI statement the day before.

Practical Examples

Example 1 — Code quality feedback:

"In the last three sprints, you have merged several PRs without waiting for a second review. Last week, the payment module went into production with a race condition that took us four hours to diagnose. Moving forward, every PR touching the payment layer needs two approvals. I want to check in on this again in two weeks."

Example 2 — Communication feedback:

"In the architecture discussion on Thursday, you interrupted three separate people mid-sentence. I noticed the two junior developers stopped contributing after that point. I want your technical perspective in those meetings, but I need everyone to feel they can contribute. Can we talk about how to structure your input differently?"

Example 3 — Positive reinforcement using SBI:

SBI is not only for critical feedback. "In the incident on Wednesday night, you took the on-call rotation without being asked and stayed online until the issue was resolved at 2am. The whole team mentioned it to me the next morning. That is exactly the kind of ownership I want to see, and I want to make sure it is recognised."

Making Feedback a System

Ad hoc feedback is better than no feedback. Systematic feedback is better than ad hoc feedback.

The most effective engineering managers treat their 1-on-1 agenda as a feedback infrastructure. They have a dedicated agenda module for feedback and recognition that they visit every session. They rotate between critical feedback, positive reinforcement, and growth conversations. They log the feedback they have delivered so they can track whether behaviour changes.

This is where structured 1-on-1 tooling replaces free-form documents. When your agenda is a visual system with dedicated modules for different conversation types, feedback becomes a first-class citizen of the meeting rather than something you squeeze in when you are three minutes over time.