Rule 35 of 38 · Chapter VI — Shipping Is Part of Engineering
Own what you deploy
Why this rule exists
When the person who wrote the code also runs it in production, incentives line up: you feel the pages, the latency, and the confusing logs you left behind, so you build for operability instead of just correctness. Throwing code over the wall to a separate ops team severs that feedback loop, and quality quietly erodes because the author never learns what breaks.
In practice
Take a turn on call for what you build. Before you ship, make sure it emits the logs, metrics, and alerts you'd want at 3 a.m., and write the runbook while the design is fresh. Watch your change roll out and stay until it's healthy. When something breaks, fix the root cause and the gap that let it surprise you, not just the symptom.
When it doesn't apply
Not every organization can have engineers on call, and some domains rightly separate duties for compliance or safety. Where that's true, close the loop another way: shared incident reviews, blameless postmortems, and real feedback from operators back to authors.