Coachability, Feedback, and Humility Questions

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

A teammate told me directly that in technical discussions I tended to dive straight into jargon-heavy back-and-forth with one or two people who already had context, which left others, including people newer to the codebase, unable to follow or contribute. I took it seriously rather than defending my intent, changed specific habits in how I ran discussions, and pushed a couple of those habits into how the team runs meetings generally, not just my own behavior.

Structured elaboration

This kind of feedback has a particular trap: the instinct to explain intent, "I didn't mean to exclude anyone," instead of engaging with the impact the other person actually experienced regardless of intent. The better response is to ask for a specific instance if one wasn't given, confirm you understand what happened from their point of view, and commit to a concrete, observable change rather than a vague promise to be more mindful. Personal behavior changes worth naming: explicitly summarizing context before diving into a technical debate, so people without the same background can follow; directly inviting quieter people by name to weigh in rather than assuming silence means agreement; pausing fast, jargon-dense exchanges to check whether everyone is tracking. Process changes matter too, since a personal habit change alone does not fix a recurring team pattern: adding a brief written context section to design docs before a discussion so people can prepare regardless of how much hallway context they already have; rotating who facilitates technical discussions so the same one or two voices do not dominate by default; explicitly reserving time in a meeting for questions before moving to open debate.

Worked example

A newer teammate told me, after a design discussion, that they had wanted to raise a concern about an approach but could not find an opening because two of us were deep in a fast, jargon-heavy exchange about implementation trade-offs for the whole meeting. I asked them to walk me through specifically where they had wanted to speak up, which turned out to be right after we had glossed over an assumption about how an existing system behaved, something they actually had direct, relevant experience with. My immediate behavior change: in the next several discussions I explicitly paused after any fast technical exchange to ask "does anyone have context that changes this?" before moving on, and I made a point of summarizing the working assumption before diving into detail, not just for that teammate but as a general habit. Beyond my own behavior, I raised it with the team and we changed how we ran design discussions: a short written summary of the proposal and key assumptions gets shared at least a day before the meeting, and we started rotating who facilitates so the discussion does not default to whoever is fastest to jump in.

Trade-offs and pitfalls

Responding to this kind of feedback by immediately explaining your intent, even sincerely, can land as dismissing the impact the other person actually experienced, so asking first and defending later matters. A personal habit change that is not paired with any process change tends to regress once the original feedback fades from memory, especially under time pressure, when a team reverts to whichever pattern is fastest, so a durable process change is what makes the fix stick. There is also a real trade-off between structuring discussions enough that everyone can follow and slowing every conversation down so much that genuine urgency gets lost; the goal is specific checkpoints, a pre-read, a pause for questions, rather than making every discussion uniformly slower.

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.

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

Treat mentorship on a specific skill as a short deliberate-practice loop (short, focused practice cycles aimed at one specific named weakness, with fast feedback after each attempt) rather than an open-ended relationship: name the exact skill gap, ask narrow questions tied to real work rather than abstract ones, request feedback on a fixed, fairly tight cadence while actively building the skill, and show the mentor concrete evidence of change rather than just asserting improvement.

Structured elaboration

• Name the skill area precisely. "I want to get better at estimating the risk in a technical proposal before committing to it" is something a mentor can actually coach. "I want to get better at my job" is not.
• Example questions, tied to real work. "In this proposal, where did I underestimate the risk, and what would you have looked for that I didn't?" "Looking at how I handled this ambiguous requirement, what's the pattern in what I'm missing?" Questions that reference a specific artifact get much more useful answers than questions about the skill in the abstract.
• Cadence. Tighter at the start, roughly weekly or every other week, while the skill is actively being built and mistakes are still common, so feedback catches the pattern before it's repeated many times. Stretch it out as independence grows, since a mentor's time is finite and the marginal value of very frequent feedback drops once the basic pattern has been corrected.
• Demonstrating progress over several weeks. Bring the same kind of artifact back at each checkpoint so the comparison is apples to apples, the third proposal reviewed against the first, and be explicit about what changed: "last time you flagged that I didn't account for the dependency on the other team, this time I called it out explicitly." This turns the mentor's role from repeatedly finding the same issue into actually watching it disappear, which is also what makes a mentor willing to keep investing time.

Worked example

A mid-level engineer wants to get better at scoping technical risk in proposals. Week one: brings a real proposal, asks "where did I underestimate risk here, and what signal did you use that I missed?" The mentor points out the estimate didn't account for a dependency on a team with a different release cadence. Week three: brings the next real proposal, having deliberately looked for cross-team dependencies this time, and asks the same style of question; the mentor confirms that risk is now covered, but flags a new pattern, underestimating the effort of migrating existing data. Week six: a third proposal shows the pattern from both earlier checkpoints being caught independently, and the check-in question shifts from "what did I miss" to "does my reasoning for this risk assessment hold up," a harder, more senior question that reflects the earlier patterns being internalized.

Trade-offs and pitfalls

Asking for feedback so frequently that it outpaces having anything new to show wastes the mentor's time and makes progress hard to see. Asking generic questions about the skill instead of anchoring each ask to a specific piece of real work produces generic answers back. Never showing the mentor evidence that earlier feedback was applied leaves them repeating the same correction indefinitely. And picking a skill area too broad to make visible progress on in a few weeks makes the whole loop feel directionless.