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

Right after a high-severity incident, I treat the criticism or blame as data to sort through later, not something to argue with in the moment: I focus on physically and mentally coming down from the adrenaline first, then reflect once I'm actually calm enough to separate fair critique from people just venting stress, and only then do I re-engage with normal work. Trying to defend myself or process the emotional hit while still inside the incident's aftermath tends to make both the recovery and the reflection worse.

Structured elaboration

Recover. In the first hour or so after a severe incident, the priority is coming down, not making decisions. That means deliberately stepping away from the keyboard for a few minutes, doing something physical (walk, water, food), and consciously delaying anything that requires social or emotional bandwidth: replying to a pointed message, apologizing, or explaining yourself. Responses made while still running on adrenaline tend to be either over-defensive or over-apologetic, and neither ages well.

Reflect. Once the immediate heat has passed, usually later that day or the next, I separate genuine critique (a specific, checkable claim about what went wrong) from blame-venting (frustration expressed at a person rather than a cause). A useful test: does the comment point at something checkable in the timeline, or is it just an expression of how bad the incident felt? I also deliberately look at contributing factors beyond my own action, since single-cause blame is rarely the full picture in a real incident, without using that as an excuse to dismiss the parts that were genuinely on me.

Return. Getting back to productive work means rebuilding trust visibly rather than just feeling ready internally: following through on whatever concrete fix or process change came out of the reflection, and not swinging into either checked-out avoidance or overcorrected hypervigilance (double- and triple-checking everything out of fear, which slows you down without actually reducing risk).

Worked example

