Don't Ship an Integration You Can't Assign

The change was 4 lines. It took 5 hours to ship, and none of that time went to code.

A production integration broke at 11am on a Tuesday. The customer who depended on it filed a P1. The on-call engineer opened it up and, within thirty minutes, had the diagnosis: a third-party API had changed a field the integration didn't handle. A four-line patch to the response parser would fix it. Then came the real problem. Nobody could say who should ship the patch.

The integration had been built two years earlier by an engineer who'd since left. It went in for a sales ask, for a customer now using a different feature. It lived in a repo no current team owned. The on-call engineer escalated to engineering leadership, who escalated to product, who escalated back to engineering. The director of engineering polled four team leads; none of them counted the integration in their scope. Nobody had owned the code since the original author walked out the door. The patch shipped at 4pm, after the customer had spent five hours assuming the company didn't care.

Every company past fifty engineers has these. They're integrations, scripts, dashboards, data pipelines, internal tools: small systems built once, useful once, then left running in production with no owner on record. They hum along for months without attention, which fools everyone into thinking they need none. That holds until something upstream moves. An API deprecates, a credential expires, a dependency jumps a major version, and the thing falls over. The break is instant. Finding the cause is quick. What drags is the org question of who's responsible for the repair.

Orphans get created the same way every time. An engineer builds a system for a specific request. It ships. The requester moves on. The engineer changes teams or leaves. The system keeps running, because running is its default. Nobody gets assigned to it, because the assignment was only ever implicit: the person who built it owned it. When that person evaporates, so does the ownership. The system is now homeless and doesn't know it.

None of this shows up in normal operations. No velocity dashboard, incident count, or deploy chart surfaces an orphan, because an orphan isn't being touched. It's dormant code quietly depending on assumptions about the outside world that will eventually break. Its cost is roughly zero in calm years and steep in the year an assumption gives way. And that steep cost gets filed under the incident, not under the missing ownership that made the response slow.

The incident is rarely the worst part. Worse is what the customer lives through during those hours of internal confusion. Their P1 gets acknowledged in minutes. They expect a response. The delay that follows has nothing to do with the difficulty of the fix and everything to do with the argument over who owns it. From where the customer sits, a five-hour silence has one obvious reading: the company doesn't care. Every hour of internal confusion buys an hour of damaged trust. A customer who watches this happen is one quiet churn risk you won't see coming.

What corrects it is an artifact ownership register. One engineering manager can build the first version in about a day. Every external integration, every cron job, every internal tool, every third-party dependency, listed in one document, each with a single named team on the hook to wake up at 3am if it breaks. Review the list quarterly. Anything without an owner gets one. Anything the assigned team can't reasonably maintain gets either funded with real capacity or shut down.

The register surfaces conversations people avoid. The first review usually shows that a quarter of the company's running systems have no owner on record. Deciding who takes each one is uncomfortable, because every team wants it to land on a different team. Leadership generally has to settle it, not consensus, because each team's incentive is to shrink its own maintenance load.

Harder still is the deprecation talk. Plenty of orphans have no active users, or one or two who could move to something else with a week's notice. For those, the right answer is shutdown, not adoption. The team that would inherit the upkeep should push hardest to kill it, because the alternative is a permanent tax on its capacity. Most engineering orgs are too polite to push for shutdowns. The ones that do get real capacity back from the shrunk maintenance surface. It's the same discipline behind the cash-collection cycle nobody owned: unowned processes don't fail loudly, they bleed quietly.

The shutdown talk forces leadership to face the customers still on the orphan. That group is usually small, two or three accounts, often running the integration as a workflow they could migrate off with notice. Killing it costs some goodwill in the short term. That cost is bounded. Keeping the orphan alive forever is unbounded, because it will break at random intervals and each break reruns the same multi-hour confusion until someone either kills it or formally adopts it.

Better still, demand an ownership declaration the moment any integration ships. The PR includes a field naming the team that will maintain it. That team's manager signs off on taking the burden. No sign-off, no ship. You buy a little friction at ship time and save a lot at every future moment of maintenance.

Most orgs skip this, because shipping is the urgent thing and ownership feels like paperwork. The paperwork is the point. Fifteen minutes of ownership talk before shipping buys you out of four hours of ownership talk when the integration breaks eighteen months later, against an on-call engineer who's never seen the code.

The integration nobody owns will break. The only open question is whether you spent one day building the register before the break or four hours arguing after it. The first bill is smaller.

Before your next engineering offsite, ask:

• Does the org have an explicit artifact ownership register?
• If yes, when was it last checked against the current team structure and code surface?
• If a customer-facing integration broke this Friday at 4pm, would the on-call engineer know within five minutes which team owns the fix?
• What share of the company's running systems would survive an honest deprecation conversation?

Run those honestly and most teams find a register that either doesn't exist or went stale a year ago. Building it is one day of structured work. Skipping it gets paid every time an orphan breaks, in front of customers who read the delay as indifference.