I traced 60 dropped work items back to their root cause over 6 months. The answer almost never matched what I expected going in.

Last year I did a retrospective that I'd recommend to anyone running a team without dedicated ops support.

I went back through 60 items that had stalled, been dropped, or died quietly over 6 months and tried to identify exactly where each one broke. I kept a spreadsheet. I was expecting patterns around unclear requirements, bandwidth problems, shifting priorities. Those existed. But they weren't the dominant pattern.

The dominant pattern was something I didn't have a clean name for at the time.

I started calling it ownership diffusion.

Ownership diffusion is what happens when a piece of work passes through enough people and enough tools that accountability becomes shared, which in practice means it belongs to nobody.

The item starts as a Slack conversation. Someone moves it to a Jira ticket. It gets referenced in a meeting. Someone emails about it. It shows up in a Linear card. And by the time it stalls, four people can each point to evidence that someone else should be following up on it.

Nobody lied. Nobody dropped the ball on purpose. The accountability got distributed across tools and people until it effectively vanished.

Here is what the stalled items had in common.

No single owner at the moment it stalled. Almost every stalled item had an assignee on the ticket. But the assignee owned the task not the outcome. When the task hit a blocker they stopped. Nobody was responsible for the overall result continuing to move forward. Owning the task and owning the outcome are completely different things and most teams never make this distinction explicitly.

The last communication existed in a different tool than the execution tracking. The last real conversation about a deliverable happened in Slack. Progress was supposed to be tracked in Jira. Neither system knew about the other. The Jira ticket looked healthy. The Slack thread had been silent for 9 days. Unless you manually checked both you'd have no idea anything was wrong.

No trigger was defined for silence. Items aged because nobody had set a rule like if this hasn't moved in 5 days something needs to happen. Without a trigger, silent items just accumulate indefinitely. Your tools send you notifications when things happen. They send you nothing when things stop happening.

Completion was defined as the task being done not the outcome being closed. The design got approved but the contract wasn't sent. The feature shipped but nobody confirmed the client saw it. The decision was made but nobody was assigned to execute it. Task done is not the same as outcome closed and conflating the two leaves a consistent gap.

What I now try to define for every significant piece of work at the moment of agreement not later: one owner, not a team. An expected outcome, not a task. A time window. And what happens if it goes silent.

If any of those four are undefined, the work is ambient. It might happen. It might not. You have no real visibility either way.

The more uncomfortable finding from the retrospective: we had a very active team during those 6 months. Lots of messages. Lots of tickets. Lots of meetings. Activity and output are not the same thing. You can have an extremely active team with completely stalled outcomes and the activity masks the stall until something blows up.

I ended up building a tool to handle the tracking and silence-detection parts of this. It's called Zelyx. But the pattern exists regardless of tools and the retrospective exercise alone is worth doing.

What does everyone else do for work that falls between tools? Is there a system that actually works or is everyone managing it manually?