Shared Ownership
Who is responsible for a service in production, and why that answer has to be a specific team rather than everyone.
The question, the obvious approach, and why it breaks
Every lesson starts where the work starts: an operational problem, a first attempt that is entirely reasonable, and the way production disagrees with it.
Who owns this service in production, and what does owning it actually oblige them to do?
Services outlive the projects that created them. Without an explicit owner, a service is maintained by whoever last touched it, until nobody has.
Everyone owns everything. We are one engineering team and anyone can fix anything.
Shared responsibility with no named owner is unowned. When an alert fires for a service nobody is assigned to, the response is slower and less confident.
- Shared responsibility with no named owner is unowned. When an alert fires for a service nobody is assigned to, the response is slower and less confident.
- Nobody performs the unglamorous maintenance — dependency updates, certificate renewals, capacity review — because it is not anyone's in particular.
- Knowledge concentrates informally in one person, and leaves when they do.
- At more than a handful of services, "everyone owns everything" means nobody has enough context about any of them to operate them well.
What is actually happening
Underneath the tooling, which is the part that survives a change of tool.
- Ownership is a routing decision: it determines where alerts go, who decides on a risky change, and who is accountable for the service being operable.
- It is distinct from authorship. The team that owns a service now may not have written any of it, and that is fine as long as the record is current.
- Shared ownership in the DevOps sense means the *same* team builds and operates — not that *all* teams own everything.
Ownership is a routing table
The most practical framing: ownership is what an alert, a question or a risky decision routes to. Everything else follows from that.
- Alerts route to the owning team's rotation, not to a shared channel where everyone assumes someone else is looking.
- Changes are approved by people who understand the service's operational behaviour.
- Questions from other teams have a destination, so integration does not depend on knowing the right person.
- Maintenance — upgrades, renewals, capacity review — has an owner, so it happens before it becomes an incident.
- Incidents start with diagnosis rather than with working out who is responsible.
You have found a production service with no owning team. What now?
when It is genuinely serving that team's domain.
cost Adds operational load to a team that did not choose it; needs capacity to be real.
when It is genuine shared infrastructure with cross-team users.
cost Only works if the platform team has the capacity and authority; otherwise it is an orphan with a nicer label.
when Nobody depends on it, which is more often true than people expect.
cost Requires proving there are no consumers — often the hardest part.
when Never, for a service carrying production traffic.
cost The next incident on it starts with an argument instead of a diagnosis.
How to do it properly
Most important first.
- Record an owning team for every production service, with an escalation path, and treat a missing owner as a production defect (The Ownership Record).
- Give the owning team the authority to change the service, not just the pager for it.
- Make ownership transfer an explicit event with a handover, not a silent consequence of a reorg.
- Audit for orphans periodically — services whose owning team no longer exists are the ones that fail worst.
How much can this affect
Every production change has a blast radius. Stated as a scale so it is comparable between changes rather than adjectival — and paired with what actually contains it, because a wide scope with a real containment mechanism is a different situation from a wide scope with none.
Usually contained to the affected service — but an unowned shared dependency escalates to everyone.
What can go wrong
- Ownership recorded once and never updated, so alerts route to a team that dissolved.
- Pager duty assigned without authority to change the system, producing burnout and no improvement (Rotations People Can Sustain).
- A shared service — the platform, the shared library, the deployment pipeline — that everyone depends on and no team owns.
- "Shared ownership means no owners." It means the builders are the operators. It does not mean the owner is unspecified.
- "The platform team owns anything shared." Only if they have capacity and authority for it; otherwise it is an orphan with a label.
Operating it
Evidence is the signal, not the intention. Rollback is sometimes 'you cannot, and that is the point'.
- Every alerting rule resolves to a team that currently exists.
- For any service, you can find the owner, the repository, the dashboard and the runbook without asking a person.
- Ownership changes should be reversible in the sense that the previous owners remain reachable during a transition period; a hard cutover on a service the new team has never operated is how handovers fail.
- Automate the linkage: alert routing, dashboards and runbooks derived from an ownership record rather than maintained separately.
- Do not automate the judgement of who *should* own something — that is an organisational decision with real consequences for the people involved.
- Explicit ownership creates boundaries, and boundaries create handoffs at the edges. The cure for that is good interfaces, not vaguer ownership.
- Small organisations may genuinely operate well without formal records; the cost arrives with the third or fourth service.
Where this applies
This domain is unusually tool- and organisation-dependent. These labels say what each claim is specific to, and what a different platform, provider or organisation does instead.
- ORG-SPECIFICTeam structure and on-call arrangements are organisational choices. A single-team company needs no ownership records; a fifty-team company that lacks them has orphaned services it does not know about.
- SCALE-SPECIFICThe cost of missing ownership scales with service count, not with traffic. Three services and eight engineers is fine informally; thirty services is not.
Where the depth lives
This domain teaches delivery and operation, and hands the mechanism off to the domain that owns it.
- — Testing & Reliability Engineering — service level objectives as the contract an owning team commits to.