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

A comment like "make this more robust" gives me no way to know whether I'm done, so I turn it into questions that produce a checkable answer: what specific failure or scenario prompted the comment, what would count as evidence the concern is addressed, and is there a concrete case I should test against. The goal is to leave that exchange with something I could hand to someone else and have them verify, not just a vaguer version of the same feeling.

Structured elaboration

I ask a small set of questions aimed at converting vague language into something testable:

What specifically prompted this? "Was there a particular input, load, or failure case you had in mind, or is this a general concern?" This alone often resolves most of the ambiguity, since "robust" against malformed input is a completely different fix than "robust" against high concurrency.

What would satisfied look like? "If I add handling for X, would that address it, or is there more you're thinking of?" This turns a feeling into a testable claim, and lets the reviewer confirm or expand on it before I go build the wrong thing.

Is there a concrete example? "Do you have a specific case, or one you've hit before, that I should make sure this handles?" A concrete example is worth more than several more rounds of clarifying questions, since it's directly checkable.

Worked example

A pull-request comment says only "this needs improvement" with no further detail. I'd reply: "Happy to improve it, can you point me at what specifically prompted that, whether it's the error handling, the structure, or something else? And is there a particular case I should make sure it handles?" If the answer comes back as "the retry logic doesn't handle a timeout," that's now a concrete, testable requirement I can actually implement and verify, instead of guessing at what "improvement" meant and possibly missing the actual concern entirely.

Trade-offs and pitfalls

Asking too many clarifying questions at once, rather than the smallest set needed to get moving, can read as pushing the thinking work back onto the reviewer instead of engaging with it yourself. Assuming you know what "robust" or "improvement" meant, and guessing rather than asking, risks spending real effort solving the wrong problem and having to redo it. And once you do get a concrete answer, treating it as the only thing that ever needed fixing (rather than one instance of a possibly broader pattern) can mean the same vague comment resurfaces on the next piece of work.

Direct answer

Use a rough time-box and a cost check, rather than comfort level, to decide when to stop trying alone: if a bounded amount of time has passed without real progress, or if the cost of staying stuck starts to outweigh the usually smaller than imagined cost of interrupting someone, ask, and be honest when the real reason for the hesitation was ego or not wanting to look inexperienced rather than a good reason.

Structured elaboration

• Recognizing the hesitation for what it is. Name honestly what's actually driving the delay: is it genuinely productive persistence (still learning something by continuing to try), or something less useful, not wanting to look like you don't know something, or an assumption that a colleague is too busy that was never actually checked.
• Setting a decision rule instead of relying on feel in the moment. A rough time-box (if there's no meaningful progress after a set amount of effort, that's a signal) combined with a cost check: what does it cost the team if you stay stuck longer, versus what does it cost to interrupt someone for a few minutes. Most of the time the second cost is much smaller than it feels like while you're the one hesitating.
• Escalating well when the time comes. Come with what's already been tried, not just the problem, so the person being asked isn't starting from zero and can see the easy steps weren't skipped. This also makes it easier on the ego, since it demonstrates effort, not just an admission of being stuck.
• The result to describe. Name what actually happened once the ask was made, and if it turned out to be a smaller ask than it had been built up to be, say that honestly, since that's often the real lesson of these stories.

Worked example

Stuck on a configuration issue that's blocking progress, the hesitation to ask comes from not wanting to bother a senior engineer over something that might be "obvious." After roughly forty-five minutes of trying reasonable things with no real progress, and noticing the deadline is close enough that staying stuck another hour has real cost to the team, the message goes out: "I've tried X, Y, and Z, still stuck on this specific error, do you have five minutes?" The senior engineer recognizes the issue in under two minutes, a known gotcha they'd have mentioned earlier if asked. The result: the actual interruption cost almost nothing, far less than the imagined cost that had kept things stuck for forty-five minutes, and afterward there's more willingness to ask earlier next time rather than assuming it's a bother.

Trade-offs and pitfalls

Waiting so long that the eventual ask comes at the worst possible time, right before a deadline, turns a small interruption into a real emergency for the person being asked. Asking too quickly with no attempt of your own wastes the answer-giver's time on something findable alone, and doesn't build your own skill. Assuming a colleague is too busy without actually checking is often a story told to yourself rather than something they've said. And framing the ask apologetically or with excessive self-criticism makes the interaction more uncomfortable for both people than it needs to be.

Direct answer

Two separate moves here, and they matter in this order. In the moment at standup: acknowledge the specific gap directly, without leading with why it happened, and commit to a concrete, checkable next step. In the next status update: lead with the completed unblock, not with another apology, so the update itself is evidence you moved.

Structured elaboration

In the moment (standup):

1. Acknowledge without minimizing: name the actual gap ("you're right, I've been slow answering those review comments") instead of a vague "sorry about that."
2. Don't lead with the excuse: even a true reason (other priorities, a buried notification) reads as deflection if it comes before the acknowledgment. If context is worth sharing, offer it briefly after owning the gap, not instead of owning it.
3. Commit to something specific and time-bound: a vague "I'll get to it" doesn't reset confidence the way "I'll respond to every open comment today and have the PR back up by tomorrow morning" does.
4. Keep it short and take detail offline: standup is a status forum, not the place to work through what actually happened; if there's a real blocker behind the delay, say you'll bring it to the lead right after standup rather than unpacking it live.

In the next status update:

1. Lead with the resolution, not the apology: what's now unblocked or changed.
2. Show evidence, not just a claim: link the closed comments, the updated pull request, the new estimate.
3. Give a realistic forward date, not an optimistic one meant to smooth things over; a second missed date does more damage than the original delay.

Worked example

Standup: "You're right, three of Priya's review comments have been sitting since Tuesday, that's on me. I'll clear all of them today and have the PR back up for re-review by tomorrow morning." If the lead asks why, a brief, honest answer works: "they got buried under the migration ticket, I should have flagged that instead of letting it sit."

Next day's status update: "Addressed all six open review comments on PR #482, including the retry-logic change Priya flagged, and requested re-review. Revised ETA: merged by Thursday." That's specific and shows a completed action, not just an intention.

Trade-offs and pitfalls

Over-apologizing reads as spending more effort managing the lead's perception than doing the actual work; keep the acknowledgment short and let the action carry the weight. Pure silent compliance is also a trap: if you genuinely didn't realize the comments were time-sensitive, it's fair to ask, briefly and without defensiveness, so the same gap doesn't repeat. And a status update that's all forward-looking plan with no evidence of something already done still reads as "still catching up," not "caught up."

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.