Giving and Receiving Feedback — The Engine of Growth

Giving feedback is uncomfortable because:
  → You might damage the relationship
  → The other person might react badly
  → You might be wrong
  → It might not land the way you intend

Receiving feedback is uncomfortable because:
  → It can feel like criticism of who you are, not what you did
  → The feedback might be delivered badly (even if correct)
  → It triggers defensive instincts — fight, flee, or freeze
  → It's humbling to hear you're not as good at something as you thought

The result: most teams operate with almost no real feedback.
Engineers write code for years without knowing how their colleagues experience them.
Problems that feedback would resolve early become entrenched team dynamics.

The cost of a feedback-deficient culture:
  → People repeat the same mistakes because nobody told them
  → Resentment builds ("everyone knows she doesn't communicate — why does nobody say anything?")
  → The annual review becomes the first time feedback is delivered — months too late
  → Exits are surprises ("I had no idea they were unhappy")

Feedback, done well, is the most direct investment in another person's growth.
Done badly, it damages trust. Done not at all, it abandons people to their blind spots.

SBI: Situation → Behaviour → Impact

The most common feedback model in engineering teams.
Keeps feedback specific, observable, and connected to real consequences.

Situation: the specific context (when and where)
  → "In yesterday's production incident call..."
  → "During the sprint review on Tuesday..."
  → "In the PR review you left for James..."

Behaviour: the observable action (not interpretation, not character assessment)
  → "you explained the root cause clearly before the stakeholders escalated"
  → "you presented the INR validation feature without mentioning it was 3 days late"
  → "you left 12 comments but didn't explain why any of them were blockers"

Impact: the effect on the team, user, or clinical outcome
  → "which gave the clinical director confidence and stopped the call from going to MHRA"
  → "which meant I found out about the delay from the product manager, not you"
  → "which meant James couldn't tell what to fix first and the PR sat blocked for 2 days"

SBI for positive feedback:
  "In the ward round demo last Friday [Situation], you noticed the clinical lead
   was confused about the INR history view and you stepped in to explain it
   without being asked [Behaviour]. She said afterwards it was the clearest
   demo she'd seen — it changed her view of the system [Impact].
   That kind of user awareness is something I want to see more of."

SBI for constructive feedback:
  "In the architecture review on Monday [Situation], you interrupted Sarah three
   times while she was explaining her approach [Behaviour]. I noticed she stopped
   elaborating after the second interruption, and I think we missed her full
   perspective on the trade-offs [Impact]. I'd like to talk about how we can
   create more space for everyone in those discussions."

Timing:
  Soon after the event — not weeks later.
  "Can I give you some feedback about the incident call yesterday?" lands better than
  "Remember 6 weeks ago when..."
  Exception: if you need to calm down first, wait — angry feedback does more damage
  than late feedback.

Privacy:
  Constructive feedback: always private. One on one.
  Positive feedback: can be public, but check the person's preference first.
  Some people find public praise uncomfortable — ask before you assume.

Permission:
  "Can I share some feedback about the PR review process?" — creates a receptive mindset.
  Feedback delivered without warning triggers more defensiveness.
  The question isn't "may I?", it's a signal that signals: "this is feedback, prepare yourself."

One topic at a time:
  "You interrupted Sarah, you were late to the design review, and your code
   has too many comments" — the person doesn't know which to address first
   and feels attacked.
  Pick the most important thing. Have one conversation.
  If there are three things, have three conversations.

Invite their perspective:
  End constructive feedback with a question — not a verdict.
  "I wanted to share how that landed for me. What's your experience of those discussions?"
  Sometimes there's context you don't have.
  Sometimes the person already knows and has been trying to change.
  The question turns a delivery into a conversation.

The default response to feedback:
  → Immediate explanation of why you did it that way
  → Correction of the feedback-giver ("actually, what happened was...")
  → Deflection ("the context was really difficult")
  → Silence followed by thinking about why they're wrong

These responses feel protective in the moment.
They signal to the feedback-giver: "don't bother again."
And they prevent you from learning anything.

A better response — even when the feedback is wrong or badly delivered:

