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

When feedback lands that seems based on a misunderstanding, I resist the urge to immediately correct the other person and instead ask clarifying questions to find out exactly what they think happened. That usually surfaces the misunderstanding faster, and with less friction, than defending myself outright.

Structured elaboration

In the moment. I listen fully before responding, resist forming a rebuttal while the other person is still talking, and treat the feedback as their honest read of what they observed, even if I suspect it is based on incomplete information.

Clarifying questions. I ask specific, non-defensive questions aimed at understanding their view of the situation, not at proving them wrong, such as "can you walk me through what you saw that led you to that?" or "what would the right version have looked like to you?" These usually reveal exactly where the disconnect is without me having to assert anything yet.

Confirm before correcting. Once I think I see the misunderstanding, I check it gently rather than declaring it, since it is possible I am the one missing something, not them.

Afterward. I identify what made the misunderstanding possible in the first place, was the work not visible enough, was a decision undocumented, was there a communication gap, and fix that root cause, not just this one instance.

Worked example

Situation: a reviewer said my API design was inconsistent with the rest of the service and pushed back on it as sloppy.

Task: check whether their read was accurate before disagreeing further.

Action: instead of immediately explaining my reasoning, I asked what specifically looked inconsistent. They pointed to two endpoints using different pagination styles. I realized they were comparing my new endpoint to an older, deprecated pattern that had actually already been flagged for replacement, information they did not have. I confirmed it gently: "it sounds like you're comparing this to the older pagination style, that one's actually being phased out, my endpoint follows the new standard we agreed on last quarter, do you have the design doc from that?"

Result: once they saw the doc, they agreed the new endpoint was the consistent one; the actual inconsistency was in the old code, not mine. Afterward, I realized the new standard was not linked from the code or the pull request description, so a reviewer without recent context had no way to know. I added a link to the standard in the pull request template so future reviewers would not hit the same gap.

Trade-offs and pitfalls

Correcting the person immediately and confidently can come across as dismissive even when you turn out to be right, and can make them defensive in return. Capitulating to feedback that felt wrong just to avoid conflict, without ever finding out it was based on a misunderstanding, means a real fix, like linking the standard, never happens. Asking clarifying questions takes longer in the moment than just asserting the correct answer, but it is what actually surfaces whether you, not just them, are the one missing something.

Direct answer

I treat a piece of feedback as a diagnostic signal, a possible symptom of something bigger, rather than a standalone complaint, by asking whether it could plausibly recur under a different name from a different person. When it does, I trace it back to the actual process, data, or definitional root rather than resolving the surface instance and moving on.

Structured elaboration

Reframing. Before responding to any one piece of feedback, ask: if this is really about some deeper issue, would I expect to see it show up somewhere else too? That turns an isolated complaint into a hypothesis worth testing, not just a one-time fix to apply.

Investigating. When the hypothesis holds, trace the feedback back through the actual process or pipeline that produced the confusing artifact, not just the surface symptom the person happened to notice. A definitional mismatch, a process gap, or a data-quality issue usually sits one or two layers behind the visible complaint.

Fixing the root cause. The fix is structural, redefining a term consistently, closing a process gap, correcting a data source, rather than a one-off clarification that leaves the underlying inconsistency in place for the next person to trip over.

Worked example

Two different stakeholders, in unrelated conversations a few weeks apart, told me the "engagement" numbers I'd shared didn't match what they were seeing on a separate team's dashboard, and each initially framed it as if the other team's number must be wrong. Instead of reassuring each of them individually that my number was correct, I noticed the pattern, two independent people hitting the same mismatch, and traced it back rather than re-explaining my calculation each time.

It turned out the two teams' dashboards used genuinely different definitions of "engagement": one counted any session, the other required a specific action within the session, and neither dashboard stated its definition anywhere visible. Both numbers were internally correct and had simply drifted apart in meaning without anyone deciding that on purpose. The fix wasn't reassuring the next person who noticed the gap; it was getting the two teams to agree on one shared definition, documenting it visibly next to both metrics, and adding a note explaining the one case where the numbers would still legitimately diverge. After that, the recurring "your numbers don't match" comment stopped, because the actual definitional root cause was gone, not just explained away each time it surfaced.

Trade-offs and pitfalls

Treating every single complaint as evidence of a deep systemic issue is its own failure mode; most feedback really is about the one artifact in front of you, and chasing a root cause that isn't there wastes time and can read as evasive. The harder skill is telling the two apart, which mostly comes down to whether the same underlying confusion shows up independently more than once. And fixing the visible symptom, re-explaining the number, without tracing it back means the same confusion, and the same erosion of trust in the metric, keeps recurring under a slightly different complaint each time.

