Why Nobody Wants to Own the Shared Library (And What It Costs You)

TL;DR: Shared libraries usually start with good intentions: one team pulls duplicate code into a common package so everyone benefits. The problem is nobody assigns a permanent owner, so when the original team moves on, the library keeps running but nobody is responsible for fixing it. This piece walks through how that happens step by step, and gives you a simple test for deciding when sharing code is actually worth the risk.

The library that everyone uses and nobody owns

Here’s a scenario that plays out in almost every mid-size engineering org sooner or later.

Team A is building a checkout service. They need to send order confirmation emails and SMS messages. A few weeks later, Team B, working on a totally different product, needs to send similar notifications. So does Team C. Someone on Team A says, reasonably, “let’s not write this three times.” They pull the notification code into a shared package called common-notifications. Teams B and C import it. Everyone claps. Duplicate code avoided, an engineering win.

Fast forward a year. Team A gets reorganized into two smaller teams working on different parts of the checkout flow. The engineer who wrote common-notifications leaves the company for a new job. A vendor changes their SMS API, and common-notifications starts silently failing for 8% of messages.

Who fixes it?

Technically, nobody owns it anymore. It’s not on anyone’s roadmap. It doesn’t show up in anyone’s sprint planning, because no team’s manager is measured on how healthy common-notifications is. Each of the three teams that depend on it assumes someone else is responsible, because from their point of view, they’re just “using a library,” the same way they’d use any open-source package.

Ownership is a people problem wearing a code costume

When we talk about “who owns this code,” we usually mean something like: who decides what changes go into it, who gets paged when it breaks, and who has time carved out in their week to maintain it. That’s not a technical property of the code. It’s an organizational commitment, made by a manager, that shows up in someone’s job description and someone’s performance review.

A shared library only stays healthy as long as that commitment exists. The moment the team that made it changes shape, the commitment can silently disappear, even though the code itself hasn’t changed at all. This is the part that catches people off guard: the library didn’t get worse. The organization around it did.

The code doesn’t change in this story. The organization around it does, one step at a time, until nobody is left holding it.

Why good intentions turn into a ghost town

A few forces push shared libraries toward this fate, and none of them are anyone acting maliciously.

Extraction is a one-time event, ownership is ongoing. Pulling code into a shared package takes a sprint. Maintaining it takes a fraction of someone’s attention forever. Only the first part gets celebrated in a demo.
Promotion criteria reward shipping, not maintaining. If your manager evaluates you on features delivered to your own product, spending time fixing a shared library that “belongs to everyone” is a bad career move, even if it’s the right thing for the company.
Reorgs don’t carry code ownership with them. When a team splits or a project ends, people get reassigned to new priorities. Nobody explicitly hands off the shared library, so it just becomes an orphan by default.
Consumers assume it’s “somebody else’s job.” Once a piece of code looks like a library rather than “our code,” the teams using it start treating it like a vendor dependency, something they consume rather than something they’re responsible for. That mental shift is subtle but it’s the whole problem.

None of this requires anyone to be lazy or careless. It’s just what happens by default when responsibility isn’t explicitly assigned and re-confirmed over time.

Why this matters beyond one broken library

The cost isn’t just the occasional outage from a stale dependency. It’s slower over time, in ways that are easy to miss:

Bugs in shared code take longer to fix, because someone has to figure out who even has the context to touch it safely.
Teams start quietly forking the shared code into their own copy just to avoid dealing with an orphaned dependency, which defeats the entire point of sharing it.
New engineers avoid touching the shared library because it’s unclear who to ask for a review, so it calcifies into code nobody wants to change even when it needs to.

Eventually the shared library becomes exactly the kind of code the original extraction was supposed to prevent: something everyone is scared to touch, that quietly drifts out of date, except now it’s used by three teams instead of one.

A simple test before you extract shared code

The instinct to avoid duplicating code is a good one. The mistake is treating extraction as free. Before you pull something into a shared library, it’s worth asking a short sequence of questions, and being honest about the answers.

If you can’t name the team that owns it a year from now, you don’t have a shared library, you have a shared liability.

The key question in that tree is the second one: does a team exist that will own this for the long term, not just today? If the honest answer is “no team wants this,” that’s valuable information. It usually means one of two things is true:

Duplicating a small amount of code across teams is actually cheaper than the coordination cost of shared ownership, at least for now.
You need a platform or infrastructure team whose actual job includes owning shared internals, not a volunteer team that happened to write it first.

Some organizations solve this by having a real platform team that owns all cross-cutting shared code as a first-class responsibility, with its own roadmap and on-call rotation. If you don’t have that, be skeptical of extracting shared code across team boundaries at all, even though the duplication will feel wasteful in the moment.

If you already have an orphaned library

If you recognize your own common-notifications in this story, the fix isn’t a dramatic rewrite. It’s making the invisible ownership question visible again:

Name an explicit owning team in writing, even if it’s a rotating responsibility, so “who do I ask” has a one-sentence answer.
Put the library in that team’s actual planning process, not as a side project squeezed in during slow weeks.
If truly nobody can own it, that’s a signal to deprecate it deliberately, with a migration plan, rather than letting it decay silently and get discovered mid-incident.

Shared code is a genuine engineering win when the organizational commitment behind it is real. The trap isn’t sharing code. It’s assuming that extracting the code once is the same thing as owning it forever. Those are two very different promises, and only one of them shows up in the pull request.