Coachability, Feedback, and Humility Questions

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

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.

Direct answer

In the moment, I de-escalate with a short, calm acknowledgment rather than defending point by point in public, then move the substance to a private conversation quickly. I resolve it there before returning anything final to the public thread, and I preserve the relationship by treating the private follow-up as genuine curiosity about what they saw, not damage control.

Structured elaboration

In the moment. A short, non-defensive acknowledgment that doesn't concede a point you haven't verified. Don't litigate the technical substance in the public thread; a back-and-forth there tends to escalate, since both people end up performing for an audience instead of solving the actual problem. This can be as simple as one line said in the room, or one line posted back in the thread: "good flag, let me look into that and follow up."

Follow up privately, quickly. Same day if possible, to actually understand the concern in full, away from the public framing, which is often more compressed or more pointed than intended.

Resolve the substance there, then close the loop publicly. A short, factual update, what was found and what changed, so the thread doesn't stay hanging as an unresolved public criticism. In a pull-request context, that update is often best as a concrete follow-up comment on the same thread, showing the fix rather than re-litigating the tone.

Preserve the relationship. Treat the private conversation as genuine curiosity about what they saw, not a negotiation to get them to back down.

Worked example

A senior engineer left a pull-request comment, visible to the whole team, saying my approach "showed a lack of understanding of how the service handles concurrency" and suggesting my change would cause a race condition (two operations happening at the same time in a way that produces the wrong result depending on which one finishes first). In the thread, I replied briefly: "good flag, let me dig into the concurrency behavior and get back to you," rather than apologizing profusely or arguing my design was fine. I then messaged them directly and asked them to walk me through the specific race they were worried about.

They were right about a real edge case under high load, though the public phrasing read as a broader judgment about my competence than the actual, narrower issue. We worked through the fix together on a quick call. I then posted a follow-up comment on the same pull request: "Confirmed the race condition under concurrent writes, thanks for catching it. Fixed by adding the lock (a mechanism that only lets one operation touch the shared data at a time) around the update in commit X, added a test for the concurrent case." That comment did double duty: it closed the technical thread with a concrete fix and quietly reset the public record from "you don't understand this" to "a specific bug was found and fixed," without relitigating the original tone.

Trade-offs and pitfalls

Defending yourself point by point in the same public thread usually escalates rather than resolves, since both people end up performing for the audience instead of solving the problem. Going silent in public after being publicly challenged can read as agreement or avoidance, so a brief acknowledgment before moving it private still matters. And posting only a public fix without ever actually talking to the person leaves the relationship unrepaired even if the code got fixed.

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

I treat the criticism of a past decision as separate from the forward plan: I acknowledge honestly what I would do differently with today's information, then move the conversation to a remediation plan senior engineers can actually evaluate, a way of weighing it against feature work, and a rollout approach that protects reliability while the fix is underway.

Structured elaboration

Receiving the criticism. I acknowledge what information was and was not available when the original decision was made. If it genuinely was the wrong call even given what was known then, I say that plainly rather than hiding behind hindsight; if it was reasonable then and only wrong in light of how the system grew afterward, I say that too, precisely.

Presenting a remediation plan. I name the failure mode precisely, its blast radius (how often it happens, which paths are affected, what the user impact is), the root architectural cause, and two or three remediation options with different risk, cost, and timeline profiles rather than one option to rubber-stamp. Senior engineers respond better to being given real choices than to being asked to approve a single foregone plan.

Prioritizing technical debt versus feature work. I weigh the debt against feature work using a shared, visible framework, roughly the expected cost of leaving it (how often it causes incidents, multiplied by customer impact, multiplied by the ongoing engineering cost of working around it) against the opportunity cost of delaying the feature. Where the architectural issue is actively growing in blast radius, or is now a blocker to shipping planned features safely, I make that visible in the same terms leadership already uses for feature prioritization, rather than treating it as a separate "engineering tax" conversation nobody outside the team sees.

Leading implementation while maintaining reliability. I phase the remediation, an incremental replacement of the old path piece by piece rather than a big-bang rewrite, and keep the old and new paths running in parallel behind a flag during the transition. I add monitoring specifically for the failure mode being fixed so any regression is caught immediately, and I communicate a visible timeline so stakeholders see real progress rather than a black box.

Worked example

An intermittent failure traces back to a connection pool shared across services, sized years ago for a much smaller traffic pattern, causing connection exhaustion under specific bursts. A senior engineer says the original shared-pool design should never have existed. Response: "given the traffic and team size when it was built, that was a reasonable call. It stopped being reasonable once three more services started sharing it, and I should have flagged that shift sooner."

Remediation plan presented with three options: a quick mitigation raising pool limits and adding backpressure, low cost, partial fix, ships within the week; a medium fix splitting the pool per service, moderate cost, addresses the root cause for the current architecture, three-to-four week rollout; a long-term fix moving to a managed connection proxy layer, higher cost, best long-term posture, a quarter-long project. Prioritization: the medium fix gets scheduled against feature work using incident data, this failure mode has already caused two customer-visible incidents this quarter (frequency), each incident meaningfully affecting the customers hitting the connection pool at that moment (customer impact), on top of roughly three engineer-days a month already spent on manual workarounds (ongoing engineering cost of working around it). Weighed against the roughly one sprint the medium fix itself would cost, that combination justifies displacing part of one feature-team sprint. Implementation: ship the quick mitigation immediately as a stopgap, then roll out the medium fix service by service behind a flag, with alerting on pool-exhaustion metrics added before the first service migrates so any regression is caught before it becomes a third incident.

Trade-offs and pitfalls

Presenting only one remediation option forces a binary approve-or-reject response and invites more pushback than presenting real choices does. Treating technical-debt prioritization as a purely engineering call, when it displaces committed feature work, denies stakeholders the visibility and buy-in that any other roadmap trade-off would get. A phased, flag-guarded rollout is slower than a single cutover, but it protects the exact property under scrutiny here, reliability, so the extra time is usually worth it. Finally, relitigating the original decision defensively instead of moving to the forward plan keeps the room stuck on blame rather than solutions.