Coachability, Feedback, and Humility Questions

Direct answer

I'd take the feedback at face value first, this alert set was creating alert fatigue, the point where so many alerts fire that people start tuning them all out, including the real ones, then triage every alert against whether it's actually actionable, and only then tune or remove the ones that weren't earning their page.

Structured elaboration

The feedback itself
A reviewer told me during an on-call retrospective that a specific set of alerts was firing too often to take seriously, and that people had started acknowledging and ignoring them rather than investigating.

Evaluating which to keep or tune
For each alert, I asked three questions: is there an actual runbook step to take when it fires, does it correspond to real user or system impact rather than a noisy proxy metric, and how often does it fire relative to how often it represents a genuine incident. Alerts that failed all three were candidates for removal or downgrading; alerts tied to real impact but firing too eagerly were candidates for tuning rather than removal.

Specific changes made
I raised the threshold on a few metrics that were flapping, rapidly crossing back and forth over a threshold, around a noisy baseline, added a required duration so the condition has to hold for a few minutes rather than spike once, to reduce false positives from transient blips, removed one alert that was a near-duplicate of another already covering the same failure, and moved a couple of lower-urgency ones from paging to a non-paging notification channel instead of removing them outright.

Worked example

One alert paged whenever CPU usage crossed a fixed threshold for even a single sample, which fired constantly during normal traffic spikes with no actual user impact. I changed it to require the threshold to be sustained for several minutes and paired it with a latency-based alert that reflects what users actually experience, since sustained CPU pressure that doesn't affect latency usually isn't worth waking someone up for.

Trade-offs and pitfalls

Over-tuning is a real risk. Loosening thresholds too aggressively can silence a genuine early warning along with the noise. The safer fix is usually to make an alert more specific, tying it to a condition that actually correlates with impact, rather than simply making it fire less often.

Direct answer

I would not argue with the criticism in the moment, because the underlying point is usually fair even if the delivery stings: the issue was known and it should have been fixed sooner. I would acknowledge that directly, then immediately pivot from "why didn't I" to "here is the fix and here is the timeline," because dwelling on the criticism doesn't reduce risk but a concrete plan does. From there, prioritization comes from estimating blast radius (how much breaks) times frequency (how often it recurs), and escalation prevention comes from putting a temporary safety net in place while the real fix is built.

Structured elaboration

Responding to the criticism. Own the part that's true without over-apologizing or getting defensive about workload or competing priorities: "you're right, this has been flagged before and I should have prioritized it, let me fix that now" lands better than either silence or a list of excuses. Excuses read as minimizing; silence reads as not caring. A short acknowledgment plus an immediate pivot to action is the fastest way back to a productive conversation.

