Feedback is not a personality trait. Some people are not "naturally" good at giving feedback and others are not "naturally" better at receiving it. These are learned skills, and like all skills, they improve with deliberate practice and deteriorate without use. Most organisations treat feedback as something people either have or do not have, which is why most feedback cultures never improve - because the skills are never taught, the structures are never built, and the models are never shared.

The consequence is predictable. Feedback flows downward, is often negative, arrives late, and is experienced as criticism rather than development input. Peer feedback does not happen at all, or happens in the artificially constructed environment of an annual 360 that nobody takes seriously. Engineers who are struggling do not hear about it until it becomes a formal process. Engineers who are excelling hear vague positive comments that do not tell them what specifically to keep doing.

This section builds the framework for a functional feedback system - not as an aspiration, but as a set of specific skills, structures, and habits that can be adopted and practised.

Why Most Feedback Fails

Understanding the failure modes of feedback is the starting point for fixing them. Most feedback fails for one or more of four reasons: it is too vague, it arrives too late, it is framed as personal rather than behavioural, or it is too positive to be useful.

Too Vague

"Good job on the release." "Your communication could be better." "You need to think more strategically."

None of these is feedback. They are assessments without evidence. The recipient cannot act on them because they do not know what specifically was good about the release, what specifically their communication is doing that needs to change, or what strategic thinking looks like in their context.

Vague feedback has no development value. It may have some motivational value in the positive case, but even that is limited because the recipient does not know what behaviour to repeat. In the developmental case, it creates anxiety without direction. The engineer leaves the conversation knowing they have fallen short of something without knowing what or how to fix it.

Too Late

Feedback delivered weeks or months after the event is not actionable. The engineer cannot remember the context clearly, cannot reconstruct the situation, and cannot make any meaningful link between the feedback and their behaviour. Feedback loses utility rapidly - within days for most behavioural feedback. The principle is simple: if you have feedback worth giving, give it as close to the relevant event as is practical.

Too Personal

"You are not very detail-oriented." "You can come across as arrogant." "You are quite passive in meetings."

These are character assessments, not feedback. They describe who the person is rather than what the person did. They invite defensiveness, not reflection, because defending a behaviour is possible but defending an identity is necessary for self-preservation. Feedback that is experienced as an attack on identity will not be heard, and the feedback giver will conclude that the recipient is "not open to feedback" - which may be true of identity-level feedback, but tells us nothing about whether they could hear behavioural feedback.

Too Positive to Be Useful

Feedback sandwiches, positive-only feedback sessions, 360 reports that are predominantly complimentary - these create a false picture of performance and deprive engineers of the developmental input they need. Being generous with positive feedback is valuable and important. Positive feedback that is deployed as a cushion around developmental feedback, or as a substitute for it, serves the feedback giver's comfort more than the recipient's development.

The SBI Model

The Situation-Behaviour-Impact model is the most useful practical framework for feedback delivery. It is not the only one, but it addresses the most common failure modes directly: vagueness (by requiring specificity about situation and behaviour), lateness (by anchoring the conversation in a specific event), and personalisation (by focusing on behaviour, not character).

How SBI Works

Situation - Name the specific context. Not "in meetings" but "in the architecture review last Tuesday." Not "when you write code" but "on the authentication service PR you submitted on Wednesday." Specificity prevents the recipient from deflecting by disputing the general characterisation.

Behaviour - Describe what was observable. Not "you were dismissive" but "you interrupted Alex twice and did not respond to his technical objection." Not "your code was poor quality" but "the PR had no test coverage for the error paths and the naming conventions did not match the rest of the codebase." Observable behaviour is not debatable in the way that character assessments are. Either the interruptions happened or they did not.

Impact - Name the consequence. Not "it was not great" but "the team stopped contributing ideas after that point, and we may have missed a significant risk as a result." Not "it slowed down review" but "the reviewer spent an hour unpicking the error handling because the intent was not clear, which delayed the release by half a day."

Worked Examples

