The four non-negotiables
Most ownership programs fail because they stop at a name in a table. A name is necessary but not sufficient. Use these four checks for every service:
- A current team is named as accountable, with a start date for the edge.
- An escalation path exists: a person or rotation that can be paged today.
- The last handover is a dated decision, not a silent edit.
- The record has a verification date and a review cadence.
The monthly review
A short monthly review catches the drift that a quarterly audit misses. Filter for four things: services with no owner, ownership edges not verified in 90 days, services whose on-call rotation points at a different team, and owners who have left the company.
Keep the output small. A list of ten services with a named provisional owner and a review date is more useful than a 60-page report that nobody reads.
What a complete record contains
For each service, record the accountable team, an escalation contact, the start date of the current edge, the last verification date, the on-call rotation and the dependencies that matter for impact. Link the decisions that changed ownership, and keep the previous owner as history.
This is enough to answer who owns it, who is paged, what breaks and why it changed without opening five tools. More fields are fine if they are maintained; a field nobody updates is worse than no field at all.
Common failure modes
The same four failures show up in most companies: the owner is a team alias that nobody monitors, the record lives only in a README, CODEOWNERS is treated as operational ownership, and handovers overwrite history instead of adding a dated edge.
Each failure has the same cure: make the record queryable, dated and linked to a decision. The point is not process for its own sake. It is that an engineer can check the answer instead of trusting a stale page.
Worked example: the quarterly review
The review finds config-service with no OWNED_BY edge and no on-call engineer, payments-gateway with a current Platform owner and a verified on-call, and a service whose owner left two months ago. The first and third go on the action list; the second is marked verified with today’s date.
Two weeks later the list is empty except for the provisional owner on config-service. The measure is not how many fields the catalog has; it is how many services would give an engineer a dead end today.