Giving and Receiving Feedback Questions

Situation: During a high-severity outage, a peer on-call repeatedly escalated incidents to the on-call rotation instead of using the runbook’s safe rollback steps. Their postmortem also lacked timelines and root cause analysis—mostly a timeline of alerts and personal notes.

Task: As the secondary SRE and later reviewer of the postmortem, I needed to give constructive feedback so future incidents would be resolved faster and the postmortem would be actionable for the team.

Action:

• I scheduled a 30-minute one-on-one the next day, opened with appreciation: “Thanks for staying late—your detective work helped surface useful clues.” That lowered defensiveness.
• I used specific examples: “At 02:14 you escalated to engineering before attempting the documented rollback; that added ~18 minutes to recovery. The runbook has a tested rollback that often resolves this class of failure.”
• I suggested concrete changes: “For on-call steps, try: 1) follow runbook rollback, 2) collect diagnostics, 3) escalate if rollback fails. For postmortems, include a concise timeline, root cause (why it happened), and an action item with an owner.”
• I offered help: “I can pair with you next on-call to run through the rollback once so it feels comfortable.”

Result: Immediate reaction was receptive—they said, “I hadn’t realized the rollback was that safe; I’ll practice it.” Within two weeks they updated the postmortem with a clear timeline and root cause and followed the rollback in a subsequent alert, reducing time-to-recovery by ~15 minutes. The team adopted the suggested postmortem template; subsequent reviews were more actionable. I learned that framing feedback with appreciation, specificity, and an offer to coach leads to faster behavioral change.

Situation: During a late-night incident the cache cluster thrashed and our alerting flooded team channels. A newer SRE had deployed an alert change that lowered thresholds and enabled noisy notifications without coordinating with the on-call rotation.

Task: I needed to give corrective feedback so they wouldn’t repeat it, while preserving psychological safety and keeping the team confident.

Action:

• I asked to speak privately the next day and started by asking for their view of what happened (permission + listen).
• I used the SBI (Situation-Behavior-Impact) structure: “In yesterday’s cache incident (Situation), you changed the alert thresholds and unmuted several notifications shortly before the surge (Behavior). That caused repeated pages and delayed triage, which increased MTTR and stressed the on-call team (Impact).”
• I emphasized intent: “I know you were trying to improve visibility,” and asked what constraints led to the change.
• We co-created a corrective plan: revert the aggressive thresholds, add a staging test for alert changes, and require a short peer-review or runbook update for alerting config changes.
• I offered coaching: paired on creating test alerts, reviewed templating best practices, and scheduled a 1:1 learning session on alert fatigue and SLO alignment.

Result: The teammate adopted the staging + peer-review flow. Over the next quarter noisy alerts from our services dropped 65%, and MTTR for similar incidents improved. The teammate told me they appreciated the constructive, non-blaming approach and became a go-to for safe alerting changes.

Situation: On a large service I supported, I noticed a pattern of flaky deploys and repeated pager alerts tied to a teammate’s manual rollout process; it was causing ~3 hours/week of firefighting and burn on on-call rotations.

Task: As the SRE on-call lead, I needed to address the reliability problem with the engineer owning deploys and with their manager so the process would change without alienating the team.

Action:

• I gathered objective data first: incident timestamps, alert counts (12 incidents in 6 weeks), mean time to recovery, and a short timeline showing correlation with manual rollbacks.
• I requested a 30-minute one-on-one with the engineer, framed as collaborative debugging: “I want to understand the constraints you’ve had with our deployment pipeline and share what I’m seeing so we can reduce on-call noise.”
• I used neutral, fact-based language: “I observed…” and “When X happens, the on-call pager fires Y times,” avoiding “you” blame. I asked open questions: “What trade-offs led to manual rollouts?” and “What parts of automation feel risky?”
• We mapped failure modes together and agreed on three pragmatic steps: add a deployment health-check, implement a canary with automated rollback, and add post-deploy dashboards.
• I followed up with the manager in a separate meeting, presented the data, the agreed plan, and offered SRE support for implementation and testing.

Result: Within 3 sprints we reduced deployment-related incidents by 75% and averaged 1 hour/week less on-call toil. The engineer felt supported rather than criticized; they later led the canary rollout work. The team adopted the neutral, data-driven feedback pattern for other reliability improvements.