The difference is not just style. The specific feedback is actionable. The engineer knows exactly what to do differently or what to keep doing.

Giving Feedback That Lands

Having the right framework does not guarantee that the feedback will be heard. The conditions around the delivery matter as much as the content.

Timing

Give feedback as close to the event as practical. "As practical" means:

• Not in the middle of a stressful moment - feedback during a live incident will not be heard and will increase anxiety
• Not in a public setting when the feedback is developmental - developmental feedback is almost always better given privately
• Not in writing when the feedback is significant - significant developmental feedback deserves a conversation, not a message that can be reread in isolation repeatedly without the context of tone and relationship

For positive feedback, immediacy matters less, but promptness still signals that you are paying attention.

Framing

Lead with intent. "I'm giving you this feedback because I think you have significant strengths and I want to help you use them more effectively" is a different opening than launching directly into the SBI structure. The recipient's psychological state when they receive feedback determines how much of it lands. If they are already defensive, the most accurate SBI feedback in the world will be filtered out.

Do not use the feedback sandwich (positive - developmental - positive). The recipient has been conditioned by enough sandwiches to know that "great job on X" means "here comes something difficult." The positive feedback becomes noise in service of the developmental point. If you have positive feedback and developmental feedback to give, give them at separate times.

When It Is Not Received Well

Sometimes feedback is not received well. This is information, not failure. The appropriate response depends on what is happening:

• Defensiveness about the content. Slow down. Ask a question rather than repeating the assertion. "Help me understand what your read of the situation was." Sometimes the feedback is wrong and you will find out. Sometimes the engineer needs to process before they can hear it.
• Rejection of the framing. If the engineer disputes that the situation or behaviour occurred as described, acknowledge the discrepancy without backing down from what you observed. "I can only tell you what I observed. I'm open to the possibility that I missed context."
• Shutdown. If the engineer goes quiet and disengages, name it. "I notice you've gone quiet - is this a difficult thing to hear?" Do not force the conversation, but do not pretend you have not noticed.
• Deflection. If the engineer redirects to someone else's behaviour or an external factor, acknowledge it and return. "That may be relevant, and I want to hear about it. Can we finish this point first?"

Never end a feedback conversation without checking that the engineer has heard what you intended to say. Not "did you understand?" but "what's your take on what I've said?"

Receiving Feedback

Receiving feedback well is a skill. It is rarely trained. Most people's default responses to developmental feedback are shaped by experiences of feedback that felt like criticism, by workplaces where admitting difficulty was risky, and by the natural human instinct to defend one's sense of self when it feels under threat.

The Default Responses and Why They Are Unhelpful

Immediate defence. "That is not what happened." "You are taking it out of context." This response shuts the conversation down before the recipient has actually processed the feedback. Even if the defence is partially valid, deploying it immediately signals that you are not going to hear the feedback and the giver will stop trying.

Immediate agreement without processing. "Yes, you are absolutely right, I'll do better." This looks like good feedback reception but is often a social strategy for ending an uncomfortable conversation quickly. The engineer agrees, the conversation ends, and no change follows. This is the performance of receiving feedback rather than actually receiving it.

Turning it back. "I think the real issue is that the team doesn't give me clear requirements." This may be valid context, but using it as an immediate redirect is deflection. It protects the self from examination by pointing outward.

What Good Feedback Reception Looks Like

Listen first. Do not form your response while the feedback is being delivered. Actually listen to what is being said. If you are constructing your defence or your agreement while the person is still speaking, you are not hearing the content.

Ask clarifying questions. Not challenging questions that imply the feedback is wrong, but genuine clarifying questions. "When you say my communication is unclear, are you talking about written communication, verbal, or both?" "Can you give me another example so I can see the pattern?" Clarifying questions signal engagement and generate more useful information.

Separate message from delivery. Feedback is sometimes delivered poorly - in the wrong tone, without enough context, with more directness than the relationship warrants. If the delivery is imperfect but the content has merit, separating the two is essential. Dismissing valid feedback because it was delivered badly is a significant development cost.

