Guide

Owning projects

Production postmortems

Blameless writeups so the system learns. Your job is timeline facts, contributing factors, and action items you actually finish.

83 of 166 · 2 min read

Blameless postmortems exist so the system learns. Your job as an IC is not to find a villain. It is to add accurate timeline facts, help name contributing factors, and own specific action items with dates — then follow through. Open action items are how the same outage repeats.

Trade-off

Speed of mitigation vs perfect diagnosis. During the incident, bias to mitigation. During the postmortem, bias to root causes and systemic fixes. Mixing them — debugging deep while users burn — is a common early-career mistake.

Walking through your contribution

  • Add timeline facts (what you saw, what you did).
  • Help identify contributing factors (missing alert, unclear ownership, risky deploy process) — not a person.
  • Own specific action items with dates: "Add canary on export workers — @you — by Fri."
  • Follow through.

The night-page follow-ups from handling a page are the shape: (1) fail jobs to a retry queue instead of user-facing 5xx when object-store blips; (2) the alert should mention a store dependency check as step 1 in the runbook; (3) a postmortem comment with the timeline. That is production ownership as a loop, not as a single heroic night.

Sustainability is part of the same loop. Rotations need real coverage (not "you are always secondary"). Take comp time or a late start after a rough night when policy allows. Say in standup: "I was up for an incident; today is follow-ups, not new feature work." Push back when a launch skips instrumentation to "hit the date" — that debt gets paid at 2 a.m., usually by you.

Managers worth working for treat operational load as real work in reviews. Document pages reduced, toil automated, and incidents led. If the culture only rewards feature launches, still keep the operational bar for your code — and factor culture into career strategy over longer horizons.

Volunteer for the rotation once you can ship a feature with a dashboard. After each shift, write down one system insight and one improvement. In reviews, "I reduced pages from N/week to M by doing X" is concrete ownership.

Common mistakes

  • Leaving follow-ups as vibes instead of dated tickets with owners.
  • Hunting a villain instead of contributing factors.
  • Skipping the rotation until promo time, then discovering you have no production stories.

Check yourself

During the incident you want to prove the deploy was innocent. Users are still failing. What first?

Mitigate. Diagnosis belongs in the postmortem, not while users burn.

You volunteered an action item in the writeup. What makes it real?

A date, a name, and a closed ticket. Open items are how the outage repeats.

Key takeaways

  • Postmortems are for systemic action items you actually complete.
  • Mitigate during the incident. Diagnose in the writeup.
  • Name contributing factors, not villains.
  • Document operational wins. Quiet pages are evidence.

Further learning

Site Reliability Engineering (Google SRE book)Go through the complete table of contents of sre Google book, outlined are the key topics and insights covered in this essential resource for SRE professionals.sre.google

Back to the map: owning your code in production.

Owning your code in production

On-call, alerts, runbooks, and the loop that makes you trustworthy — and better at building systems that survive users.

Handling a page

Acknowledge, assess blast radius, mitigate first, escalate when needed, communicate. Diagnose after users are safe.

Ownership

Acting like an owner: close loops, care about outcomes, and be the person things do not fall through with.