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

I took the sales team's read of the room as real signal even though technical pitch effectiveness isn't usually their domain, since they're the ones watching prospects' faces in real time. I asked what specifically lost the audience, then reworked the pitch to lead with business outcomes instead of architecture, and judged the change by how prospects engaged afterward rather than a fabricated conversion number.

Structured elaboration

Receiving the feedback
It would have been easy to dismiss this as "sales doesn't understand the technical depth," but that misses the point: sales is the audience-reading function in that room, and if they say the technical narrative lost the prospect, that's data, not a technical critique to argue with. I asked for the specific moment attention dropped, a slide, a term, a point where the technical depth outpaced what the prospect needed to make a decision.

Iterating on the architecture narrative and materials
I restructured the pitch to open with the business problem and outcome the prospect cared about, moved the deep technical architecture to a later section or a separate technical-deep-dive follow-up meeting, and replaced dense jargon with a concrete analogy where possible. I also built a short executive summary to go alongside the technical deck so a non-technical stakeholder in the room had something to hold onto.

Measuring the change in outcomes
I didn't invent a precise conversion percentage, since the pitch wasn't the only thing changing deal to deal and a single clean number would have implied more confidence than the data actually supported. What I tracked was still a real comparison, not just a feeling: of the pitches using the restructured deck over the following quarter, most moved on to a next meeting, versus roughly half before the rework, and prospects started asking business-relevant questions instead of visibly disengaging.

Worked example

The original pitch opened with the proposed system's component diagram. The revised version opened with "here's what changes for your team's deployment speed, and why," with the same component diagram moved to a later slide for anyone who wanted the mechanism. In the next few pitches using that structure, prospects who used to go quiet after the first ten minutes started asking things like "how would this affect our current release cadence," a question about their outcome, not our architecture.

Trade-offs and pitfalls

Oversimplifying can backfire with a technically sophisticated buyer in the room who wants to see real depth to trust the architecture, so a single fixed deck for every audience isn't the answer. The better approach is tailoring how much technical depth leads versus follows based on who's actually in the room, and being ready to go deep when someone in the audience asks for it.

Direct answer

In the meeting, I treat the criticism as a request for evidence rather than an attack: I ask what specifically looks unrealistic, and I do not defend the number on the spot if I do not actually have the backing data in front of me. Afterward, I validate the estimate against real data or a small benchmark and come back with either an updated number or the original number plus evidence, so the final plan is grounded rather than just re-asserted by whoever argued more persuasively.

Structured elaboration

In the meeting. I avoid getting defensive or justifying the number purely from memory, and instead ask a clarifying question such as "which part looks off to you, the assumption or the math?" That often reveals whether the critic is questioning the methodology or simply has a different intuition. If I can answer with real backing on the spot, a benchmark I already ran, or a comparable service's numbers, I share it plainly. If I cannot, I say so honestly rather than defending a guess: "I don't have hard data for that specific path in front of me, let me validate and come back with real numbers instead of debating estimates." I also avoid letting the room settle the question by volume or seniority, proposing a concrete next step, a joint spike or a shared benchmark, rather than ending on an unresolved disagreement.

Afterward: validation steps. I run or find the actual data, a load test, a trace from a comparable existing path, or a small prototype, targeting specifically the assumption that was challenged rather than re-deriving the whole estimate from scratch.

Afterward: communication steps. I share the validation results with the engineer who raised the concern first, not the whole group, so they can sanity-check it before it goes back to the broader meeting; this also signals the concern was taken seriously rather than steamrolled. If the data confirms the original estimate, I share it with the group and explain the gap between intuition and measurement. If the data shows the critic was right, I update the estimate and say so directly, crediting the catch. Either way, I bring the reconciled number back to the group, in writing where possible, with the evidence attached, so the shared plan is anchored to something checkable rather than to whoever argued more persuasively in the room.

Worked example

In a design review I estimate a new endpoint's added latency (the delay between a request and its response) at 15ms. An engineer from the platform team says that is unrealistic given an extra network hop through their gateway, closer to 40-50ms in their experience. In the meeting: "That's useful, what similar endpoint are you basing that on? I based my estimate on compute cost alone and might be missing the gateway hop." They point to a comparable endpoint they own. Rather than argue the number further without data: "Let me pull real numbers from that comparable path and get back to you tomorrow instead of debating estimates here."

Afterward, I pull trace data from their comparable endpoint and instrument a quick prototype of the new endpoint's actual call path, including the gateway hop. The prototype's measured latency comes out to 38ms, close to their estimate and well above my original 15ms, because the extra hop genuinely had not been accounted for. I message the engineer directly first: "You were right, the gateway hop adds real latency, here's the prototype trace." Then I update the design document's latency estimate to 38ms with the trace attached, and note the change and reasoning in the next design review.

Trade-offs and pitfalls

Defending an unvalidated number in the room just because backing down publicly feels uncomfortable trades short-term face-saving for a plan built on a number nobody actually trusts. Validating only enough to confirm the original number, rather than genuinely testing the specific path the critic raised, defeats the point of validating at all. Running a real benchmark takes time the meeting does not have, which is exactly why "let me validate and come back" is usually the right call rather than resolving anything beyond a trivial estimate by argument in the room. Finally, reconciling privately with the critic but never bringing the updated number back to the full group leaves the shared plan the rest of the team is working from silently wrong.

Direct answer

I paraphrase the feedback back in my own words before doing anything else with it. Saying it back does two things at once: it proves to the other person I actually understood (rather than nodded along), and it often surfaces a mismatch between what they meant and what I heard before I've gone and acted on the wrong interpretation.

Structured elaboration

The technique itself is simple: after hearing a piece of feedback, restate the core of it in your own words, framed as a check rather than a repeat, and pause for confirmation before moving on. This is different from just repeating their words back verbatim, which can feel robotic and doesn't actually prove understanding; paraphrasing forces you to process the meaning, not just the sounds.

It matters most exactly when feedback is even slightly ambiguous, which is more often than it seems, because people frequently give feedback assuming shared context that isn't actually shared. A quick paraphrase costs seconds and prevents the much more expensive failure mode of confidently building the wrong fix.

Worked example

In a code review, a reviewer says: "this function is doing too much." I'd paraphrase: "so you're saying I should split the validation logic out from the actual processing, is that the split you had in mind, or something different?" That single sentence confirms my read of "doing too much" (which could have meant several different things: too many responsibilities, too long, poorly named) and gives them an easy chance to correct me before I go rewrite the function around the wrong interpretation.

Trade-offs and pitfalls

Paraphrasing everything, even feedback that was already completely unambiguous, slows the conversation down and can read as stalling rather than clarifying; it's most useful specifically when there's real room for multiple interpretations. Paraphrasing in a flat, mechanical way (repeating their exact words back) misses the point of the technique, since it doesn't actually demonstrate you processed the meaning. And treating a confirmed paraphrase as license to stop listening for anything further is its own trap; the technique confirms one point, it doesn't close the conversation.

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.