Coachability, Feedback, and Humility Questions

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

State the failure plainly and specifically in your own words, rather than a vague "I own it," name a concrete, applicable lesson instead of a generic resolution, and describe the trust shift as an observable change in how the team worked with you afterward, not a claimed feeling.

Structured elaboration

1. What to actually say in the moment: a specific, checkable statement of the failure and your role in it, said early rather than after explaining context. Use "I," not "we," when the decision was actually yours, and avoid over-broad self-criticism that isn't specific enough to be useful either.
2. What to learn: the difference between "I should validate more" and "I should have added a shadow-traffic comparison (running the new version in parallel on real traffic, without exposing users to its results, and comparing outputs before fully switching over) before rollout for anything touching this codepath" is the difference an interviewer is listening for. A generic lesson signals you haven't actually diagnosed the failure.
3. Effect on team trust: describe it through observable change, what the team did differently with you afterward, being brought into design review earlier, being asked to write the rollout plan for the next similar change, rather than asserting a feeling like "they trusted me more."

Worked example

A ranking model I owned regressed a key engagement metric after a rollout, and it took a stakeholder team flagging the drop before we caught it ourselves. In the review, I said directly: "I shipped this without a shadow-traffic comparison against the previous model because the offline evaluation looked strong, and that gap is what let this reach real users before we caught it." What I actually learned wasn't a general "test more," it was specific: the offline evaluation numbers on my team's data had a known skew toward one user segment, and I hadn't accounted for that skew before trusting the offline result as sufficient on its own. I proposed adding a mandatory shadow-traffic window before full rollout for anything touching this ranking path, and pushed it into our rollout checklist myself rather than waiting to be asked. The trust shift showed up concretely afterward: on the next major model change, my lead asked me to write the rollout and rollback plan for the team, rather than reviewing one I'd written alone after the fact, which is the opposite of what happens when trust erodes.

Trade-offs and pitfalls

A too-broad statement of fault, "I should have just been more careful," sounds humble but tells an interviewer nothing about your actual judgment; specificity is what separates a strong accountability answer from a generic one. Framing the fix purely as a personal habit change, with no system-level fix like a checklist item or a required review step, suggests the same failure could recur the moment you're not personally vigilant. And claiming the team trusted you more afterward as a stated feeling, rather than showing it through what changed in how you worked together, reads as unverifiable self-assessment rather than evidence.

Direct answer

The concrete fix is almost never "explain it more simply." It's restructuring what comes first: lead every update, meeting or written, with the business-relevant result or decision needed, and push the technical mechanism to the end or to a follow-up. I did that after being told a status update lost the room, and I checked it worked by watching stakeholder behavior change, not by grading my own delivery.

Structured elaboration

Receiving the feedback
The instinct to defend, "they should already understand this," is the trap. I asked for the specific moment attention dropped rather than accepting a general "too technical" label, which usually turns up something concrete: an acronym used without definition, or a slide that opened with implementation detail before the reader knew why it mattered.

Concrete changes, and why they went beyond that one meeting
The fix generalized past the original meeting once I noticed the same pattern in written updates too. I restructured every stakeholder-facing communication, meetings, status docs, and dashboards, to open with a headline (the result, decision, or ask), keep jargon out of the first two sentences, and move architecture or implementation detail to an appendix or a separate technical follow-up for anyone who wants it. I also became more proactive rather than reactive, sending a short plain-language summary ahead of a decision point instead of waiting to be asked.

Measuring whether it improved
Since there's no honest single number for "clearer," I tracked behavioral signals instead: whether stakeholders started asking business questions ("what does this mean for the launch date") rather than clarification questions ("what's a materialized view"), and whether they began referencing my updates directly in their own decisions instead of routing everything through a translator. I also just asked directly in a 1:1 whether the update had been clear enough to act on.

The deeper payoff
The more durable outcome was trust, not just comprehension. Stakeholders started looping me into strategic conversations earlier instead of getting my work secondhand through someone else, which is the real signal that the communication gap had closed.

Worked example

In a quarterly review, I originally opened with "we migrated the pipeline to an incremental load pattern," which lost a product stakeholder immediately. The rework opened with "the report you use will now be a day fresher, here's what changed to make that possible," with the incremental-load detail moved to a single follow-up slide. Afterward, that same stakeholder started asking things like "when will the next report also update faster," a question about the outcome, not the mechanism, which was the signal the reframe had worked.