What I learned: Tough feedback lands best when it’s objective, collaborative, and paired with concrete support and measurable outcomes.

Coaching approach (brief): I’d focus on audience-first writing, clear structure, and actionability. Teach the engineer to separate technical deep-dives (appendix) from an executive summary that stakeholders can act on.

Sample feedback email:
Subject: Feedback on recent postmortem — making it more actionable for stakeholders
Hi [Name],
Thanks for the thorough investigation into the outage — your technical analysis is excellent and helped identify the root cause. I’d like to suggest a few changes so non-engineering stakeholders can use the postmortem quickly:

• Add a 3–4 sentence TL;DR at the top: high-level impact, duration, customer impact, and the immediate mitigation.
• Follow with “What happened” (plain language), “Root cause” (concise), and “Actions we’re taking” with owners and dates.
• Move deep logs, timelines, and debugging steps to an appendix labeled “Technical details.”
  Could we pair for 30 minutes to revise the last postmortem together? I think a quick template will make your excellent work more broadly useful.
  Thanks — I value your rigor and want it to have maximum impact.
  —[Your name]

Short training plan (4 weeks):
Week 1 — 60-min workshop: “Audience-first postmortems”

• Goals: TL;DR, impact framing, action owners
• Exercise: Condense a long postmortem into a 5-line executive summary
  Resources: Google SRE postmortem guide, “Write Better Postmortems” blog
  Week 2 — 60-min template walkthrough
• Introduce standard template: TL;DR, Impact, Timeline (high-level), Root Cause, Remediation, Prevention, Appendix
• Exercise: Fill template using a past incident
  Week 3 — Peer review session (60 min)
• Practice giving/receiving feedback; use rubric
  Week 4 — Shadowing + 1:1 coaching (30 min)
• Revise a real postmortem together; set ownership for next incident
  Ongoing resources: checklist, example good/bad postmortems, optional technical appendix template

Measurable indicators:

1. Stakeholder usefulness score: average rating from a short survey (1–5) sent to PMs/ops within 3 days of each postmortem — target +1 point within 8 weeks.
2. Reduction in clarification requests: number of follow-up questions from non-engineering stakeholders per postmortem — target ≤1 follow-up within 6 weeks and fewer required edits before publication.

This approach keeps technical rigor while improving clarity and organizational impact.

Situation: Our team’s service had a spike of PagerDuty alerts over two weeks — ~18% of on-call wake-ups were for a single health-check alert that passed locally but failed intermittently in CI. Investigation showed one developer’s end-to-end test was flaky: it relied on timing and a non-deterministic mock, causing transient failures that triggered automated rollbacks and alerts, wasting ~10 on-call hours that fortnight.

Task: As the SRE on-call owner, I needed to stop the wasted cycles, give the developer constructive feedback, and put in place changes so flaky tests wouldn’t undermine reliability metrics.

Action:

• I collected data (failure rates, timestamps, CI logs) and reproduced the flake locally to be specific.
• Scheduled a one-on-one with the developer, opened by acknowledging their hard work, then showed the concrete evidence: CI traces and how the flaky test correlated with alerts.
• Focused feedback on impact, not blame: explained how flaky tests inflate alert noise, impact on-call fatigue, and SLO signal quality.
• Collaboratively proposed remediation: make the test deterministic (replace timing waits with event-based waits), use reliable mocks, add idempotent cleanup, and mark tests that truly require integration as flaky with a short-term quarantine.
• Implemented CI safeguards: add a flaky-test detection job (run suspected tests 10x), require passing gate for deploys of tests touching critical paths, and add automated retries only after investigating root cause.
• Followed up with a shared improvement plan and paired on a patch to fix the test.

Result: Within a week the flaky test was fixed and quarantined tests were reduced by 80%. PagerDuty noise from that alert dropped to zero over the next two weeks; on-call hours saved were ~12 hours/month. The developer appreciated the data-driven, respectful approach and adopted best practices (deterministic mocks, clearer test ownership). We also added a short checklist for test authors to prevent regressions. This preserved team trust and improved our alert fidelity.