Giving and Receiving Feedback Questions

Direct answer

I would talk to them privately, use SBI (Situation, Behavior, Impact: one concrete moment, what they actually wrote, and what it caused), then show a rewrite and offer to help. Vague wording is usually a habit or a way to avoid being wrong, so I ask a question before I prescribe.

Short script (about a minute)

1. Ask permission and set the tone: "Can I give you some feedback on your status updates? I think it will make you look more reliable, and I want your read on it."
2. Situation and behavior: "In Tuesday's update to the launch group you wrote 'should be done soon'."
3. Impact (a fact, not a guess): "Dana asked what soon meant, then scheduled an extra sync to find out, and the partner team could not plan around it."
4. Ask: "What makes it hard to commit to a date in those updates?" Listen. Often the answer is fear of being held to a date, and that deserves a real response.
5. Offer the pattern: "Try three parts: current state, a date or range with your confidence, and what could move it."
6. Close: "Want to draft the next one together, and I'll read it before it goes out?"

Before and after

• Before: "Migration should be done soon, just a few things left."
• After: "Migration status: 4 of 6 tables are moved. The two remaining tables are the largest. Expected finish: Thursday noon, medium confidence. Risk: backfill speed on the big tables. I will post Wednesday end of day with a firm date or flag a slip."

The after version gives a state (4 of 6), a date (Thursday noon), a confidence (medium), a risk, and the next check-in. The reader can plan, and the writer is protected because the uncertainty is stated rather than hidden.

Trade-offs and pitfalls

• A date they cannot hit is worse than a range. Give a range such as "Wednesday to Friday" when the work is truly uncertain, and say why.
• Do not say "you are always vague"; use the single example. One example is observable, a label is an argument.
• If they push back that precision invites blame, agree that status updates should be safe for honest slips, and say you will back them when a flagged risk happens.

Direct answer

I'll tell this as an illustrative story skeleton. A senior engineer on my project proposed that three new services (separate programs, each owned by a different team) share one database table (one shared set of rows and columns that all of them read and write). I was convinced it would cause cross-team breakages, and he outranked me. I prepared evidence, asked permission to give feedback, framed it as impact and questions, and offered an alternative to try, so the power gap shaped how I spoke without silencing the message.

Situation

He was respected and had designed much of the system. Several teammates had doubts but kept quiet. I was mid-level, and the design review (a meeting where the team examines a proposed design before building it) was in two days.

Managing the power gap