Trade-offs and pitfalls

Oversimplifying can backfire too: cutting every technical detail can make a decision look riskier than it is, or hide a real caveat a stakeholder needed to know. The fix isn't a uniform "less technical" style, it's ordering information by what the specific audience needs first, and being ready to go deeper when someone asks.

Direct answer

I'd name what reviewers actually said rather than a vague "docs were bad," describe the concrete rewrite I did in response, and point to a real change in outcomes for the people who depended on the material, whether that was an on-call engineer during an incident or a new hire ramping up on an internal library.

Structured elaboration

What reviewers said
The feedback showed up in two different contexts I've experienced: during an incident retrospective, where an on-call engineer said the runbook's steps were out of date and didn't match what the system actually did anymore; and separately, a new hire trying to use an internal library said the README had no working example, just a list of function signatures.

Concrete improvements made
For the runbook, I re-verified every step against the current system and rewrote it with explicit, tested commands, added the prerequisites someone would need before starting, and added a troubleshooting section for the failure modes that had actually happened, not hypothetical ones. For the library README, I added a minimal working example someone could copy and run immediately, not just an API reference. In both cases I tested the fix by having someone unfamiliar with the system follow it end to end before considering it done.

Outcome for the people who relied on them
After the runbook rewrite, on-call engineers were able to resolve that specific incident type themselves without escalating to me directly. After the README rewrite, a new hire was able to get the library working on their own instead of pinging me with the same setup question that had come up repeatedly before.

Worked example

The runbook originally said "restart the ingestion service if lag exceeds normal levels," which didn't say what command to run, what "normal" meant, or what to check first. The rewrite specified the exact check command, the specific threshold, the restart command with the correct flags, and a note on what to check if restarting didn't resolve it. The next time lag spiked, the on-call engineer on shift resolved it directly from the runbook without needing to reach me.

Trade-offs and pitfalls

Documentation rots if nobody owns keeping it current, so a one-time rewrite isn't enough without a habit of revisiting it, ideally triggered by the next incident or onboarding session that exposes a gap. The opposite failure is writing exhaustive documentation that covers every theoretical case but that nobody actually reads, instead of scoping it tightly to the failure modes and setup steps people actually hit.

Direct answer

I'd get the feedback down to something specific before scoping anything, since "diverges from user needs" could mean almost anything, then assess how much of the built feature can be salvaged versus needs real rework, and loop in the right people before committing to a timeline.

Structured elaboration

Clarifying the feedback
I'd ask the product manager for the specific gap: which user or use case isn't served, or which metric the feature was supposed to move that it isn't moving, rather than assuming I already know what they mean.

Assessing the scope of required changes
Once the gap is specific, I'd figure out whether the fix is a UI or copy-level tweak, or whether it touches the underlying data model or flow, since those have very different costs. I'd estimate a couple of candidate fixes rather than committing to the first idea.

Planning the next iteration
I'd propose a scoped fix for the next iteration rather than an open-ended redo of the whole feature, and if there are multiple gaps, sequence them by impact and cost instead of trying to fix everything at once.

Stakeholders to involve
Beyond the product manager who raised it, I'd loop in design if the change affects the user experience, QA for anything touching existing flows, and the original requester or user research if there's a way to validate the fix addresses the actual gap before building it.

Communicating timelines
I wouldn't commit to a date before the scope is clear. I'd give a range once I understood which kind of fix was needed, flag any dependency that could shift it, such as needing a design review, and follow up with a firmer estimate once that was resolved.

Worked example

Say the feedback is that the feature doesn't support a common use case for power users, who make up a small but important segment. Clarifying gets to a specific flow that's missing. The scope turns out to be a moderate one, adding a new path through existing components rather than a new data model, so I could commit to a timeline for the next sprint after a quick design check-in, and loop QA in early since it touches an existing flow other users rely on.

Trade-offs and pitfalls

Rebuilding the whole feature when a targeted fix would have addressed the actual gap wastes time and often re-introduces new problems. The opposite mistake, committing to a date in the room before scoping is done, tends to result in either a missed deadline or a rushed, incomplete fix.