Ownership is the atomic unit

Every company past roughly thirty engineers has a service that nobody owns.

It has a name that made sense in 2021. It was written by two people, one of whom has left.

It handles something quietly load-bearing. PDF generation. The nightly reconciliation job.

Three teams touch it and none of them would say it's theirs. When it breaks the page goes to whoever was closest last time, and that person is slowly becoming its owner through a process nobody ever agreed to.

You can predict what happens next.

Unowned things fail in the same order every time.

The decay sequence

First the dependencies rot.

Nobody upgrades anything, because upgrading requires testing, testing requires understanding, and understanding is somebody's weekend.

Then the documentation goes stale, which is a smaller problem than it sounds until it combines with the first one.

Then the alerts get muted. This is the real turning point.

An alert that fires and reaches nobody with the authority to act on it gets silenced inside about two months, and once silenced it never comes back.

The system is now running unobserved.

Then people become afraid of it.

Changes get routed around rather than through. The workaround becomes a feature, then a second system, and now you have two things doing the same job badly, one of which nobody owns.

The whole sequence takes about eighteen months.

Every step of it is individually reasonable.

What ownership actually includes

Saying a team owns something means five specific things.

Organisations that claim ownership usually hand over two or three of them.

They own change. Nobody modifies it without their review.

They own quality. If it's broken, that's theirs.

They own cost. The cloud bill appears in their numbers, which changes behaviour faster than any amount of encouragement ever does.

They own the pager. At three in the morning it's their phone.

And they own the right to say no. That's the one quietly removed, and without it the other four are just responsibility without authority.

That last one deserves the space.

A team that owns a service but can't decline a request to change it doesn't own the service. They staff it.

You see this in orgs where a platform team is accountable for reliability but any product team can merge into their repo on a deadline. The reliability goes, and it goes while everybody follows the rules.

Why "we all own it" doesn't work

The counterargument is collective ownership, and it has a respectable version: the whole engineering group is responsible for the whole codebase, anyone can fix anything, no silos. Some very good organisations run this way.

It works below roughly fifteen engineers. Above that it stops meaning anything, for reasons social psychologists documented in the 1960s and every on-call engineer has since confirmed independently. Responsibility diffused across a large group is responsibility held by nobody. What you actually get is a de facto owner (the person who cares most, or who was most recently burned) carrying it without the title, the time, or the authority.

Collective ownership also fails asymmetrically. Everyone will happily co-own the interesting new service. Nobody co-owns the reconciliation job.

The map

The intervention is boring and it works: a single table, in a place everyone can find, listing every system, its owning team, and who to page. Then a standing rule that nothing new goes to production without a row in it.

Keep it in the repo. Review it once a quarter, in a thirty-minute meeting whose only agenda is finding rows with no team and rows with two.

The first time you build this list you will find things you didn't know existed. That's not a sign of a badly run organisation, it's a sign of one that's been shipping. The list is also the single most useful document you can hand a new director in their first week.

Adopting an orphan

Assigning an unowned service to a team is not the same as fixing it, and doing the first while calling it the second is how you lose good managers.

An adoption needs three things. Time, meaning a real allocation, usually two to four weeks of someone's capacity to read the thing, write down what it does, and fix whatever they find. A handover from whoever knows it best, even if that person is grumpy about it. And an explicit reduction of something else the team was committed to, so the adoption isn't paid for out of evenings.

If you can't fund the adoption, you have a different decision to make: turn the service off, or accept that it's unowned and say so out loud rather than assigning it on a slide.

The exception I do make

Genuinely shared infrastructure can be genuinely shared, and pretending otherwise produces its own damage.

The case: a component that several teams depend on equally, that no single team is the primary consumer of, and where assigning it to one of them would make that team the arbiter of everyone else's roadmap. A shared client library. The core schema. The build system, before there's a platform team to hold it.

What makes shared ownership work in that narrow case is that it's explicit rather than residual. Named people from each team, not "the teams." A stated review rule so changes can't be merged unilaterally. And one team that carries the pager, even though the change rights are shared, because at 3am somebody has to be responsible and a group cannot be woken up.

That last part is the line. Shared change rights, single accountability. What I won't accept is shared accountability, which is the thing that reliably decays, and which is what people usually mean when they say a system is co-owned.

The honest test: if it broke on a Sunday, can you name the person whose phone rings, without checking. If you can't, it isn't shared ownership, it's the orphan state described above with better branding.

Ownership is not a fence

The obvious failure mode of clear ownership is territorial behaviour: gatekeeping, six-week queues to change a shared library, teams that treat their repo as sovereign territory.

I had this backwards for a while. The instinct is to soften ownership to prevent the territorialism. That makes both problems worse, because the diffusion doesn't reduce gatekeeping, it just removes the accountability that would let you challenge it.

The better split is between stewardship and exclusivity. Anyone can propose a change to any system. The owning team reviews it, holds the standard, and is accountable for the result. That's the model behind internal open source at large companies and it's the only version I've seen that keeps both speed and coherence.

The tell that you've drifted into fences is lead time. If a small, well-written change from another team takes more than a couple of days to get merged, the owning team has become a queue, and you have a capacity problem or an incentive problem rather than an ownership problem.

One thing to do this week

Open a document. List every production system you can name. Put a team next to each one.

The rows you can't fill are your actual backlog.