Coachability, Feedback, and Humility Questions

Direct answer

In the meeting, I treat the criticism as a request for evidence rather than an attack: I ask what specifically looks unrealistic, and I do not defend the number on the spot if I do not actually have the backing data in front of me. Afterward, I validate the estimate against real data or a small benchmark and come back with either an updated number or the original number plus evidence, so the final plan is grounded rather than just re-asserted by whoever argued more persuasively.

Structured elaboration

In the meeting. I avoid getting defensive or justifying the number purely from memory, and instead ask a clarifying question such as "which part looks off to you, the assumption or the math?" That often reveals whether the critic is questioning the methodology or simply has a different intuition. If I can answer with real backing on the spot, a benchmark I already ran, or a comparable service's numbers, I share it plainly. If I cannot, I say so honestly rather than defending a guess: "I don't have hard data for that specific path in front of me, let me validate and come back with real numbers instead of debating estimates." I also avoid letting the room settle the question by volume or seniority, proposing a concrete next step, a joint spike or a shared benchmark, rather than ending on an unresolved disagreement.

Afterward: validation steps. I run or find the actual data, a load test, a trace from a comparable existing path, or a small prototype, targeting specifically the assumption that was challenged rather than re-deriving the whole estimate from scratch.

Afterward: communication steps. I share the validation results with the engineer who raised the concern first, not the whole group, so they can sanity-check it before it goes back to the broader meeting; this also signals the concern was taken seriously rather than steamrolled. If the data confirms the original estimate, I share it with the group and explain the gap between intuition and measurement. If the data shows the critic was right, I update the estimate and say so directly, crediting the catch. Either way, I bring the reconciled number back to the group, in writing where possible, with the evidence attached, so the shared plan is anchored to something checkable rather than to whoever argued more persuasively in the room.

Worked example

In a design review I estimate a new endpoint's added latency (the delay between a request and its response) at 15ms. An engineer from the platform team says that is unrealistic given an extra network hop through their gateway, closer to 40-50ms in their experience. In the meeting: "That's useful, what similar endpoint are you basing that on? I based my estimate on compute cost alone and might be missing the gateway hop." They point to a comparable endpoint they own. Rather than argue the number further without data: "Let me pull real numbers from that comparable path and get back to you tomorrow instead of debating estimates here."

Afterward, I pull trace data from their comparable endpoint and instrument a quick prototype of the new endpoint's actual call path, including the gateway hop. The prototype's measured latency comes out to 38ms, close to their estimate and well above my original 15ms, because the extra hop genuinely had not been accounted for. I message the engineer directly first: "You were right, the gateway hop adds real latency, here's the prototype trace." Then I update the design document's latency estimate to 38ms with the trace attached, and note the change and reasoning in the next design review.

Trade-offs and pitfalls

Defending an unvalidated number in the room just because backing down publicly feels uncomfortable trades short-term face-saving for a plan built on a number nobody actually trusts. Validating only enough to confirm the original number, rather than genuinely testing the specific path the critic raised, defeats the point of validating at all. Running a real benchmark takes time the meeting does not have, which is exactly why "let me validate and come back" is usually the right call rather than resolving anything beyond a trivial estimate by argument in the room. Finally, reconciling privately with the critic but never bringing the updated number back to the full group leaves the shared plan the rest of the team is working from silently wrong.

Direct answer

When the defensive reaction starts (the urge to interrupt, the tight-chest feeling), the fix isn't suppressing it, it's slowing the sequence down: notice the reaction as information, listen to the whole point, ask a clarifying question before reacting, and only then decide whether to act on the feedback, adapt it, or push back. Most defensiveness happens because people skip straight from hearing to reacting.

Structured elaboration

Before (when you can see a critique coming): if you already suspect a decision will be challenged, read the full context once before responding to any of it, and mentally separate "the decision" from "me" ahead of time so the first hit doesn't land as personal.

In the moment, the checklist:

1. Notice the signal. The urge to explain or interrupt is information, not something to hide; consciously pause one beat before speaking.
2. Listen to the whole point, not just the first sentence. Defensiveness is often triggered by an assumption about where a critique is headed that turns out to be wrong once you hear the rest of it.
3. Ask a clarifying question before agreeing or disagreeing. "When you say the retry logic is fragile, do you mean it doesn't handle timeouts, or that it retries too aggressively?" This buys a beat, and it often reveals you agree with the real concern even if your first-pass reading of it was off.
4. Decide: act (the critique is right, change it), adapt (partly right, modify your approach), or push back (state your reasoning once, calmly, backed by evidence, and let it stand on its merits without repeating yourself).