Give it time. Do not judge the feedback in the moment. Say "I want to think about this" and mean it. The feedback that stings most acutely in the moment is often the most useful. Come back to it later with more distance.

Close the loop. If someone has given you developmental feedback and you have taken an action as a result, tell them. It reinforces the feedback relationship and signals that you took the input seriously.

Peer Feedback

Peer feedback is the most valuable kind and the most commonly absent. Managers see a fraction of an engineer's actual work. Peers see it all - the code quality, the approach to difficult problems, the collaborative behaviour, the ways of communicating under pressure. Peer feedback, when it is honest and specific, is extraordinarily useful. When it is absent, or when it is systematically positive regardless of reality, the development system is operating with a significant blind spot.

Why Peer Feedback Is Hard

Social cost. Giving honest developmental feedback to a peer risks the relationship. It feels safer to say nothing or to say something vague and positive. The instinct to protect the relationship is natural and, in the short term, rational. The long-term consequence is that peers who could be genuinely useful development partners become sources of noise rather than signal.

Unclear permission. Most teams do not have an established norm of peer feedback. In the absence of an explicit structure and expectation, feedback feels like overstepping.

No skill. The SBI model is not widely known. Most people, asked to give peer feedback, default to general impressions and positive observations because they have no framework for being specific.

Creating Conditions for Honest Peer Feedback

Explicit structure. Create the expectation and the vehicle. Whether that is a practice of feedback at the end of collaborative projects, a regular structured retrospective element, or a lightweight template - the expectation needs to be named.

Model it from leadership. If senior engineers and managers are giving and receiving specific, honest feedback openly, it signals that it is safe to do the same.

Pair feedback. Ask for feedback and give feedback together. "I'd like to exchange some feedback on the project we just finished - can we find twenty minutes?" This reduces the one-sidedness and makes it feel less like an evaluation.

Protect what is shared. Peer feedback shared in a confidential conversation must stay there. If it is fed back without permission, the feedback channel closes permanently.

Avoiding the "All Positive" Trap

Annual 360 tools almost universally produce predominantly positive feedback. This is not because everyone is performing excellently. It is because:

• People know the recipient will see who wrote what, even when nominally anonymous
• The format encourages general responses rather than specific observations
• Social norms discourage honesty in formal, recorded feedback

Designing better peer feedback means designing for informality, specificity, and genuine safety. The annual 360 in its standard form is largely a waste of time. A conversation between two engineers at the end of a shared project, with a simple prompt ("what's one thing I did well and one thing that would have made it easier to work with me?"), is substantially more valuable.

Feedback Cadence

Feedback should be a habit, not an event. The question is not "when do we do feedback?" but "how do we make feedback the normal texture of how this team works?"

Building Feedback Into Existing Rituals

Code review. The pull request review is already a feedback mechanism. It is often used only for technical content. It can also be used for communication feedback (was the PR description clear?), process feedback (were the changes appropriately scoped?), and positive reinforcement ("this approach to the error handling is really clean - I'll follow this pattern").

Sprint retrospectives. The retrospective is a natural vehicle for team-level feedback. Adding a brief structured element where individuals can give and receive feedback - not just talk about team process - makes it more useful.

1:1s. If feedback is explicitly on the agenda of every 1:1, it normalises the exchange. "One thing I've noticed this week" as a standing item, flowing in both directions, builds the habit over time.

Project closures. When a significant project ends, a structured conversation about individual contribution and learning is more valuable than a general team retrospective alone.

Frequency Guidance

The most important number here is "immediately when warranted" for positive reinforcement. Most managers dramatically underestimate how infrequently they recognise good work with specific, timely feedback. The engineer who receives a specific positive observation about something they did well is more likely to repeat that behaviour and more likely to be open to developmental feedback from the same manager.

Creating a Team Feedback Culture

The individual skills described above are necessary but not sufficient. A feedback culture is a property of the team, not of any individual, and it requires both structural support and modelling from leaders.

