Generally speaking on most software teams, one or two devs do most of the work, bear most of the responsibility, and it's a huge game of catch-up for the rest o

Generally speaking on most software teams, one or two devs do most of the work, bear most of the responsibility, and it's a huge game of catch-up for the rest of the team if they leave. The reason why this is is twofold. First, this is knowledge work, the main task you're doing is fitting stuff in your head. Once one person has something fit into their head, the benefits for the second person doing the work of fitting it also into their head is not nearly as much. So knowledge becomes siloed, and 'knowledge transfer' doesn't work because there's very little the person with the knowledge can do to speed along the process of another person cramming it into their head. Second, infrastructure become unavoidably, yet unnecessarily complex. Decisions about which software projects to use and depend on get handed down by decision-makers who never have to touch those projects themselves. An example from my current team is GitHub Actions. We had to throw away a working Cloud Build CI infra because they liked the pretty interface. But the rest of our infra is on GCP. This complicated the setup such that it was very difficult for other people on the team to build working pipelines. So the knowledge about how it all works gets further siloed into a few people, who find showing others how it works difficult, because of the complexity. In practice the people that know end up doing the hard complex parts for them, no knowledge gets shared, and piling on to the list of things the rest of the team has to learn once they leave. In larger companies, this is solved at the management level like you say. They'll pressure the devs to come up to speed faster as much as they can get away with, incentivize key resources to stick around. The root cause can't be solved at a management level because management can only manage, they have no insight into software complexity and team dynamics. In smaller companies, the resources for doing this are non-existent, it can only be solved through prevention. Not over-complicating the stack, avoiding endless churn. Proactively rotating devs onto other parts of the team to facilitate knowledge transfer. Doing it before someone leaves. Spotting silos and getting someone else in there to learn what's going on.