1. Acknowledge receipt
   "Thank you for telling me."
   Not "thank you — that's really helpful!" if it didn't feel helpful.
   Just acknowledgment that you heard it.

2. Ask questions to understand
   "Can you tell me more about what you noticed?"
   "Can you give me an example?"
   This is not the same as arguing. It's understanding.

3. Separate the delivery from the content
   Feedback delivered harshly can still be correct.
   Feedback delivered kindly can be wrong.
   Don't evaluate the content based on the delivery.

4. Take time before responding
   "Let me think about this. Can I come back to you tomorrow?"
   This is not avoidance — it's processing.
   Immediate responses to feedback are usually defensive.

5. Close the loop
   If you decide to act on feedback: tell the person.
   "You were right that I interrupted too much in the meeting. I'm working on it."
   This completes the loop and builds trust that feedback lands.

Most feedback requests are vague: "Any feedback on how I'm doing?"
Vague requests produce vague answers: "You're doing well, keep it up."
Useless for growth.

Better: specific, targeted feedback requests

Instead of: "How am I doing as tech lead?"
Ask:        "I want to improve how I run architecture reviews — am I creating enough
             space for the team to contribute? What would make those meetings more useful?"

Instead of: "Any feedback on my code?"
Ask:        "In the prescription module PRs — are my review comments clear enough?
             Are there things I'm missing that I should be catching?"

Instead of: "How was the stakeholder presentation?"
Ask:        "When I explained the INR integration timeline to the product manager —
             did my explanation of why we needed the 2-week buffer land? Did she
             seem to understand the risk?"

The specificity signals:
  → You're serious about improving (not just asking for reassurance)
  → You have a specific area of uncertainty
  → The feedback-giver knows what to observe and reflect on

Ask upward, sideways, and downward:
  → From your manager: strategic clarity, stakeholder perception, career trajectory
  → From peers: collaboration patterns, communication, blind spots in cross-team work
  → From junior engineers: am I creating space? Is my feedback helping you grow?
    (These responses take the most psychological safety to give — ask directly)

Technical feedback requires an extra step — separating correctness from approach.

When someone challenges your technical decision:
  "I don't think we should have used a GUID for the prescription event stream ID —
   it's causing index fragmentation."

The wrong response: "We discussed this in the ADR — it was the right call."
(Defensiveness + appeal to prior decision)

The right response:
  1. Acknowledge the concern: "The fragmentation — how bad is it? What numbers are you seeing?"
  2. Separate fact from recommendation: "You're right that NEWID() causes fragmentation.
     The question is whether NEWSEQUENTIALID() is the right fix, or whether we need
     to address the index separately."
  3. Be open to being wrong: "If the fragmentation is affecting performance, we should fix it.
     What's the option you'd recommend?"
  4. If the feedback is correct: "You're right. I should have used NEWSEQUENTIALID()
     from the start. Let's plan a migration."

The principle: technical decisions are not personal commitments.
Being wrong about a database key type does not make you a bad engineer.
Defending a wrong decision because it's yours does make you a less effective one.

The fastest way to earn technical respect: be right about the things that matter,
and acknowledge quickly when you're wrong about the things that don't.

Feedback culture is created by leaders going first.

If the tech lead:
  → Asks for feedback publicly ("I want to improve how I run our design reviews — what's not working?")
  → Acknowledges feedback received ("You were right that I moved too fast past
     Sarah's concern in Monday's meeting — I'm going to slow down in those moments")
  → Thanks people for difficult feedback ("I appreciate you telling me — it wasn't
     easy to hear but it was useful")

Then the team learns:
  → Feedback is safe to give
  → Feedback is taken seriously
  → Being corrected is not a punishment

If the tech lead:
  → Never asks for feedback
  → Responds to feedback with justification and defensiveness
  → Doesn't visibly act on feedback received

Then the team learns:
  → Feedback is not welcome here
  → Giving feedback has no positive outcome
  → Problems should be discussed elsewhere (hallways, 1:1s with the manager's manager)

You cannot ask a team to be feedback-receptive if you are not feedback-receptive yourself.
Model the behaviour you want to see.