> Every dev is allowed to spin up their own service. Teams can self organize and self govern around business problems they feel like solving. The best teams are the ones that produce the services that product owners rely on the most to get things done.
Have you considered handover, people moving on, new hires, etc? One guy running one service sounds like entrenchment to me. You need, as a company, to ensure people are replaceable. One way to do that is to for example stick to one or two programming languages.
You cannot, as a company, afford to have your services be written in a dozen different languages by a dozen different people. That's a huge risk.
It’s a huge risk if the unit of ownership is “engineer”. It’s less of a risk, but still not zero risk, if the unit of ownership is a squad/team/whatchamacallit, because you’ll get more brains applied to “should we really use Haskell for this?” and are isolated from the one Haskell engineer quitting. (Teams do rarely quit together, but individuals leave all the time in comparison.)
It’s also a risk to force your entire company to use 1-2 languages (one of which is [practically for most] hardwired to be Javascript, so you get to pick the other one).
At some points in time, c, c++, php, perl, or C# would have been reasonable choices for web dev. Do you want to be leading a company of Perl experts maintaining a large Perl codebase right now? Doing it, I can say that even C# is painful when it’s your mono-language monolith. (Inertia in language cuts both ways.)
Have you considered handover, people moving on, new hires, etc? One guy running one service sounds like entrenchment to me. You need, as a company, to ensure people are replaceable. One way to do that is to for example stick to one or two programming languages.
You cannot, as a company, afford to have your services be written in a dozen different languages by a dozen different people. That's a huge risk.