What Leaders Model

If the team lead never gives specific feedback, never asks for it, and reacts poorly when they receive it, the team will follow. If the team lead gives specific feedback regularly, asks "what's one thing I could have done better?" in retrospectives, and visibly incorporates feedback they receive, they are demonstrating that the feedback culture is real and safe.

The specific leader behaviours that build a feedback culture:

• Give positive feedback publicly and developmental feedback privately
• Ask for feedback on your own leadership explicitly and regularly
• Act visibly on feedback received ("last month someone told me my meeting facilitation cut discussion off too early - I've tried to change that")
• When someone gives you difficult feedback, thank them specifically for it
• Never let difficult feedback become a grudge

Structures That Help

• A team working agreement that explicitly includes "we give each other honest, specific feedback"
• A lightweight template for project-end peer feedback
• A retrospective format that includes individual feedback as well as team process
• Manager 1:1s where feedback is explicitly and regularly on the agenda

What Gets in the Way

Psychological safety deficits. If engineers do not feel safe to be honest - because feedback has been used against people, because the culture is politically charged, because managers have reacted poorly to difficult feedback in the past - no amount of structural encouragement will generate honest feedback. Safety comes first.

Hierarchy dynamics. In organisations where seniority is strongly signalled, feedback upward feels risky. Senior engineers need to actively invite and model receiving feedback from more junior colleagues for this channel to open.

Overwork. Teams that are consistently overloaded do not invest in feedback practices. The feedback culture is a casualty of capacity pressure. This is a real cost that is rarely counted when evaluating the impact of sustained overwork.

Common Failures

The Feedback Sandwich

The feedback sandwich (positive observation - developmental observation - positive observation) is so widely practised that most recipients have developed an automatic response: "here comes the thing I actually need to worry about." The positive bookends are discounted immediately. The developmental observation is heard in isolation, often more harshly than intended because the recipient is braced for it. The final positive is not heard at all.

Give positive feedback when you have positive feedback to give. Give developmental feedback when you have developmental feedback to give. Do not mix them into a format that undermines both.

Annual 360s Nobody Reads

The 360 feedback report that arrives once a year, is filed with HR, is summarised in one line in the annual review, and is never discussed again is not a feedback system. It is a compliance exercise. The time invested in generating it far exceeds the development value it produces.

If a 360 process exists in your organisation, make it mean something: discuss it in a dedicated conversation, identify two or three specific development priorities from it, and revisit those priorities in the next six months. Otherwise, retire it and invest that time in the more frequent, informal feedback practices that actually change behaviour.

Feedback That Is Really Just Venting

Feedback that is designed to express frustration rather than support development is not feedback - it is venting with a veneer of developmental intent. "I need to tell you that I found that behaviour really frustrating" is an expression of emotion. It may be valid, but it is not feedback unless it includes specific description of what happened, why it had the impact it did, and what different behaviour would look like.

Managers who give feedback primarily when they are frustrated with someone are not building a feedback culture. They are creating a culture where feedback is associated with negative emotion and is therefore avoided.

Feedback That Protects the Giver

The engineer who says "just to let you know, some people on the team are frustrated with you" without being specific, without naming sources (even in general terms), and without being willing to stand behind the observation is not giving feedback. They are passing on information in a way that protects them from any accountability for it. This kind of "feedback" creates anxiety without direction and corrodes trust.

If you have something worth saying, say it in your own name, with specificity, and with the intent of helping.

Connection to Your Operating Model

A feedback system does not function independently. It depends on:

Psychological safety. Feedback flows in proportion to safety. The engineering team that feels safe to surface problems, admit mistakes, and share honest observations will generate far more useful feedback than one where honesty feels risky. Safety is built through how leaders respond when hard things are said.

A shared performance framework. Feedback is most useful when both parties share a reference point for what "good" looks like. The capability framework and role archetypes give feedback conversations a common vocabulary. "In the level 3 expectation around technical leadership, this is an area where I'd expect to see more..." is more actionable than "you need to be more of a technical leader."

