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

I separate fixing the bug from evaluating the criticism, since the first is urgent and does not wait on the second. I investigate immediately to understand what actually broke, then look at what testing existed for that specific path before agreeing or disagreeing that rigor was the gap, and either way I put a concrete prevention measure in place afterward.

Structured elaboration

Immediate steps to investigate the bug. Reproduce the bug, identify the specific code path and condition that triggers it, check severity and blast radius, how many users or how much data is affected, and put a mitigation in place, a rollback, a feature flag off, a hotfix, before doing a full root cause analysis. Stopping the immediate damage comes before assigning cause.

Deciding whether to accept or push back on the testing-rigor criticism. I check what tests actually existed for the affected path. If nothing covered this exact scenario, and it is a scenario that reasonably should have been covered, a common input or a known edge case, the criticism is fair, and I say so directly. If the bug comes from a genuinely unexpected combination of conditions that would not reasonably be anticipated, or from something outside test scope entirely, a third-party API change, an infrastructure issue, a data pattern that did not exist when the feature shipped, I push back with the specific evidence rather than accepting blame that is not accurate. I try to distinguish "insufficient coverage" from "a bug slipped through despite reasonable coverage," since perfect coverage is not realistic and conflating the two teaches the wrong lesson.

Preventing similar issues in the future. I add the specific missing test case, then look one level broader: is this an isolated gap, or a whole category of scenario, for example all boundary conditions on this type of input, that is systematically under-tested. If it is a category, I prioritize closing the category, not just this one instance.

Worked example

A stakeholder reports users are seeing incorrect account balances after a batch update job runs. Immediate steps: reproduce against a copy of the affected data, find the trigger, a rounding error that only appears when a user has more than a specific number of transactions in a single batch cycle, confirm blast radius (roughly 2% of accounts cross that threshold), and ship a hotfix correcting the rounding while a full root-cause review continues.

Testing-rigor question: checking the existing tests shows there was a unit test for the rounding logic, but it only used small transaction counts, well below the threshold that triggers the bug. The specific scenario genuinely was not covered, and reasonably should have been, since batch sizes above that threshold are not unusual. I accept the criticism: "you're right, our test suite didn't cover high-volume batches for this path, that's a real gap." Prevention: I add a test case at and above the threshold, then audit the other batch-processing paths in the same module for the same class of gap, untested behavior at high transaction counts, finding and fixing two more before they cause a separate incident.

Trade-offs and pitfalls

Investigating the criticism before fixing the bug delays mitigation while the production issue is still live. Accepting all blame reflexively, to appear accountable, even when the evidence shows the gap was not really about testing rigor, hides the actual root cause and can misdirect future prevention effort. Pushing back defensively without first checking the actual test coverage risks denying a real gap. Broadening the prevention fix to a whole category of untested scenarios costs more time than patching just the one case, worth it when the category, not just the instance, is genuinely under-tested.

Direct answer

Say the gap out loud early and plainly to the team, rather than quietly trying to fake competence, then take a few fast, targeted steps to get just enough working knowledge to be useful, not to become an expert, and before relying on that understanding for anything consequential, check it against someone who actually knows the area or against a small, low-stakes test.

Structured elaboration

• Acknowledging the gap. Say it directly and specifically, "I haven't worked with this before, give me a bit to get oriented," or "I don't know this tool, but here's my plan to get up to speed," rather than staying vague or implying more familiarity than you have. Framing it as a plan, not just an admission, keeps the team's confidence that the work will still get done.
• First concrete steps. Start narrow and targeted at what the current task actually needs, not a full deep dive: read the specific documentation or code relevant to the task, find the smallest reproducible example, and if possible find someone on the team who's used it before and ask a focused question rather than starting from zero alone.
• Validating understanding before moving forward. Don't trust the new understanding blindly; test it in a low-stakes way first, a small script, a scoped experiment, a quick review of the plan with someone experienced, before applying it to something that matters. If something is genuinely high-stakes, explicitly ask someone more experienced to sanity-check the plan before executing it, not just the result after.

Worked example

Assigned to add a feature that touches a message queue technology never used before, the first step is telling the team lead directly: "I haven't used this before, I'm going to spend the morning on the docs and a small test, then check in." Concrete steps: read the specific section of documentation relevant to the exact pattern needed, write a small standalone script that publishes and consumes a test message to confirm the basic mechanics work as expected, and ask a teammate who's used it before one specific question about a gotcha they might already know about, such as message ordering guarantees. Before building the actual feature on top of that understanding, the planned approach gets walked past that teammate in five minutes: "here's how I'm planning to use it, does this match how it's used elsewhere in the codebase?" Only after that quick validation does the real feature get built.

Trade-offs and pitfalls

Pretending familiarity to avoid looking behind usually surfaces later as a mistake that's more expensive to catch. Going too deep too early, reading an entire manual before writing anything, delays delivering when a narrower, task-focused ramp-up would have been enough. Never validating the new understanding against anyone else risks discovering a misunderstanding only once it's already built into something bigger. And over-communicating every small uncertainty in a way that makes the team lose confidence rather than build it is also a risk; the acknowledgment should come with a plan, not just an admission.