Direct answer

In the moment, I de-escalate with a short, calm acknowledgment rather than defending point by point in public, then move the substance to a private conversation quickly. I resolve it there before returning anything final to the public thread, and I preserve the relationship by treating the private follow-up as genuine curiosity about what they saw, not damage control.

Structured elaboration

In the moment. A short, non-defensive acknowledgment that doesn't concede a point you haven't verified. Don't litigate the technical substance in the public thread; a back-and-forth there tends to escalate, since both people end up performing for an audience instead of solving the actual problem. This can be as simple as one line said in the room, or one line posted back in the thread: "good flag, let me look into that and follow up."

Follow up privately, quickly. Same day if possible, to actually understand the concern in full, away from the public framing, which is often more compressed or more pointed than intended.

Resolve the substance there, then close the loop publicly. A short, factual update, what was found and what changed, so the thread doesn't stay hanging as an unresolved public criticism. In a pull-request context, that update is often best as a concrete follow-up comment on the same thread, showing the fix rather than re-litigating the tone.

Preserve the relationship. Treat the private conversation as genuine curiosity about what they saw, not a negotiation to get them to back down.

Worked example

A senior engineer left a pull-request comment, visible to the whole team, saying my approach "showed a lack of understanding of how the service handles concurrency" and suggesting my change would cause a race condition (two operations happening at the same time in a way that produces the wrong result depending on which one finishes first). In the thread, I replied briefly: "good flag, let me dig into the concurrency behavior and get back to you," rather than apologizing profusely or arguing my design was fine. I then messaged them directly and asked them to walk me through the specific race they were worried about.

They were right about a real edge case under high load, though the public phrasing read as a broader judgment about my competence than the actual, narrower issue. We worked through the fix together on a quick call. I then posted a follow-up comment on the same pull request: "Confirmed the race condition under concurrent writes, thanks for catching it. Fixed by adding the lock (a mechanism that only lets one operation touch the shared data at a time) around the update in commit X, added a test for the concurrent case." That comment did double duty: it closed the technical thread with a concrete fix and quietly reset the public record from "you don't understand this" to "a specific bug was found and fixed," without relitigating the original tone.

Trade-offs and pitfalls

Defending yourself point by point in the same public thread usually escalates rather than resolves, since both people end up performing for the audience instead of solving the problem. Going silent in public after being publicly challenged can read as agreement or avoidance, so a brief acknowledgment before moving it private still matters. And posting only a public fix without ever actually talking to the person leaves the relationship unrepaired even if the code got fixed.

Direct answer

Bring the gap or failure to your manager before they discover it independently, frame it factually rather than either minimizing it or over-apologizing, and pair the admission with a concrete plan you've already started thinking through, so the conversation is about moving forward, not just confessing.

Structured elaboration

• Framing the conversation. State the fact plainly and early, without burying it in caveats or waiting to be asked. Be specific about what happened or what the gap is, rather than vague ("things didn't go great"). Avoid both extremes: minimizing it in a way that undersells the manager's need to know, and being so self-critical that the conversation becomes about reassuring you rather than solving the problem.
• Proposing a development plan. Come with at least a first draft of a plan, even expecting the manager to adjust it, since arriving with only the problem puts the entire solution-finding burden on them. A good plan names a specific action, a way to check it's working, and a rough timeframe.
• The result. Describe honestly what actually happened afterward, including if the plan needed to be adjusted, since a story where everything worked perfectly on the first try can read as too tidy. Showing the plan was adapted when the first version wasn't quite right is itself evidence of the coachability the question is testing.

Worked example

Partway through a project, it becomes clear there isn't enough depth in a specific area, say a particular kind of performance analysis, that the project now needs, and it's starting to slow the team down. The proactive move is going to the manager directly: "I want to flag that my lack of experience with this kind of analysis is slowing this down. Here's what I'm planning to do about it: pair with a teammate who's strong in this area for the next two work sessions, and if I'm still stuck after that, I think we should bring someone else in for this specific piece." The manager agrees, adds one suggestion, a specific internal resource to read first, and two weeks later the candidate follows up with what actually happened: the pairing helped, but a third session was needed rather than two, which was proactively flagged rather than quietly pushing the deadline.

Trade-offs and pitfalls

Waiting until the manager notices the gap or failure independently reads as either avoidance or poor self-awareness. Bringing only the problem with no plan shifts all the work back onto the manager. Over-apologizing in a way that makes the manager spend the conversation managing your emotional state instead of solving the problem is also a risk. And describing a result that's suspiciously perfect is usually less credible than acknowledging the plan needed adjusting, which, done well, still demonstrates the coachability being tested.