Coachability, Feedback, and Humility Questions

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.

Direct answer

I'd treat the public criticism as legitimate signal about business impact even if the underlying reliability decision was correct: acknowledge the impact first instead of defending the decision on principle, then re-examine the trade-off with real numbers. I'd look for a narrower design that protects reliability without simply overriding the business need, rather than treating it as a binary keep-or-remove choice.

Structured elaboration

Respond to the feedback. Leading with "the rate limit is necessary" dismisses their actual pain. Leading with acknowledging the customer-visible slowdown is real and worth solving buys the credibility to have the harder conversation next.

Manage the political fallout. Bring data, not defensiveness: quantify what the limit is protecting against and what it's currently costing in the feature's usability. Involve the affected teams in evaluating the trade-off rather than unilaterally deciding it was right.

Protect reliability without just blocking the business goal. Look for a fix narrower than "keep or remove the limit" entirely: scope it to the actual abusive traffic pattern rather than the whole feature, add a burst allowance for legitimate spikes, add caching or backpressure upstream (having the downstream system signal the upstream one to slow down instead of dropping requests) that reduces how often the limit is hit at all, or fast-track a capacity fix that makes the limit unnecessary at the current scale.

Worked example

I'd added a rate limit on an API endpoint after it caused a cascading outage during a traffic spike; the limit stopped the outage but also visibly slowed a client-facing dashboard feature during normal peak usage, and product and sales called it out publicly in a cross-team channel as making the product look broken to customers. I didn't open by explaining why the limit existed. I opened by saying the slowdown was real and asked for specific examples of where customers were hitting it, so I wasn't debugging a vague complaint.

Digging into the actual traffic, the limit was scoped too broadly: it applied uniformly to the endpoint instead of just the burst pattern that had caused the original outage. I re-scoped it to trigger only on the abnormal traffic shape, added a short burst allowance for normal peak load, and paired that with a caching layer upstream that cut baseline request volume enough that the endpoint was no longer close to the danger threshold under normal conditions. I reported back to the same channel with what changed and why, including the actual traffic numbers: at peak, only about 3% of requests were now hitting the limit, down from the 40%-plus spike that had caused the original outage, which mattered for not making it look like sales had simply won an argument.

Trade-offs and pitfalls

Capitulating and removing the limit to make the complaints stop re-opens the outage risk that motivated it in the first place. Digging in and defending the limit unchanged reads as prioritizing your own comfort over customer impact and burns trust with product and sales for the next disagreement. And treating this as purely a technical fix skips the part where you actually close the loop with the people who were publicly frustrated, so the reliability work stays invisible to them even after it's solved.

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

I treat accessibility requirements as a hard constraint rather than one more opinion to weigh against the stakeholder's, since they are often tied to legal obligation and to real users who cannot use the product otherwise. I still take the business concern seriously and look for a design that satisfies both, rather than either overriding the stakeholder outright or quietly dropping the requirement.

Structured elaboration

Handle the conversation. I start by understanding the actual concern behind the pushback, not just the literal request, "remove that alt text field, it clutters the interface" is often really about visual density, not opposition to accessibility itself. I explain briefly why the guideline exists in terms the stakeholder cares about: most accessibility requirements trace back to WCAG (Web Content Accessibility Guidelines, the standard most legal and organizational requirements are based on), and meeting them maps directly to real legal risk and to a meaningfully sized group of users, screen-reader users, low-vision users, people with motor impairments, not an abstract ideal.

Reconcile the business concern. I look for the actual constraint underneath the pushback: aesthetics, engineering time, a deadline, or a genuine belief the requirement does not apply here. Each needs a different response. If it is aesthetics, there is often a design solution that satisfies both. If it is time, I phase it, shipping the accessible version now and refining visual polish later, rather than the reverse. If it is a genuine scope question, whether the guideline even applies to this component, I verify against the actual standard rather than assuming either side is right by default.

Ensure the final design meets both. I treat this as a design problem to solve jointly, not a negotiation to win, bringing one or two concrete alternative designs that meet the accessibility bar while addressing the stated business concern, rather than presenting a binary choice between the guideline and the stakeholder's idea. Where a requirement is truly non-negotiable, a legal minimum such as a required color-contrast ratio, I say so plainly and hold the line, while still offering to solve the underlying business concern a different way.

Worked example

A stakeholder pushes back on visible focus indicators (the outline that appears around an interactive element when a user tabs to it with a keyboard) around buttons, calling them "cluttered" and asking for them to be removed for a cleaner look. Handling the conversation: "the focus indicator is required for anyone navigating by keyboard, including many users with motor impairments who cannot use a mouse, without it they cannot tell where they are on the page." Reconciling: the real concern turns out to be visual density in the default, mouse-hover state, not opposition to keyboard access itself. Solution: keep the default and mouse-hover states visually minimal as requested, but ensure the focus indicator still appears distinctly when the element receives keyboard focus, which modern CSS supports by showing the outline only for keyboard and assistive navigation rather than on every mouse click. This satisfies the visual goal for the common case and the accessibility requirement for keyboard users, and it is the concrete alternative brought back to the stakeholder instead of a flat refusal.

Trade-offs and pitfalls

Treating every accessibility pushback as either full capitulation or a flat refusal misses that a design solution often satisfies both sides. Assuming the stakeholder is acting in bad faith, rather than simply not knowing the guideline's rationale or scope, makes the conversation adversarial when it does not need to be. This joint-solution approach takes more design iteration than either overriding the stakeholder or just shipping what they asked for, worth it because an accessibility failure creates real legal and user-trust risk that a rushed compromise does not actually reduce. Finally, quietly deprioritizing the fix to "phase 2" with no concrete date is, in practice, often how it never ships at all.

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.