Coachability, Feedback, and Humility Questions

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

Default to gathering input widely and quickly, but reserve final-call authority for decisions that are hard to reverse or that block the timeline if left open. Defer when feedback changes the outcome's actual correctness or safety; push forward despite dissent when the feedback reflects a difference in risk tolerance or preference you are accountable for owning, and say so out loud either way.

Structured elaboration

Set the decision rule before the pressure hits. Distinguish reversible, lower-stakes calls, where you default to consensus or whoever is closest to the work, from irreversible or high-stakes calls, where you own the final call once input has genuinely been sought.

Solicit dissent early, when it is cheap to incorporate, rather than only reacting to it once it shows up late in the timeline.

Defer when feedback surfaces new information: a bug, a missed edge case, a real risk that changes whether the plan is actually correct. That is not indecision, it is the input working as intended.

Push forward when feedback is a legitimate difference in judgment or risk tolerance, not new information, and time is genuinely short. Make the call, own it explicitly, and state the rationale out loud so dissenters know they were heard, not overridden silently.

Revisit both kinds of calls afterward. Did deferring slow things down more than it should have? Did pushing forward turn out to be right? Use that to calibrate the next high-stakes decision.

Worked example

As an Engineering Manager overseeing a fraud-detection model launch with a fixed compliance deadline, two days before launch an engineer flagged that the model's precision (of the cases the model flags, how many are actually correct) on a rare transaction type had not been validated and pushed to delay a week to test it properly. That was new information about correctness, so deferred: pulled in the extra validation, which surfaced a real gap that got fixed before shipping. Separately, a different stakeholder argued the launch should carry a much more conservative fallback threshold "just to be safe," even after seeing the validation results, out of general risk aversion rather than new evidence. Time was short, and the more conservative threshold would have meaningfully hurt the model's usefulness on legitimate transactions. Made the call to ship with the validated threshold, and explained the reasoning directly to the stakeholder, the data supported it and a documented fast-rollback plan covered the residual risk, rather than simply overruling them without comment.

Trade-offs and pitfalls

Treating every piece of dissent as "just risk aversion, not new information" is a convenient way to dismiss real concerns under deadline pressure; the discipline is genuinely checking which kind it is before deciding, not assuming. Deferring on everything to avoid conflict under a tight deadline can mean the launch never actually ships. And making the hard calls without ever explaining the rationale, even when the call itself was right, reads as unilateral and erodes the team's willingness to raise dissent next time.

Direct answer

Treat each feedback channel as answering a different question rather than assuming they all give you the same kind of input, actively pull input from each one at the point in the project where it's cheapest to act on, and when suggestions conflict, resolve them against the project's actual goal and current stage rather than by seniority or volume.

Structured elaboration

• Match the channel to the kind of feedback it's good for. Lab meetings are good for direction and framing ("is this even the right question, does this connect to related work I'm missing"). Code reviews are good for correctness and reproducibility of the specific implementation. Preprints (early, not-yet-formally-published drafts shared for comment) or informal reader comments are good for clarity and whether the argument lands with someone outside the immediate group. Pulling the right kind of feedback from the right channel avoids drowning in generic comments.
• Solicit proactively and early. Raise the framing question in lab meeting before running expensive experiments, not after. Ask for a code review on the core logic before building more features on top of it. Share an early draft or figure with someone outside the group before the direction is locked in. The earlier the feedback, the cheaper it is to act on.
• Prioritize competing suggestions with three questions. Does the suggestion touch the core claim of the project or a peripheral detail? How much would it cost in time to explore? Is this a matter of taste or style, where either choice is fine, or a substantive risk to the result being right? Prioritize suggestions that threaten the core claim and are cheap to check first, defer expensive-but-peripheral suggestions, and explicitly park stylistic disagreements rather than letting them stall the work.
• Communicate the resolution back. When a suggestion isn't acted on, say why, briefly, to the person who gave it, rather than silently dropping it. This keeps people willing to keep engaging even when their specific suggestion isn't taken.

Worked example