Direct answer

Make the ask specific and low-effort for the senior person to answer, bring a concrete artifact rather than asking for feedback in the abstract, and afterward close the loop by showing exactly what changed because of what they said.

Structured elaboration

• Phrasing the ask. Avoid "can you give me feedback on my work," which is vague and shifts the burden of finding something useful onto the senior person. Instead, name the artifact and the specific dimension: "I have a draft of the results section, could you spend fifteen minutes checking whether the claim in the second paragraph is actually supported by the data I'm showing?" A narrow, well-scoped ask gets a much higher response rate from busy senior people than an open-ended one.
• What to bring. Bring the artifact in a state where it's genuinely reviewable, not a rough sketch you expect them to fill in, plus your own best attempt at the parts you're unsure about, plus one or two specific questions you want answered. This shows you've already done the thinking and respects their time.
• Timing and venue. Ask before a decision is locked in (before submission, before an experiment is finalized), not after, and match the venue to the weight of the ask: a quick hallway question for a sanity check, a scheduled slot for something that needs real attention.
• Following up to show you acted on it. After incorporating (or deliberately not incorporating) the feedback, go back briefly: "I changed the analysis based on what you flagged, here's the updated version," or "I thought about your comment on X and decided to keep it as is because Y, does that reasoning hold up?" This second part matters even when you disagree: showing you engaged with the critique, rather than silently ignoring it or silently complying, is what makes a senior person willing to keep giving you real feedback instead of a polite pass next time.

Worked example

An early-career researcher has a draft methods section for a paper. Instead of emailing "let me know what you think," they write: "I'm not confident the baseline comparison in section three is fair, could you look at just that section for ten minutes and tell me if it holds up?" The senior reviewer replies with a specific concern about a confound (an unaccounted-for factor that could explain the result instead of the thing being tested). The researcher runs an additional control, updates the section, and sends a two-line follow-up: "Added the control you suggested, it changes the effect size but not the conclusion, here's the updated section." That follow-up is what turns a one-off favor into an ongoing relationship where the senior reviewer keeps engaging.

Trade-offs and pitfalls

Asking too broadly leaves the senior person unsure where to focus, so they give generic comments back. Never following up leaves them with no evidence their time mattered, and they deprioritize you next time. Treating every piece of feedback as something to implement verbatim, rather than engaging with the reasoning, is also a mistake: a senior person often respects a well-argued "I considered this and here's why I didn't change it" more than blind compliance. And only ever asking the most senior person available, instead of also asking someone one level up who remembers what it's like to be early-career, can mean missing more actionable feedback.

Direct answer

Subtle, informal feedback (a passing comment, not a formal review) is easy to discount precisely because of how casually it arrives, but the delivery method says nothing about whether the observation is correct. Evaluating it on its own merit, actually trialing the suggestion on real work rather than just nodding along, and keeping it as a lasting habit rather than a one-time try is what separates genuinely acting on informal feedback from politely ignoring it.

Structured elaboration

Don't discount feedback because it's informal. A hallway comment or an offhand "have you tried X" carries no less signal than a formal review comment just because it lacks a title or a scheduled meeting around it. Dismissing it because of how it arrived, rather than what it says, is the most common way genuinely useful suggestions get lost.

Evaluate it on merit. Ask whether the peer is naming a real, recognizable friction point, one you may have been tolerating without noticing how much time or annoyance it was actually costing. A quick internal check, does this ring true when I think about my last few days of work, is usually enough to tell a worthwhile suggestion from a stylistic preference that doesn't apply to your situation.

Trial it deliberately. Rather than nodding and forgetting, actually try the suggested tool or habit on a real task, not a toy example, since that's the only way to know if it actually removes the friction it claims to.

Make it stick. The real test of taking feedback seriously isn't the first use, it's whether the habit or tool is still part of the routine weeks later. If it lapsed, that's worth noticing and either reviving deliberately or acknowledging honestly that it didn't end up fitting.

Worked example

During an informal coffee chat, a peer mentions, almost as an aside, that manually re-running the same set of data-quality checks by hand before every pipeline deploy sounds like exactly what a small pre-deploy validation script is for. It doesn't land as a big deal in the moment, but reflecting on it afterward, it's a real recurring annoyance that had just become background noise. Taking it seriously means actually writing a small validation script rather than filing the idea away, and running it as a required step before every deploy from then on. Months later, it's still part of the routine, not something that was tried once and abandoned, which is the real signal that the informal suggestion was worth acting on.

Trade-offs and pitfalls

Dismissing a suggestion because it wasn't delivered with authority or formality risks losing genuinely useful ideas that colleagues are often too casual (or too polite) to insist on. Trying a suggestion once and quietly letting it lapse without noticing is functionally the same as never having taken the feedback, even if it felt like progress at the time. It's also worth not overcorrecting into adopting every casual suggestion uncritically; the evaluation step matters precisely so that trialing effort goes toward suggestions that actually address a real friction point.