Kill “who owns this?” pings with a living ownership map
When onboarding is slow, the first question is often not technical:
“Who owns this?”
If ownership isn’t obvious, the team has to escalate just to find the right person. That’s expensive:
- new engineers feel blocked (and judged)
- EMs become the router
- staff engineers get interrupted to redirect people
You don’t fix this with org charts or a wiki.
You fix it with a small ownership map that lives close to the workflow.
What an ownership map needs to include
For each service or workflow, capture:
- Primary owner team
- Escalation channel (Slack, pager, rotation)
- Runbook link
- Truth dashboard link
- Deploy history link
If it doesn’t have links, people won’t trust it. If it isn’t easy to find, people won’t use it.
Service:
Primary owner:
Escalation channel:
Runbook:
Truth dashboard:
Deploy history:
The rule that keeps it current
Every entry has an owner.
“Ownership map” entries without owners become stale. Stale maps are worse than no map.
Add update triggers
Update the map when:
- a service changes owners
- a new service ships
- a runbook or dashboard link changes
Where to put it so it gets used
Put it where the question happens:
- a pinned message in the relevant channel
- a short
who owns <service>command - the top of the runbook
- the service README
The worst place is “somewhere in Confluence.”
How to roll it out without stepping on toes
Don’t show up with a decree.
Start with one team and one workflow for 30 days:
- capture the ownership map for that workflow
- fix the top repeated “who owns this?” pings
- make the links easy to find
Once the team feels the difference, scaling it’s a pull, not a push.