In one week, three pieces of feedback arrive at once: lab meeting flags that a related paper already tried a similar approach and got a null result; a code reviewer flags that a data-loading function silently drops malformed rows; and an outside reader of a preprint draft says the abstract oversells the contribution. The lab-meeting comment touches the core claim (is this worth pursuing at all) and is cheap to check, so it's handled first; it turns out the prior work used a different dataset, so the project continues but the framing is adjusted to explain the distinction. The silently-dropped-rows bug is a correctness issue that could invalidate results, so it's fixed immediately before any more experiments run. The abstract-oversells comment is real but doesn't affect the underlying work, so it's parked until the paper is being finalized.

Trade-offs and pitfalls

Treating every channel's input as equally weighted regardless of project stage either causes churn from late-arriving direction changes, or lets a serious correctness issue sit unfixed while chasing style feedback. Only surfacing work in the easiest channel (say, lab meeting) and skipping code review because it feels less urgent lets implementation bugs compound. Resolving conflicts by who's most senior rather than by what the suggestion actually threatens trains people to escalate rather than reason. And never communicating back why a suggestion wasn't taken quietly discourages people from giving input next time.

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

The clearest signal is whether the feedback points at something checkable: a specific claim about the work that I could verify or disprove with evidence, versus a comment that's really just describing the reviewer's own taste. A second signal, one I've learned to distrust on its own, is how much the comment stings; sharp or blunt delivery feels like a bigger deal than a mild-sounding one, but sting is about tone, not substance, and plenty of substantive critique is delivered gently. When it's substantive, I act on it directly; when it's preference, I still take it seriously as one input, but I don't treat it as a required change.

Structured elaboration

The core signals. Substantive feedback usually points at a consequence: this will break under a specific condition, this number doesn't match what we'd expect, this choice conflicts with a constraint we already agreed on. Preference feedback usually points at how something feels without a checkable claim attached: "I'd have done it differently," "this doesn't feel right to me," with nothing you could go verify. A useful test is to ask yourself: if I ran an experiment, checked a number, or asked a third person, could this comment turn out to be simply wrong? Substantive feedback can fail that test; pure preference generally can't, because there's no external fact being claimed.

Why the sting test is unreliable on its own. Feedback that lands hardest emotionally is not necessarily the most substantive; a harshly worded comment can be pure opinion, and a mildly worded one can be pointing at a genuine, checkable flaw. Using emotional intensity as your filter means you'll sometimes chase down a stylistic complaint because it stung, while quietly dismissing a calmly delivered but substantive concern.

What changes based on the distinction. For substantive feedback, I go verify the claim (rerun the analysis, check the edge case, re-read the constraint) and act on what I find, regardless of how it was delivered. For preference feedback, I still note it, since patterns across multiple people's preferences can eventually become a real signal, but I don't treat one person's taste as mandatory, and I'll say so directly rather than either silently complying or silently ignoring it.

Worked example

Three quick illustrations across different work: a colleague says a chart's y-axis should start at zero instead of the current range, because starting elsewhere exaggerates the visual difference. That's checkable: does the truncated axis actually misrepresent the size of the effect? If yes, it's substantive and worth fixing regardless of preference. Separately, on a business intelligence (BI) dashboard, a stakeholder says they'd prefer more chart types instead of mostly tables; there's no checkable claim there, it's a stated preference, worth noting but not obligatory unless it recurs across multiple stakeholders. On a proposed system architecture, a reviewer says a particular service boundary "feels wrong" with no further explanation; I'd treat that as underspecified rather than automatically substantive or automatically preference, and ask what specifically prompted the reaction, since it might be pointing at a real coupling problem they haven't fully articulated yet.

Trade-offs and pitfalls

Dismissing feedback as "just preference" is an easy way to avoid genuinely uncomfortable, valid criticism, so the test has to be applied honestly, not used as a shield. On the other side, treating every comment as substantive because you can't immediately disprove it leads to chasing every stylistic complaint as if it were a bug report, which is exhausting and doesn't actually improve the work. And an unexplained "feels wrong" comment shouldn't automatically be filed as preference just because it wasn't stated as a checkable claim; ask before you categorize it.