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

I do all three at once rather than treating them as sequential or in tension: I own the specific failure plainly and without hedging, I defend only the decisions the postmortem data actually supports, and I rebuild trust with concrete, verifiable change rather than promises of harder effort.

Structured elaboration

Distinguish what went wrong from what was a reasonable bet at the time. I run or reference a blameless postmortem, a factual, no-blame reconstruction of what happened and why, to separate genuine gaps (a missing alert, an untested failover path) from decisions that were sound given the information available when they were made, such as an SLO (service-level objective) tier that was appropriate before a specific class of enterprise customer signed on.

Take responsibility. I name the specific failure without minimizing it, without over-broad self-criticism that erodes confidence further, and without singling out one engineer, since owning it at the team and leadership level protects psychological safety (people staying willing to surface problems without fear of punishment) while still being genuinely accountable.

Defend what holds up. I bring the data. If an alerting threshold was reasonable and the actual gap was one specific untested runbook step, I say so plainly. Executives conflating "the team was unprepared in general" with "one specific gap caused this" is a common and unfair generalization, and correcting it with evidence is accuracy, not deflection.

Rebuild trust. I propose specific, time-bound, verifiable remediation, not a vague commitment to do better, and set a follow-up checkpoint to report back on whether the fix actually held under a similar condition.

Worked example

A multi-hour outage stemmed from a database failover that took ninety minutes longer than expected because the automated failover script had an untested edge case around a specific replica-lag threshold. Executives ask why the SLOs didn't catch this. The root cause analysis shows the SLO target of 99.95% availability was reasonable and had held for fourteen months prior; the real gap was that the failover automation had never been tested against a replica-lag scenario above a certain threshold, because that scenario had not occurred in staging.

Response to executives: own it directly, "the failover automation had an untested edge case, and that's why recovery took as long as it did, we should have tested that scenario"; defend what held, "the SLO target itself was appropriate and had been meeting expectations for over a year, moving it would not have prevented this specific failure"; rebuild trust with a concrete plan, add the missed replica-lag scenario to the automated failure-injection test suite, and set a checkpoint in sixty days to report the test results back to this same group.

Trade-offs and pitfalls

Defending everything reflexively reads as excuse-making even where part of the defense is legitimate. Over-apologizing and agreeing the whole approach was wrong just to placate executives in the room throws away real institutional knowledge and can push the team into an unnecessarily conservative posture afterward. Being precise about the specific technical gap can feel exposing in the moment, but a vague response erodes trust faster than an owned, specific explanation does. Finally, promising remediation with no concrete verification step means the next outage of the same shape reads as the same broken promise repeating.

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

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

Being criticized by leadership for an under-forecast that led to a peak-traffic degradation is a direct hit on judgment, so the right response is to own the specific gap in the forecasting method rather than explain it away, and then rebuild both the forecasting approach and the safety margins around it so the same class of miss cannot recur unnoticed.

Structured elaboration

Diagnose why the forecast was wrong. Before changing anything, pin down the actual mechanism: was capacity sized to average traffic instead of peak, was a known demand driver (a launch, a marketing push, a seasonal pattern) missed entirely, or was there no safety margin at all above the point forecast. The fix has to match the actual mechanism, not a generic "add more buffer everywhere" reaction.

Improve the forecasting inputs. Move from a single point estimate to tracking the peak-to-average ratio over a rolling window, since average-based sizing is exactly what tends to break under bursty, real-world traffic. Explicitly incorporate known future demand drivers by coordinating with the teams that know about them (marketing campaigns, product launches, seasonal events) rather than relying only on historical trend extrapolation.

Define explicit safety margins as policy, not guesswork. Provision capacity to comfortably exceed the highest recent observed peak, with the specific margin size grounded in the variance actually observed in your traffic (how much peaks have varied period to period), not picked arbitrarily. Document the margin and its rationale so it's defensible and can be revisited, rather than being a personal habit that leaves with you.

Build in a review cadence. Compare the forecast against what actually happened after every period, and treat a miss (in either direction) as a signal to recalibrate the method, not just the number. This is what prevents the improved process from quietly drifting back to the same failure mode a year later.

Worked example

A post-incident review finds that capacity was provisioned to the trailing average traffic, with no formal buffer, and a product launch drove a spike well above that average, degrading the service. Leadership's criticism, that the forecasts weren't trustworthy, is fair. The rebuilt approach starts tracking weekly peak (not average) traffic over a rolling window, and adds a standing check-in with the marketing and product teams ahead of any planned launch so demand drivers are known in advance rather than discovered after the fact. A safety margin is defined explicitly above the highest recent observed peak, sized using how much peaks have varied recently: for example, if the trailing 4-week peak was 3,000 requests per second against a 1,900 requests-per-second average (about a 1.6x peak-to-average ratio), the margin is set at roughly 1.3x that peak, around 3,900 requests per second, and documented so it can be reviewed rather than adjusted on gut feel. Automated alerting is added to trigger scale-up well before traffic approaches that new safety threshold, turning the margin into an operational trigger instead of just a planning number.

Trade-offs and pitfalls

Overcorrecting into an excessively padded margin avoids the embarrassment of another miss but quietly hides cost inefficiency and can itself draw criticism later; the margin should be grounded in observed variance, not fear. Treating this one incident's specific cause (missed launch, average-based sizing) as the only capacity risk worth fixing can leave other gaps unaddressed. The most common failure after a genuine improvement is skipping the recurring review: without checking forecast against actual traffic every period, the same mistake resurfaces quietly once the memory of this incident fades.