Giving and Receiving Feedback Questions

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.

Direct answer

I post a short, blameless write-up that covers the facts, the cause in terms of our process, and the changes we are making. I leave anything about this one person (their intent, how they felt, whether this is a pattern) for a private conversation. To prevent a repeat I change the system (a heads-up rule and a pre-rollout check), not just the person.

Terms used

• Hot path: code that runs on most requests or on every one, so a slow change there is felt everywhere.
• Request path: the sequence of code that runs while a user is waiting for a response.
• Pool: the group of servers handling the same kind of work.
• Load test: running the change against traffic as heavy as production before release.

What goes in the channel, what stays private

• Public (the team needs it): what happened and when, the user-visible effect, the technical cause, the fix, and the new guardrails with named owners.
• Private (it is about the person): the junior engineer's reasons for not announcing the patch, how they are feeling, and feedback on their judgment, delivered with the SBI model (Situation, Behavior, Impact: a specific moment, what was observably done, what it caused). I do this the same day, before they read the channel post, so nothing about them is a surprise.
• Never in public: the person's name attached to blame, speculation about motives, or a comparison with others.
• Naming an owner is not naming blame: the channel post never says who wrote the patch. The one place the engineer appears is as owner of the re-proposal (item 3), and only because I asked them privately beforehand and they agreed. If they would rather not be named, the post says "the original author" and the follow-up is tracked in the ticket instead.

The message I would post (placeholders in brackets)

Update on today's CPU spike after the [time] deploy
What happened: An optimisation patch for [component] shipped in the [time] deploy. It ran a long operation inside the request path, and CPU on the [service] pool climbed until alerts fired. We rolled back at [time]; service is back to normal.
Cause: The patch was not load-tested at production traffic, and nothing in our flow made a change to a hot path visible to the team before it went out. That is a gap in our process, and as the team lead I own it.
What changes:

1. Any change to a hot path gets a one-line heads-up in this channel before merge, saying what it does and how it was tested. Owner: me, starting Monday.
2. The deploy checklist adds a 15-minute canary watch (release to a small slice of traffic first) on CPU and latency before full rollout. Owner: [site reliability engineer], in place by [date].
3. We re-run the optimisation under a load test and re-propose it. Owner: [engineer], with [senior] as reviewer, re-proposed by [date].
   If you have something similar queued, post it here first.

Item 3 also gives the junior engineer a clear path to get the work shipped safely, which keeps the tone constructive.

The same post, filled in (illustrative values)

Update on today's CPU spike after the 14:05 deploy
What happened: An optimisation patch for the search results page shipped in the 14:05 deploy. It ran a long operation inside the request path, and CPU on the web pool climbed until alerts fired at 14:20. We rolled back at 14:32; service is back to normal.
What changes: (1) Any change to a hot path gets a one-line heads-up in this channel before merge. Owner: me, starting Monday. (2) A 15-minute canary watch on CPU and latency before full rollout. Owner: Dana, in place by Friday. (3) Re-run the optimisation under a load test and re-propose it. Owner: Arjun, with Priya reviewing, by the end of next week.

In this filled-in version "Arjun" is named only as the owner of a forward task, with the person's agreement obtained in the private conversation. Nothing in the post links the name to the cause, which is stated in terms of the process gap. The filled-in version shortens the first one; in a real post I keep the Cause paragraph from the template above.

Why this shape

• It is blameless: it describes what the system allowed, which is what the next person will actually hit.
• Each change has an owner and a date, so it does not evaporate.
• I take ownership of the norm gap, because an unwritten expectation ("tell us before you push performance work") cannot fairly be held against someone who was never told it.

Trade-offs and pitfalls

• Posting nothing publicly leaves the team guessing and the process unfixed. Naming the engineer publicly teaches everyone to hide risky changes.
• If this is the third such incident or the engineer knowingly skipped a rule that was written down, the private conversation becomes firmer, but the public post stays the same.
• More process has a cost: if the heads-up rule becomes a heavy approval gate, people will route around it. Keep it to one line.

Direct answer

I prepare with specific examples and a check on my own part, open the one-on-one with the facts and ask for their view before I judge, agree a short written plan with measurable expectations, and then follow up on a fixed rhythm with recognition of progress. I stay kind about the person and clear about the standard. Empathy shapes how I say it; accountability decides what must change. Neither replaces the other.

Prepare (before the meeting)

• Write the gap in observable terms. "Two of the last five changes were rolled back (undone because they broke something) after causing a customer-visible error" beats "your quality is poor". Use 2 or 3 recent, dated examples.
• Check my side. Were expectations ever stated? Is the workload, onboarding or unclear ownership part of it? Did they get earlier feedback, or is this a surprise? If it is a surprise, that is partly my failure and I say so.
• Pick the outcome. What would "good" look like in 30 to 60 days, specifically?
• Plan the logistics. Private, unhurried, not on a Friday afternoon, no one else surprised (a quick word with HR, the human resources team, if this could become formal).

Run the one-on-one

1. Open plainly: "I want to talk about the quality of recent production changes. I want you to succeed here."
2. Give the facts using SBI (Situation, Behavior, Impact, from the Center for Creative Leadership): "Over the last five changes (Situation), two were rolled back and only one had tests (Behavior). Customers saw failed payments for part of a morning, and the team lost trust in releases from this area (Impact)."
3. Ask, then listen. "How do you see it? What is getting in the way?" Their answer may reveal a blocker (unclear requirements, no staging data, which means no realistic test copy of production data to try changes on, or personal strain).
4. Agree the expectation and support: e.g. tests for every behavior change, a named second reviewer for anything touching billing, and a weekly 20-minute check-in.
5. Put it in writing afterwards, in three lines they can reply to, for example:

