Giving and Receiving Feedback Questions

Direct answer

I would comment on the claim, not the author, ask for the evidence as a question, say what would change my mind, and mark which comments block approval. I push back when the claim drives a costly or hard-to-undo decision, accept when it is cheap to reverse and the design includes a way to check it, and move to a call when the thread has gone two rounds without converging, when the tone is tightening, or when the disagreement is about meaning (what the claim or the goal actually is) rather than about facts a benchmark could settle.

Example

The design doc says: "The new cache will cut p99 latency (the time within which 99% of requests finish) in half." There is no benchmark.

Comment drafts

• Question about the evidence: "This claim is the main reason for adding the cache, so I want to be sure of it. What workload and data size was this measured on, and what is the baseline? If you have not measured yet, could we add a quick benchmark to the doc, or mark this as a hypothesis with a plan to test it?"
• Say what would settle it: "A comparison of cache-on vs cache-off on a replay of last week's traffic (recorded real requests sent through both versions) would convince me."
• Label severity: start with "Blocking:" for the claim, and "Nit:" or "Optional:" for minor edits, so the author knows what must change.
• Acknowledge what is good: "The invalidation section (how stale cached entries get removed) is clear, and the rollout plan is thoughtful."

Push back or accept

When to move to a call

1. After two rounds of replies that still disagree.
2. When the thread is getting longer or the tone is tightening, since text hides intent.
3. When the author is likely to be discouraged by a stack of comments.
4. When the disagreement is about meaning, such as what "latency" or "fast enough" refers to, not about a fact a measurement could settle. A call clears up definitions quickly, while more text rarely does.

Accepting an incidental claim without a check is safe only if the thread says it is unverified, so nobody later builds on it as if it were measured.

After the call, write the outcome back into the doc ("agreed to benchmark on replayed traffic, owner Sam, due Friday") so the decision is on record.

Written feedback on a research-style draft

The same structure fits a colleague's paper draft: a short summary of what you understood the claim to be, then strengths (specific), then concerns ordered by importance (for example: the baseline is weak, the claim is stronger than the experiment supports), each with a suggested check, in a respectful tone. A concern written out: "The comparison is against a model with default settings, so the gain may come from tuning, not the new method. Could you add a baseline that gets the same tuning effort? If the gap holds, the claim is much stronger." Starting with the summary shows the author whether you understood them, which often removes half the disagreement.

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

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 not agree to a blanket rule. I would tell the lead, with an example, that the sandwich (praise, criticism, praise) works when the praise is specific and true and the criticism is small, and backfires when the praise is a ritual cushion that people learn to ignore or when the real issue gets buried. My rule is simpler: be specific, explain why, and make severity unmistakable; add praise where it is genuinely earned.

A performance suggestion on a colleague's pull request

The pagination logic is easy to follow, and the test for the empty page is a good catch.

Suggestion (non-blocking): load_all_users() is called inside the request handler and loads every user into memory (the program's working storage) before slicing out one page. That is fine at today's size but gets slower and heavier as the table grows. Could we ask the database for just one page? Two common ways are ORDER BY id LIMIT 20 OFFSET 40 (skip 40 rows, return the next 20, i.e. rows 41 to 60) or a keyset query (WHERE id > 40 ORDER BY id LIMIT 20: continue after the last id already seen; here 40, assuming ids 1 to 40 were on earlier pages, so it returns the same rows 41 to 60 as the OFFSET form). Both need the ORDER BY: without it the database may return any rows in any order. I can share a short example if useful.

"Non-blocking" is the severity label: the author may merge without fixing it, while "blocking" means it must be fixed before merge. The praise is specific and about this change; the suggestion has a reason and a severity; the closing offer is optional.

When the sandwich helps

• The person is new or visibly discouraged, and there is real good work to point at.
• The criticism is minor and the praise is related to it.
• It is a long relationship where warmth is already established.

When it backfires

• The praise is generic ("nice work!") and followed by "but": people learn to wait for the "but" and discount the first slice.
• The real message is buried, so the person misses that something is blocking.
• It is formulaic: if every comment follows the pattern, readers notice and distrust all of it.
• Urgent or serious issues (a security flaw): clarity matters more than cushioning.

Positive and negative balance

I don't aim for a fixed ratio. I aim to notice good work when it happens, say it when I mean it, and keep criticism separate and clear. A teammate who hears praise only as a cushion starts to hear all praise that way.

How I would raise this with the lead

Not as an objection to their intent (they want kind feedback). I would say, "I want review comments to be kind and clear. Can we agree on: specific praise when it's real, labeled severity, and the reason for every suggestion?" Then show the example above.

Trade-offs and pitfalls

• Dropping praise entirely makes reviews cold and one-directional.
• Over-polishing comments slows reviews; short and clear beats elaborate.
• Accept the lead's decision if the team wants the sandwich; make your own comments good within it.

Direct answer

I'd talk to the teammate privately, describe the specific pattern and its effect on the team, ask what is making reviews slow, agree a small concrete change, and track a number before and after. A pull request (PR) is a proposed code change that teammates review before it is merged, so a slow reviewer holds up everyone's work.

Prepare

• Pull the data: how long PRs wait for their first review. I'd call that the time to first review.
• Check causes: are they buried in their own work, getting huge PRs, or in a different time zone? The fix depends on the cause.

Deliver

"Over the last month, PRs assigned to you waited a median of about two days for a first look. Two teammates told me their work was blocked while waiting. I'd like us to get that down. What's getting in the way, and what would help?"

Possible agreements: a fixed 30-minute review slot each morning, a one-working-day target for a first response (even just "I'll look Thursday"), or asking authors to keep PRs small.

How I'd tell whether it helped

Measure the same thing before and after. Illustrative numbers (hours to first review, five PRs each):

• Before: 52, 70, 30, 66, 48. Median 52 hours.
• After: 20, 6, 26, 4, 10. Median 10 hours.

The median drops from 52 to 10 hours. I'd use the median since one very slow PR distorts an average. With only five PRs, it is evidence, not proof, so I'd look again over a couple of weeks.

I'd also check that quality did not drop: are reviews still catching problems, and are teammates reporting fewer blocked days?

Pitfalls

• Public shaming or a leaderboard of reviewers.
• Making speed the only goal, so reviews become rubber stamps.
• Skipping the conversation and quietly reassigning their reviews.