html

The Migration Nobody Owned

A critical transition was planned, discussed, and assumed to be in progress. It wasn't. Each person had a reasonable model in which someone else had it covered. The pattern is what happens when ownership lives in the gaps.

Summary: A critical transition was planned, discussed, and assumed to be in progress. It wasn't. Nobody lied, nobody forgot — everyone had a reasonable model in which someone else had it covered. The pattern that follows is not about negligence. It's about what happens when ownership lives in the gaps between people.

Pattern

A critical transition is planned. Everyone on the team is aware of it. Work happens around it. Then, at the moment it should have been completed, it surfaces that no one had actually taken ownership of it. Each person assumed someone else had. By the time the gap is visible, the window has closed or the cost of delay has already been incurred.


What tends to happen

A team is moving off one billing provider. Or migrating customer data to a new schema. Or sunsetting a legacy API version. The decision is made in a meeting. Action items are discussed but not formally assigned. The project board has a card for it, labelled with a sprint that has since passed.

In the weeks that follow, adjacent work continues: the new system is built, the UI is updated, the documentation is rewritten. The migration itself is assumed to be progressing. It is mentioned in passing during standups. Nobody raises a flag because nobody has checked.

The moment of failure arrives not with a loud crash but with a quiet question: "Is the migration done?" The answer, after a few seconds of silence, is "I thought you were handling that."


Why it fails

Nobody lied. Nobody was negligent in the usual sense. Each person had a reasonable, self-consistent mental model in which the migration was covered.

The engineer assumed the lead had picked it up. The lead assumed it had been delegated. The product manager assumed it was a purely technical task that the team had divided internally. The founder assumed it was on someone's sprint.

These models never collided until they had to. The assumptions were never audible — they were the background hum of "that's sorted", never surfacing into a sentence anyone had to say out loud.


Human layer

Teams are good at tracking work that has been done. They are poor at tracking work that is assumed to be in progress by someone else.

The shared mental model of a task in flight is a cognitive shortcut. It allows teams to move without constant verification. Most of the time it works because the person who should own the task does own it, and the assumption is correct.

The failure condition is specific: the task is critical, the ownership is ambiguous, and nobody has a strong enough stake in confirming it to push past the assumption. Everyone is operating in good faith. Nobody checks because everyone assumes someone is checking.


System layer

The systems around the migration were not built to surface this gap.

The project tracker had a card. The card had no owner, or it had an owner who left the sprint and whose assignment was never revisited. The card was not blocking any other card. There were no automated alerts on progress or completion. The migration did not have a deadline with teeth — no external commitment that would have forced the question to be asked.

Status was self-reported, which means status was never reported at all.


What it costs

The cost depends on what the migration was.

If it was moving customers to a new pricing structure, the cost is revenue running on the old structure longer than planned — or, worse, customers being transitioned at an unexpected moment when the team finally forces it through under pressure.

If it was deprecating an endpoint, the cost is a breaking change that lands on customers without warning, because the window for gradual migration was missed.

If it was moving off a vendor, the cost is another billing cycle on a contract that was supposed to be terminated.

In all cases there is a secondary cost: the team now knows that its coordination model has a hole in it. That knowledge tends to produce one of two responses — a new process, or a new anxiety that doesn't change anything.


Reduction path

The simplest intervention is to make ownership of a migration a named, single-person responsibility before the migration is considered planned.

Not a team. Not a workstream. One person whose name is attached to the completion condition.

This doesn't require a new tool or a new process. It requires one sentence in the meeting: "Who owns this?" And then waiting for a specific name, not a pronoun.

The second intervention is to tie the migration to something visible — a deadline attached to a customer commitment, a contract termination date, a public deprecation notice. Work without an external forcing function relies entirely on internal coordination. Internal coordination fails in exactly the way described here.

The third is to treat "I assumed it was covered" as a diagnostic signal rather than an explanation. When it appears, the question is not who dropped the ball but why the assumption was never tested. Usually the answer is that there was no moment in the process where testing it was anyone's job.