Run13 Operations · 3 of 3
Ownership at handover
Two kinds of ownership, both required, neither substitutable: a group owns the object so it survives a leaver, a named person carries the pager so the alert reaches somebody.
Stand 29.07.2026
#Named owners, and getting off the rota
WhatThe ownership sheet — reviewed at handover, then quarterly
Production objects are owned by groups in Unity Catalog — an individual owner leaves and takes the ability to grant with them, which the Unity Catalog route covers. Operational ownership is the opposite: it must be a named human, because a group cannot be woken up. The handover artefact holds both.
| Asset | UC owner (group) | Rota (named) | Runbooks (one per alert) | Last exercised |
|---|---|---|---|---|
| dwh_prod.gold.fct_order_line | grp_dwh_engineers | dwh-oncall — pool of 4 | rb_fct_order_line_* — 2 | 12.06.2026 game day |
| Lakeflow pipeline silver_sales_order | grp_dwh_engineers | dwh-oncall — pool of 4 | rb_silver_sales_order_* — 3 | 03.07.2026 incident |
| Job silver_customer | grp_dwh_engineers | dwh-oncall — pool of 4 | rb_silver_customer_* — 1 | never |
| dwh_prod.gold.mv_sales | grp_dwh_analytics | bi-oncall — pool of 2 | rb_mv_sales_* — 1 | never |
The last column is the point of the sheet. Two rows say never — those runbooks are fiction until something exercises them, and the next game day should target exactly those. The pool of two is the second finding: the rota puts two names on call every week, which a pool of two can only sustain until the first holiday.
The handover test is a date, not a document. The consultant comes off the alert rota four weeks before the engagement ends, not on the last day. Those four weeks are the only period in which the team genuinely operates the warehouse while you are still reachable, and every gap they hit is one you close together rather than hear about by email in October.
Why
The failure has a distinctive signature: an alert destination still pointing at an address nobody reads — the consultant's mailbox, or a shared
data-team@ inbox with 400 unread messages. Alerts keep firing and keep being delivered, so every dashboard is green: the alerting works perfectly and lands nowhere.Nobody notices, because no response to an alert produces no signal at all. It surfaces months later as a freshness problem that had been alerting daily since March.
Doing it
- Build the ownership sheet in week 20 and review it with names in the room, not with roles
- Hold the rota exit date agreed at kick-offMake it four weeks before the end rather than the last day.
- Fire a real test alert down every destination at handover and confirm a human repliesConfigured is not delivered.
- Grep the workspace for the consultant's address before the last weekExpect to find it in a job notification nobody remembers creating.
Defaults
- Groups own UC objects; named people carry the pager. Both, always
- A pool of at least four, so the weekly pair of names can always be filled
- Consultant off the alert rota four weeks before the end, and reachable for all four
- Sheet reviewed quarterly; 'last exercised' is the column that shows rot
Gotchas
- The consultant's address left in a job notificationAlerts deliver successfully for months after the contract ends, so nothing looks broken — and the discovery is a freshness breach that had been firing daily since March.
- A pool of twoIt holds until one holiday overlaps one illness, and then the weekly pair cannot be filled, so the page goes to whoever is online — which at 03:00 is nobody.
- UC objects owned by an individualThey leave, nobody can grant on the table, and the fix needs a metastore admin at exactly the moment the grant was urgent.
- The ownership sheet living in the handover deckIt is never edited, so within a quarter it names two people who changed team and one who left, and the rota it describes has not existed for months.