The Ownership Problem

The Ownership Problem

Debt accumulates fastest where ownership is unclear.

Who Owns the Debt?

Technical debt is often:

- Created by one team, paid by another

- Created by people who've left

- Distributed across systems with no single owner

- "Everyone's" problem (meaning no one's)

This ownership diffusion means debt doesn't get prioritized.

The Tragedy of the Commons

Shared systems become dumping grounds:

- Teams optimize for their features, not the shared health

- No one invests in infrastructure they don't own

- Maintenance falls to whoever happens to be around

- Quality degrades until crisis forces action

This is the classic tragedy of the commons, applied to code.

Ownership Models

Different organizations try different approaches:

Service ownership: Each service has a clear owner team, including its debt.

Platform teams: Shared infrastructure has dedicated owners.

Rotating stewardship: Teams take turns maintaining shared systems.

Debt sprints: Dedicated time across teams for debt reduction.

None is perfect. The key is having some model, not just hoping someone will care.

The Hero Problem

Often, debt gets owned by "heroes"—individuals who care when no one else does:

- They fix things no one assigned them to

- They remember how the old systems work

- They hold everything together through personal investment

This is noble but unsustainable. Heroes burn out. When they leave, their knowledge leaves too.

Making Ownership Explicit

To address the ownership problem:

1. Inventory the debt: What exists? Where is it?

2. Assign ownership: Who is responsible for each area?

3. Allocate capacity: Do owners have time to address it?

4. Make it visible: Does leadership see the debt and its costs?

Explicit ownership doesn't guarantee debt gets paid. But implicit ownership guarantees it doesn't.