Code Ownership Is an Anti-Pattern

The Claim

Strong code ownership-“this is Alice’s code, ask her”-creates knowledge silos, blocks progress, and makes teams fragile. Collective ownership, where anyone can change any code, is better for teams and products.

Why I Think This

I’ve been on both sides of code ownership.

The problems with strong ownership:

Bus factor of one. Alice goes on holiday. Her component needs a bug fix. Everyone waits. Alice gets sick. Everyone panics.

Bottlenecks. Every change needs Alice’s approval. She’s overloaded. Everyone else is blocked. Alice becomes the constraint.

Knowledge silos. Nobody else understands Alice’s code. When she eventually leaves, the knowledge leaves with her.

Territorial behaviour. “That’s my code” becomes “don’t touch my code.” Improvements are resisted. Refactoring is blocked. The code calcifies.

Uneven workload. Alice’s component is busy? Alice is overworked. Bob’s component is quiet? Bob is idle. Work can’t flow.

What collective ownership provides:

Resilience. Anyone can fix anything. Illness, holidays, departure-the team continues.

Better reviews. When you can change anything, you actually read and understand it. Code review becomes meaningful.

Shared standards. Nobody can hide behind “my code, my rules.” Consistency emerges.

Flexible teams. Work goes to whoever’s available. No artificial constraints on who can help.

The Counterargument

Some ownership accountability is useful. “Everyone owns this” can become “nobody owns this.” Clear responsibility prevents neglect.

And expertise is real. Alice might genuinely understand her component better. Forcing others to change it introduces risk.

Where I Might Be Wrong

Maybe my experience is specific to small, senior teams. Larger teams might need ownership for coordination. Inexperienced teams might need ownership for learning.

And “collective ownership” requires collective capability. If the team can’t maintain quality without gates, gates might be necessary.

The Takeaway

Weaken ownership boundaries:

• Pair across components. Alice pairs with Bob on Alice’s code. Knowledge spreads.
• Rotate on-call. Everyone supports everything. Forced learning.
• Encourage cross-contributions. Celebrate PRs to unfamiliar areas.
• Document aggressively. No oral tradition. Knowledge in code and docs.

The goal is a team that survives any individual’s absence.

The healthiest teams I’ve seen have no “Alice’s code.” Just “our code.” Everyone can help. Everyone does help. Nobody is indispensable.