I think it is complicated because a large number of management jobs are "bullshit" (see [1]). I.e. they could be eliminated, and productivity would not be affected, or it could even be improved.
Remote work does an exposé on the usefulness of these roles. And of course, those holding them, would be eager for everyone to return to the office work theater.
Whether we hire a dedicated manager or have the responsibility rotate among teammates really depends on a bunch of factors both internal and external to the team / company.
Most people who get a job in America (can't speak for other places) are not interested in managing. It's too messy. If more doers took on management work - we'd be able to push out shitty managers. Until that happens though, my recommendation is to immediately move to a different team or company as soon as a shitty manager is installed.
There certainly are bullshit jobs and people doing valuable roles in bullshit ways, but Graeber’s claim that more than half of societal work is bullshit is also clearly bullshit, and not just because I read some of the book and sighed heavily before putting it down, but also because of claims like this that I didn’t see in the book but are in the Wikipedia page:
> duct tapers, who temporarily fix problems that could be fixed permanently, e.g., programmers repairing shoddy code...
To think that code can be “fixed permanently” shows a complete lack of understanding and insight into programming, and brings to mind the Gell-Mann Amnesia Effect - if Graeber is so wildly wrong about a subject I know well, why do I trust him on those I don’t?
MVP's are supposed to be temporary, that's a weird cherry pick. Regardless, code is contextual and relies on so many things other than its own quality at the time of that assessment being made that to say it's been fixed permanently, as if there's some Platonic ideal code that can be written, is, in my view, something I'd only hear from someone new to the industry or not in the industry at all, like Graeber. The job is about solving problems in the clearest way possible over time, not once. Managing change is of central importance. If your product is good, it will change. If it changes, bugs will inevitably be introduced. That's not shoddy practice or the fault of some poor architecture decision.
I imagine that the only bug that gets fixed "permanently" is in a product that nobody uses enough for it to need change. Like some failed MVPs.
I've been in the industry over 20 years, and in my experience agile steers everything to be MVP in the pursuit of velocity, even on projects where they are replacing an existing platform and there is no time to market benefits to rush it.
And it looks great at the start, the project is making great progress until people start to leave and the tech debt starts to kick in. By that stage all the "high performance" agile rock stars have pissed off to another company and left behind their legacy.
And then its death by 1000 cuts, things aren't logged correctly, no proper exception handling rather just do a print(e) and falling over, any integrations with 3rd parties aren't documented when they break and its just a mess.
There's always the human factor in capitalism. And with the human factor comes ego.
IIRC, Graeber roughly compares CEOs to feudal kings. You want more people under your rule as a metric of success. Also, the "king" often seeks to have a big "court" (top-level managers) to reflect their prestige.
The effect is cascading. The "king's court" members want their own smaller courts (second-level managers) and compete with their peers for power, as measured by the headcount. As we go down, unecessary hires will start to occur, only to justify a title.
And everyone involved in the theater has an incentive to turn a blind eye on the situtation.
It's complicated because a large number of managers haven't figured out how to manage a remote team.