• Be sure I was right to speak: I had seen two schema changes (edits to a table's structure, such as renaming or removing a column) in the previous quarter break other teams' downstream jobs (scheduled programs that read that table and fail when a column they expect disappears). Picture one team renaming a column on Monday and another team's nightly report failing on Tuesday. That was observable, not opinion.
• Prepare and structure: I wrote a half-page: the two incidents, the risk if three services shared one table, and one alternative (each service owns its table and exposes data through an interface, a defined set of calls, instead of direct reads).
• Private first, with permission: "Could I give you a concern about the shared-table design before the review? I'd rather bring it to you than surprise you."
• Questions, not verdicts: "What happens to the other services when the orders table changes? I saw two cases last quarter where that broke downstream jobs."
• Own my uncertainty: "I may be missing a constraint."
• Offer a small test: "Could we try the owned-table approach for the first service and compare?"

What happened

He was quiet, then said I was right about the incidents but that separate tables would cost extra migration work (the effort of moving existing data and code onto the new layout). We agreed to a compromise: shared table only for read-only data (data services look at but never change), with owned tables for anything written. He credited the concern in the review. The relationship stayed good, and he later asked for my review earlier.

Do differently: I'd have raised it a week sooner, not two days before the review.

Pitfalls

Going over his head first, raising it for the first time in a public meeting, or arguing about whose opinion should count for more instead of pointing at observable impact. If the person is your manager, the same method applies, but state the impact on shared goals and what you need.

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.

The message (about 100 words)

Context: the dashboard tracks churn, the share of customers who stopped using the product.

Hi Priya, I opened the churn dashboard after Tuesday's review, where two people read the headline number differently. Two things caused it: the "Active" label does not say it means a login in the last 30 days, and there is no region or plan filter, so each team read the global figure as its own. The meeting then spent its time on what the number meant instead of the decision. Could we add a one-line definition under each label and the two filters? I can pair for 30 minutes this week and test it on someone who has not seen it. The charts themselves are clear.

Why it is built this way

• It follows SBI (Situation, Behavior, Impact, a model from the Center for Creative Leadership). Mapped onto the message: Situation = "after Tuesday's review"; Behavior = "the 'Active' label does not say it means a login in the last 30 days, and there is no region or plan filter"; Impact = "the meeting spent its time on what the number meant instead of the decision".
• It critiques the dashboard, not the person. The sentence about clear charts is true and specific, not a compliment sandwich.
• It makes one concrete ask (definitions plus two filters) and offers help with a time limit, so it is easy to say yes to.
• It gives evidence of misreading (two people, one number), which beats "stakeholders are confused" because the peer can check it.

The same method on a README for a model-serving container

A container is a packaged way to run a program with everything it needs, so a teammate can start it with one command. A model-serving container does that for a trained model that answers requests. Environment variables are named settings (such as a database address) that the program reads when it starts, and the Dockerfile is the recipe that builds the container image (the packaged template a container is started from).

Feedback note: "Your README (the file explaining how to run the container) starts with the architecture. When I tried to start it, I could not find the command to run it or which environment variables it needs, so I had to read the Dockerfile. Could the first screen be: what it does, the exact run command, required environment variables, and how to check it is healthy? A new teammate could then run it in five minutes, and we could drop the setup questions in chat." For a junior's README, add one comment on each of the three things you want: purpose, a reproducible run command, and the reason behind non-obvious settings.

The same method on an exploratory notebook with no conclusions

Feedback note: "In the churn notebook I found the plots, but I could not tell what you concluded or what you tested and dropped. Could you add a short summary cell at the top: the question, the three findings, the data and date range used, and what you would do next? Anyone opening it later could then use it without rerunning all of it."

Pitfall to avoid

A message that says "labels are confusing" with no example gives the peer nothing to fix and invites defensiveness.

Direct answer

I'll tell this as an illustrative story skeleton. A peer engineer on my team delivered more than anyone, but in design meetings he cut people off and dismissed ideas with "that won't scale." Within a quarter two quieter teammates stopped proposing anything. I decided to raise it because the cost was real and growing, I gathered specific examples first, and I spoke to him privately about the effect on the team, not his personality.

Situation

His output was strong, which is exactly why it was hard: people excused him, his manager had no complaint about results, and I risked looking petty or jealous. The team, though, was losing ideas and, over time, was at risk of losing the juniors who had gone quiet.

How I decided to raise it

• Evidence over impression: across four design reviews I noted what happened (interruptions, a design dropped after a one-line dismissal, a teammate who stopped presenting).
• Is it mine to raise? I worked with him daily and saw it first-hand, so yes. I did not go to his manager first because he had not had a fair chance to change.
• Cost of silence: psychological safety (the shared belief that you can speak up without being embarrassed) was dropping. That hurts decisions, not just feelings.

What I did

I asked for 30 minutes and said: "I want to talk about design reviews, because I think you'd want to know." Then: "In Tuesday's review, you said 'that won't scale' before Mei finished. She didn't present the rest, and we lost her caching idea, which turned out worth trying. I've seen similar in the last few reviews. I know you care about quality. How do you see the reviews going?" He was surprised and said he thought he was being efficient. We agreed he would ask a question before rejecting an idea and let people finish.

What changed

Over the next month he visibly changed his approach, the quieter engineers began speaking again, and I checked in once with a quick "that went better" note. The relationship stayed good, and he later asked me to tell him if it slipped.

Do differently: I'd have talked to him sooner; I waited about six weeks.

Pitfalls: treating strong results as a pass on behavior; waiting for a crisis; making it about his attitude.