Coachability, Feedback, and Humility Questions

Direct answer

I run every piece of feedback through three checks before deciding whether to incorporate it or push back: how specific and testable is the claim, how strong is the evidence behind it, and how expensive and reversible is being wrong either way. Strong, specific evidence on a cheap-to-reverse decision gets incorporated quickly; vague preference on an expensive, hard-to-reverse decision gets pushed back on, or at least held for more evidence.

Structured elaboration

Evaluation criteria I weigh:

• Specificity. Is the feedback concrete enough to act on ("this function has six responsibilities and caused two of the last three bugs in this module"), or is it a vague preference ("this feels overcomplicated")? Vague feedback is not automatically wrong, but it needs a clarifying question before it can be evaluated at all.
• Evidence type. I rank convincingness roughly as: direct measurement or a reproducible failure case, above documented precedent (this exact pattern has caused a problem before), above a well-reasoned but unverified opinion, above an unsubstantiated opinion stated with confidence.
• Source's proximity to the outcome. Someone who owns the downstream consequence, such as the person who gets paged when this breaks or the user who hits the bug, usually has stronger standing on that specific claim than someone commenting from a distance, even if the distant commenter is more senior in general.
• Consistency with other signals. Does this match what other independent reviewers or past incidents have already flagged, or is it a one-off?
• Cost of being wrong either way. If incorporating the change is cheap and reversible, I lean toward incorporating even on moderate evidence. If it is expensive or hard to reverse, I require stronger evidence before either agreeing or confidently pushing back.

Types of evidence I find convincing, most to least: reproducible data such as metrics, logs, or a benchmark; a concrete failure case that demonstrates the flaw directly; a documented precedent where this exact pattern caused a problem before; a second independent reviewer agreeing unprompted. Least convincing: a stylistic preference stated with confidence, an appeal to authority alone ("I've been doing this longer") with no mechanism attached, or feedback that cannot specify what a better version would actually look like.

How I communicate the rationale to stakeholders with differing priorities. I separate the decision from the person: I state which criteria I weighed and why they landed where they did, rather than just announcing a conclusion. I invite the stakeholder to challenge the weighting itself, not just restate their original conclusion, since disagreement is often really about which criterion should dominate. Where priorities genuinely differ, for example speed versus long-term maintainability, I say so explicitly rather than pretending it is a purely factual dispute, and I name who has the authority to make that trade-off call if we cannot agree.

Worked example

A reviewer comments, "this function is too complex, refactor it." First pass: specificity is low, "too complex" alone is not actionable, so I ask what specifically makes it hard to follow. Suppose they clarify with a concrete signal: the function has six distinct responsibilities and was the site of two of the last three bugs in this module, a documented precedent. Cost of being wrong: the refactor is contained to one file and easily reversible if it goes badly. Strong evidence plus low reversibility risk means: incorporate.

Contrast that with a different reviewer on the same file who says, "I would have named this function differently." Specificity is moderate, but the evidence is pure preference with no functional impact, and the cost of the current name is negligible either way. My response: apply it as a welcome but non-blocking suggestion rather than a required change, and say so directly rather than silently ignoring it.

Trade-offs and pitfalls

Turning this into a formal scorecard for every comment makes normal discussion feel like an audit; it works best as a mental checklist, not something I table explicitly except on genuinely contested calls. A senior reviewer's terse comment can look like weak evidence when it is really just brevity from someone who trusts me to fill in the specifics, so I ask before discounting rather than assuming vague means unfounded. The biggest risk is using "insufficient evidence" as a shield to dodge feedback I simply do not like; the rubric only holds up if I apply the same bar to feedback that confirms my instincts as to feedback that contradicts them.

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

In the moment, say plainly that you don't yet know, without guessing out loud to fill the silence, immediately pair that admission with a concrete next step so it doesn't sound like a dead end, and afterward protect trust by actually following through on that plan and closing the loop even if the answer takes longer than hoped.

Structured elaboration

• Handling the moment. Resist the pressure to speculate confidently just to have something to say; a wrong guess stated as fact is worse than an honest "I don't know yet," because it can send the stakeholder's own decisions in the wrong direction. Say it plainly: "I don't have a confident answer for why that happened yet."
• Proposing an investigation plan on the spot. Immediately follow the admission with a specific next step and, if possible, a rough timeframe: "I'm going to check X and Y first, and I'll have an update by [a specific time]," rather than an open-ended "I'll look into it." This converts "I don't know" from a dead end into a plan the stakeholder can trust is moving.
• Maintaining trust during follow-up. Actually deliver on the timeframe given, even if the update is "still investigating, here's what I've ruled out so far," rather than the final answer. A stakeholder tolerates not having the answer yet far better than they tolerate silence after being promised an update. If the investigation takes longer, or turns up something uncomfortable, including a mistake, say that plainly too rather than softening it.

Worked example

A stakeholder asks why a report's numbers jumped overnight, and there's no confirmed reason yet. Instead of guessing, "probably a data refresh issue," the response is: "I don't have a confirmed reason yet, I don't want to guess and send you down the wrong path. I'm going to check the two most likely sources, the upstream data feed and a recent code change, and I'll update you by end of day either way." The follow-up happens by end of day as promised, even though the investigation isn't finished: "I've ruled out the code change, still checking the data feed, will have a final answer by tomorrow morning." The next day brings confirmation that it was an upstream data quality issue, along with what's being done about it. Trust holds because every promise about timing was kept, including the intermediate ones.

Trade-offs and pitfalls

