Giving and Receiving Feedback Questions

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

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

Private is the default for critical feedback about an individual's behavior or work. Public (in a retro or team meeting) is right for team-level patterns framed as process, for praise, and, rarely, for correcting something happening right now that would hurt others. A rule I use: public about the system, private about the person.

When each applies

• Private: the feedback is about one person's judgment, habits, tone or quality; it might embarrass them; I need to hear their side. (A 1:1 is a regular private meeting between two people, often with a manager.)
• Public: it concerns a shared pattern (review turnaround, flaky tests); the team needs to agree a change; or it is praise that sets a standard.
• Public correction in the moment: only if waiting causes harm (someone about to run a destructive command on production). I correct the action briefly, then follow up privately.

Example 1: private (a recurring behavior)

A teammate repeatedly merges without tests. I use the SBI structure (Situation, Behavior, Impact: name the moment, what the person did, and the effect). In a 1:1 I say: "Last week's pull request for the billing job (Situation) was merged without tests (Behavior). The nightly run failed on Monday because of a case a test would have caught (Impact). Can we talk about what is getting in the way of adding tests?" I ask first, because the cause might be a slow test setup, not carelessness.

Example 2: public (a team pattern, in a retro)

(A retro is a regular team meeting to review how work went.) Instead of "Sam is slow reviewing", I say: "Our pull requests are waiting about two days for the first review (this can be checked from the tracker). That blocks releases. Can we agree on a first-response expectation and a rotation?" This names the pattern and invites a shared fix. The wording is blameless (it describes what happened and the process, not whose fault it was), and nobody is singled out.

Example 3: public correction in the moment

Someone in a team call is about to run a delete command against the production database (the live system customers use). I say, right then and calmly: "Hold on, that command targets production. Can we check the environment first?" I correct the action, not the person, and keep it to one sentence. Afterwards I message them privately: "Thanks for stopping. Here is how I would set up the safeguard so it is harder to hit prod by mistake. Want to pair on it?"

Trade-offs and pitfalls

• Public criticism of a person damages trust and teaches others to hide problems.
• Private-only for team patterns means nothing changes, because each person thinks it is only their issue.
• If something in a retro clearly points at one person, take it offline; do not let the room guess.
• Some people want praise privately; ask.
• Cultural norms differ on how comfortable people are with group feedback, so check preferences rather than assuming.

Direct answer

Situation-Behavior-Impact (SBI) is a three-part feedback structure from the Center for Creative Leadership. You name the Situation (when and where, so it is specific), the Behavior (what you directly saw or heard, with no guesses about motive), and the Impact (what it caused for you, the team or the product). Because it describes facts and effects instead of labeling the person, it is harder to argue with and easier to act on.

How to use it for a teammate who keeps missing sprint commitments

A sprint is a fixed work cycle (often two weeks) and a commitment is the set of tasks the team agreed to finish in it. Steps:

1. Check the facts first. Pull the last few sprints so you describe a pattern, not one bad week.
2. Ask privately, early, and say the purpose. "I'd like to talk about sprint delivery. I think it will help both of us."
3. Deliver S, B, I in two or three sentences, then stop and listen.
4. Ask for their view. CCL's extended version adds a fourth step, the person's intent, which turns it into a conversation. They may be overloaded, blocked, or under-estimating.
5. Agree one concrete next step and a check-in date.

Worked example (illustrative numbers)

• Situation: "In our last three sprint reviews..."
• Behavior: "...you committed to five stories (a story is one small piece of work, written from the user's point of view) each time and finished three, so two were carried over each sprint (six carried-over stories in total)."
• Impact: "QA (quality assurance, the people who test changes) could not start testing the carried-over stories, and Priya's work that depends on yours kept slipping. It also makes our forecast (our estimate of what we will deliver and when) to the product manager unreliable."
• Ask: "What's getting in the way from your side?"
• Next step: "Next planning, let's commit to four and split any story bigger than two days. We'll look again at the next sprint review."

Weak versions to avoid

Pitfalls

• Skipping the listening step turns SBI into a verdict.
• Impact must be real and specific; vague impact ("it's bad for the team") adds nothing.
• Use it for behavior the person can change; if the cause is unrealistic planning by the whole team, the fix is in planning, not in feedback.

Direct answer

I would give the feedback privately, in person first and then in a short written note, using specific examples of what stakeholders could not find. I would ask for one concrete change (a plain-language summary at the top), and I would check it landed by seeing whether a stakeholder can use the next postmortem without asking an engineer.

A postmortem is a written report after an incident: what happened, why, and what changes. Stakeholders are the non-engineers who rely on it, such as support, product or management. The jargon in the note below: a database failover is the automatic switch to a backup database when the main one fails; replication lag is how far the backup was behind the main database, shown in graphs; a config diff is a line-by-line comparison of settings before and after the change. All three matter to engineers and tell a support lead little about customers.

The conversation

1. Open with what is strong: the analysis is accurate.
2. Describe the observable gap: where the impact sits, and a real instance of a stakeholder asking for help.
3. Ask what audience they had in mind. A senior engineer may have written it for other engineers on purpose.
4. Agree on the change and on a date.

The written note (SBI: Situation, Behavior, Impact)

Hi Maya, I read the database failover postmortem from last week (situation). The technical analysis is sound, and the timeline is the clearest I have seen. The first page opens with the replication-lag graphs and the config diff, and the customer impact appears in section 4 (behavior). Our support lead told me she could not tell from it how many customers were affected or whether it could happen again, so she asked me instead of reading it (impact). Could the top of each postmortem have four lines: what happened, who was affected and for how long, whether it is fixed, and what we are changing? The detail can follow. Would you try it on the next one? I can read the draft first.

The note contains the three parts (situation: the failover postmortem; behavior: impact buried in section 4; impact: the support lead had to ask) plus a specific request and an offer to help. It is under 150 words and avoids words like "unreadable."

What a stakeholder-usable postmortem has at the top

The engineering detail stays below, as it is.

How I tell whether it landed

• Direct signal: I ask a stakeholder (the support lead) to read only the top of the next postmortem and tell me the impact. If she can, it worked.
• Indirect signal: fewer "what does this mean for us" questions arrive in chat after a postmortem is published.
• Behavior signal: the next postmortem opens with the summary without a reminder.
• If it did not land: I ask what got in the way. It may be time, uncertainty about how much to simplify, or disagreement, and I respond to that cause.

Pitfall

Do not rewrite their postmortem for them, since it fixes the document without fixing the habit.