Giving and Receiving Feedback Questions

Direct answer

My default is asynchronous (written, on the pull request (PR), doc, or ticket) for specific, checkable feedback, because it is precise, linkable and gives the author time to think. I switch to live when the feedback is about direction or architecture, when the topic is ambiguous or emotionally loaded, or when an async thread has gone about two rounds of reply and counter-reply without converging. I make feedback get acted on by turning it into items with an owner and a date, writing the outcome of any live conversation back to the written record, and checking at a set point.

Choosing the channel

Making sure it is acted on

• Each item gets an owner, a due date, and a place (ticket or PR checklist), and I ask for a one-line reply.
• After a live review, I post the decisions and action items the same day; otherwise the conversation did not happen as far as absent teammates are concerned.
• At the next checkpoint I look at the list, not at my memory.

Reviewing SQL, ETL and dashboards

(ETL means extract, transform, load: the jobs that move and reshape data.) I use criteria, not taste, and put them in the review checklist:

• SQL: the output grain (what one row represents, for example one row per order), join correctness, row counts reconciled to the source, and readable formatting, enforced by a linter (a tool that automatically flags style problems) such as SQLFluff.
• ETL: safe to re-run without duplicating rows, automated data tests (for example the dbt tool's not_null check, which fails if a column has blanks, and unique check, which fails if a key repeats), and clear failure alerts.
• Dashboards: metric definitions written down, filters that behave as labelled, and the audience's question answered on the first screen.

A written review comment on a join might read: "This join to customers can return two rows per order when a customer has two addresses, so revenue is double counted. Row count before the join is 10,000 and after is 10,400. Please join on the primary address only, or aggregate first. Blocking, because the totals are wrong."

Tracking implementation uses the same method: checklist items in the PR or ticket, closed explicitly.

Example: a design review that changed a design, and the pushback

In a design review I flagged that a new feature chained three services synchronously (each call waits for the previous one to finish, so one slow or failed service stalls the whole request). If each service is up 99.9% of the time ("99.9% available"), the request only succeeds when all three are up, so the chain is about 99.7%:

0.999 x 0.999 x 0.999 = 0.997

That is roughly 26 hours of failure a year instead of 9, so one risky hop becomes everyone's outage. The owner pushed back: a queue (a buffer that lets work wait and be processed later, so the caller does not block) would cost two weeks. I asked what the real deadline was, separated must-fix from suggestions, and proposed a smaller step: make only one hop asynchronous, the one with the worst incident history (the weakest link in practice, even though the 99.9% figure above is a simplifying assumption of equal services), meaning it runs through the queue instead of making the caller wait. That leaves two synchronous services: 0.999 x 0.999 = 0.998, about 17.5 hours of failure a year instead of about 26. We agreed, and I wrote a short decision note with a trigger to revisit if volume doubled.

Pitfalls

• Two rounds of reply and counter-reply in a pull request (PR) thread without convergence, and certainly ten messages, is a signal to get on a call.
• A call without a written summary leaves the feedback unowned.

Direct answer

I treat what I know about cultural norms as a hypothesis about a person, not a fact about them. I ask people how they like to receive feedback, write feedback so the content is clear regardless of tone, avoid idioms and sarcasm, and check what was understood by asking for the takeaway in their own words. My assumptions get tested by watching what actually happens, not by country.

How I adapt

1. Ask early, one to one: "How do you prefer to get feedback: in writing first, live, in private? Anything I should know about how you read direct comments?" and offer my own style: "I tend to be direct. Tell me if that is too blunt."
2. Use a neutral structure. SBI (Situation, Behavior, Impact) states a specific moment, what was done, and the effect. It is easy to translate and avoids loaded labels.
3. Use plain language in writing. For non-native speakers, avoid idioms ("this is a bit off the mark"). Do not rely on hedges or silence to carry the message.
4. Make the ask explicit. Instead of "maybe consider...", say "I would like this changed before merge" or "this is optional".
5. Choose the channel on purpose. Some people prefer written first, then discussion; some find public feedback more costly than others do.

Checking assumptions

• Ask: "What are you taking away from this, and what will you change?" Silence or "yes" may mean "I heard you", not "I agree".
• Notice patterns: does someone never raise disagreement in meetings but write a careful note afterward? Give them that route.
• Ask a trusted colleague from that region how a comment would read, and ask the recipient directly afterward: "Was that clear? Too direct?"
• Erin Meyer's The Culture Map includes an "evaluating" scale of direct versus indirect negative feedback across cultures. It is a useful prompt for questions, but individuals vary widely within any country.

Worked example

Two reviewers on one pull request (PR) have the same concern about a missing retry. A direct writer says: "This will fail under load. Add a retry." An indirect writer says: "Perhaps we might think about whether retries are needed?" A teammate used to indirect feedback may read the first as hostile, and a teammate used to direct feedback may miss the second as a requirement. My version: "Observation: this call has no retry, and a timeout in staging last week dropped orders. I'd like a retry added before merge. Does that work for you, or do you see a reason not to?" It is clear, specific and invites a reply.

Pitfalls

• Stereotyping by nationality rather than asking.
• Softening until the message is lost; kind and clear are compatible.
• Assuming a direct culture wants harsh delivery.

Direct answer

I would design a light process with four parts: (1) feedback attached to moments the work already has (a model review, a launch, a quarter end), (2) a short template that keeps it safe and specific, (3) every actionable item tracked with an owner and a date, and retros used to close recurring themes, and (4) a graduated, non-punitive response to teams that do not participate. Success is measured on participation, follow-through and recurring themes, by team, not by individual.

1. Timely: tie feedback to existing moments

• Trigger after milestones that ML teams already have: an experiment review, a model sign-off (the formal approval that a model is good enough to ship), a handover of a dataset or pipeline (passing ownership to another person or team), and a launch retro (a review meeting after release). Teams outside ML use their own equivalents, such as a design sign-off or a release retro.
• A short prompt goes to collaborators within a week of the milestone: "What should this person keep doing, and what is one thing to change?"

2. Safe: a small template and ground rules

• Two lines in SBI (Situation, Behavior, Impact) form plus one suggested next step. For example: "In the ranking-model review on 12 March, the ablation results were shared only as a screenshot (Situation and Behavior), so I could not check which features drove the gain and the sign-off waited two days (Impact). Next step: attach the notebook with the results."
• About the work and behavior, not the person's character. Feedback is developmental (meant to help the person improve) and kept separate from performance ratings and pay decisions, so people are candid.
• Attributed by default, meaning the giver's name is shown to the recipient, so the recipient can ask follow-up questions. For sensitive cases there is a manager-routed option: the giver tells their own manager or the recipient's manager, who passes the message on in person, still saying who it came from, rather than sending it anonymously.

3. Tracking follow-through

• Actionable items are written as: what, owner, due date, where tracked (the recipient's one-to-one (1:1) meeting notes or a team board).
• Teams review open items in their retrospective (a regular team meeting about how work went). If the same theme appears in two retros, it becomes a team improvement item with an owner, so recurring problems are solved at the system level.
• Measure follow-through as the share of items closed by their due date.

4. Chronic non-participation

• First, find out why: workload, unclear value, fear, or a lead who does not model it.
• Steps: a nudge, then a conversation between the team lead and their manager, then the participation expectation written into lead responsibilities. The aim is a fixed barrier, not a penalty.
• Report participation by team to leadership, never name individuals.

Worked example (illustrative numbers)

An organisation with 8 teams sends 24 feedback requests in a quarter (3 per team) and 15 are answered within 7 days: 15 / 24 = 62.5%. Of 12 actionable items raised, 9 are closed by their due date: 9 / 12 = 75%. That leaves 9 requests unanswered. Teams A, B and C answered 0, 1 and 1 of their 3 requests, so they account for 7 of the 9 unanswered; the other five teams answered 13 of 15. I meet those three leads, discover that one has no meeting slot after launches, and move the prompt into their launch retro. The next quarter I compare the same two rates for the same teams.

Pitfalls

• Over-engineered forms kill participation.
• Anonymous-only feedback cannot be followed up.
• Counting volume without checking follow-through rewards noise.

Direct answer

In the moment I listen without defending, thank them, and ask for the specific moment that landed badly. Afterwards I change how I deliver (private first, check intent, plainer wording) without dropping the substance of the feedback, and I repair the relationship with a follow-up that acknowledges the impact and asks how they would like to hear it. Intent and impact are different: I can mean well and still have hurt.

In the moment

• Pause and listen. Do not explain your intent first; that sounds like "you are wrong to be hurt".
• Say thanks and name what you heard: "Thank you for telling me. It sounds like it landed as criticism in front of others, and that stung."
• Ask one specific question: "What was the moment, and what did you hear in it?"
• If I feel defensive, say "I want to think about this properly, can we talk tomorrow?" rather than answering badly.

What I change

1. Venue: negative feedback goes private first unless it is about a team-level process.
2. Structure: use SBI (Situation, Behavior, Impact): a concrete moment, an observable behavior, the effect, with no labels like "careless".
3. Ask before I tell: "Would it be useful to hear some feedback on X?" and "How did that land?" afterward.
4. Tone check on written words: read the message as the recipient would, on a bad day.

Repair

• A short follow-up: "I've thought about what you said. The point I raised still matters, but I should have raised it privately and with an example. I'm sorry it landed that way."
• Do not retract the feedback itself if it was valid; apologise for the delivery.
• Ask: "How would you like me to bring things like this up in future?"
• Then do it. The repair is confirmed by the next few interactions (for example the next two or three times I have critical feedback to give), not by the apology. The number is a rule of thumb, not a measured threshold.

Worked example

I told a peer in a design review, "your error handling is sloppy." Later they said it felt like a public shot. I replied, "Thanks for telling me. What part felt worst?" ("Hearing it in front of the team.") The next day I said: "I should have said this privately. The specific issue: the retry in the payment call swallows failures, which would hide outages. Can we look at it together?" We fixed it, and I now send substantive critiques privately first.

Pitfalls

• "I'm sorry you feel that way" is not an apology.
• Over-correcting into never giving candid feedback again makes things worse for both of you.

Direct answer

I would start a small, regular habit, not a program: a short feedback slot in the team's existing retrospective (a regular meeting where the team reviews how work went), a "no surprises at review time" rule, and me asking for feedback first. I get adoption by going first and keeping it light, and I judge success with a few leading signals (early indicators that show up before the final outcome: frequency, speed, lack of surprises) plus what people tell me, not a single score.

The practice

1. I go first. In 1:1s (regular one-to-one meetings) I ask, "What is one thing I could do differently that would help you?" and visibly act on it. People copy what the lead does with feedback.
2. A standing two-minute slot in the retro. Each person gives one piece of peer feedback or appreciation using SBI (Situation, Behavior, Impact: a specific moment, what was done, the effect). This makes feedback small, regular and normal.
3. "No surprises" rule. Anything that would appear in a performance review should already have been said at least once before it. Managers check this before each review cycle.
4. A one-page guide: an SBI card with a good and a bad example, so people have words to start with. For example:
   • Weak: "Your updates are confusing."
   • SBI: "In Tuesday's stand-up (Situation) you listed five tasks without saying which one was blocked (Behavior), so I did not know whether to step in and the blocked task sat for a day (Impact). Could you lead with the blocker next time?"
     In the retro slot the same shape is shorter: "Thanks for the design walkthrough on Thursday; the diagram made the trade-off clear for me."

Getting adoption

• Start with a trial: "Let's try this for six weeks, then decide if it is useful." At six weeks I check the early signals (is the slot still happening, how many items were given); the 12-week pulse comparison below is the fuller read, so the trial is extended to 12 weeks if the six-week signals are mixed rather than judged on too little time.
• Keep it low ceremony. If it feels like homework, it dies.
• Build psychological safety (people believe they will not be punished for speaking up) by thanking people for feedback in public, including feedback about me, and by never using shared feedback against someone.
• Expect the first rounds to be shallow. Praise first, specifics later.

How I tell it is working

• Frequency: feedback items given in the slot and outside it (a rough count is enough).
• Surprise rate: at review time I ask each person, "Was anything here new to you?" The goal is "no".
• Pulse question (a single quick survey question repeated over time): one anonymous question, "In the last month I received feedback that helped me", asked at the start and after 12 weeks.
• Qualitative: are people raising concerns earlier, in smaller form?

Worked example

On a team of six, baseline (the starting measurement before the change): two say they received helpful feedback in the last month. After 12 weeks: five say so, and nobody reports a surprise at review. Because the team is only six, one person changing their answer moves the result by about 17 percentage points. So I would not declare success on the number alone; I also look at whether the retro slot is still happening without me chasing it and what people say in 1:1s.

Pitfalls

• Mandating anonymous surveys as the only channel signals that direct feedback is unsafe.
• Measuring only volume can encourage empty feedback.