After, a follow-up habit: close the loop later, especially if the feedback stung or landed in a moment where you couldn't process it fully. Circle back within a short window, a day or two, showing the change or the reasoning rather than letting the conversation end at the moment of discomfort. For example, a stakeholder says flatly in a meeting, "this dashboard isn't useful." In the moment, don't defend the build choices, ask one clarifying question: "useful for which decision specifically?" Within about 48 hours, come back with either a revised version addressing the actual gap or a short note showing you traced their specific decision need and adjusted for it.

Worked example

In a design review, a senior engineer said my proposed retry approach would make an outage worse, not better. My first internal reaction was to defend it, since I'd thought it through carefully. I paused, listened past the first sentence instead of responding to it immediately, and asked: "are you worried about retry storms (a spike where many failed requests all retry at once and overwhelm the recovering service) during a full dependency outage, or slow individual failures?" It turned out he meant retry storms specifically, a case I hadn't modeled. I adapted rather than scrapping the whole proposal or defending it unchanged: kept my approach for individual failures, and added backoff (waiting progressively longer between each retry instead of retrying immediately) plus a circuit breaker (a mechanism that stops sending requests to a dependency once it's clearly failing, so retries don't pile on and make an outage worse) for the storm case. I sent a short note after the meeting with the two-case breakdown, so the difference between where I'd agreed and where I'd refined was visible, not just spoken and forgotten.

Trade-offs and pitfalls

Treating "not defensive" as suppressing any visible reaction reads as hollow or checked-out rather than composed; the goal is to slow the sequence down, not perform calm. Skipping the clarifying question and jumping straight to "you're right" is reflexive capitulation, not genuine receptiveness, and it forfeits legitimate pushback when the critique really is off-base. A purely before-the-fact ritual with no in-the-moment mechanism doesn't help when feedback is genuinely unexpected, which is most of it, so the checklist has to work cold. And closing the loop too late, or not at all, erases the credit for having actually adapted, since nobody outside your own head saw the process.

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

Developmental feedback, whether it lands in a formal performance review, a string of recurring code-review comments, or a candid conversation with a cross-team peer, only becomes useful once it's turned into a concrete plan with real milestones, not just a private intention to "do better." Structuring that plan around short checkpoints (for example, roughly 30, 60, and 90 days out), pairing each one with a way to actually show progress, and checking back with whoever raised the feedback rather than assuming the plan alone closes the loop is what separates a real development plan from a good intention that fades.

Structured elaboration

Clarify the specific behavior behind the label. A word like "ownership," "testing," "communication," or "business impact" can mean many different things in practice. Ask for a concrete example of what prompted the feedback, since the plan needs to target the actual behavior, not the label attached to it.

Build a milestone plan with visible checkpoints. An early checkpoint (roughly the first month) is about smaller, low-stakes practice: trying the specific behavior somewhere the cost of a misstep is low, and, where useful, pulling in a resource deliberately, whether that's a course, a mentor, or pairing with a colleague who's strong in that exact area, rather than just resolving to try harder. A middle checkpoint (roughly two months in) is about applying it in a real, higher-stakes setting and actively gathering a read on whether it's landing. A later checkpoint (roughly three months in) is about showing the behavior consistently across contexts, not just with one team or one person who already knows to expect it, and bringing concrete evidence back to whoever gave the original feedback.

Use resources deliberately rather than relying on willpower. A mentor, a targeted course, or pairing with someone strong in the gap area is usually far more effective than simply trying harder at the old approach; naming the specific resource used is part of what makes the plan concrete rather than aspirational.

Create your own way to see progress along the way. Feedback that matters doesn't only arrive at the next formal review; it can also show up informally, in a comment from a colleague or a passing remark. Building in a lighter self-check, or asking a trusted colleague to flag it if the old pattern resurfaces, keeps the plan honest between the big checkpoints.

Worked example

