Ownership is accountability, not code volume
A service owner is the team that answers for the service in production: the team that fixes it, accepts the operational risk and decides who is paged. That is different from code ownership, which describes who reviews changes in a repository. A team can own a service while another team owns most of its code, and a person can have hundreds of commits without being accountable for the service today.
The distinction matters when ownership changes. A handover is a decision with a date, not a silent edit to a wiki table. Keeping the previous owner as history lets an engineer see why an answer changed instead of wondering whether the record is current.
Four questions an ownership system must answer
An engineer usually arrives with one of four questions, and a useful system answers all of them from the same records:
- Who owns this service today, and who is the escalation path?
- Who is on call now, and how is that different from ownership?
- What breaks if this service fails, and which of those services are unowned?
- Why did ownership change, and when was the current edge last verified?
What belongs in the record
At minimum, record the service, the accountable team, a named escalation contact, the start date of the current ownership edge and the last verification date. Add the on-call rotation, the upstream and downstream dependencies, and links to the decisions that changed any of those facts.
Dates are not decoration. They let a reader judge whether an answer is current and let a monthly review find edges that have gone stale. An ownership record without a date is a claim without a timestamp.
Keeping the record current
Ownership drifts when people change teams, services split, or a temporary owner becomes permanent. Review unowned services monthly, re-verify ownership edges every 90 days, and create a dated decision whenever a handover happens.
The goal is not a perfect org chart. It is an answer an engineer can act on at 2am, with enough evidence to know whether to trust it.
Worked example: one question, four records
Question: "Who owns payments-gateway, who gets paged, what breaks if it fails, and why did the owner change?" The graph returns the Platform team as owner, the current Platform on-call as the active responder, eight downstream services across three hops, and Decision D-21 as the handover from the previous owner.
Each part of the answer has a source and a date. If the handover was reversed last week, the graph is wrong until the record is updated, but the date on the edge makes that visible instead of hiding it.