Code Ownership Is an Anti-Pattern
When a Component Gets a Surname
You can spot it in a stand-up. Someone raises a bug, and the answer isn’t “I’ll look at it”, it’s “that’s Alice’s, we’ll have to wait for Alice.”
Nobody decided this. There was no meeting where the team agreed Alice would be the only person permitted near the billing module. It just happened, because Alice wrote it, Alice knows it, and it is always faster in the short term to route the work to whoever already understands it.
That’s the trap. Every individual decision to send the work to Alice is correct. The accumulated result is a team that can’t function without her.
What It Actually Costs You
A bus factor of one. Alice books a fortnight in Spain and a production bug lands in her component on day two. Now you’re either waiting, or you’re texting someone on holiday, and neither of those is a plan.
A permanent bottleneck. Every change needs her review. She’s the busiest person on the team and getting busier, because being the bottleneck generates work rather than reducing it. Meanwhile three people are blocked and looking for something to do.
Knowledge that leaves when she does. And she will, eventually. Everyone does. What walks out of the door isn’t the code, it’s the reasoning: why it’s shaped like that, which bits are load-bearing, what the strange bit in the middle is quietly protecting against.
Territory. “That’s my code” becomes “don’t touch my code” faster than anyone expects. Improvements get resisted, refactors get quietly blocked, and the code stops changing. People mistake that for stability.
Work that can’t flow. Alice’s area is on fire and she’s drowning. Bob’s area is quiet and he’s idle. Nothing structural stops Bob helping except that everyone has agreed he can’t.
What You Get Instead
Collective ownership isn’t a slogan. It changes the mechanics.
The team survives absences. Anyone can pick anything up. Illness, holidays, someone handing their notice in. The work continues and nobody has to be heroic about it.
Reviews get real. When you might genuinely be maintaining this code next month, you read it properly. Review stops being a formality where two people say “LGTM” and one of them means “I trust you.”
Standards emerge on their own. Nobody can hide behind “my code, my rules”, so the codebase drifts towards consistency instead of becoming six dialects in a trenchcoat.
Nobody is indispensable. Which sounds like a threat and is actually a kindness. Being indispensable is exhausting, and it’s the thing that stops people taking a proper break.
The Argument Against
I’m not going to pretend this is free either.
“Everyone owns it” curdles into “nobody owns it” remarkably easily. Shared ownership without shared accountability means the awkward, unglamorous maintenance jobs sit in the backlog forever, because they’re everyone’s problem and therefore nobody’s. Clear responsibility genuinely does prevent neglect, and pretending otherwise is naive.
And expertise is real. Alice does understand her component better than you do, and that isn’t ego, it’s just true. Someone changing it without the full picture introduces risk. Sometimes the safest thing really is to let the person who knows do the thing.
Where I Might Be Wrong
My experience skews towards small, fairly senior teams, and this may simply be advice that works at that size. Larger organisations may genuinely need ownership boundaries for coordination, because you can’t have forty people all feeling entitled to reshape the same module.
Collective ownership also requires collective capability. If a team can’t hold a quality line without gates, those gates might be doing something load-bearing. Ripping them out because a blog post called ownership an anti-pattern would make for a bad afternoon.
Nobody is indispensable. That sounds like a threat and it’s actually a kindness.
How to Weaken the Boundaries
- Pair across components, not within them. Alice pairs with Bob on Alice’s code
- Rotate on-call across everything. Nothing spreads knowledge like being woken up by it
- Celebrate PRs into unfamiliar areas, especially the small tidying ones
- Write down the reasoning, not just the behaviour. Oral tradition leaves with the person
- Make Alice the reviewer rather than the author for a few sprints. She stays the safety net without staying the bottleneck
- Keep accountability named even when the code isn’t
That last one is the balance I’d actually argue for. The goal isn’t erasing responsibility, it’s separating who looks after this from who is allowed to change it. Those two got welded together somewhere along the way and they never needed to be.
The healthiest teams I’ve worked in had no Alice’s code. Just our code. Everyone could help, and because they could, they did.
Until next time, happy coding!