In a software team, accountability is knowing who owns the outcome and being able to say so in a post-incident review without theater. It is not blame, and it is not “everyone owns everything” (which means no one does).
What it looks like in practice
- A name on the service: pager, merge rights, “this SLO is ours.”
- A written owner for a change: who can roll it back at 2 a.m.
- Reviews that say “I would run this in prod” or “I would not,” not only “LGTM.”
After a failure
Blameless means you hunt causes in the system (missing test, unclear runbook, a deploy with no canary). It does not mean nobody changes anything. The accountable team still ships the fix and the missing guardrail. If the same incident repeats, that is a management problem, not a “learning” slogan.
Example
What breaks it: the outage channel says “everyone owns checkout,” and the pager rotation has no one who has shipped that service.
Better: one name owns checkout. After a blameless review, that owner still ships the missing guardrail.
Pitfalls
- Spreading on-call so thin that the person paged never heard of the service.
- Accountability as public shaming in Slack.
- Hero culture: the same person always unblocks, so the system never learns.
Related: communication, mentoring.