A manager's review notes that communication with other teams needs work, and the specific example given is that cross-team updates tend to arrive late and are too dense to act on quickly. In the first month, the update format changes to lead with the ask and the deadline, and early drafts get a quick review from a mentor before sending, as a low-stakes way to practice the new habit. In the second month, that habit gets applied in a real, higher-visibility setting: proactively posting a mid-sprint update to a cross-team channel before anyone has to ask for one, and paying attention to whether people are actually finding it clearer. By the third month, after several cycles of this, the pattern shows up in the threads themselves: cross-team updates that used to draw a "can you clarify" reply on roughly half of them are drawing one on maybe one in ten, and a direct check-in with a cross-team peer confirms updates now feel timelier and clearer. Both the count and the peer's read get brought back to the manager at the next check-in as evidence the specific behavior has changed, not just a claim that it has.

Trade-offs and pitfalls

Writing a plan and not revisiting it until the next annual review lets the good intention quietly lapse with nobody the wiser. Choosing milestones that describe activities (attended a course, read a book) rather than evidence that the underlying behavior actually changed makes the plan easy to complete without the feedback ever really landing. The other common failure is treating a specific example as an attack to be argued away instead of the concrete anchor it actually is; escalating defensively over one instance of feedback wastes the opportunity the specific example was giving you to target the plan precisely.

Direct answer

I take the manager's underlying concern seriously, that outcomes need consequences and the process should not feel like nothing happens after a mistake, while defending the specific mechanism, no individual blame during the review, that makes blameless postmortems actually surface the truth. I adapt the process to add real accountability where it is legitimately missing, without reintroducing blame that would make people stop reporting honestly.

Structured elaboration

Reconcile the feedback. I find out what specifically reads as "too lenient" to the manager: is it that no one seems personally accountable, that repeat incidents are not being tracked, that the review does not feel consequential. This is usually not actually a request to punish someone, it is a request for visible accountability, which a blameless process can provide without individual blame.

Defend the blameless approach through its mechanism, not just its philosophy. A blameless postmortem, a factual, no-individual-blame review of what happened and why, exists because when people expect punishment for surfacing a mistake, they hide details, self-censor timelines, or avoid reporting near-misses at all, which makes the next outage more likely, not less. The goal is to fix the system that let a competent, well-intentioned person make the error, since blaming one individual usually does not prevent a different person from hitting the same gap later.

Distinguish blameless from consequence-free. Blamelessness applies to how the postmortem investigation itself is run, it does not mean there is never any individual accountability anywhere. A pattern of repeated negligence, ignoring a known process, or a genuine performance issue is a separate management conversation, handled outside the blameless postmortem, not folded into it.

Adapt the process to meet the management need. I add explicit tracking of remediation items with named owners and deadlines, so "nothing happens afterward" becomes visibly false, a recurring review of whether fixes actually landed, and a clear escalation path for the rare case that turns out to be about individual conduct rather than a systemic gap, routed to management directly rather than folded into the blameless review.

Worked example

After an outage, the postmortem concludes the cause was a manual deploy step that skipped a safety check, performed by an on-call engineer under time pressure. The senior manager says: "no one is being held accountable, that engineer just gets a pass."

Reconciling: I ask what accountability would look like to them specifically. They say they want confidence this will not happen again and some sense that skipping steps has consequences. Defending the mechanism: "if we punish the engineer here, the next person under similar pressure has an incentive to hide that they skipped the step rather than report it, which is worse for us. The system let a careful person make this mistake under pressure, that's the actual fix target." Adapting the process: I add a tracked remediation item, automating the safety check so it cannot be skipped manually, with a named owner and a two-week deadline, plus a follow-up review to confirm it shipped and actually blocks the bypass. I also clarify with the manager: if this had instead been a case of someone repeatedly and knowingly ignoring the process despite training, that is a distinct conversation for them to have directly with that person, separate from how the postmortem itself is run.

Trade-offs and pitfalls

Capitulating and quietly naming the individual at fault in the postmortem to placate the manager undermines the psychological safety, people staying willing to report mistakes honestly without fear of punishment, that the process depends on, and teaches the whole team to hide details next time. Refusing to adapt the process at all, and treating the manager's concern as illegitimate, leaves a real gap, visible accountability, unaddressed. Adding remediation tracking and follow-up review is more process overhead, worth it because it is what actually answers the "nothing happens" complaint without compromising the blameless mechanism. Conflating "no individual blame in the postmortem" with "no individual accountability ever" is the exact distinction most likely to get lost under pressure from someone senior.