Opening the book…
Shared ownership sounds collaborative and reliably produces neglect, because a responsibility split between two people is a responsibility each of them assumes the other is handling. Every important thing we run, a service, a customer relationship, a recurring process, needs exactly one name attached to it, one person who's accountable for it being healthy and who you can go to when it isn't. This isn't about that person doing all the work alone; it's about there being a clear answer to 'who do I talk to about this,' which is a question that comes up constantly and wastes real time when nobody knows. Single ownership also creates the pride and continuity that shared ownership lacks, because people care more about the thing that's clearly theirs. When ownership is fuzzy, things rot in the gaps, and the gaps are exactly where nobody's looking. A clear owner is a promise that someone is paying attention.
For each significant system, area, or process, name a single owner and make that ownership visible, so anyone can find who's responsible without asking around. The owner isn't the only one who works on it, but they're the one accountable for its health and the default point of contact. When you're the owner, keep an eye on your thing even when you're not actively touching it, and be the person who knows its state. When ownership needs to change, hand it off explicitly, with context, rather than letting it quietly lapse into no-owner limbo. Avoid committees for things that need an owner, since a committee is how you get the appearance of responsibility without the substance. And when something has no owner, that's a gap to fill, not a state to tolerate.
Some things are genuinely collective, team norms, the shared codebase's overall health, and forcing a single owner there is artificial. And a good owner builds enough shared knowledge that they're not a bus-factor-of-one; single ownership of accountability shouldn't mean single ownership of understanding.