Manager capability. Feedback skills are manager skills. The quality of feedback in an organisation is a function of the quality of manager development. If feedback skills are not explicitly part of how managers are developed and assessed, the feedback culture will be inconsistent at best.

Frequency and rhythm. A feedback culture is not built with a training day and a new form. It is built through repeated small interactions over time. The daily and weekly rhythms of the team determine whether feedback becomes a habit or remains an event.

Continuity. Feedback relationships take time to build. They are damaged by reorganisations, manager churn, and team instability. Frequent structural change is the enemy of feedback culture because it prevents the relationship trust that makes honest feedback possible.

This section connects directly to: Modern Performance Management, PDPs and PIPs, Addressing Underperformance, Talent Reviews and Calibration, and the psychological safety dimensions of Team Effectiveness.

Implementing a Feedback System

Building a feedback culture requires a phased approach. Announcing "we are going to have a feedback culture now" and issuing a policy document produces compliance without behaviour change. The following implementation path is based on what actually works.

Phase 1: Build Manager Capability First

Manager feedback behaviour is the primary driver of team feedback culture. Before asking teams to exchange feedback with each other, equip managers to give and receive feedback well. This requires:

• Training in the SBI model with worked examples relevant to your engineering context
• Practice sessions where managers give feedback to each other on simulated situations
• Coaching support for managers after their first difficult feedback conversations
• A feedback norm within the management group itself - managers should be receiving and giving feedback about their management, not just about their technical work

If managers are not practising feedback as a skill, asking teams to do so is asking them to model behaviour that leadership is not modelling.

Phase 2: Introduce Team Structures

Once managers are practising feedback consistently, introduce lightweight structures at the team level:

Retrospective feedback segment. Add a brief structured element to every retrospective: "One thing someone on this team did well this sprint" and "One thing that would have made it easier to work together." This normalises feedback in the team setting.

Project-end peer feedback. At the end of each significant delivery, prompt team members to exchange feedback in pairs. A simple prompt works: "What's one thing I did well in this project, and what's one thing I could have done differently that would have made your work easier?"

Channel for recognition. A team Slack channel or equivalent for specific peer recognition. The key is the norm: recognition should be specific and about something concrete, not a generic "great job."

Phase 3: Develop Individual Feedback Skills

Once structures are in place, develop individual skills explicitly. Run a workshop (two to three hours) covering:

• Why feedback fails and what the failure modes look like
• The SBI model with practice
• How to receive feedback without becoming defensive
• How to give feedback when the relationship is at risk
• What to do when feedback is not landing

The workshop should include real practice, not just theory. Managers and engineers practising with each other on real (if somewhat sanitised) situations will build the muscle memory that makes the skills accessible when they are needed under pressure.

Phase 4: Embed and Sustain

Feedback culture is not a destination - it requires sustained maintenance. The factors that erode it over time:

• Manager turnover (new managers who have not been inducted into the culture)
• Reorganisations (disrupted team relationships)
• Periods of high pressure (feedback deprioritised in favour of delivery)
• Incidents where feedback was misused (trust eroded, channel closed)

Sustained maintenance requires:

• Induction for new managers that explicitly covers the feedback culture and expectations
• Manager peer groups where feedback practice is maintained
• Regular pulse checks on feedback culture (one-question survey: "I receive specific, useful feedback regularly" - track over time)
• Leadership attention when the culture slips

Feedback in Code Review

The pull request review is already a feedback mechanism. In most teams, it is used almost exclusively for technical content. Expanding its use to include communication feedback, process feedback, and explicit positive reinforcement - while maintaining its technical rigour - can significantly increase the frequency of specific feedback without adding any new meetings or processes.

Principles for Feedback-Rich Code Review

Be specific about what works. "This error handling approach is exactly right - it preserves the contract while protecting against the failure mode we saw in the incident last year. I'll reference this in the codebase guide." This is positive reinforcement that the engineer can use. "LGTM" is not.

