I think you'll end up in one of two scenarios there. Either a) the devs and product owner will assume a bunch of the "management roles" as they self asses prior

I think you'll end up in one of two scenarios there. Either a) the devs and product owner will assume a bunch of the "management roles" as they self asses priorities and choose which issues/tasks to do next, or b) they will choose issues and tasks without any regard for "management roles". a) May work, depending on the maturity of the dev team (not naively measured by age or years of experience, although both those have some significant correlation to "maturity" in this sense) - and their alignments with the client requirements. This is certainly something I've seen work with remarkable speed and success with the right team solving a problem they understand and are motivated to get right. b) is likely top result in only "interesting" tasks getting done and "shiny new thing" architectural decisions and "resume driven development" happening - and client needs and expectation remaining unmet. Devs like to look down on "management" as a role, probably deservedly so given how much "bad management" is on display across the industry. But great management is just as much a "super power" for a team as having a great tech lead. The "10 x" dev myth has at least a basis in reality, there is without doubt the same kind of mythical unicorn manager also based in reality - people who's ability to multiply the effectiveness of they team is real and powerful.