Having worked in a company where no single team "owned" the monolith, the term "communally owned" tended to come up.
It was generally understood within the platform teams that if everyone owns it then in reality, no one owns it :)
This enforcement of communal contract is toil. The only way to enforce it without toil is via spending engineering time creating systems. Maybe they are dependency injection frameworks, maybe they are servlets, maybe it's refactoring, maybe it's dependency elimination, maybe it's migration, but it is all fundamentally planned engineering work that will come at the cost of other potential work and therefore be at the mercy of management's priorities. Furthermore this kind of work must be opinionated and have the backing of internal authority, because people will absolutely violate the communal contract to get work out faster, especially senior engineers with lots of clout.
From a managerial perspective, you plan work on some cadence and expect work to get done. The engineers who are most effective at doing what they said they would do are the ones who are most going to please you, and therefore the ones who are going to get promoted. All toil comes directly at the cost of this. In order for this work to be internally incentivized it must be done as part of the companies overall planning and reward system.
Remember that this communal ownership is over a commons (overall complexity), and just like cows over grazing a field and running out of food, engineers over produce complexity and run out of time (time gets spent pushing code, dealing with bugs, running tests, refactoring code, etc.). When individual incentives are sour, you must have a governing body regulate the system. Each cow is individually incentivized to eat their fill, and each engineer is individually incentivized to ship product asap, regardless of code quality.
Most damning of all to communal enforcement is that as the number of engineers scales up, any non-explicit contract will be unenforceable as the number of communal "enforcers" with reasonable/relevant scope disappears entirely.
The greater problem is that the ways to fail monolith specific work vastly outnumbers the way to succeed. Furthermore, the primary work involved is months to years worth of horrible unattractive refactoring. Then this is compounded by it being very hard to measure success. So you run into a situation that makes principal engineers run or look for the door. Rather than working on an actually hard problem, they would rather pad their resumes with increasingly complex novel work, further detracting from the commons. So not only is it an un-owned common, but senior engineer alignment is directly against work involving the root problem because no one in their right mind would be responsible or accountable for something with so few avenues to success.
Not only is senior engineering alignment individually against being directly responsible for the monolith, but managerial leadership is as well. You have infrastructure with infrastructure concerns, and product worried about shipping product, and then you have to ask where this monolith responsible team is. Pushing code, monitoring, capacity management, oncall, etc. are all traditionally under the infra umbrella. Business logic is traditionally under the product umbrella. So who takes responsibility for the monolith, the chief repository of business logic? A monolith is a marriage between the two entities. Each individual product team doesn't want to do monolith work, because it makes it harder to ship the features they promised. Infra doesn't want to do monolith work because it is business logic code that needs to be refactored. So no infra team and no product team will directly feel responsible. Senior managerial leadership is at the mercy of senior engineering leadership, and therefore also cannot claim responsibility for the monolith. If you travel up the management hierarchy, that leaves roughly 4 people capable of doing anything about this most critical problem. The CEO, who has ultimate responsibility for all problems, the VP of infra, who could choose to claim responsibility for this area, the VP of product, who could choose to claim responsibility for this area, or the CTO who is the most directly responsible person for solving this problem as the de facto mediator of product and infra concerns and responsibilities. The answer is probably inventing a 3rd VP responsible for the area between product and infra and giving them proper authority.