After a severity-1 outage where a config change I pushed contributed to a multi-hour outage, a stakeholder said in the incident channel that I should have caught it before it shipped. In the moment, I didn't respond beyond confirming the immediate mitigation status, then stepped away for twenty minutes once the incident was declared resolved. The next morning, reviewing the timeline calmly, I separated what was actually mine (I skipped the staging rollout step under time pressure) from what wasn't (the alerting for that specific failure mode was genuinely too slow, which wasn't something I controlled). I acknowledged the first part directly with the stakeholder and proposed making the staging step non-skippable in the deploy tool, which became the actual process change, rather than just promising to "be more careful."

Trade-offs and pitfalls

Recovering too slowly (going dark for days) reads as avoidance and can damage trust just as much as reacting too fast and defensively. Reflecting without separating fair critique from stress-venting either makes you absorb blame that wasn't really yours, which erodes confidence for no reason, or dismiss valid critique as "people were just upset," which prevents the real fix. And overcorrecting on return, becoming so cautious that you slow the whole team down, often gets mistaken for diligence when it's actually still unprocessed anxiety from the incident.

Direct answer

In the moment, say plainly that you don't yet know, without guessing out loud to fill the silence, immediately pair that admission with a concrete next step so it doesn't sound like a dead end, and afterward protect trust by actually following through on that plan and closing the loop even if the answer takes longer than hoped.

Structured elaboration

• Handling the moment. Resist the pressure to speculate confidently just to have something to say; a wrong guess stated as fact is worse than an honest "I don't know yet," because it can send the stakeholder's own decisions in the wrong direction. Say it plainly: "I don't have a confident answer for why that happened yet."
• Proposing an investigation plan on the spot. Immediately follow the admission with a specific next step and, if possible, a rough timeframe: "I'm going to check X and Y first, and I'll have an update by [a specific time]," rather than an open-ended "I'll look into it." This converts "I don't know" from a dead end into a plan the stakeholder can trust is moving.
• Maintaining trust during follow-up. Actually deliver on the timeframe given, even if the update is "still investigating, here's what I've ruled out so far," rather than the final answer. A stakeholder tolerates not having the answer yet far better than they tolerate silence after being promised an update. If the investigation takes longer, or turns up something uncomfortable, including a mistake, say that plainly too rather than softening it.

Worked example

A stakeholder asks why a report's numbers jumped overnight, and there's no confirmed reason yet. Instead of guessing, "probably a data refresh issue," the response is: "I don't have a confirmed reason yet, I don't want to guess and send you down the wrong path. I'm going to check the two most likely sources, the upstream data feed and a recent code change, and I'll update you by end of day either way." The follow-up happens by end of day as promised, even though the investigation isn't finished: "I've ruled out the code change, still checking the data feed, will have a final answer by tomorrow morning." The next day brings confirmation that it was an upstream data quality issue, along with what's being done about it. Trust holds because every promise about timing was kept, including the intermediate ones.

Trade-offs and pitfalls

Guessing confidently to avoid looking uninformed risks being wrong, which costs more trust than the original "I don't know" would have. Saying "I don't know" with no plan attached reads as unhelpful rather than honest. Promising a timeframe and then going silent when it's not met damages trust more than the original uncertainty did. And over-apologizing or being defensive in the moment can make the stakeholder more anxious rather than reassured that it's being handled.

Direct answer

Coachability shows up as a small set of repeatable, visible habits, not a personality trait: you ask for input before it's forced on you, you respond to feedback with a specific change someone else can point to, and you close the loop by showing the result. That's what makes it observable to a manager or teammate rather than just something you claim about yourself.

Structured elaboration

A useful way to see the habit as one loop with five steps: solicit, receive, interpret, act, close the loop.

1. Solicit. Proactively ask for review or a candid read rather than waiting for it to be imposed: requesting a code or design review before it's strictly required, asking "what would you push back on here?" in a one-on-one.
2. Receive. Listen fully, without visibly bristling or immediately explaining. A teammate can literally see this in your body language and response pattern in a meeting.
3. Interpret. Ask a clarifying question when a note is ambiguous rather than guessing at it or ignoring it.
4. Act. Make a specific, attributable change, something a teammate could point to and say "that's different because of what I said."
5. Close the loop. Tell the person, or show them, once the change lands. This is the step most people skip, and it's the one that makes the whole cycle visible rather than invisible.

This loop looks slightly different when work is asynchronous or remote rather than in person. Soliciting means leaving an explicit open question in a design doc or pull request description rather than reading a room. Receiving means not letting a written comment sit unacknowledged for days, even a short "got it, will address by Thursday" signals you saw it. Closing the loop means replying in the same thread rather than letting a change land with no comment at all.

Worked example

On a design doc for a service migration, I left an explicit note asking reviewers to poke holes in my rollback plan (the plan for undoing the migration if something goes wrong) specifically, rather than waiting for someone to volunteer concerns (soliciting). When a reviewer flagged that my rollback didn't account for in-flight writes (write operations already underway when a rollback starts, which could be lost or applied twice), I replied within the day acknowledging it visibly in writing (receiving), and asked one clarifying question about which write path (which part of the system was actually doing the writing) they meant (interpreting). I updated the doc with a specific new section handling in-flight writes (acting), and replied directly in the comment thread linking to the update once it was in (closing the loop). A teammate reading that thread later, with no other context, could see the whole cycle just from the comment history.

Trade-offs and pitfalls

Claiming to be coachable with no visible artifact behind it, a comment thread, a before-and-after, a teammate's account, is exactly the gap this question is testing for; "I'm very open to feedback" with no example is a weak answer. Soliciting feedback constantly on trivial decisions can read as seeking reassurance rather than genuine review; the habit should target real decision points, not every small choice. And skipping the close-the-loop step is the most common gap: the change happens, but nobody who gave the original note ever finds out, so from their side, the coachability looked invisible even though it happened.

Direct answer

I would not argue with the criticism in the moment, because the underlying point is usually fair even if the delivery stings: the issue was known and it should have been fixed sooner. I would acknowledge that directly, then immediately pivot from "why didn't I" to "here is the fix and here is the timeline," because dwelling on the criticism doesn't reduce risk but a concrete plan does. From there, prioritization comes from estimating blast radius (how much breaks) times frequency (how often it recurs), and escalation prevention comes from putting a temporary safety net in place while the real fix is built.

Structured elaboration

Responding to the criticism. Own the part that's true without over-apologizing or getting defensive about workload or competing priorities: "you're right, this has been flagged before and I should have prioritized it, let me fix that now" lands better than either silence or a list of excuses. Excuses read as minimizing; silence reads as not caring. A short acknowledgment plus an immediate pivot to action is the fastest way back to a productive conversation.

Prioritizing the fix. A recurring reliability issue almost never gets fixed by pure willpower after being told off; it needs to actually move up the queue. I would size it by two factors: blast radius (a fancier way of asking "how much of the system or how many users does this affect when it happens") and frequency (how often it's actually triggering). A low-blast-radius issue that fires constantly, and a rare issue with a large blast radius, both deserve real priority even though they look different on paper; a rare, low-impact issue can reasonably stay lower on the list even after criticism, as long as I say that out loud rather than silently deprioritizing it again.

Preventing escalation into a bigger outage. While the permanent fix is in progress, put a mitigation in place immediately: an alert with a tighter threshold, a manual runbook step, or a temporary workaround that reduces the chance of the known issue compounding into something worse. The goal is to convert "recurring nuisance that could become an outage" into "known, bounded, and actively monitored" within the same day, not to wait for the full fix before doing anything.

Worked example

Say the recurring issue is an intermittent connection-pool exhaustion warning that has shown up in logs roughly four times over the past three weeks (frequency) without causing a full outage yet, each time affecting the shared pool used by around 15% of requests (moderate blast radius), which together is why it ranked above the cosmetic bugs on the queue but below an already-flagged payment-path issue. My manager flags it after a near-miss and says it should have been handled already. I'd respond with: "you're right, I saw this before and treated it as noise instead of a pattern, I'm fixing it today." Same day, I add a tighter alert threshold and a documented manual restart step as a stopgap (mitigation), then start the real fix: raising the pool size and adding backpressure so requests queue instead of exhausting the pool (the permanent change, based on how often it was recurring versus how disruptive a full exhaustion event would be). I'd also tell my manager what I changed and why, so the loop closes visibly instead of just quietly getting fixed.

Trade-offs and pitfalls

Two failure modes are equally common: over-apologizing and spiraling into self-criticism, which stalls the actual fix and makes the person receiving the update trust you less, not more; and getting defensive about "I had other priorities," which is often true but reads as an excuse in the moment even when it's fair context to raise later, separately, about workload. Another pitfall is fixing the symptom (silencing the specific alert) instead of the underlying pattern, which technically resolves the immediate criticism but sets up the exact same conversation again next quarter.