Name the principle, not just the correction. "The variable name d doesn't give the reader enough to work with - a reader unfamiliar with this section would lose the thread. In our codebase, we prefer names that communicate intent without requiring context." This is more useful than "rename this variable."

Distinguish must-fix from suggestion. Feedback that is blocking should be clearly marked as such. Suggestions and preferences should be equally clearly marked as non-blocking. Engineers whose PRs are returned with ten unmarked comments do not know how to prioritise. Engineers who receive specific, labelled feedback can make good decisions about how to respond.

Review the communication as well as the code. "The PR description gives me the what but not the why - what was the alternative you considered and ruled out?" This kind of feedback develops communication skills as well as technical ones.

The Code Review as a Teaching Vehicle

Senior engineers who give rich, specific feedback in code review are building capability in the team continuously. The senior engineer who writes "nit: use list comprehension here" as their only comment is missing a significant teaching opportunity. The senior engineer who writes "list comprehension would be more idiomatic Python here, but more importantly I'd want us to think about whether this transformation should live in the service layer at all - the data model seems like a better home for it" is giving feedback that develops both craft and design thinking.

Code review feedback from senior engineers should be considered part of their contribution to team capability. It should be recognised as such, and the quality of code review feedback should be part of capability assessment for senior levels.

Reference: Feedback Quality Self-Assessment

Use this checklist before delivering significant developmental feedback:

Preparation:

• I can name the specific situation (date, context, project)
• I can describe the observable behaviour without characterising the person
• I can name the specific impact - on the team, the product, or a specific person
• I am delivering this because I want to help, not because I am frustrated
• The timing is appropriate - not in the middle of a stressful moment, not weeks after the event

Delivery:

• I will lead with my intent before the content
• I will use SBI structure
• I will leave space for the recipient to respond
• I will not soften the message to the point of losing it
• I will check at the end that the message has been received as intended

Follow-up:

• I will check in with the person in the next week to see how they are
• If they have acted on the feedback, I will notice and name it

A feedback conversation that fails more than two of these criteria should be rescheduled or significantly revised before delivery.

Reference: Common Feedback Phrases That Undermine Impact

The following phrases are frequently used and consistently undermine the feedback they accompany:

None of these phrases are never appropriate. All of them are overused in ways that dilute the feedback they surround. Awareness of the patterns is the first step to using them more intentionally.

Reference: Receiving Difficult Feedback - A Practical Guide for Engineers

Receiving feedback well is a professional skill. The following guidance can be shared directly with engineers as a reference:

When feedback arrives that is hard to hear:

1. Do not respond immediately. Take a breath. The immediate response is almost always defensive. A pause of even five seconds changes the character of the conversation.

2. Listen to the whole thing. Do not formulate your response while the feedback is still being delivered. You will miss content and the speaker will know you are not listening.

3. Ask a clarifying question before responding. "Can you give me an example?" or "When you say X, what specifically do you mean?" is a more productive first response than defence or agreement.

4. Separate the message from the delivery. If the feedback is delivered badly, note that separately. The question of whether the content has merit is independent of whether the delivery was skilful. Bad delivery does not make valid content invalid.

5. Say "let me think about this" and mean it. It is perfectly acceptable to say "I want to sit with this before responding" and to come back to the conversation later. This is not avoidance - it is processing.

6. After some time, ask yourself honestly: Is there anything true in this? Even 20% true? If so, what would it mean to act on that 20%?

7. Close the loop. If you have acted on feedback someone gave you, tell them. "I've been thinking about what you said last week about my PR descriptions. I've tried to be more explicit about the context in the last three PRs. Did it land better?" This reinforces the feedback relationship and signals that you took the input seriously.

The engineer who has a reputation for receiving feedback well will receive more of it, which means more development signal, which means faster growth. The engineer who is known for becoming defensive will stop receiving honest feedback, which means they will receive only positive feedback - which is comfortable and developmentally useless.