The principle is sound, but your managers' way of implementing it is stupid. Productivity shouldn't go down as a result of knowledge sharing, it should go up.
Because all I have are anecdotes, but all of my anecdotes are on the side of shared knowledge being heavily biased towards safety and consensus building demanding a lot of time. That happens even between two people that mostly agree, and only increase with more people or different opinions.
Of course, some times a bias towards safety is exactly what you want. But on informatics projects, that happens very rarely.
Once in a long while two people can have complementary ideas that make them faster. But it tends to happen more often when one is the clear owner of the project and the other is advising. Shared ownership seems to almost kill those chances.
My anecdata (at multiple companies) supports their opinion.
What matters is that there is a clear owner who is the voice of final decision. In most cases there is no objectively better way to do something, so having a person who is a tie-breaker is beneficial. Of course, they must be involved in actual coding, doing code reviews of other people's code and similar. And other people must review the owner's and each others code.
But, having an owner is not the same as having a bus factor 1. There should be an owner, but other people should know the project and the codebase enough to step in at any given time, even as (temporary) owners if needed. And this is only possible if they actually work on the project, even if the approach that the team (/owner) decides upon is not what they would pick.
I don't know what you would consider evidence but I've looked in-depth at 200+ companies now and as far as I'm concerned this is no longer up for debate. But feel free to see things differently, that keeps me in business. Disaster recovery is a trick that comes with very high fees and what are you going to do about it?
Me and my peers sharing WW2 knowledge at the water-cooler probably considerably reduced productivity at one of my jobs. Your work on a part of the application that I have no interaction with is just about as relevant. Sharing knowledge just in case costs time.
Practioners of the 'hero' model also feel that they have it right. And that's all true right up to the point that they don't and then it is up to other people get them out of their mess.
See also: documentation, testing, refactoring and all the other goodies that keep a large codebase maintainable.
You can always tell the documentation and testing of a shared / non-owned codebase, just like the code: it’s incoherent. A series of random people make random get-in-get-out local changes with no awareness of non-local effects or any kind of design integrity. It’s like Twitch Plays Pokémon.
Because all I have are anecdotes, but all of my anecdotes are on the side of shared knowledge being heavily biased towards safety and consensus building demanding a lot of time. That happens even between two people that mostly agree, and only increase with more people or different opinions.
Of course, some times a bias towards safety is exactly what you want. But on informatics projects, that happens very rarely.
Once in a long while two people can have complementary ideas that make them faster. But it tends to happen more often when one is the clear owner of the project and the other is advising. Shared ownership seems to almost kill those chances.