Guessing confidently to avoid looking uninformed risks being wrong, which costs more trust than the original "I don't know" would have. Saying "I don't know" with no plan attached reads as unhelpful rather than honest. Promising a timeframe and then going silent when it's not met damages trust more than the original uncertainty did. And over-apologizing or being defensive in the moment can make the stakeholder more anxious rather than reassured that it's being handled.

Direct answer

Build a habit of asking for feedback at natural checkpoints before work is finished, not after, and ask narrow, specific questions rather than "does this look okay," because a specific question gets a specific, useful answer instead of a polite pass.

Structured elaboration

• Pick the right moment. Ask when there's still time to change course, not after something is shipped or submitted, since feedback on a finished thing mostly produces regret rather than improvement.
• Pick the right person for the right kind of question. A peer close to the work, for detail-level correctness. A manager or more senior person, for whether you're solving the right problem at all. Someone outside the immediate team, when you want to know if the work is understandable to someone without full context.
• Ask specific, narrow questions instead of "does this look good." "Does the way I've broken this problem down make sense, or am I missing an approach?" "Is there a risk here I'm not seeing?" "If you were reviewing this from a user's or a reviewer's perspective, where would you push back?" A specific question also signals you actually want a real answer, not reassurance, which makes people more willing to give you the honest version.
• Adjust for remote or asynchronous settings. When you can't just walk over to someone's desk, specificity matters even more in writing, since a vague written ask like "thoughts?" is even easier to answer with a one-word non-answer than a vague spoken one. Write the specific question directly into the message or the document comment itself.
• Track and act on it. Keep a short, simple log, a note, a doc, even a comment thread, of what was said and what you changed, and revisit it before the next similar piece of work to check whether the same kind of note keeps coming up.

Worked example

Midway through building a new feature, instead of asking a teammate "can you review this," the ask is: "I'm not sure I've handled the case where the input is empty, could you specifically check that path?" The teammate finds that the empty-input case actually crashes a downstream function. That gets fixed before the change ships, logged as: "empty-input edge case missed, added a test for it." Two features later, the same kind of question turns up nothing new, which is itself useful signal that the specific gap has closed. In an asynchronous, remote setting, the same discipline applies to a design document review: instead of leaving a comment like "any thoughts?", the note reads, "does the fallback behavior in section two make sense if the primary service is down?", which gets a substantive reply instead of silence.

Trade-offs and pitfalls

Asking "does this look good" out of habit trains reviewers to give a quick approval rather than real scrutiny. Only asking after the work feels finished makes it psychologically harder to actually change course. Asking for feedback but never showing what you did with it teaches people their input doesn't matter. And in remote settings, mistaking silence for approval is a real risk, since silence may just mean the question wasn't specific enough to prompt a reply.

Direct answer

The clearest signal is whether the feedback points at something checkable: a specific claim about the work that I could verify or disprove with evidence, versus a comment that's really just describing the reviewer's own taste. A second signal, one I've learned to distrust on its own, is how much the comment stings; sharp or blunt delivery feels like a bigger deal than a mild-sounding one, but sting is about tone, not substance, and plenty of substantive critique is delivered gently. When it's substantive, I act on it directly; when it's preference, I still take it seriously as one input, but I don't treat it as a required change.

Structured elaboration

The core signals. Substantive feedback usually points at a consequence: this will break under a specific condition, this number doesn't match what we'd expect, this choice conflicts with a constraint we already agreed on. Preference feedback usually points at how something feels without a checkable claim attached: "I'd have done it differently," "this doesn't feel right to me," with nothing you could go verify. A useful test is to ask yourself: if I ran an experiment, checked a number, or asked a third person, could this comment turn out to be simply wrong? Substantive feedback can fail that test; pure preference generally can't, because there's no external fact being claimed.

Why the sting test is unreliable on its own. Feedback that lands hardest emotionally is not necessarily the most substantive; a harshly worded comment can be pure opinion, and a mildly worded one can be pointing at a genuine, checkable flaw. Using emotional intensity as your filter means you'll sometimes chase down a stylistic complaint because it stung, while quietly dismissing a calmly delivered but substantive concern.

What changes based on the distinction. For substantive feedback, I go verify the claim (rerun the analysis, check the edge case, re-read the constraint) and act on what I find, regardless of how it was delivered. For preference feedback, I still note it, since patterns across multiple people's preferences can eventually become a real signal, but I don't treat one person's taste as mandatory, and I'll say so directly rather than either silently complying or silently ignoring it.

Worked example

Three quick illustrations across different work: a colleague says a chart's y-axis should start at zero instead of the current range, because starting elsewhere exaggerates the visual difference. That's checkable: does the truncated axis actually misrepresent the size of the effect? If yes, it's substantive and worth fixing regardless of preference. Separately, on a business intelligence (BI) dashboard, a stakeholder says they'd prefer more chart types instead of mostly tables; there's no checkable claim there, it's a stated preference, worth noting but not obligatory unless it recurs across multiple stakeholders. On a proposed system architecture, a reviewer says a particular service boundary "feels wrong" with no further explanation; I'd treat that as underspecified rather than automatically substantive or automatically preference, and ask what specifically prompted the reaction, since it might be pointing at a real coupling problem they haven't fully articulated yet.

Trade-offs and pitfalls

Dismissing feedback as "just preference" is an easy way to avoid genuinely uncomfortable, valid criticism, so the test has to be applied honestly, not used as a shield. On the other side, treating every comment as substantive because you can't immediately disprove it leads to chasing every stylistic complaint as if it were a bug report, which is exhausting and doesn't actually improve the work. And an unexplained "feels wrong" comment shouldn't automatically be filed as preference just because it wasn't stated as a checkable claim; ask before you categorize it.