ownership-map

Ownership map

Who to ask, who to tell, and who can say yes.

Why this exists

The most common way an FDE's work fails is not technical. It is a correct change that never merges, because the reviewer who needed to see it was never identified, or the team that owns the downstream consumer heard about it in the release notes.

Knowing who is as load-bearing as knowing what. And the org chart won't tell you — it shows reporting lines, not the person who actually knows the batch job, or the one whose approval is treated as decisive regardless of title.

The repository will tell you, though. Commit history, review patterns, and directory activity are evidence, and unlike the org chart they reflect what is currently true.

When this applies

• You need a reviewer, an approver, or an interview subject
• A change crosses a team boundary
• A change crosses a team boundary
• Nobody seems to own a component
• Preparing for knowledge-interview — this tells you whom to interview

When it doesn't

• You already know the team and its decision paths
• Solo repository with one obvious owner
• The question is about a business decision rather than a system — that's stakeholder territory, in the charter

Prerequisites

.fde/00-engagement.md, and .fde/02-system-map.md if it exists — you map ownership of components, so it helps to know what they are.

Procedure

1. Read the declared ownership first

git ls-files | grep -E '(^|/)(CODEOWNERS|OWNERS)$'

Read every hit. Nested package owners are common; the root file is not the whole story.

Also check for a service catalogue (catalog-info.yaml for Backstage), a docs/owners.md, or team metadata in the CI config.

Treat all of it as a hypothesis. Declared ownership goes stale faster than almost any other documentation — teams reorganize, people leave, and nobody updates the file. Verify it against activity before relying on it.

2. Derive actual ownership from history

The strongest signal, and it's free.