> individuals can get sick, go on vacation, etc. having it be owned by a team creates resiliency from a people perspective.

Resilience against what? It isn't like teams make decisions quickly, an individual will get decisions done faster in almost every case, and if they are on leave right now its just slightly slower than a team.

For example, if you ask a team "can you get this feature in", likely they will come back at you a few weeks later. That isn't faster than an individual on leave, so I don't see what "resilience" even is here.

For most teams that I've worked in, I've chosen certain parts to guard and nurture into a better state. I'll recognize certain shortcomings that have a real-world negative impact and incrementally nudge the design and future decisions in that direction. At some point it will have arrived. Eventually people that are in non-adjacent teams gets to know that I'm the XyzService person. I do socialize the design and implementation changes and even distribute the work and write up thought/decision processes for the team to see. I'll eventually run out of challenging work and move on to another sore area with the team well capable of managing what they've got. If the process were to be interrupted at any time, it's generally not in any worse shape than it started, only failing to reach the desired end improvements.

Edit: My current pet project is eliminating a bad DSL which has led to so many bad implementations and near-identical but different copies because factoring aspects isn't well supported. I started with a PoC, then a Hackdays project, and now with that looking good, the team is willing to convert all of the codebase we maintain so that we can use normal programming language features like static typing and source navigation with easy to follow data flows.

well, maybe that explains why I've gravitated hard away from general-purpose backend work :)

I've had a great time on teams where folks can go off and build great tools/libraries/etc that others can use and adapt, without needing a whole team around them—ideally there's lots of collaboration, but it doesn't have to be formally structured

I guess the main difference is that you don't have to operate a tool or a library; if somebody has issues with it, they can patch the code themselves or simply adapt around it in their own code

I also enjoyed working on simulation and optimization problems for similar reasons; there's lots of direct business value, but there's enough slack around it that if I go somebody else can take a model over and maintain it without any issues

unfortunately lots of organizations do not know how to make library-style code "count" the same way a service or stateful component "counts"

We have a pretty strong culture of individual ownership, but each owner has at least one other person reviewing their PRs, usually several junior engineers contributing, design review at the team level, and oncall at the team level.

When the owner is away, the other people involved keep things moving. If they're away long-term or leave the company, we'll designate someone else to take ownership.