Very much agree. As someone who has been involved in something similar to "self-organizing teams" in the past, I'll take a hard pass. The primary issue is that there are usually hard external constraints on the business (e.g. client deadlines) that make self-organizing teams a recipe for chaos and inefficiency.
I find a culturally-ingrained model of "servant leadership" works much better. For example, most programmers I know are happiest when they are programming. An ideal management chain would take care of all the other (often shitty) work so that the product team and programmers can just focus on building the product, and they are given the freedom to build that product in the best manner they see fit.
I have found that devs really only work well in a team using servant leadership style. Especially if the leader can't code and doesn't understand how software development is actually done.
There is an interesting anti-pattern that happens where the "alpha geek"[0] is actually leading the team and the designated manager isn't in charge at all. This can go well, or it can lead to disaster, depending on the personalities involved. I suspect that a lot of success stories from "self-organising teams" are actually succeeding by removing the designated manager and allowing the "alpha geek" to lead without having to fight about it.
[0] not a derogatory term, just a metaphorical take on the relatively common occurrence of developer teams creating ad-hoc hierarchies based on experience and personality.
I find a culturally-ingrained model of "servant leadership" works much better. For example, most programmers I know are happiest when they are programming. An ideal management chain would take care of all the other (often shitty) work so that the product team and programmers can just focus on building the product, and they are given the freedom to build that product in the best manner they see fit.