Coachability, Feedback, and Humility Questions

Direct answer

Confirm the finding factually rather than arguing scope, volunteer the specific technical detail that helps pinpoint exactly what happened since you often know something the reviewers don't, state your own responsibility precisely instead of a generic "I'm sorry," and move the conversation to concrete, assigned remediation rather than stopping at contrition.

Structured elaboration

A post-incident review is a structured, after-the-fact discussion of an outage or incident meant to establish what happened and how to prevent it recurring, not just to assign blame.

1. During the review: don't dispute a fair, evidence-backed finding, and don't over-claim more responsibility than the evidence supports either; both distort the record the team is relying on. Contribute the specific technical detail that clarifies exactly what happened, what you were looking at, what assumption you made, what monitoring gap let it through, since that's usually more useful to the group than an emotional response.
2. Accepting responsibility: be specific about what you did or didn't do. "I deployed the config change without the canary step (rolling a change out to a small slice of traffic first to catch problems before a full release) because I judged it low-risk, and that judgment was wrong here" is a stronger and more useful statement than a vague "I'm sorry it happened."
3. Remediation: propose or help write concrete, assigned action items, not "be more careful." Look for a guardrail (a check that makes the mistake harder to make again), a detection gap (an alert that should have fired sooner), or a process change (a step that shouldn't have been skippable).
4. Follow-through: actually complete your assigned action items and report back that they shipped and were validated. The review is only credible if the fixes materialize.

Worked example

In a review for an incident where a config change I pushed without the canary step caused a spike in errors, the review traced it directly to my deploy. I confirmed the finding: I'd judged the change low-risk because similar changes had gone fine before, and that judgment didn't hold for this one because it touched the routing layer. I also flagged a detail nobody else had surfaced: our alert on that route only fired on raw error count, not error rate, so a low-traffic window let the problem linger longer than it should have before anyone noticed. I proposed two action items, made the canary step non-skippable for routing-layer changes, and switched that alert to a rate-based threshold, owned both myself, and reported back in the next team review that they'd shipped and been validated.

Trade-offs and pitfalls

Accepting a review's finding is not the same as agreeing to every downstream framing; if a review labels something "human error" when a missing guardrail made the error easy to make in the first place, it's fair, and useful to the team, to name the systemic contributor alongside your own ownership. Staying silent on that just guarantees the next person makes the same mistake. Volunteering to personally own every remediation item, even ones better owned by someone with more context, can look eager but actually slows the fix and reads as more about personal redemption than the right outcome. And stopping at the apology, with no concrete follow-through reported later, is the most common shallow version of this answer.

Direct answer

Prioritize by risk and reversibility first, whatever breaks something or blocks others if left unaddressed goes first, then by who actually owns the outcome the feedback concerns, then by how expensive the fix becomes if delayed. When those three still leave a genuine conflict, get the stakeholders talking to each other directly rather than mediating between them one at a time.

Structured elaboration

Three criteria, applied in order:

1. Risk and blast radius (a fancier way of asking "how much of the system or how many users does this affect when it happens"). Does this piece of feedback point at something that could cause a defect, a security issue, or a missed requirement if ignored? That goes first, regardless of who raised it or how it was phrased.

2. Ownership and authority. Whoever is accountable for the outcome the feedback concerns gets more weight on the parts of the work that intersect their ownership. A quality engineer's release-blocking bug outranks a peer's style preference; a product manager's scope call outranks a style preference too, but not a real defect.

3. Cost of delay versus cost of rework. Fix now what gets more expensive to change later, like a data shape, an interface, or a security gap, and defer what is cheap to change after shipping, like wording or minor visual polish.

When the criteria do not resolve it. If two pieces of feedback still genuinely conflict on the same decision after applying all three, that is usually a sign the decision is not actually yours to make unilaterally between two people's legitimate authority. Bring the relevant stakeholders into the same conversation so they negotiate the trade-off directly, rather than you picking a side and explaining it to each of them separately afterward.

Worked example

As a Backend Developer, while building a new API endpoint, quality assurance flagged a missing edge-case validation before merge, a peer engineer suggested a broader refactor of the surrounding module for long-term maintainability, and the product manager wanted the feature shipped by the end of the week. Applying the criteria: the validation gap was risk-and-blast-radius critical, a real defect could reach production, and cheap to fix, so it went in immediately. The refactor was valuable but not release-blocking, and doing it properly under time pressure would be more expensive than doing it later with more care, so it was logged as a follow-up ticket instead of done inline. Told the product manager directly that the validation fix was non-negotiable for the ship date, but the refactor would slip to the next sprint (the team's next short, fixed work cycle), and the product manager agreed once the risk was made concrete rather than abstract.

Trade-offs and pitfalls

Defaulting to whoever is loudest or most senior instead of applying real criteria erodes trust with whoever gets deprioritized repeatedly, even when the decision happens to be right. Silently picking one stakeholder's feedback without explaining the reasoning to the others reads as favoritism, even when the underlying call was sound. And treating every piece of feedback as equally urgent means nothing actually ships; the discipline is in explicitly and visibly deferring some of it, not doing everything at once and hoping it works out.

Direct answer

I reach for a small set of question types depending on what's actually missing from the feedback: what specifically prompted it, what a good outcome looks like, and whether there's a concrete example I should be checking against. Which one I lead with depends on whether the feedback is missing a trigger, a target, or a test case.

Structured elaboration

"What specifically led to this?" I use this when the feedback names a symptom without a cause, like "this feels slow" or "the messaging is off." It surfaces the underlying observation the person is reacting to, which is usually more actionable than the summary they gave you.

"What would a good version of this look like to you?" I use this when the direction is vague but the person clearly has something in mind, like "make this more strategic" or "this needs to feel more polished." Rather than guessing at their mental model, I ask them to describe the target directly, since two people can read the same vague word very differently.

"Is there a specific case or example I should make sure this handles?" I use this when the feedback sounds like it's reacting to a particular instance rather than a general pattern, like "this broke for me" or "a user complained about this." A concrete example is the fastest way to convert a vague complaint into something you can actually verify you've fixed.

A fourth, quieter tool: paraphrasing what you think they meant and asking them to confirm or correct it, useful any time you're not fully sure which of the above three questions even applies yet.

Worked example

A stakeholder says a report "doesn't feel complete." I could ask any of the three: "what specifically feels missing, is it a metric, more context, or something else?" (surfacing the trigger), "what would a complete version include, in your view?" (surfacing the target), or "is there a specific decision you were trying to make with this that the report didn't support?" (surfacing a concrete case). In this instance I'd probably start with the third, since "doesn't feel complete" often really means "didn't help me decide something," and that question gets at the actual gap fastest.

Trade-offs and pitfalls

Asking every question at once, rather than picking the one that fits the specific gap in the feedback, can overwhelm the person and make simple feedback feel like an interrogation. Relying on the same single question every time, regardless of what's actually missing, means you'll sometimes ask for a concrete example when what was actually missing was a definition of "good," which doesn't move the conversation forward. And treating the clarifying question as the end of the interaction, rather than following through on what the answer reveals, wastes the value of having asked at all.

Direct answer

Being criticized after a major outage for not tracking the right metrics is a fair critique to own directly: the gap wasn't effort, it was blind spots in what was being measured. The fix is a small, targeted set of KPIs (key performance indicators, the specific measures chosen to track how well a system or process is doing) tied directly to what would have changed the outcome, each with a clear reason it matters, plus a standing habit of revisiting that set after every future incident rather than treating the new metrics as a permanent fix.

Structured elaboration

Choose metrics tied to the actual gap the outage exposed, not a generic wish list. A detection-speed metric, the time from when a problem actually starts to when it's first alerted on, matters when the postmortem shows the real failure was not knowing about the problem soon enough. A leading-indicator metric closer to the root cause (for example, a resource-saturation or error-rate trend that historically shows up before the user-facing symptom does) matters when the team was only watching a lagging, user-facing signal. A recovery-speed metric, time from detection to mitigation, matters separately from detection speed, since a fast detection with a slow response is still a long outage.

Explain why each one matters in terms of the specific gap, not "more monitoring is good." Every metric added should trace back to a specific moment in the postmortem timeline where the team either found out too late or didn't know something was building. If a proposed metric doesn't map to a real gap from that timeline, it's probably not the right one to add.

Use feedback over time to refine the set. After every subsequent incident or even a near-miss, ask explicitly whether the current metrics would have caught it earlier. If not, add or adjust. Just as importantly, retire metrics that turn out noisy or that nobody actually acts on; a growing pile of dashboards is not automatically more signal, and treating your own metric choices as something to keep getting feedback on, from real incidents, is what keeps the set useful rather than decorative.

Worked example

A postmortem finds that the team only alerted on user-facing error rate, which spiked only after a slow resource leak had been building for hours with no earlier signal being tracked at all. Leadership's criticism, that the right things weren't being measured, is fair given that gap. The response adds a saturation-trend metric with a warning threshold well before the symptom would appear, a time-to-detect metric that makes the detection gap itself visible on every future incident, and a time-to-mitigate metric to track response speed once detected. Later, a different but related saturation issue trips the new earlier warning threshold well before it reaches users, which is the new metrics doing exactly what they were added for, but the same incident also shows the mitigation-time metric alone doesn't say which specific response step was slow, prompting it to be broken into finer sub-steps next.

Trade-offs and pitfalls

Reacting to this kind of criticism by adding a large dashboard of everything measurable, rather than a small set tied to the actual gap, buries the useful signal in noise nobody has time to watch. Treating the new metric set as a one-time fix, rather than something to keep checking against future incidents, lets the same class of blind spot quietly return once memory of this outage fades. Picking metrics because they're easy to instrument rather than because they map to a real gap in the postmortem timeline produces dashboards that look thorough but don't actually change how fast the next problem gets caught.

Direct answer

I separate fixing the bug from evaluating the criticism, since the first is urgent and does not wait on the second. I investigate immediately to understand what actually broke, then look at what testing existed for that specific path before agreeing or disagreeing that rigor was the gap, and either way I put a concrete prevention measure in place afterward.

Structured elaboration

Immediate steps to investigate the bug. Reproduce the bug, identify the specific code path and condition that triggers it, check severity and blast radius, how many users or how much data is affected, and put a mitigation in place, a rollback, a feature flag off, a hotfix, before doing a full root cause analysis. Stopping the immediate damage comes before assigning cause.

Deciding whether to accept or push back on the testing-rigor criticism. I check what tests actually existed for the affected path. If nothing covered this exact scenario, and it is a scenario that reasonably should have been covered, a common input or a known edge case, the criticism is fair, and I say so directly. If the bug comes from a genuinely unexpected combination of conditions that would not reasonably be anticipated, or from something outside test scope entirely, a third-party API change, an infrastructure issue, a data pattern that did not exist when the feature shipped, I push back with the specific evidence rather than accepting blame that is not accurate. I try to distinguish "insufficient coverage" from "a bug slipped through despite reasonable coverage," since perfect coverage is not realistic and conflating the two teaches the wrong lesson.

Preventing similar issues in the future. I add the specific missing test case, then look one level broader: is this an isolated gap, or a whole category of scenario, for example all boundary conditions on this type of input, that is systematically under-tested. If it is a category, I prioritize closing the category, not just this one instance.

Worked example

A stakeholder reports users are seeing incorrect account balances after a batch update job runs. Immediate steps: reproduce against a copy of the affected data, find the trigger, a rounding error that only appears when a user has more than a specific number of transactions in a single batch cycle, confirm blast radius (roughly 2% of accounts cross that threshold), and ship a hotfix correcting the rounding while a full root-cause review continues.

Testing-rigor question: checking the existing tests shows there was a unit test for the rounding logic, but it only used small transaction counts, well below the threshold that triggers the bug. The specific scenario genuinely was not covered, and reasonably should have been, since batch sizes above that threshold are not unusual. I accept the criticism: "you're right, our test suite didn't cover high-volume batches for this path, that's a real gap." Prevention: I add a test case at and above the threshold, then audit the other batch-processing paths in the same module for the same class of gap, untested behavior at high transaction counts, finding and fixing two more before they cause a separate incident.

Trade-offs and pitfalls

Investigating the criticism before fixing the bug delays mitigation while the production issue is still live. Accepting all blame reflexively, to appear accountable, even when the evidence shows the gap was not really about testing rigor, hides the actual root cause and can misdirect future prevention effort. Pushing back defensively without first checking the actual test coverage risks denying a real gap. Broadening the prevention fix to a whole category of untested scenarios costs more time than patching just the one case, worth it when the category, not just the instance, is genuinely under-tested.