Owning your code in production

"You build it, you run it" is not a punishment slogan. It is how you learn what your abstractions actually cost. Engineers who never touch production optimize for the wrong function: merge velocity instead of user outcomes and operable systems.

Production ownership is the operational half of ownership. Deeper rotation design and incident command live in on-call and incident response. This section is the craft you need as an individual contributor: ship with observability, handle a page, learn from shifts, fix what hurt you, and contribute to postmortems.

If you only ever build behind someone else's pager, you will ship sharp edges you never feel. If you only ever fight fires, you will never pay down the toil. The craft is the loop: build → observe → get paged → mitigate → improve → build.

Three feedback loops you cannot get from unit tests alone: real failure modes (timeouts, retries, bad deploys, dependency brownouts); empathy for the next on-call; and trust. Managers and partners trust engineers whose services are quiet and whose runbooks work. That trust becomes scope.

A useful personal SLO: after any page that took more than fifteen minutes, file at least one improvement within a week. The night export page is the whole loop in miniature — ack, mitigate with the flag before debating the deploy, then a retry queue and a runbook line the next day. That is how a noisy service becomes a quiet one, and how you get production stories for reviews without waiting until promo season to volunteer for the rotation.

Concepts in this section

Read them in order.

Pair operational maturity with project execution so "done" always includes runbooks and alerts.

Sustainable ownership needs real rotation coverage, not "you are always secondary." After a rough night, take the late start when policy allows and say in standup that today is follow-ups, not new features. Push back when a launch skips instrumentation to hit a date — that debt is paid at 2 a.m., usually by you. Document pages reduced and toil automated; those are review artifacts, not chores.

Common mistakes

• Shipping features with no metrics.
• Alerts that page on causes nobody can act on.
• Being a hero every night instead of fixing toil.
• Debugging root cause while users still burn.
• Leaving follow-ups as vibes instead of dated tickets.

Key takeaways

• Running what you build teaches failure modes tests cannot, and builds trust.
• Ship logs, metrics, dashboards, and actionable alerts with the feature.
• On a page: acknowledge, assess, mitigate, escalate, communicate.
• Turn painful pages into runbooks and fixes. Complete postmortem actions.

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 Being On-Call (Google SRE book)Proven strategies for on-call engineers to ensure reliable services and maintain sustainable workloads in IT operations.sre.google

Google SREs on what the job feels like: