Coachability, Feedback, and Humility Questions

Direct answer

I react by checking the substance of what a more junior colleague said, not their tenure: pause, verify the claim on its merits, and if it holds up, say so plainly and update the work. I make a point of crediting them specifically when explaining the change to others, and I follow through with something concrete afterward so the next correction is easier for them to raise than this one was.

Structured elaboration

React in the moment without letting seniority filter the input. The instinct to weigh a correction by who said it, rather than what they said, is exactly backwards for this scenario: a specific, checkable claim deserves the same "let me verify" response whether it comes from the most senior person in the room or the newest hire. Reflexively explaining why it's probably fine is a defensive reflex worth noticing and resisting.

Incorporate the input for real, not just acknowledge it. Verify the claim independently rather than taking it on faith either way, then actually change the artifact, not just the conversation. When explaining the change to anyone else, name where it came from; quietly absorbing a junior colleague's catch without attribution both undersells them and removes the signal that raising things gets noticed.

Encourage it going forward. The single biggest lever is visible follow-through: thank them for the specific substance, not the general gesture, and let other people see that the correction changed something real. Over time that's what tells a junior colleague, and everyone watching, that flagging something up the seniority ladder is worth the risk, rather than a nice idea that goes nowhere.

Worked example

A data scientist a few weeks into the team reviewed a pull request where I'd added a churn-prediction feature, and pointed out that one of my features was computed using a column that got its final value after the prediction label's time window, meaning the feature was leaking information from the future. My first reaction was to actually check, since it was a specific, testable claim, not a matter of opinion. I said "good catch, let me verify" rather than explaining why it should be fine, and traced the pipeline. It was a real leak.

I fixed the feature so it only used data available strictly before the label window, then re-ran the model without the leaked feature: AUC (a single score from 0.5, no better than random guessing, to 1.0, a perfect ranking, summarizing how well the model ranks a true churner above a non-churner) dropped from 0.91 to 0.84, a lower but real performance number instead of the inflated one. I posted in the team channel crediting them by name for catching a leakage bug that would otherwise have shipped an inflated benchmark to stakeholders. That visible follow-through mattered: the next sprint, a different engineer on the team, having seen that post, flagged a similar issue to me directly, and I thanked them the same specific way rather than treating it as a one-time exception.

Trade-offs and pitfalls

The most common failure is a polite "thanks for the input" that changes nothing, which teaches a junior colleague that raising something is safe but pointless. A subtler version is over-praising to the point that it reads as performative rather than substantive, especially if it isn't followed by an actual change. On the other side, treating the correction with more skepticism than you would from a peer, quietly re-checking it "just to be sure" in a way you wouldn't for someone senior, sends the same discouraging signal even if you never say it out loud.

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

Agreeing with feedback in the moment produces no evidence of anything; I only trust that I have actually incorporated feedback when I can point to a specific behavior change that shows up again later, checked against a written record rather than my memory of having nodded along.

Structured elaboration

The core problem with relying on memory is that people, myself included, systematically overestimate how much they have changed based on a single instance of trying. A concrete system fixes that:

• Keep a running feedback log. Every time I get substantive feedback, I write it down close to when it happens: the date, who gave it, what was said, and the specific change I am committing to. This is the same kind of artifact some people call a growth plan or retrospective notes; the exact format matters less than that it exists and gets updated in the moment, not reconstructed from memory weeks later.
• Tie each entry to something observable, not a vague intention. "Write tests before merging" is checkable later; "be more careful" is not. If feedback arrives too vague to turn into a checkable behavior, I ask a clarifying question before logging it, rather than logging something I cannot later verify.
• Revisit the log on a fixed cadence, not only when reminded. I check it weekly while it is short, and specifically before one-on-ones (1:1s, regular individual meetings with a manager) and ahead of performance conversations, where I use the log as raw evidence rather than trying to reconstruct the last few months from memory.
• Treat recurrence as the sharpest signal. If the same feedback shows up a second time, that is stronger evidence that the change did not actually stick than any amount of me believing it did; a recurrence gets escalated into a more concrete, checkable commitment rather than a repeated promise to try harder.

Worked example

A manager once told me my pull request descriptions explained what changed but never why, which made review slower for everyone. I logged it that day with the specific commitment: every PR description states the reason for the change, not just its contents. Two weeks later, reviewing the log before a 1:1, I checked my last several PRs against that commitment and found the "why" was present in most, but had slipped on one that was written under time pressure. That single recurrence told me the habit had not fully stuck yet, so instead of just recommitting verbally, I added a "why" field to the team's PR template, which turned the commitment into something the process enforced rather than something I had to remember unaided. I brought that log entry, including the slip and the fix, into my next 1:1 and later cited it in a self-review as concrete evidence of acting on feedback rather than just agreeing with it.

Trade-offs and pitfalls

It is possible to over-engineer the tracking itself into busywork, logging feedback in exhaustive detail without ever actually reviewing the log, which defeats the point. Conflating "I remember agreeing with it" with "I changed" is the exact failure mode this whole system exists to catch, so skipping the periodic review and trusting memory instead quietly reintroduces the problem. Tracking only critical feedback and never noting what is already working can also mislead, since it produces a lopsided, overly self-critical picture rather than an accurate one. Finally, a log that only gets opened right before a performance review, instead of on a regular cadence, provides much weaker evidence, since by then it is too late to correct course on anything that slipped months earlier.

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 phrases I try to avoid all do the same thing: they shift energy toward defending myself instead of understanding the critique. Things like "well, actually..." or "yeah, but..." or "that's not really my fault" all signal I'm arguing, even if that's not the intent. Instead I reach for language that keeps me listening: acknowledging what landed, and asking a specific question about the part I don't yet understand.

Structured elaboration

Phrases and reactions to avoid. "Well, actually..." (frames the other person as wrong before you've fully engaged with what they said). "Yeah, but..." (technically agrees while immediately undercutting it). "I already thought of that" or "I know" (implies the feedback was unnecessary, even when it wasn't wrong). "That's not really my fault, because..." (redirects to blame before addressing the substance). Silence with a flat expression is its own version of this: it reads as shutting down rather than processing, even if that's not what's happening internally.

What to say instead. "That's fair, let me look into it" acknowledges the point without conceding every detail you haven't verified yet. "Can you say more about which part specifically?" turns a vague or stinging comment into something actionable, and buys a genuine second to think. "I hadn't considered that, give me a moment" is an honest, non-defensive way to signal you're processing rather than ignoring. If you do disagree after actually understanding the point, "I see it differently, here's why, but tell me if I'm missing something" keeps the door open rather than shutting the conversation down.

Worked example

A reviewer says my API design "doesn't handle the failure case well." The instinctive response is "well, actually, I did handle it, just not for that specific scenario," which sounds like disagreement even if it's technically accurate, because it leads with correction. A better response: "can you say more about which failure case you mean?" That question does real work: it might reveal a case I genuinely missed, or a case I did handle but explained poorly, and either way I now know exactly what to address instead of guessing.

Trade-offs and pitfalls

Swapping in softer language without actually changing the underlying reaction is a common trap: saying "that's fair" while internally still building a rebuttal is not real progress, and it usually leaks through in tone anyway. Also, "can you say more" used as a delay tactic every single time, rather than when genuinely needed, starts to read as evasive rather than curious. And going too far the other way, agreeing with everything to avoid seeming defensive, is its own problem: it stops you from ever raising a genuine disagreement when one is actually warranted.