Thanks for talking today. Agreed: (1) every behavior change ships with a test, starting now; (2) Dana reviews anything touching billing, and we meet for 20 minutes each Friday. (3) In week 4 we look together at your last five changes. Reply if I have missed anything.

Follow-up that avoids wrecking morale

The plan therefore covers the whole window, not only the first month. If progress is clear, say so openly. If it is not, move to a formal improvement plan (a PIP, performance improvement plan, with HR), which should never be a surprise because the earlier conversations were documented.

Worked example

Quality issue: of an engineer's last five changes, two were rolled back and only one had tests. Plan: tests required for every behavior change, review from a named senior on risky areas (the billing code, where a mistake costs customers money), and a Friday check-in. At week 4 the five new changes show tests on four, so I name that gain (from 1 of 5 to 4 of 5) before discussing the one miss. Empathy: I acknowledged the team had just absorbed a reorg (a reorganization, where reporting lines and projects changed). Accountability: the test requirement did not soften.

Trade-offs and pitfalls

• Being so gentle that the message is missed, or so blunt that the person shuts down. Test: could they repeat back what must change?
• Blaming character ("careless") instead of behavior.
• Vague follow-up: without dates and examples, "improve" cannot be measured by either of us.
• Ignoring the rest of the team: others see whether standards are held.

Direct answer

I'd start with what is genuinely good (the numbers are right, which is the hardest part to teach), name the problem as the audience's experience, show one slide fixed rather than describe it in the abstract, and then ask for just two changes first: (1) one message per slide, stated as a title that says the takeaway, and (2) one chart or table per slide, with everything else removed or moved to an appendix.

What I would actually say

"Thanks for sending this. Your numbers check out against the source, and that's the part people usually get wrong, so well done. When I read it as someone who wasn't in your analysis, though, I had to hunt for the point on slides 4, 5 and 8. Each has three charts and a paragraph, and I couldn't tell which one mattered. Here's one slide redone as an example (I'll share it). I'd like you to try two changes first. One: make each slide title the takeaway, like 'Churn rose in the new-plan cohort', instead of 'Churn analysis'. Two: keep one chart per slide and move the rest to an appendix. Do those two on the whole deck, then send it back and we'll look at colors and wording after. How does that sound? Anything you were trying to show that I've missed?"

Why this structure

• Specific praise first is information, not cushioning; it tells them what to keep.
• Audience impact ("I had to hunt") is observable and not about ability.
• A worked example teaches faster than a list of rules for a junior.
• Only two changes because a long list overwhelms a newcomer and they fix the cheap items (fonts) instead of the important ones. Colors, chart types, and spacing come in round two.
• Ask for their intent, since the clutter may come from fear of leaving something out.

Pitfalls

Do not rewrite the deck for them, do not say "it's messy" with no example, and do not hand over eight changes at once.

Direct answer

I make each comment specific (point at the line), explain the reason, offer a way forward, and phrase it about the code, not the person. I include one true, specific piece of praise, mark which items must change, and offer to pair (work through it together, live) on the hard one. The aim is that the new hire knows exactly what to do next and feels the review was about their work getting good, not about them being judged.

Principles

• Comment on the code, never the developer (Google's code-review guidance): "this function" instead of "you wrote".
• Explain why: the reader learns a rule for next time, not only this fix.
• Prefer a question or a suggestion with a reason over a command.
• Label severity (Blocking, Consider, Nit) so they can plan.
• Limit the volume. Pick the three most important problems first; the rest can follow in a later round.

Key comments, worded

• Weak: "This is wrong, you forgot null handling (a null is a missing value)."
  Better: "Blocking: if email is null here, line 42 will throw and the request fails. Could we check for null first, or return a clear error? Example: if email is None: return error(...)."
• Weak: "Why did you copy this?"
  Better: "Consider reusing parse_date from utils. It already handles the time zone case, so we avoid two copies to keep in sync."
• Praise that is real: "The tests for the happy path (the normal case where everything works) are clear, thank you for adding them."

ML-model review example

Terms first: a scaler rescales numbers using the data's average and spread. Fitting it means calculating that average and spread. A train and test split holds some data back so the model can be scored on rows it never saw. Data leakage is when information from the held-back rows sneaks into training, like seeing the exam answers before the exam. Tiny example: training values 10, 20, 30 have average 20; if a held-back value of 100 is included in the calculation, the average becomes 40. The test set has quietly shaped the training.

Blocking: "The scaler is fitted on the whole dataset before the train and test split. That lets test data influence the training statistics (data leakage), so the reported accuracy can look better than production. Could we fit it on the training split only and apply it to the test split? It's an easy mistake, and I can show you the pattern." This balances correctness (it is blocking) with encouragement (the mistake is named as common, with help offered).

Unclear commit messages (short role-play)

Reviewer: "Thanks for fixing the blocking items. Can we talk about the commit message?"
New hire: "Is it too long?"
Reviewer: "It's long, but the main point is hidden. A reader skimming history needs the 'what' in the first line."
Before (for the null-email fix above): "fixed stuff and changed the config so the thing works now, also tried some other approach"
After: "Fix null email crash in signup handler" plus a one-line body: "Check email before normalizing; add test for empty email." The config change and the other approach, if they belong in the PR at all, get their own commits with their own first lines.

Trade-offs and pitfalls

• Praise that is generic ("nice job!") reads as a cushion; specific praise teaches.
• Fixing everything for them in the review stops the learning. Offer to pair on one hard point and let them write the rest.
• Do not water down a real bug: if it is a blocker, say so plainly and kindly.