Feedback is the mechanism through which engineers learn, grow, and course-correct. Without effective feedback, performance issues fester, growth stalls, and excellent work goes unrecognised. This guide provides engineering managers with a comprehensive framework for giving, receiving, and systematising feedback across their teams.
Effective Feedback Models for Engineering Contexts
Several feedback models provide useful structure. The SBI model (Situation-Behaviour-Impact) describes a specific situation, the observed behaviour, and its impact. The COIN model (Context-Observation-Impact-Next steps) adds an action-oriented component. The ASK model (Actionable-Specific-Kind) provides a simple quality checklist for any feedback you give.
For engineering managers, the SBI model is particularly effective because it grounds feedback in observable facts rather than interpretations. 'In yesterday's sprint planning (Situation), you estimated every story at two points without discussion (Behaviour), which meant the team did not benefit from your expertise in identifying complexity (Impact)' is far more useful than 'You do not engage enough in planning sessions.'
Choose the model that fits the context. SBI works well for specific incidents. COIN works well when you want to prescribe a specific change. ASK works as a mental checklist before delivering any feedback. The model matters less than the principles it embodies: be specific, focus on observable behaviour, describe impact, and suggest a path forward.
- SBI (Situation-Behaviour-Impact) grounds feedback in observable facts
- COIN (Context-Observation-Impact-Next steps) adds an action-oriented element
- ASK (Actionable-Specific-Kind) provides a quality checklist for all feedback
- All models share core principles: specificity, behaviour focus, impact description, and forward action
- Choose the model that fits the context rather than forcing one model for all situations
Giving Feedback That Drives Change
Timing determines whether feedback drives change or creates resentment. Deliver feedback as close to the event as possible - within twenty-four hours for significant observations. Feedback delivered weeks later loses its connection to the specific context and feels like an accumulation of grievances rather than a growth opportunity.
Balance positive and constructive feedback, but do not use a mechanical ratio like the 'feedback sandwich' (positive-negative-positive). Engineers see through this technique, and the positive feedback feels insincere when it is always paired with criticism. Instead, give positive feedback frequently and independently, creating a relationship where constructive feedback is received as genuine support rather than an attack.
Adapt your feedback delivery to the individual. Some people prefer direct, blunt feedback. Others need more context and gentleness to hear the message without becoming defensive. Learn each person's preferences through observation and direct conversation: 'How do you prefer to receive feedback? What has been most helpful in the past?' This adaptation is not about softening the message but about ensuring it is received.
Building Peer Feedback Systems
Peer feedback is often more impactful than manager feedback because it comes from people who understand the day-to-day work intimately. Code reviews are the most natural peer feedback mechanism in engineering teams, but they are often limited to code quality rather than broader contributions like collaboration, communication, and mentoring.
Implement structured peer feedback through regular retrospectives, 360 reviews, or dedicated peer feedback sessions. When implementing 360 reviews, keep the process lightweight - three to five questions maximum, with a focus on strengths and growth areas rather than numerical ratings. Make peer feedback a development tool, not a performance evaluation tool, to encourage honesty.
Coach the team on how to give good peer feedback. Many engineers are uncomfortable providing feedback to colleagues - they either avoid it entirely or deliver it bluntly without considering impact. Model the behaviour you want, share the feedback models with the team, and create opportunities to practise in low-stakes settings like retrospectives before expecting high-quality peer feedback in formal reviews.
Receiving Feedback as an Engineering Manager
Engineering managers who do not actively seek feedback operate with blind spots. Your team members observe your management effectiveness daily but rarely volunteer critical feedback unless explicitly invited and rewarded for doing so. Create multiple channels for feedback: direct questions in one-on-ones, anonymous surveys, skip-level meetings, and regular self-assessments shared with the team.
When you receive feedback, resist the urge to explain or defend. The immediate response should be gratitude and curiosity: 'Thank you for sharing that. Can you tell me more about what you observed?' Take time to process the feedback before responding substantively. Some feedback will resonate immediately; other feedback will require reflection to understand its validity.
Visibly act on feedback you receive. When a team member suggests you are not providing enough context for decisions, and you subsequently start explaining the reasoning behind your decisions more explicitly, point out the connection: 'You mentioned wanting more context behind decisions - is this level of detail helpful?' This closes the feedback loop and reinforces that providing feedback to you leads to positive change.
Creating a Continuous Feedback Culture
Annual or bi-annual feedback cycles are insufficient for engineering teams where the pace of change is rapid. By the time a formal review occurs, months of accumulated observations land as overwhelming and disconnected from the specific events that prompted them. Continuous feedback - small, frequent observations shared in real time - is more effective and less emotionally charged.
Build feedback into existing workflows. Code review is feedback. Sprint retrospectives are feedback. One-on-ones are feedback opportunities. Stand-ups can include brief feedback moments. When feedback is woven into the daily rhythm of work rather than reserved for special occasions, it becomes a normal part of how the team operates.
Recognise and celebrate good work publicly and promptly. Engineering culture sometimes under-values positive feedback, treating it as unnecessary or even patronising. But genuine, specific recognition of excellent work is one of the most powerful tools an engineering manager has. 'Your approach to decomposing that migration into small, safe steps was exactly right - it reduced our risk significantly' costs nothing and creates lasting motivation.
Key Takeaways
- Use structured models like SBI to ground feedback in observable behaviour and specific impact
- Deliver feedback within twenty-four hours while the context is fresh and actionable
- Give positive feedback frequently and independently - do not bundle it with criticism
- Actively seek feedback about your own management through multiple channels
- Build feedback into existing workflows rather than reserving it for formal review cycles
Frequently Asked Questions
- How do you give feedback to a senior engineer who is resistant to it?
- Approach with respect for their expertise while being clear about the specific behaviour and its impact. Senior engineers often resist feedback because it feels like a challenge to their competence. Frame it differently: 'Your technical skills are not in question - this is about the impact of a specific behaviour on the team.' Be specific, use evidence, and focus on the systemic impact rather than personal shortcomings. If resistance persists, explore whether the underlying issue is the feedback itself or the way it is being delivered.
- How do you handle feedback that you disagree with?
- Take time to sit with it before dismissing it. Feedback you initially disagree with is often the most valuable because it highlights a blind spot. Ask yourself: is there any truth in this feedback? even if the specific example does not resonate, is there a pattern it points to? Seek additional perspectives from other trusted sources. If, after genuine reflection, you still disagree, explain your perspective to the feedback giver - but acknowledge that their perception is real even if you interpret the situation differently.
- How do you give feedback about someone's personality versus their behaviour?
- You do not give feedback about personality - only about observable behaviour and its impact. 'You are abrasive' is a personality judgement that invites defensiveness. 'When you dismiss others' ideas without explanation in design reviews, it discourages participation' describes behaviour and impact. People can change their behaviour; they cannot change their personality. Always focus your feedback on what someone does, not who they are.
Try the Feedback Tools
Use our feedback framework templates, peer feedback survey builder, and continuous feedback tracker to build a stronger feedback culture in your engineering team.
Learn More