Prioritizing the fix. A recurring reliability issue almost never gets fixed by pure willpower after being told off; it needs to actually move up the queue. I would size it by two factors: blast radius (a fancier way of asking "how much of the system or how many users does this affect when it happens") and frequency (how often it's actually triggering). A low-blast-radius issue that fires constantly, and a rare issue with a large blast radius, both deserve real priority even though they look different on paper; a rare, low-impact issue can reasonably stay lower on the list even after criticism, as long as I say that out loud rather than silently deprioritizing it again.

Preventing escalation into a bigger outage. While the permanent fix is in progress, put a mitigation in place immediately: an alert with a tighter threshold, a manual runbook step, or a temporary workaround that reduces the chance of the known issue compounding into something worse. The goal is to convert "recurring nuisance that could become an outage" into "known, bounded, and actively monitored" within the same day, not to wait for the full fix before doing anything.

Worked example

Say the recurring issue is an intermittent connection-pool exhaustion warning that has shown up in logs roughly four times over the past three weeks (frequency) without causing a full outage yet, each time affecting the shared pool used by around 15% of requests (moderate blast radius), which together is why it ranked above the cosmetic bugs on the queue but below an already-flagged payment-path issue. My manager flags it after a near-miss and says it should have been handled already. I'd respond with: "you're right, I saw this before and treated it as noise instead of a pattern, I'm fixing it today." Same day, I add a tighter alert threshold and a documented manual restart step as a stopgap (mitigation), then start the real fix: raising the pool size and adding backpressure so requests queue instead of exhausting the pool (the permanent change, based on how often it was recurring versus how disruptive a full exhaustion event would be). I'd also tell my manager what I changed and why, so the loop closes visibly instead of just quietly getting fixed.

Trade-offs and pitfalls

Two failure modes are equally common: over-apologizing and spiraling into self-criticism, which stalls the actual fix and makes the person receiving the update trust you less, not more; and getting defensive about "I had other priorities," which is often true but reads as an excuse in the moment even when it's fair context to raise later, separately, about workload. Another pitfall is fixing the symptom (silencing the specific alert) instead of the underlying pattern, which technically resolves the immediate criticism but sets up the exact same conversation again next quarter.

Direct answer

Accept the customer's frustration as valid and specific to what happened, rather than offering a generic "sorry for the inconvenience." Write the message to be concrete about what broke and what's changing, not just contrite, and treat the apology as the start of a follow-through commitment you actually track, not the end of the conversation.

Structured elaboration

1. Accepting feedback. A customer's anger after an outage is proportional to the impact on them, not to how hard the incident was to fix. Resist the urge to explain the technical difficulty of the incident before acknowledging the impact; leading with the technical story reads as minimizing.
2. Crafting the message. State plainly what happened, what it affected, and what's changing. Avoid vague reassurance language, "we take reliability seriously," with nothing concrete behind it, and avoid over-promising a guarantee you can't actually back, "this will never happen again."
3. Follow-through. Commit to specific, checkable remediation items with real owners and timelines, and treat the long-term reliability improvement as a real deliverable, not just message content. Customers, and your own team, will notice if the same class of incident recurs.

Worked example

After an outage that took our API down during a partner's peak traffic window, I wrote the public incident note myself, a written explanation of what happened and what's changing, shared with affected customers. I didn't lead with root-cause detail; I led with impact: what broke, and what it meant for their traffic during that window. Then I named the concrete fix: the failure was a single point of failure in a region-failover path that hadn't actually been tested under real load, and we were adding automated failover testing to the release pipeline plus a second, verified failover region for that path. I committed to a follow-up update once the failover testing was live, with an actual date rather than an open-ended promise. When that date came, I sent the follow-up unprompted, which is what turned the apology from words into something the partner could verify.

Trade-offs and pitfalls

Leading a customer apology with technical justification, even accurate technical justification, before acknowledging impact reads as defending the outage rather than owning it. Promising a reliability outcome you can't actually guarantee, "this exact failure will never recur," sets up the next incident to look like a broken promise rather than a normal part of operating complex systems. And an apology with no dated, checkable follow-through is just words; customers, and interviewers, are listening for whether the follow-up actually happened, not just whether the apology was well-worded.

Direct answer

Look for a case where a mentor didn't just critique the output of a workflow, but questioned the workflow itself, because that's the version of mentorship feedback that actually changes how you operate rather than just what you ship once. The strongest answer walks through the original approach, the specific feedback, the redesign, how you checked it actually helped rather than assuming it did, and how you got the people who depended on the old process on board with the change.

Structured elaboration

• Original approach. Describe concretely what the workflow was and why it existed in its current form, often because it grew organically, or was copied from somewhere else without being re-examined.
• The mentor's feedback. Name what the mentor actually said and, more importantly, why it landed, what assumption it challenged. The strongest version of this feedback usually isn't "this is slow," it's a reframe: "you're treating this manual step as necessary, but the reason it exists doesn't apply anymore," or "you're optimizing the wrong part of this process."
• The changes implemented. Be specific about what changed structurally: a manual step automated, a review gate moved earlier or removed, ownership of a handoff reassigned, a tool swapped. A vague "I streamlined the process" is weak; name the actual before and after.
• How you measured improvement. Pick something you can actually observe and describe it honestly, not a fabricated precision statistic. Structural counts (fewer manual steps, fewer handoffs, a recurring failure mode that stopped recurring) are credible and checkable; broad percentage claims without a real measurement behind them are not. Say plainly what you tracked and over what period, and be honest that some improvements are more "this stopped being a recurring problem" than a hard number.
• How you communicated the change to stakeholders. Name who depended on the old process and needed to be brought along, what you told them and when, before the change, not after, if it affected their work, and how you handled any resistance to the change.

Worked example

A mentor reviewing a recurring release process notices the candidate manually verifies five checklist items before every deploy, and points out that three of those checks duplicate what an automated test already covers, while the other two exist because of an incident from years earlier that no longer applies to the current architecture. The original approach: five manual pre-deploy checks, taking real time and occasionally skipped under time pressure, which had itself caused a near-miss once. The feedback reframes the problem: the candidate had been treating the checklist's existence as evidence it was still necessary, rather than re-deriving why each item was there. The change: the three duplicated checks are removed since the automated test already covers them, one of the two remaining checks is automated into the deploy pipeline itself, and the last one, the only one that genuinely still requires human judgment, stays manual but is documented with why it exists, so a future person doesn't have to guess. To check it actually helped, the candidate tracks whether the near-miss failure mode that originally justified the checklist recurs over the following release cycles (zero near-misses across the next six release cycles, versus one in the six months before the change), and whether deploys that used to occasionally skip the manual step under time pressure now consistently complete the much shorter remaining checklist. To bring stakeholders along, the candidate walks the team through the reasoning in a short written proposal before changing anything, naming the incident history behind each check so nobody feels like safety is being cut for speed, and gets sign-off from whoever owns incident response before removing anything.

Trade-offs and pitfalls

Making the change and only afterward telling the people who depended on the old process reads as unilateral, even when the change is objectively good. Describing the improvement in vague terms, "it's much better now," instead of naming something concrete that was actually tracked, weakens the story. Over-crediting yourself and under-crediting the mentor's reframe misses the point of the question, which is showing you could actually hear and act on someone else's insight. And removing a safety-motivated step without checking whether the original reason for it still applies repeats, in the other direction, exactly the mistake the mentor's feedback was pointing at in the first place.

Direct answer

Treat the rejection itself as feedback worth investigating rather than a verdict to argue against: find out specifically what the team leads were protecting, usually coverage risk or a cost or headcount concern, rebuild the proposal around that real constraint, pilot a small and reversible version, and use the pilot's outcome to build consensus instead of re-arguing the original pitch.

Structured elaboration

Separate what was actually rejected. Ask directly whether it was the goal (reducing burnout on the on-call rotation, the schedule where engineers take turns being reachable to handle production issues outside business hours), the specific mechanism proposed, or the transition risk that the leads objected to. Re-pitching the identical plan louder only works if you already know it was the goal itself that was rejected, which is rarely the case.

Find the real constraint. Team leads who reject a burnout-reduction proposal are usually not rejecting the concern for burnout itself, they are protecting against a coverage gap they are accountable for, or a change to on-call headcount math that affects other commitments. Address that constraint directly rather than restating the original proposal with more urgency.

Shrink the ask to something reversible. Pilot the new rotation on one team, or for one rotation cycle, with an explicit rollback point, rather than asking for an organization-wide policy change up front. A pilot is easier to say yes to because a bad outcome is cheap to undo.

Bring data, not sentiment, to round two. Pull metrics that matter to the decision makers, such as after-hours page counts per person, paired with evidence the pilot did not create a coverage gap.

Iterate publicly. After the pilot, report the outcome back to the same leads who rejected the original proposal, whether it went well or not, and adjust again from there. Consensus here comes from a visible, low-risk feedback loop, not from a single persuasive meeting.

Worked example

Proposed collapsing two overlapping on-call shifts into one shorter, better-staffed shift to reduce the number of after-hours pages any single person handled. Team leads rejected it, worried it would leave a coverage gap during the highest-incident window. Went back and asked directly what evidence would change their mind; the answer was a real trial with a safety net, not a stronger argument. Proposed a one-rotation pilot on a single, lower-risk service, with a secondary on-call engineer available as backup for the first two weeks and an explicit rollback trigger if any incident's response time slipped. Ran the pilot: after-hours pages per person dropped from about 6 a week to 2, response times held within a couple of minutes of baseline, and the primary on-call engineers reported feeling less constantly reachable. That comparison was shared directly with the same leads, who then approved extending the approach to two more services with the same safety net built in.

Trade-offs and pitfalls

A pilot scoped too small can be dismissed as not representative of the real risk; scoped too large, it recreates the exact coverage risk the leads originally rejected, so choosing the pilot's size and safety net is itself a real judgment call. Re-pitching the identical plan with more enthusiasm instead of addressing the leads' actual objection reads as not having listened the first time. And treating a single "no" as final, without ever returning with new evidence, leaves a legitimate burnout problem unresolved, and it tends to resurface anyway, often at a worse moment.