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

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

I treat the stakeholder's words as a symptom report, not a technical spec: I ask enough clarifying questions to understand the actual business impact behind the complaint, then translate that into a concrete engineering ask stated in terms of observable behavior and business consequence, not in the stakeholder's original wording and not in engineering jargon either.

Structured elaboration

Non-technical stakeholders describe problems in terms of outcomes and frustration ("the system is too slow," "this integration keeps breaking deals"), not root causes, so the translation has two steps. First, extract the specific, concrete situation behind the general complaint: ask what exactly happened, when, how often, and what it cost them. Second, restate it for engineering as an observable behavior plus a business consequence, and leave the "why" and the technical fix for engineering to diagnose rather than guessing at a cause on the stakeholder's behalf. A good translation preserves urgency and business stakes (why this matters, and to whom) without inventing a technical root cause the stakeholder never actually reported.

Worked example

A sales representative told me "the demo environment keeps embarrassing us in front of prospects, it's unreliable." That is not actionable on its own. I asked clarifying questions: which step fails, how often, in front of how many prospects, and what the prospect specifically sees when it happens. It turned out the demo environment's nightly data reset job was intermittently leaving it in a half-reset state, so a noticeable fraction of demos showed duplicate or missing sample records mid-presentation. The translation I gave engineering was: "the demo environment's nightly data reset job fails silently on a recurring basis, leaving stale or duplicate records visible during live sales demos; we need the reset job to fail loudly, alerting someone, instead of silently, and ideally to be verified before the start of each business day." That statement names the specific symptom, its recurrence, its business consequence (a customer-facing demo looking broken in front of a prospect), and a concrete engineering ask, without asserting a root cause I had not verified, and without simply repeating the word "unreliable," which by itself gives engineering nothing to act on.

Trade-offs and pitfalls

Translating too far toward technical language risks putting words in the stakeholder's mouth, claiming a root cause they never actually observed, which can send engineering chasing the wrong problem. Translating too little, passing the stakeholder's exact phrasing straight to engineering, leaves the team to reverse-engineer the actual issue themselves and wastes the clarifying step you were there to provide. The discipline is to report the symptom precisely and the consequence clearly, and let engineering own the diagnosis. A related pitfall is smoothing over urgency in translation: calmer, technical-sounding framing can accidentally under-prioritize something that is actually costing the business real deals.

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

Safety for upward feedback comes from repeatedly demonstrating that it's welcomed and acted on, not from claiming an open door. I invite it with specific, low-stakes questions rather than a generic "any feedback?", and then, when it comes, I visibly act on it and say so, since that follow-through is what actually proves it was safe.

Structured elaboration

Invite it deliberately. Ask direct, specific questions ("what's one thing about how I ran that design review you'd change?") instead of an open-ended invitation that leaves a junior report guessing whether it's really welcome. Start low-stakes, in a 1:1 or async, rather than in a group where they're more exposed. Model it by sharing your own mistakes first, so correcting you doesn't feel like the first crack in the ice.

Make it safe in the moment it arrives. Thank them for the specific point rather than a generic "noted." Don't argue defensively even if you disagree in the moment; you can acknowledge the input without committing to act on it instantly if you genuinely need to think it over.

Act on it visibly, and close the loop. Tell them, or the wider team, what changed as a direct result. Safety is proven by follow-through, not promised by policy; a single private thank-you is far less powerful than a visible, attributed change.

Worked example

As an engineering manager, I asked a newer engineer on my team, a few months in, a specific question in a 1:1: "what's one thing about how I run architecture reviews you'd change?" She told me I tended to cut people off mid-explanation when I thought I already saw where they were going, and that it made people rush their points instead of thinking out loud. I thanked her specifically for naming something concrete instead of a vague compliment, asked one clarifying question, and didn't explain why I do it.

I changed the actual behavior: in the next few reviews, I deliberately let people finish a full thought before responding, even when I was confident I already knew where it was going. Two reviews later, in the team retro, I named the change out loud and credited her by name for the observation. That public attribution mattered more for safety than the private thank-you had: the rest of the team saw that raising something about how I ran meetings had a visible, positive consequence rather than disappearing into a private conversation that no one else ever heard about.

Trade-offs and pitfalls

A generic "my door is always open" without a specific ask rarely produces real upward feedback, since the junior person still has to guess whether it's genuinely welcome and absorb all the risk of being wrong about that. Reacting defensively even once, even quietly, can undo months of safety-building, since junior reports are watching for exactly that signal. Crediting someone publicly without checking first can backfire if they didn't want the attention. And treating the first piece of upward feedback as proof the culture is fixed is premature; it usually takes repeated, visible follow-through before people trust it wasn't a one-time fluke.